> > 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
