On 8/24/05, Benj. Mako Hill <[EMAIL PROTECTED]> 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)