.comment: Can Linux Grow Up? - page 3
A Muddled Mess
As I talk with people, I hear more and more frequently that Linux has reached the point where the open community model of development falls apart. People in a small community can agree on what goes into a particular application, though without some final responsibility for decision making, this, too, can fall apart. The kernel is great and getting better in large measure because of the talented people working on it--but also because Linus has final say as to what it contains.
Deciding what makes up a Linux distribution is
more than any one person could or should handle, but that's a decision that's
long overdue. Yes, the FHS does a great deal toward this, but not enough, and
with no teeth, and slowly. I'm thinking more of a body, living and active, that
establishes the specifications of a Linux distribution. If that body decides
that Mesa belongs somewhere in the
/usr/X11R6 labyrinth, fine. If it is decided
instead that it goes in
/usr/lib, fine, too. Much is made of POSIX compliance,
and that is a good thing. But what we also need is Linux compliance. The body I
propose would specify a Linux distribution, if not in particulars then in
sufficiently detailed description that no one, distributor or programmer, would
have the slightest doubt where files should go and, if they are improvements on
old ones, what they should be called--same name if backward-compatible,
different name if not. Use of symlinks if absolutely necessary, but otherwise,
no. Symlinks are a good thing, used properly. A gin and tonic is good, too, but
when you're having them for breakfast, there's a problem.
I'd further imbue this body with the power to declare distributions and programs Linux-compliant and Linux-noncompliant. Given the power that the FSF stamp of approval has displayed, this would probably be enough to make compliance a practical requirement.
This idea will raise the feathers of many in the community; it is, after all, a certain nonconformity and rejection of authoritarian standards that brought many to Linux in the first place. But that not need be a problem. Every program in Linux has some kind of organization -- that's why it runs. It recognizes some standards, too--it was written in some language. Any true anarchist would of course be free to write his own operating system and applications; any true nonconformist could, or get Linux and put everything in one big directory and carefully symlink all the files into the Linux hierarchy.
How to establish such a body? Beats me, though I think that it would be useful to draw upon the experience of some of the companies now involved with Linux who have other experience in bringing operating systems to market. IBM knows a thing or two about this (let's not include their marketers, though), as does SGI. There are others. I do not propose giving them control, but I do propose tapping their experience. There ought to be someone from among the upper echelon of kernel people, certainly, and someone from XFree86; several others selected in a way that I do not know. Jon "Maddog" Hall would be a natural (I'm sure he's eager to hear new suggestions as to how to spend his time); and while the companies that have become involved in Linux should not have control, they shouldn't be excluded, either. Who do I think should be excluded? For a start, anyone from a particular distribution. This is where the conflict would become too great.
Is this a draconian proposal? Some will say so, and there's a good chance that they are right. But the alternative is worse: the organizational mess that Linux has in some ways become will get worse, and distributors will apply their own standards. The forking of Linux will become more pronounced, and it will ultimately fritter away into Unix-like inconsequentiality.
It's time to discuss this seriously, and then to bring it to pass.
Oh, and by the way. If you're still looking for
tdfx.o, you can find it, once you've built XFree86-4.01, in your build
I know. You were going to look there next.
- 1Linux Top 3: Alpine Linux 3.4, deepin 15.2 and Linux Lite 3.0
- 2Linux 4.7 Set to Boost Live Patching, Security and Power Management
- 3Linux 4.6 Charred Weasel adds USB 3.1 Support
- 4Linux Top 3: OpenIndiana 2016.04, Ubuntu 16.04 and Debian's New Leader
- 5Linux Top 3: KaOS 2016.04, TurnKey 14.1 and pfSense 2.3