Letter to the Editor: Regarding the LSB (a response to Dennis Powell)May 17, 2001, 21:18 (34 Talkback[s])
(Other stories by Bob Bernstein)
Opinions expressed by contributors to Linux Today are not necessarily those of LinuxToday's staff or management.
By Bob Bernstein
To The Editor,
I've just read Dennis Powell's "How Distributions Can Succeed (and help Linux take over the world)". I remain (unsurprisingly, for those who know me) unmoved. First a quibble or two. I will shout a little: 1. "Failing this, create an exception for self-contained packages in /usr/local."
NO NO NO. /usr/local has always been BY DEFINITION the one area in the filesystem that distributions will NEVER TOUCH. Let's leave that alone.
2) "The existence of /opt as the parking place for things that sensibly call for isolation."
Not going to fly, at least not in the sense you want. See:
which is part of the LSB. It calls for /var/opt and /etc/opt. But /opt will not be what you want for good reason: what you want is a creature of your experience building KDE from source, and that is not a model to be followed for binary distributions. Basically, it resembles what we used to do with DOS packages!
Part of the problem is that you think in terms of a do-it-yourselfer compiler from source, but you aim to speak to the needs and purposes of distribution packagers. So, although you would like your new version of KDE to be under one directory in /opt - for your convenience - distro packagers aim to distribute _binary_ executables and their associated support files, and it is NOT helpful for that purpose to have each package or system under its own directory under /opt! That method went out when DOS went out. Besides, if you _could_ content yourself with a proper packaging system, such as Debian's, then you would discover that you would not need to have, say, all of KDE under one dir under /opt!
3) "Settle on a standard package management system."
And who is to decide which is the best one? Granted, this is not a question you take up, but it's there, and it speaks to the main fallacy of your one-size-is-best approach. No one packaging system can ever claim to have cornered the market on the best attributes of a package management systems. More is better. It's only in your imagination that a solitary, mythically ideal, packaging system takes form and carries on untroubled by other approaches. Frankly, this is the most frightening of your proposals, if only because there is good reason to suspect that, market forces being what they are, we would - IN GOOD MICROSOFT FASHION - get stuck with the inferior technology (rpm, of course) solely on account of its market share!
I must say it continues to gall me that you see fit hold forth on the need for ONE packaging system when you have absolutely no experience with one of the major contenders for that job. I would hold that you do not know beans about packaging systems, because all you have ever used is rpm. You have no idea what a proper system can do for the average user. Since you don't know what the possibilities are, you are not in a position to dictate a solution.
4) "It has to be one that traps and includes the results of "make install."
(Let's avoid the pitfall of wondering out loud what a packaging system would look like that did NOT do that!)
But, again, you fall victim to the shortsightedness of a do-it-yourselfer who thinks his experience is valid for packaging binary distros. What is obvious is that 'make install' belongs to the world of source code, not the world of binary distributions. And yes Virginia the two are miles apart. 'Make install' takes for granted the presence of a lot of a lot of things that will not be present for the installation of the binary package, and similarly can produce a lot of things that will not be needed for the binary package. Also, for packages such as kdebase, 'make install' is really a succession of 'make install's. There is a fair amount of arbitrariness in what lands in kdebase, and what, say, lands in another kde tarball. So it _makes sense_ to break up these huge tarballs in order to fine tune the installation of the binary editions of their constituents. It also makes sense to break them up thus in order to facilitate upgrading binary packages as and when the upstream source gets upgraded.
Finally, you dodge the really hard question: how is this "absolutely iron-clad" (no mincing words there, huh?) LSB supposed to become such? Everything you write reeks of coercion. You seem to have a blind spot about all this. "Iron clad"? How about "Iron Cross"? It's as if your authoritarian evil twin has taken charge on this one issue!
Of course, all talk of "what Linux needs in order to survive" is just so much self-serving, self-important poppycock. You guys (meaning you and Kevin, mostly) take yourselves much too seriously, and as a result you are not sensitive to the irrelevance of your commentary to how the history of this thing is playing out. Linux evolved. It was not managed into existence. The minute it falls victim to management, especially management by journalists (or, in your case, reporters), it indeed will fall victim. "Free" means something. "Open" means something. Either learn to tolerate Linux evolving freely and openly, or continue to blow hot air about what "Linux needs"!
Frankly what Linux at this point needs is a few good historians who can eke out how IN FACT Linux got to where it is. Then _maybe_ we might be able to crack open a few Becks and muse quietly amongst ourselves what mayhap "Linux needs."
Right? To repeat what I've already said privately to Dennis:
"But hey, aren't all these different sorts of TV sets confusing, and aren't they cutting into the possible commercial success that TV could have if only it unified its user interface?"
As much as I distrust the commercialization of Linux (and similarly think the GPL is the way to go and that the Open Source Inititative _hurt_ Linux by encouraging commercialization) I would not want to see what you propose come to pass. I think it might stand a good chance of killing Linux off.
Unix is fragmented in its implementations only. The variety of implementations serves to ensure the ongoing health of Unix-the-thing-in-itself. It does so by ensuring development on a variety of fronts, by a variety of groups. And, Unix continues to generate profits for most of these groups.
The now-countless distributions of Linux are here to stay. This wonderful OS _and its license terms_ inspire folks to go out and roll their own. This is A GOOD THING. The LSB is also a good thing, but it is designed to serve as a benchmark and beacon, not as legislation. If it's done well, then it will only benefit a distribution to be able to tout itself as "LSB-Compliant".