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 "

Go, LSB!

[Anonymous Coward]

I'm glad the LSB doesn't make any standard a "reference implementation" like Perens and some of the Debian people are talking about. That's an inherently dangerous thing, because any distribution will always have "metabugs" (meaning, bugs inherent to the distribution due to flaws in the distribution's own design goals). Look at all the flack recently on BugTraq about Debian, Apache, and requiring /usr/doc to be web-exported, for example.

Aren't they standardising the wrong sort of thing?

[Anonymous Coward]

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.

Uhh...

[Bill Currie]

NOTE: I'm speakinf for myself, not Daniel Quinlan.

I think that in stating that "GLIBC 2.1 is the standard", Quinlan was meaning that gblic 2.1 will be used as the basis of what libc.so must provide. ie what functions are exported and what they do (ie glibc 2.1's functionality will be used as the standard, not glibc 2.1 itself). This means that so long as all of glibc 2.1's functionality is provided, any libc can be substitued, even (shudder) M$libc 6.66 :P.

It would be the height of stupidity to specify an actuall library version. Instead, as is done for ANSI C in general, the functionality of the library should be specified. This nicely allows for future growth. Anything new will just be extensions and can eventually be folded back into the standard once those extensions have `stabilized' as such.

Re: Like the coverage, but...

[spacey]

It's always a little freaky when someone gets roasted in public, but Bruce has participated in a couple of visible public conflagurations in the last year. In fact every project I've been aware of his involvement in has resulted in a personality conflict in spite of his obviously good intentions. I have not been "present" at any of his departures so I don't really know what the ins and outs were, but I don't think I could bring myself to join him in a project.

I do wish that they got a few quotes from suse, caldera, and slackware - caldera is taking a big pro-standards position, and I'd like to see if even they would lock themselves into the LSB or if their position comes down to about the same as redhat.

-Peter

Learning not to bash

[BadlandZ]

Here's a start [freshmeat.net], learn to respect your brother *NIX.

Like the coverage, but...

[BadlandZ]

Man, I didn't like reading it.

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.

glibc

[thomasd]

As I understand it, the glibc folks now have a version number on each symbol, so, at least in principle, they'll be able to make all future releases work okay with 2.1 binaries, even if they end up making fairly major changes. At least, that's the principle, I guess now we have to wait a while to see if it actually works that way.

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.

Not Fair

[jpick]

It seems to be based largely off of the FreshMeat editorial I wrote just after you dropped out of the LSB.

I was scheduled to write an article on the LSB - but by the time I was going to write it, it had disintegrated.

So, I wrote the article to explain the backroom politics that were going on at the time so that people could understand where the LSB was.

Subsequently, the LSB team picked up the pieces and everything was nice again.

When I wrote the editorial, I assumed it would only have a half-life of a week or so, and that only a few developers would read it.

If I had realized that the little editorial would have had such a long lifespan, I would have refrained from any personal references. That type of thing is better left in email on the mailing lists, where it does have a short lifespan.

I agree with Bruce that it isn't fair - it's old news that is no longer particularily relevant, except for historical interest.

Cheers,

- Jim

Not Fair

[Bruce Perens]

When an article mentions me unfavorably several times, it would be responsible of the reporter to contact me and ask me for my side. I was in Iceland last week, and managed to log in daily and answer several reporter's emails, but I didn't get any questions about this one.

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

glibc compatibility

[itp]

Hopefully, this won't be too much of a problem. The 2.1 release of glibc, as I understand it, finally introduces solid binary versioning, so that we won't have interoperability problems or stuff like the infamous `__register_frame_info' crap to deal with.

Internal symbols are also shielded much better, so that people like StarOffice (who ignored repeated requests not to use internal symbols of the library which were not going to stay the same from release to release) won't be able to write such stupid code in the future.

--
Ian Peters

Good article, important issue

[itp]

This is exactly the kind of article I've hoped for from LinuxWorld for a while. I know that they've got to serve a diverse market, and so some of their articles come across, to us, as preaching to the choir, but it's good to see some that address the Linux community directly.

It's a shame to see the article above this one (" Linux is a waste of time? [slashdot.org]") getting so much more attention. It's obvious flame bait, the kind of FUD you can hear anytime you want. This story is much more relevant to the Linux community, but I guess it's easier to be defensive than it is to be introspective.

I think this article does a good job of pointing out the various interests at work; where they align, and where they collide. I especially think Bob Young makes some good points about Red Hat's position in the marketplace. Many people seem to judge them on the potential trouble they could cause, rather than examining past actions. As far as I can tell, Red Hat is one of the best (commercial) distributions as far as contributing back to the Free Software community. I hope that the level or paranoia in the community doesn't end up hindering us more than is necessary.

I remember this issue was really hot a couple of months ago, and I'm glad to see the level of rhetoric toned down considerably. Perhaps it's time to go back and read some of those old Freshmeat editorials again, with a more open mind. I think that this effort is at least as relevant, or more so, as it was when it was first proposed, so I hope we can maintain a focus on progress without things getting out of hand again.

--
Ian Peters

Standards and Freedom : Oil and Water? -- No

[itp]

I don't think of them as oil and water, impossible to mix. I tend to look at it as a curve, which we'd like to maximize. I'm the first to speak up for freedom, which is what I value most about the Free Software community. But there are some things that, if chosen appropriately, won't hurt that freedom.

The C library is a good example. For a long time, GNU/Linux has just operated on an understanding of what the current targets are. With increasing commercial interest, it may become necessary to point out to these developers how such things work. Suits like standards, and acronyms, so we get something like the LSB.

Similarly, I've had commercial packages trample all over my file system, rather than respecting the understood way things work. Perhaps having a good, widely accepted FSH will help this.

The difficulty is in making the standard acceptable to hackers who are already used to the way things are. I think Alan Cox makes a good point, when he emphasizes that a smaller standard is much more likely to succeed than a larger one.

--
Ian Peters

Uhh...

[craw]

A set of standards does not perclude the inclusion of other libraries nor is it a stagnant set of rules. With time, new additions or changes to the standard set will occur. If done properly, lots of the older standards will still be included with a particular distro. However, these older stuff will likely be declared as being obsolete; usually this means that eventually the obsolete stuff will be eliminated.

When SGI changed from IRIX4.X to IRIX5.X, the internal binary format of their libraries changed. To help ease the transition period when one had to recompile all of their software, the older libraries were still distributed (optional installation). Now with IRIX6.X, their are three sets of libraries (old 32 bit, new hybrid 32/64 bit, and 64 bit). Quite a mess especially when one also considers additional stuff to handle the various MIPS processors. However, old code still works.

You are correct about having the standards determined by consensus, not be decree. However, that is what the ongoing work to establish a standard is all about.

Standards and Freedom : Oil and Water?

[fprefect]

If everyone followed the "standards", what would be the point of Open Source? Aren't we talking about the freedom to take software in a different direction? Standards help software interoperate, freedom helps software evolve.

By allowing vendors to customize distributions, you allow them to move faster than a committee or standards group, but you also open the doors to fragmentation.

You can't have one without the other.

Not Fair...probably not

[CodeShark]

Agreement that Bruce's side of the story really should have been told in this article, which was otherwise well written and thought out.

My commendations to Mr. Peren's for his decision -- by "getting out of the way, as he phrased it -- he allowed the messenger to not interfere with the mission. Perhaps the LSB will not be what Bruce envisioned it to be , but as the article discussed, non-splintering of the OS is a critical issue for any/all Linux application developers wanting to reach the entire community.

This co-operation, people is what allows Linux to move forward. Take note -- end the Distro flame wars!

There IS freedom!

[RichiP]

You have the freedom to follow the standards or not. 8^) Personally, I'd follow the standard if only to be assured that more people will be able to use my program. Aren't YOU glad that people are standardizing to autoconf, automake, etc.? ;^)

Uhh...

[JoeLinux]

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

Aren't they standardising the wrong sort of thing?

[Alan Cox]

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.

What about a handheld standard??

[Cptn Proton]

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.

Same place

[Telsa]

It's in /etc/rc.d/init.d in RH 5.2.

Unfairness ruined article

[rana]

The Bruce-bashing marred what was an otherwise well-written article on some important, controversial issues. Bruce deserves some credit (or maybe lots of credit) for bringing up important issues like the need for a standard base, and, iirc, the need for end-user friendly linux distros, etc. Unfortunately for him, people often weren't ready for his ideas and were unpleasantly shaken from their complacency. I think the challenge presented by Bruce and Debian while he was leader helped push RedHat more to the GPL side. I still hope something will happen with the open hardware project.

Don't worry, Bruce. It looks like things are turning out more or less as you has hoped. People with vision, who want to change things, are often not popular.

LSB Fears? Some thoughts

[wilp]

From the looks of the latest lsb-spec mailing list [debian.org] archive, I don't see much of a reason to be afraid of one distribution ruling them all. There seems to be some intelligent (albiet slow) discussion going on there.

Everybody has thier view of which way is best, which keeps the innovation and competition going. But why compete in linux distributions on things that are clearly neutral? This causes the distributions to diverge in areas that have nothing to do with innovation; it only makes it harder to communicate. See the discussion on runlevels in the above link.

I do not agree with the statement that Debian makes a good reference implementation because of "...its noncommercial status". If Debian makes a good reference implementation, it had better be for a better reason than that!

Overall, good article. I think this kind of discussion is far more progressive and relevant than MS-bashing.

-wilp

Software Management

[stor]

Whilst standardising on certain library calls etc... could be beneficial, I'm a little worried about software management.

At the moment, RPMs are not really completely binary compatible across distributions... and .debs are really just for debian.

But we've got Debian using .debs, other dists using .rpm and ol' slackky happily without either.

There will have to be some sort of decent resolution to this, as the whole point of this standardisation thing, as I see it, is to be able to get more people working on applications for Linux, safe with the knowledge that if they develop it under Debian or RedHat, their software will be able to install safely and easily on any other distribution.

Also, this system has to cater for people wanting to release binary-only apps, and/or source that will compile on any distribution.

Some ideas:
- Work on one standard package management scheme. Naturally this will be free, etc... the spec, everything... Maybe go so far as to produce a "standard installer" that has a ncurses, plain ascii and X frontends. Make this a no-brainer. Installing/maintaining software must be simple. (Configuring and optimising a server is a different thing. I'm talking about "Ohh, I got this great new office app., I'm going to install it on my box and all the boxes in this office!", the installer oblivious to whether the boxes are running debian, suse, rh.
- Implement into the package management scheme or some derivation of package mgt. the ability to list and maintain all installed software on the box. Not every binary, every library, etc... every _app_ that's been installed, every _game_ that's been installed, you get the idea.

Software management must be a no-brainer.

I mean, people new to Linux have to learn about:

- multiuser environments.
- where things go. "Mommy, what's a /usr/local?"
- what a library is.
- why things break when you upgrade a library, and how to fix. (Although binary compatibility across certain libraries is obviously being worked on w/ standardisation of glibc2.1.)
- why you shouldn't be running as root all the time. "But I can't _DO_ everything when i'm not root!"

They don't need to be bummed by a difficult software installation. I have advanced from tech. support, but I remember people who had difficulties installing our software. Yes, I work at an ISP... software mostly outsouced of course and most problems were more Windows-related or hardware related, it's pretty simple software but software always has the potential to screw up, and it did. It is terribly frustrating to not even be able to give the software a go because the darn thing won't install. And these people were having problems installing the software under 95.

Linux support
============

"No sir, you must be root to install this..."

"I beg your pardon?"

:-)

I'd hate to be the tech supporter upgrading some newbie dude's glibc.

Remember also all the naysayers that we're talking about standardising distributions, this is to facilitate compatibility between distributions. So all the distributions standardise on some stuff, that doesn't mean _YOU_ have to standardise on it. Linux is pretty darn modular, the arguments against standardising dists. are for the most part moot. Also people in the Linux community, unlike other communities, tend to choose the technically superior thing... software evolves... so probably will the standard, over time. You increase the revision...

Cheers

Stor