LSB to Provide Standards as Optional Modules 99
An anonymous reader writes "The LSB will begin providing certain standards as optional modules to the core LSB standard that will enable standards flexibility and allow for a wider variety of standards, eWeek is reporing Free Standards Group officials said at the OSDL Enterprise Linux Summit today. The article goes on to say that the FSG is also looking at possibly franchising out the application certification component of the LSB to the distribution providers themselves."
For crying out loud, Read The Fine Article (Score:3, Informative)
Why do we need more standards defining the Least Significant Bit?
...
Seriously, why can't articles explain what all of the acronyms mean?
Here is your big pointy hat - go sit in the corner.
From the FIRST PARAGRAPH of the article:
The Free Standards Group has decided to move away from a single, core LSB (Linux Standards Base) specification, and is instead going to break this down into different modules that can be combined to give a server or desktop LSB standard.(emphasis mine)
Sounds funny but makes sense... (Score:5, Informative)
Upon first reading the above I almost laughed. What good are standards if they are flexible and come in great variety? Then I did what no other self-respecting slashdotter would dare to do: I started RTFAing...
What these guys are saying is we should have different standards for different types of machines (e.g. Servers vs Desktops) which are based on a common denominator. Therefore the addons to the standard may go into greater detail for that type of usage.
I guess they want to make the standard stronger in some directions, while at the same time not encumbering types of distros which need not concern themselves with the gory details of something they don't include. I guess that sounds reasonable...
posix (Score:2, Informative)
Re:Bad idea.... (Score:5, Informative)
LSB defines a set of libraries and applications that will be present on all LSB compatible distributions/installations. It specifies things like kernel version, libc version, etc. so that a commercial application provider can say that "This application is certified to work with LSB 1.x" instead of "This application is certified to work on redhat 7.2, and may work on debian 2.2, suse 8.0 and possibly other installiations that have kernel 2.4.x, glibc 2.y, and foobar 3.0"
What they are talking about doing now is adding optional components to the LSB. That way an application provider can say for example "This product is certified with LSB2.x + LSB Webserver 1.y" without having to add a web server as part of the LSB and thus requiring it to be installed on non-server computers. Likewise the current LSB defines few (if any) X toolkits, libraries, applications, etc. so in order to say that a commercial desktop application will run on any LSB certified platform, providers would have to statically link a lot of libraries that are already present on most desktop linux machines because the LSB doesn't include them. Also, as the article points out, there is a lot of interest in having Java be part of the standard, but so far they have not made it required because of the licensing issues. This way, Java installations could be standardized but made part of a separate module so that they would not be required for all LSB compliant installations.
However, while having optional modules for the standard doesn't seem like a bad thing to me, the idea of having the distibution providers doing the certification seems like a mistake.
Re:Bad idea.... (Score:3, Informative)
LSB is not a package format- there is not such thing as an "LSB package", and deb, ebuild, rpm, etc. have nothing to do with the LSB.
You might have to have a re-read of the Linux Packaging Specification section of the LSB. The LSB does not currently require that packages be in RPM (although it is "encouraged" and in the future may be required) but there definitely is an LSB package format and it is RPM.