Re: "Why" Debian Core Consortium ? Why not UserLinux? Why not Debian?
On 8/24/05, Benj. Mako Hill <mako@debian.org> wrote:
> <quote who="Branden Robinson / Debian Project Leader" date="Wed, Aug 24, 2005 at 04:18:16PM -0500">
> > Just out of curiosity, what interests do you think the DCC Alliance
> > has that aren't in ours? If you don't know, have you asked?
>
> The goal of the project seems to be create a large binary-compatible
> core upon which folks can certify their software. Basically, this is
> really only useful to proprietary software vendors.
And I for one would be sorry to see the name "Debian" attached to this
"golden binaries" premise. What works over time is a commitment to
ABI compatibility and to fixing things when they break, not sharing
binary needles around so everyone gets the same disease at once. Even
Microsoft has gotten that clue by now; they deliberately reshuffle a
bunch of undocumented ABIs with every service pack, and vary them
across their OS product line, so that code that doesn't play by the
rules blows up promptly.
This is for the very good reason that code that doesn't install and
run unaltered on builds done today by several different build teams
will probably fail on tomorrow's, or next year's, supposedly
ABI-compatible security-bug-fix build anyway, even if it's done by a
single centralized team. If an application that uses libcurl doesn't
consistently work right across differently optimized OpenSSL-enabled
builds as well as a GNU TLS alternative, then it should probably
bundle its own libcurl instead of gambling on changes in distro
tactics over time. If a network backup daemon doesn't survive alien's
conversion from deb to RPM, then I'm probably not going to gamble on
being able to use the same installer bits on sarge and etch, or even
on sarge-today and sarge-six-months-from-now. Better for the vendor
to learn this in the interop lab than for the customer to learn it
when a weekly apt-get dist-upgrade goes horribly, horribly wrong.
Horizontal reproducibility across distros is a lousy proxy for
longitudinal reproducibility over time, but it's the only proxy we've
got. Take the diversity away, so there's no outside evidence about
whether it takes a Ph.D. and a bunch of trial-and-error to make a
non-broken build of a given library, and how does an ISV choose
between functional alternatives? Answer: they flip a coin, and the
first time they get burned badly, they go back to statically linking
and/or supporting only "Enterprise Linux" distros where they can foist
the problem off on the OS vendor. If a motley crew of Debian
derivatives wants to band together and go down that road, that's fine;
but please don't call it Debian so-and-so, because it's antithetical
to "we don't hide problems".
Cheers,
- Michael
(IMHO, IANADD)
Reply to: