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

How are the Distro's doing?

[reaper20]

This is great and dandy and all, but which distro's are going to pay attention to this? Anyone have a link as to the state of LSB-compliance for the major distros?

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?

What is Linux to us?

[Accord MT]

There is a poison that is affecting this great land, and that poison has a name: Linux.

You may have heard of this dangerous hacker's program. Developed by the Soviets during the Cold War, Linux is a "UNIX-like operating system." In layman's terms, this means it is computer software that allows criminals to perform unauthorized (and illegal) tasks with their computers. What may shock you, however, is that this program has begun to slowly make its way through our nation's computer networks, and now threatens the economy, the stock market, and the great corporations that founded our country and keep it running.

Linux, and other hacking tools with such strange names as "emacs," "PHP" (an obvious drug reference) and "gcc," have been used by thousands of foreigners and terrorists to undermine the American way of life. Okay, I realize you might be skeptical. How, you ask, could the United States, the world's peace-keeping police force, allow such harmful programs to enter our great country? Folks, I wish this was just an alarmist rant. But the threat to capitalism is real. Although the former Iron Curtain is long gone, its final creation is coming to bear on our own soil, in our own backyards.

Yes, friends, leftist groups and individuals, although mostly confined to covert computer hideouts called "chat rooms," are actively spreading Linux into corporations and other organizations as you read this. Why would any American do such a thing? We may never know. Perhaps these misguided individuals have been shunned by legitimate software development firms like Microsoft and America Online. These poor souls, many of whom are but children, have sadly devoted themselves to a life of crime, by secretly learning programming techniques such as "debugging" and "optimizing," techniques previously reserved for patriotic, God-fearing professional engineers like Bill Gates.

The time to act is now! As proud citizens and voters, we owe it to our children to stand up to this new "red scourge" and voice our concerns to our elected representatives. It is a sad testament to our country's deteriorating moral fiber that, despite the efforts of righteous Christian organizations such as the RIAA and the MPAA, the use and possession of Linux is still legal. Frightening, yes, but through faith and determination, we shall drive these Linux terrorists from our holy American soil.

An RPM Standard

[finity]

So RPM is now the "standard?" I'm not sure I like that. RPM is great and all, and many distros use it or at least can handle them, but I think maybe it should be refined a little more. I like debian's package manager as it is easy to use and fairly straightforward. I know RPM is supposed to be that way as well, but I've had a lot more dependency problems with RPMs than I have with apt.

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.

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

[Jason Earl]

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. The -E flag for cat was almost certainly added for the same reason that many commandline flags are added to GNU software. It was easy to add, and it makes the software a little easier to use. Why in the world would I want to use sed to put a '$' at the end of the line when I can simply do cat -E?

I also think that the LSB is fundamentally flawed, but not because it specifies GNU software (complete with their various and sundry GNUisms). The LSB is flawed because it isn't self hosting. In other words there really isn't a good way to know that your binary application is LSB compliant. You can't just install the LSB onto some test machine and bang away on it. They are working on a test script that hopefully will eventually allow you to check for compliance but currently the README states:

There is not yet a complete set of official test suites released by the LSB that can be used for compliance testing. You can download unoffical development versions of test suites planned to be used in the future from the beta directory in the directory above.

And if that isn't bad enough, the LSB isn't a particularly exciting platform to port to. Most of the cool new Linux features are not included. Basically the LSB is Linux with all of the joy sucked out. No wonder commercial vendors simply test against RedHat and call it good. It simply doesn't make sense to do anything else.

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.

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.