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
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
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
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
4) "It has to be one that traps and includes the results of
(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
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".
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.