The LSB Delivers Again

gk4 writes "The LSB has updated and published the gLSB v1.1 draft for review. The LSB has also published for review the new psLSB for IA32 v1.1 draft and the completed LSB v1.0.1 Test Suites. Review ends Friday January 4th; however, the LSB welcomes comments from the community at any time."

Comments

The hell is the LSB?

[Magus311X]

For the lazy... (from the document):

The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.

The LSB defines a binary interface for application programs that are compiled and packaged for LSB-conforming implementations on many different hardware architectures. Since a binary specification must include information specific to the computer processor architecture for which it is intended, it is not possible for a single document to specify the interface for all possible LSB-conforming implementations. Therefore, the LSB is a family of specifications, rather than a single one.

The LSB is composed of two basic parts: A common part of the specification describes those parts of the interface that remain constant across all hardware implementations of the LSB, and an architecture-specific part of the specification describes the parts of the specification that are specific to a particular processor architecture. Together, the generic LSB and the architecture-specific supplement for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.

-----

Re:The hell is the LSB?

[Anonymous Coward]

Yesterday RDF, today LSB. Would it kill the /. authors to define their acronyms, preferably in the title but at least in their text?

I wonder how many sites get /.'d simply because folks are trying to find out "what the hell" the acronym means.

"L" is the problem

[chrysalis]

LSB is an excellent initiative. But the bad thing is the "L" ("Linux") in it.
This standard is designed for Linux, and only Linux.
Standardization of the filesystem namespace is needed on *ALL* Unices. And an unique document that would apply to *ALL* Unices would be a big win, both for developpers and for end-users.
DJB's packaging system isn't that bad. The only trouble is that only DJB promotes it and very few software are packaged that way because it totally changes the traditionnal namespace layout.

Re:"L" is the problem

[Wesley Felter]

Standardizing Unix has been tried; the results were things like POSIX and the Single Unix Spec. They cost millions to develop and didn't completely solve the portability problem. Why try again?

LSB is not a standard

[jgarzik]

It should be noted that LSB is not really a standard, and not really intended as a standard. It is intended as a common practices document, as the LSB mission statement points out.

My personal objections to the LSB are large, and centered around one single fact: The LSB documents as "standard" the GNU C library and command line utilities. This means that every Linux /bin/cat must support odd and non-Unix GNU options like --number-nonblank and --squeeze-blank and --show-nonprinting. /bin/cat must support cat -E, which could easily be replaced by a sed script (GNU cat implementor was apparently unaware of sed's existence). This means that, according to the LSB, libc[56] is non-standard because it does not support glibc-specific functions and interface.

So, the net effect is that any system claiming to be Linux-standard [according to the LSB] must support all these wacky, underused, GNU-specific extensions in their commands and C library. Given the proliferation of C libraries under Linux this seems like a mistake of a large order.

Jeff

Re:LSB is not a standard

[Arandir]

By that logic the GNU tar maintainer shouldn't have included the -z flag either because you could always pipe the output from tar through gzip.

You completely missed the point. Standards need to be lowest common denominator. Having a -z flag in GNU tar is damn useful. But it should not be the standard.

There are standards for most Unix utilities, and those standards should have been used instead of the mandating the GNU extensions.

Re:An RPM Standard

[big.ears]

Well, debian's packaging system isn't going away anytime soon--they are committed to using alien to maintain compliance with the LSB here. But, .debs are not necessarily technically superior to .rpms either. However, there are probably two reasons why them may appear so:

1) APT (Advanced Package Tool). This is even available and usable on .rpm systems so its not much of an advantage. It does take care of some of the headaches of dependencies automatically, but is probably a only minor advantage of Debian's packaging system.

2) Debian's packaging policy and community structure. This is where Debian shines--because each individual maintainer only handles a handful of packages, and there is a strict policy for them to follow, the packages tend to work well together. It's not that .debs are superior to .rpms--if you try to use Ximian .debs, or had in the past used Stormix or Progeny .debs, you can run into rpm-like dependency hell quite easily. You even can run into trouble if you try to mix stable and unstable debian packages.

But, all this comes at a price. debian's packagers are volunteers, and so you sometimes have to wait until the volunteer is good and ready to get the packaged software you want. For example, the new control panel and XST upgrades took a couple month's to appear, and there has recently been a little trouble with KDE--the package management changed hands. At least with a commercial system, you (hopefully) have better guarantees about package availability.

Why the LSB ain't so hot...

[augustz]

I'd like to just get a few objections in on the LSB while everyone runs around cackling with perverted glee.

I for one am sick of finding files from install packages all over the place. Everyone and their mother is sick of this. Apps should install into ONE directory only. They can symlink everything they want everywhere else (/etc and /log come to mind) but at least that lets us get an idea of where the mess all came from, and when we delete the directory we can also delete all dangling symlinks and truly get rid of stuff.

Linux is literally worse then windows on this count. PLEASE PLEASE contain the spawl. Someone needs to do an ls -l on /usr/bin and the lib directories.