Re: Linux Core Consortium
> > me
> Ian Murdock (quotes out of order)
> > If the LSB only attempts to certify things that haven't forked, then
> > it's a no-op. Well, that's not quite fair; I have found it useful to
> > bootstrap a porting effort using lsb-rpm. But for it to be a software
> > operating environment and not just a software porting environment, it
> > needs to have a non-trivial scope, which means an investment by both
> > ISVs and distros.
>
> That's precisely what we're trying to do. :-)
The context of my remark was your claim that "by definition, the LSB
codifies existing
standards, i.e., things everyone already agree[s] with". If that's
true, then the LSB doesn't represent a non-trivial investment on the
distros' part, and no one should be surprised that the ISVs don't care
about it. Agreeing on a set of LCC binaries would be non-trivial for
the distros but its entire justification would be that it's trivial
for the ISVs. That would be fine (on the assumption that ISV success
is what matters) except that I don't think it will work.
I respect your efforts to make commercial software on Linux more
viable. But be careful what you wish for -- you might get it. Make
it impossible to remove implementation warts because the binaries are
more authoritative than the specification, and pretty soon you have a
thriving ISV market -- for antivirus software, system repair
utilities, interface hacks, and virtual machines to graft
unreproducible system images onto new hardware.
> Wishing the ISVs operated a different way doesn't really get us any
> closer to a solution..
You seem to have missed my point. I don't "wish" for ISVs to operate
a different way; I cope daily with the way that they _do_ operate, and
am distressed by proposals that I think will make it worse. In my
opinion, catering to poor software engineering practice by applying
Holy Penguin Pee to a particular set of "core" binaries is unwise. I
would have expected you and Bruce to agree -- in fact, to hold rather
more radical opinions than I do -- so I must be missing something.
Here's the case I would expect a Debian founder to be making.
In short, I don't think that ISVs can afford for their releases to
become hothouse flowers that only grow in the soil in which they
germinated. It's understandable for ISVs to pressure distros to pool
their QA efforts and to propose that this be done at a tactical level
by sharing binaries. But I think that's based on a naive analysis of
the quality problem. Inconsistent implementation behavior from one
build to another is generally accompanied by similar inconsistencies
from one use case to another, which don't magically get better by
doing fewer builds.
The requirement that software run on multiple distros today serves as
a proxy for the much more important requirement that it run on the
same distro today and tomorrow. It's a poor substitute for testing in
a controlled environment, exposing only functionality which is common
denominator among distros, but that takes skill, understanding, and
labor beyond what ISVs are willing to invest. In practice, there are
still going to be things that break when bits change out from under
them. But it makes a great deal of difference whether an ISV is
committed to fixing accidental dependencies on binary internals.
Suppose I want to use an ISV's product on Debian myself, or to support
its use on systems that I control. Usually the ISV's approach to
Linux is to list a set of supported RedHat and SuSE distributions
(often from years ago) on which they have more or less tested their
software. That gives me some idea of what its de facto environmental
requirements are. Then I reverse engineer the actual requirements
(shared library versions, which shell /bin/sh is assumed to be, which
JVM installed where, etc.) and select/adapt Debian packages
accordingly. This is a pain but at least I get to use competently
packaged open source code for all of the supporting components, and I
can fix things incrementally without expecting much help from the ISV.
If I'm going to go to this trouble, it's actually to my advantage that
Debian packages are completely independently built -- separate
packaging system, separate configure parameters, separately chosen
patches. I find a lot of things up front that would otherwise hit me
in the middle of an urgent upgrade -- calls to APIs that are supposed
to be private, incorrectly linked shared objects (I do an ldd -r -v on
everything), code built with dubious toolchains, weird uses of
LD_LIBRARY_PATH, FHS violations. Sometimes ISVs even appreciate a
heads-up about these problems and fix them in the next build.
Given this strategy for ISV handling, obviously I prefer the ABI /
test kit approach to distro convergence. For one thing, if commercial
distros cooperated that way, it would make the reverse engineering
easier. More importantly, any ISV which publicly buys into ABI-based
testing will immediately gain credibility with me in a way that I can
explain to others in terms of robustness against security updates to
the supported platforms, without bringing in the issue of distro
defects. Anyone who has supported, say, a CAD application on Solaris
understands that a patch-and-rebuild cycle often introduces accidental
changes to undocumented properties of OS-provided binaries, and a
vendor commitment to fix its product when an ABI-neutral change breaks
it is a Good Thing.
When the support chain is more indirect, or when packaging tools which
have to work under conditions it's hard for me to test independently
(e. g., a hardware RAID monitoring utility), I have to do it the ISV's
way. So I go with a chroot of the last commercial Linux distro that
more or less worked like an open source project, namely SuSE 8.0 (not
that "enterprise" crap). (Getting hard to find a mirror now, though.)
When that stops working for me, I guess I'll start looking at Fedora
chroots.
Don't get me wrong; there's a place for commercial distros -- a place
which in my mind is labelled "Solaris Lite". They're commercial
branches of a shared code base, just like vendor UNIXes and most of
the BSDs. I've been happy enough working with both open and closed
source code, using open source tools, on Solaris and many other
vendor-supported OS's, including RedHat, SuSE, and Mandrake. But I
don't consider these distros open source any more, and haven't since
well before RedHat started playing trademark games. (FreeBSD I would
consider open source, though; and there are some other Linux and BSD
distros I don't know well enough to judge.)
My criterion for open-source-ness in a distro is, can I take control
over the scheduling of incremental changes to central components --
kernel, toolchain, glibc, packaging and installation tools -- without
effectively forking the distro and taking on the entire support load?
There was a time when I felt confident doing that with RedHat, but in
retrospect I was just lucky not to hit the bad times.
Here are a few things I dodged by exercising my own change control,
with the help of good fortune and a tendency to overreact when I first
stub my toe:
- early 2.4 release kernels with broken subsystems merged in (I
froze at 2.4.0test9 and did my own ATM and netfilter merge work, and
didn't move from there until 2.4.5); needless to say, I have
approached 2.6 (and backports from 2.6) with extreme prejudice, so I
missed out on rmap VM pathologies and broken NPTL / TLS backports;
- the gcc "2.96" fiasco -- I happened to see Linus's comment
archived at http://www.uwsg.iu.edu/hypermail/linux/kernel/0012.1/1252.html
when it was first sent (except for trial builds, I didn't leave 2.95
until 3.2.2 for C and 3.3.2 for C++, so I actually skipped several
fiascos);
- early glibc2.3 (I tried it the first time it hit unstable, hit
pthreads weirdness, immediately reverted to the last Debian 2.2.5 +
fixes from the tip of the 2.2 CVS branch, and waited another year
before trying it again);
- rpm binaries built against broken Berkeley DB versions (for
backwards compatibility of on-disk format with SuSE 8.0, I built rpm
3.0.6 against the working DB 1.85 emulation in Debian glibc; I
bootstrap chroots from the outside); sticking to RPM v3 has also saved
me the kind of agony documented in the Debian changelog for the rpm
package.
Obviously most IT shops don't have the skills for self-reliance (or
have other priorities for the use of these skills), don't know how to
(or don't have the time or the desire to) judge the competence of a
third party to fix and adapt to their requirements, and therefore
don't mind that they have no recourse but to call the vendor when
something breaks. They pick a commercial Linux distro and treat it as
a sort of low-budget UNIX clone. Sometimes they find out that, while
you don't always get what you pay for, you rarely fail to pay for what
you get, sooner or later, in one currency or another.
Cheers,
- Michael
Reply to: