Any views or opinions expressed here are my own, and not that of my employer or any project I am a member of.
InternetNews ran a story last Thursday (picked up via LWN) asking whether LSB 4 will standardize Linux? In it, they interview Jim Zemlin, the executive director of the Linux Foundation, and the article expresses the feeling that if only the distributions would adopt it, the world would be a better place.
To those that know me, I may sound like a skipping CD, but I just don’t see anything in LSB 4 that will change the current situation because they have not addressed the fundamental problem with the LSB.
The failure of the LSB to actually engage with the distributions it’s attempting to standardise.
This wouldn’t be so much of a problem if the LSB attempted to document existing practice in the form of standards, while acting as a forum for development of new practices which could be trialled before standardisation. Much as the IETF does, now.
Instead, the LSB sees itself as a development group that decides on future direction itself and dictates that to the distributions. That’s not necessarily a bad thing, it’s pretty much the way that the W3C works. But to work successfully, you must represent everybody that you expect to follow the standard.
To this day, the LSB still feels like an RPM-only club. The core specification specifically requires RPM, and in fact much of the other system-related pieces are based on the layout and design of RedHat and its derivatives.
That is, except for those bits that the LSB invented all by itself, such as the Init Scripts section.
While much of the LSB can be hacked into a different distribution through compatibility layers and tools, such as alien, what ISV or other vendor wants to provide a support contract against a distribution that has such kludges?
The whole point of the LSB is that ISVs and other vendors feel confident being able to simply target their software or platform to the standard, and safe to honour support contracts on any deployment to an LSB-certified operating system.
If the distributions themselves don’t directly implement the LSB specification, there will never be the confidence to deploy against it directly and we’ll remain in a world where vendors directly target the distributions.
And until the LSB invites all of the distributions to the table to fundamentally redraft the specification to provide a common base that they are all happy to implement directly, they’ll still conform through hacks, kludges and compatibility layers.
Heh, wow. I can’t believe they’re wanting it to become standard like that.
When you standardize you are going to have to make a choice between different ways of doing things. The reality is that until Ubuntu came around there wasn’t any distros that supported deb packages that were commercial friendly and large. The RPM based were doing a better job of supporting commercial interests perticularly at the server level.
The two main other distributions are redhat and SUSE at least at the server level. Both of those use rpm. We have alien so we can convert an rpm to a debian package so we don’t really need to worry about this. That is perfectly acceptable.
Personally I use ubuntu and debian only. At work I use redhat/fedora/centos sometimes but my preference is for the debian packages. But I do understand the LSB choosing rpm.
I agree about the RPM club comment. For me LSB will always be irrelevant as long as it dictates RPM and ignores DEB.
Chad
http://linuxappfinder.com
http://feedsanywhere.com
Pingback: Rejås Blog » Blog Archive » LSB 4 och diskussioner däromkring
Pingback: nenoblog » Blog Archive » LSB 4 doesn’t fix things any better than LSB 1, 2 or 3 did.
Pingback: • Linux Haters Blog: Rants and Laughs • Blog Archive • fuzion
Working on the LSB is a thankless job. For every person screaming “stop inventing solutions for things that aren’t common practice!” you have 3 others yelling “how can I just produce one package that will work everywhere?!”. Then on top of that you have a lot of FUD going around from people who really don’t understand the constraints the workgroup is under (mainly just piling on beating the dead horse issues).
When I worked on the LSB I tried to promote a middle way to keep both of the above groups happy by defining the LSB Acceptance Criteria,
http://www.linuxfoundation.org/futures/criteria/index.html
and tracked proposed candidates according to that criteria
http://www.linuxfoundation.org/futures/candidates/all-groupstatusname.html
(extremely out of date, it wasn’t maintained after I left over a year ago)
only to have it overridden in the interest of progress. The LSB/FHS are still needed, but I got sick of fighting those battles and gave up.
To quote Keith Packard, “Standards? I’ll be in the bar”
Regardless of how widespread RPM is or was, it’s a horrible format, the tool is in some kind of bizarre quasi-fork between RH and the original author, RPMs authored for one OS can not just be dropped into another RPM-supporting one, so it isn’t cross-distro in anything but layout. In short, it makes no sense to base a spec that should last any length of time into the future on something so shoddy today.
Idiot at Work here. Did not read what is in LSB 4.0 at all by the sound of it.
RPM has been found to be non functional by the LSB for the needs of ISV’s. So LSB is providing a solution that is not dependant on any package manager out there. A netural format that will integrate into any package management system out there.
RPM CLUB IS DEAD. LSB 4.0 is its grave stone.
PS the RPM CLUB was formed because LSB stupidly gave distributions the right to vote on format. There were more rpm distributions at the time.
So current day actions are taking that big blooper into account.
RPM as a file format is fine. It’s the tools around RPM (like rpmbuild and rpm itself) that sort of suck. krh’s razor project basically does RPM right; it’s hella fast, doesn’t use the rpmdb, combines yum and rpm together, and just freaking works. And it shows that RPM as a file format is actually OK, and that you _can_ build tools around it that don’t suck Sergey Brin’s left testicle, to quote LHB.
“…A development group that decides on future direction itself and dictates that to the distributions. That’s not necessarily a bad thing, it’s pretty much the way that the W3C works.”
If the LSB is worth having at all, then maybe it would be useful to investigate how one part of the W3C has broken out of that model in the past couple of years. The XHTML 2.0 Working Group were busy reinventing HTML in a backward-incompatible, feature-meagre, and Web-hostile manner that browser vendors weren’t interested in. Mozilla, Opera, Apple, and interested volunteers began an external project (the WhatWG) to standardize HTML extensions that Web authors were wanting. The pressure built to the point that the W3C was forced to revamp the HTML charter, and later accepted the WhatWG’s work (which by now included most of a detailed specification of how to handle real-world HTML) as the base for HTML 5.
In the W3C process, some new features are based closely on an experimental implementation (e.g. the canvas element from Safari, the video element from Opera), while others are invented by the editor based on evidence of real-world problems. Over time the importance of multiple interoperable implementations has increased, to the point where features may be dropped from a spec if they have not been experimentally implemented.
Pingback: The Licquia Blog » Blog Archive » Standards and Conversations, Part 1
Instead of pushing RPM format as an standard, they should promote a way (by using scripts, aliases, etc) that allows any distribution to install commonly found deb, rpm and gz packages. That way any user can install most common packages from (ie. a CD cover disk) without resorting to check what distribution they have, or which revision of the package they need to choose. In other words, the distribution being the one responsible for the conversion (ie. running alien in the background to convert an rpm file and installing it with no additional user intervention).
Part of the work is already underway, thanks to PackageKit, which allows a universal GUI for managing packages. But an option to install standalone packages in rpm, deb, or gz from the Internet or a disk is really needed.