Why Aren't More Distros Becoming LSB Certified?

mydoghasworms asks: "I have done much thinking lately about Linux Standards Base. The idea makes lots of sense: Adopt a standard which will ensure that if some piece of software is compiled on one LSB-compliant system, it will run on any other LSB-compliant system. This would be great for members of the general public who are looking for an alternative to Windows, don't want to pay for Mac, but are looking for a platform where installing and running software is as easy as on the platform they are used to. Seen in that light, if LSB lives up to its promise, it could be the step in Linux's evolution that could see it adopted by the general public. That leaves the question: Why is LSB not seeing greater adoption?" "Is it because it is not marketed well enough? Is the certification process too difficult? Are there perhaps technical challenges to LSB certification not often discussed? If people agree that LSB is in fact what Linux needs right now to ensure widespread adoption, what should be done to create awareness of LSB? Should communities developing Open Source/Free Software projects be encouraged to provide LSB binaries? Your input would be most welcome here."

Comments

And make themselves obsolete?

[anthony_dipierro]

Adopt a standard which will ensure that if some piece of software is compiled on one LSB-compliant system, it will run on any other LSB-compliant system.

Seems to me that would defeat the purpose of having a distro company in the first place. Maybe the distros just don't want to contribute to their own demise?

Seriously, I don't see the point. We've already got POSIX for the interface to the libraries and the kernel. We have FHS for the filesystem hierarchy standards. Pretty much anything else, or any deviation from those standards, is being done intentionally by the kernel or distro developers.

Four reasons

[petrus4]

a) RPM

I'm assuming that the fact that RPM is even part of the specification is due to Red Hat's influence, nevertheless it most certainly should not be. For one thing, RPM's .spec format is beyond horrible in all sorts of different ways. I advocate crucifiction for whoever came up with the idea of sub-packaging from within a spec file in particular...this "feature" alone tends to make specfiles for glibc in particular an incomprehensible nightmare...and I can also virtually guarantee that this particular feature almost exclusively is responsible for every mangled RPM-based system anyone has ever read about...it is also responsible for the inability to compile single non-RPM based applications on an otherwise RPM based system. In short, sub packaging was an almost indescribably bad (not to mention completely unnecessary) idea, and IMHO should be removed from RPM.

In addition, the standard macros are also completely opaque...you've got no way of knowing what on earth %setup -q T b does unless you've looked it up.

b) Economic theory

Economic theory says that in order to sell something, it is ideally desirable to have what is called a Unique Selling Point...i.e., to have something unique which nobody else has, which is the reason why someone is going to buy from you, and not the zillions of other companies in the world. Thus, being non-standard is actually the *only* means a Linux vendor company has of creating an incentive for a consumer to purchase from that particular company, rather than any other. Standards (at least beyond a certain degree) would end up meaning that every vendor sold a completely identical, generic product...and therefore, no consumer would have any incentive to buy from any one vendor in preference to any other. *Customers* might want that, and vendors pay lip service to it because they know customers want it...but the vendors themselves in reality do not want it, because it would be very bad for their business...so beyond a certain point, complete standardisation ain't going to happen.

c) Standards aren't *always* a good thing. Standards are primarily a good idea when talking about communication. The Web is a good example. Because the Web itself relies on standard protocols/specifications, (HTML, HTTP and so on) the idea is that individual computers, sometimes with radically different operating systems *internally*, can reliably communicate with each other *externally* on the Internet. But for each one of those computers to always be identical *internally* can be an extremely bad thing, security wise...Microsoft's woes in terms of virii, worms, and trojan horses provide all the evidence needed to prove this point.

d) An operating system/standards monoculture is only really desired by people who are seeking an excuse to be able to avoid using their brains. Such people want things to be so completely simplistic that they can perform any task on rote, and most especially, so that they can perform any task without the truly horrifying prospect of needing to actually *think.* This is not to suggest that I am completely opposed to anything being user-friendly...quite the opposite. But I *am* aware that there is a very large segment of the computer using population who are willing to put Eric Raymond's "luxury of ignorance" ahead of virtually every other aspect of software design in terms of importance, including security. "Give us one single operating system, and do not allow the complexity of any aspect of it to be greater than a retarded five year old's ability to deduce!" Such is the rallying cry among these souls, and I hear it on an almost daily basis, albeit normally somewhat veiled.