Slashdot Mirror
LSB Submitted To ISO/IEEE
mcneil@freestandards says: "The LSB has been submitted to ISO/IEEE for an ISO
imprimatur.
While this is not really new news, it is important
that every Linux user get involved to make sure their
country votes
YES for Linux ISO standardization!
With Linux achieving international standards
recognition it will be that much easier for
governments and other risk adverse organizations to
include Linux in their procurement policies. This of
course will further the normalization of free and open
source software, lessen the world's reliance on sucky
legacy platforms, etc. etc."
While I agree that standardization is a good thing, it will only have an effect if distros follow. Right now, one of the most LSB compliant "distros" is Linux From Scratch, which is not exactly a mainstream distro. I know that others have been making strides towards compliance recently, but unless all distros follow it close enough so that one person can work effectivly on different distros without having to relearn its directory layout, it won't affect adoption as it is just another unfollowed standard (HTML, CSS 3 in IE anyone?).
thisnukes4u.net
The LSB advocates RPM as the standard package management mechanism for Linux. To my mind that's a really bad idea...RPM has a lot of problems. So I for one can't really advocate this.
The LSB FAQ (for those whose first question was "What the heck is LSB?")
One line blog. I hear that they're called Twitters now.
You could use a LSB conforming RPM on both SuSE and Redhat, yes, but you could NOT just pick a random SuSE package and use that on Redhat.
LSB packages work basically completly independend from what the distro provides. If a distro is LSB conforming it only means that it can install LSB-rpms (by using alien on Debian for example), it does not mean that the distro itself consist of LSB-rpms.
The point is this:
If I'm versed in the admin of one LSB-compliant distro, it's trivial to migrate to another (in most respects) as the location of config files and the like is identical.
That's trival, however, compared to the power of influence it will have upon both developers and people looking to adopt linux for deployment. If a distro is LSB-compliant, then developers will be able to write simply for all LSB-compliant distros.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
From linuxbase.org:
Is the LSB only for Linux systems and applications?
No. The spec has been written so it can be readily implemented on top of any UNIX-like operating system, natively or as a compatibility layer. There is also no fundamental reason why it cannot be implemented on other operating systems, although it is likely to be much more work. Note that this philosophy may be one of the reasons why a seemingly "obvious" Linux feature is not part of the specification if it raises needless barriers to implementing the LSB on non-Linux systems.
1) All distros clearly say that their disro ver X is LSB ver Y compliant and stand behind that.
2) LSB mandates a sufficiently detailed configuration and fileset that a developer can build an app under any LSB ver Y.Z and expect it to install and run (with no missing libaries, re-configuration, config file editing etc) on any other LSB Y.Z compliant disro installation.
3) Oracle ver nn runs under LSB ver Y.Z NOT ONLY RH AS3.x and Suse EL 9.x (or whatever).
4) There's an automated validation that can determine if an initial distro install is (or is still) valid LSB ver Y.Z configuration.
You are confusing the packaging method with the management method. The LSB states that the standard package _type_ is rpm. APT is package type independent. It is most _famous_ because it is used in debian, however you can use apt to manage rpms also. I am not advocating either package type, I just wanted to clarify the confusion between a method of packaging programs and the management of said packages.
-- john
Before the my-format-is-better-than-your-format debate kicks into high gear, it should be said that the LSB intends to use the RPM format as a stop-gap measure
Of course, you know who is on record about how stop-gap measures "...have a way of staying around. Forever."
Thats a fair summary on the whole although slightly inaccurate.
Several distros are LSB compliant by default (notably the enterprise ones). C++ is defined in the LSB but not in the ISO standard. The reason for this was that the C++ the LSB defines is interim but was needed. Many of us felt it shouldnt be in, and definitely not in the ISO spec since we knew it was transitional. The compromise was LSB defines a transitionary C++ (which will remain supported) and ISO doesnt
You don't need to use the LSB build environment - that is simply a tool for ensuring compliance.
LSB as you rightly say is about server software right now. A push on the desktop front has begun and hopefully things like gtk will get looked at. In addition there is an exploratory working group on java/jvm packaging and standards (java itself is obviously standardised elsewhere)
To get to the stage where you can go into a shop and buy packaged applications the LSB extending to desktop will be important. Many vendors don't stock Linux products because its too confusing in their eyes. At the enterprise level it doesn't matter for small business and home it does.