Slashdot Mirror
Great Linuxworld article on the LSB and Red Hat
Marc Merlin writes "After Red Hat has been called the next microsoft
by several, and after some people saying that
Red Hat has not reason to follow the LSB (Linux
Standards Base), this
Linuxworld article should
hopefully give a better view of the situation, and
it also gives a nice history of the LSB "
It sounds to me that any document with 'the standard library shall be glibc 2.1' can't help but restrain innovation; what do you do when glibc 3 comes out? ('change the standard' is Not The Right Answer, unless the standard is made to have specific regions for changability in it).
I think you probably want to end up with something like the PC standard that Microsoft argues for, where the base level changes annually to keep up with new technology; yes, PC does eventually reject old technologies as obsolete, but I think that's probably more important in OSes than even it is in hardware.
First, they nailed Bruce to the wall.. Ouch. Least the guy had the guts to try it. And butt heads with a lot of people in the process. Many would have given up long before him. Without Bruce, it never would have started, and definately not got the attention it did. Personalities clashed, goals got fragmented, and Bruce POLITELY resigned and handed over the reigns, then got flamed hard, and flamed back. Overall, he does diserve MORE credit for what good he did that what I read!
Then the Red Hat myth. Eeek.. They quote a few people, including Bob Young, and don't really get anywhere. Simply said, "Red Hat supports it, but just like everyone else, refuses to handcuff itself in the event it sucks." But over and over, in more vague spins... Not really making the point as clear as they could have.
Quinlan, the hero... Well, k, maybe. He is. But, such a spin on it.
I like the coverage, but it was a bit lop-sided, and it didn't quite give it the "Positive" feel I wish it would have.
The point of the standard is to say that everyone should be using at least glibc 2.1. Or else. Which is fair enough -- there are still a lot of libc5 boxes knocking around, and having to support those is getting to be a pain.
The LSB was meant to be a binary collaboration between all of the distributions, not a standard distribution from Bruce Perens. There's no reason for Caldera and Red Hat to work individually on "sysvinit" when they can do so together - the package doesn't distinguish their distributions from each other, and they could use the time they saved to work on things that do distinguish their distributions.
I tried to get Red Hat on board. They opted not to sign on.
When it became clear I didn't have a consensus, I got out of the way. I've been careful to avoid criticizing LSB since then, as that would do no good for Linux.
Bruce Perens
Bruce Perens.
I think the article is very true when it says that Red Hat can't hijack the LSB. But I think that "GLIBC 2.1 is the standard" is stupid. If it had been something like, "The GNU libraries will be standard" or even a basis for finding the next common library, it would have been a little more reasonable. Like, what happens when GLIBC 3.0 comes out? Break LSB? (I prefer Linus Standard DISTRIBUTION, personally. :) ) In that case, if LSB is going to be broken every time that something new comes along, it won't be very powerful, now will it? It will Microsoft innovation, and limit people's choices.
I think that certain guildlines as to places to store things will be helpful, especially for new users (I.E. all config files go in etc, network stuff in rc.inet1, etc.) but sometimes they aren't followed, which starts a little confusion, (I.E. SysV-style config stuff in Red Hat, and BSD format in Slackware.) Being a moderate Linux user, I can see the reasoning behind wanting a standard way of doing things. By the same token, part of the advantages of Linux is its ability to change to each individual user, right down to the X server front-end you decide to use. So, choice should be available.
Libraries should be decided by popular concencus, not by decree. That is the essential of the Cathedral Vs. Bazaar essay. when you have a commitee deciding things for everyone, you have the first brick of a Cathedral. Fair though it purports, it still will not help unless it can be flexible to support the popular opinion of the people. We need a revival tent, not a Cathedral. And for that, we need lean, flexible poles. LGPL the stakes needed to provide the tension needed. The advantage is that many more people can be covered, and all can participate. Deciding by popular concencus also avoids code forks, as the people who can make it better, faster, easier will survive. When you have a commitee saying, "GLIBC 2.1 is the library you will use", and someone comes out with a kick-a@@ library, what are you going to do? You have two options: Break LSB, or go with the crappy library. Both hurt Linux. I mean, GNU recently decided to change official COMPILERS for goodness sakes (A good decision was made in that case, I might add. LONG LIVE EGCS!!) When you have that radical of a change, anything is possible. That is why Linux will continue to code circles around a certain Redmond-based Company: We are too damned fast for them to compete. So, we need to be able to switch anything as it becomes better. Just make sure everyone can use it readily, and Linux will continue on its meteoric rise to the top.
...What goes up must come down. Ask any Network Admin
Using glibc2.1 as the standard reference is being done because glibc2.1 closely follows the actual POSIX and unix standards. That makes it much cleaner and easier to specify the paper reference as it will say "xyz function performs as per SuSv2 with the following additions". It doesn't mean people will have to use glibc 2.1 either just something functionally equivalent and binary compatible.
It seems to me that it would be smart to work on a subset of the LSB in paralell to the full-scale Linux. Sort of a 'Linux CE'.
As mobile and space constrained applications become more prevalent it seems that it would be advantageous to have such a standard.