Linux Standard Base 1.0

Peter Makholm writes: "Finally the 1.0 version of the Linux Standard Base released. Now software vendors can finally just say that they comply with the standard and then you should be able to use the software on any Linux whether you uses Debian, TurboLinux or Open Linux. Check the standard at linuxbase.org."

Comments

Wow, here's a bold statement:

[Micah]

The application should not contain binary only software which it depends on running as root, as this makes security auditing harder or even impossible.


Personally I try hard not to run closed source software as root. I'm glad to see this in the standard.

---

Re:LSB quite fat - scales down badly

[Jason Earl]

Standards are good, but you wouldn't want to be stuck with these particular standards forever. The LSB talks about the libraries that are supposed to be included with a Linux distribution, and goes as far as to specifically state which versions they should be (although not which minor version). In other words you get things like ncurses 4 and 5 should be included, the tar included is GNU tar version (I don't know which version they specified) and the shell is bash version (whatever).

That's fine and dandy for now, but two years from now LSB version 1.0 is going to look pathetic. Developers aren't going to want to stick to it because the software available will be so much nicer. Heck, the software available now is nicer than what is specified in the LSB.

Not to mention the fact that their isn't an LSB reference platform. The only way to make sure that your package is LSB compliant is to do a code audit. If the commercial developers were willing to do this then they would already be making portable packages. The stuff listed in the LSB is not rocket science. In fact, every single distribution has had to solve all of the relevant problems. The LSB won't solve a thing.

The original plan for the LSB was to build a reference platform. This platform would probably have been the Debian base platform plus some other basic necessities. This way the commercial developer could have actually tested his application against the reference, and all the other distributions would have had to do was make sure they included at least an optional set of libraries that was precisely like the libraries included in the LSB reference. That would have been useful, and it would have allowed for the standard to migrate intelligently with time. Every time you got a major Debian stable rev (about once a year) the LSB would rev as well, and everyone would know ahead of time where the new standard was going (they just would have to participate in the Debian mailing lists.

All is not lost, however. Linux still has a standard. It's a de-facto standard, but it is also an open standard, and so it will do. That standard is the freely available bits in RedHat Linux. It will probably tick off Caldera, SuSE, and Mandrake that they will have to continue to track what the folks at RedHat are up to, but it is their own fault for making the LSB so unpaletable. None of the commercial Linux vendors wanted to do the right thing and create a standard that was actually competitive with their own distributions, and so they created a standard that is so unpalatable to developers that it will never get used.

Re:LSB quite fat - scales down badly

[Jason Earl]

The LSB is useless enough as it is. Your plan would basically tell the developer, "This platform is about as friendly as a rabid Komodo dragon, feel free to pay no attention to our specifications."

You need to remember the problem that the LSB is designed to solve. The LSB is designed to give commercial developers a reference platform that they can develop to and then be guaranteed that their software will run on every LSB compliant Linux distribution. Right now most commercial developers simply target RedHat, and then let the rest of us that don't use RedHat sort out how we are going to get the software to run on our platform o' choice. Sometimes, for various reasons, the commercial vendor will even admit to supporting several different distributions, but they don't like the work that this takes, especially considering the size of the market.

So the LSB folks put together a set of minimum requirements for a Linux distribution, and quite frankly, my guess is that they are too minimum to really be of any use.

You see, while you might be interested in the smallest Linux distribution possible, most people want the added features of GNU tar and bash, and you can bet that commercial developers are going to want a lot more than that. Unfortunately, since the LSB is not a distribution in itself they almost certainly will get more than that. They will continue to do precisely what they are doing now. They will develop their software on RedHat, using RedHat's cutting edge libraries, and when they are finished and want to see what it would take to make their distribution LSB compliant they will realize that it would take a significant amount of work. The LSB is like a snapshot of GNU/Linux frozen in time. It's sort of like running Debian Stable. It's chuck full of good stable software, but chances are the version that you really want to be running is not the one available. There are a lot of features that simply aren't available if you are only using the LSB libraries. If the LSB was a standalone distribution, then you could at least use it as a development platform. But since it's not, commercial developers will continue to do what they do now. They will target RedHat, and force the other distributions to follow RedHat's lead.

Oh well, I personally use Debian, but I can't help but think that we could certainly do worse than using RedHat as a de-facto standard. At least they are committed to Free Software. The standard at least will be an open standard.

LSB quite fat - scales down badly

[Florian]

Reading through the LSB specification, I am disappointed that it prescribes the "fat" GNU implementations of standard Unix tools as a minimum requirement for compliance. Of course I'm all in love with the added functionality of the GNU tools, I just think it's wrong to make them "standard", i.e. a dependency.

Examples:

• The standard LSB shell is bash,
• the standard LSB tar is GNU tar (with the -z option and others).

Making them a standard requirement rules out more lightweight implementations, such as the ash shell and the busybox or the BSD tools. This in turn makes it impossible to build embedded Linux systems conforming to the LSB - be it PDA Linux or be it one-disk routers.

Instead of targetting only server/workstation setups, I would have preferred the LSB to settle on low common denominators, like

• the common POSIX-compliant functional subset of ash and bash,
• the common subset of GNU tar, BSD tar and busybox tar, etc.etc..

This would still allow anyone to make bash the standard shell and GNU tar the standard tar in an LSB-compliant distribution, but it would require third-party software makers to take care that their shell scripts run on ash as well as on bash if they want the LSB compliance sticker for their product.

(P.S.: That said, I would love to see GNU/Linux distributions - above all: Debian - to scale down to a basic ash/busybox setup, which would require [a] to get rid of bash/GNU tool specific syntax in the setup and configuration scripts, [b] free all their package managing from dependencies on scripting languages like Perl, using ash scripts + minimal sed + minimal awk for simple tasks and compiled C code for more complicated stuff.)

Re:LSB quite fat - scales down badly

[JoeBuck]

The intent of the LSB is to document what an application developer can rely on. If you want to make the LSB allow multiple versions of the basic tools, it means that application developers have to do something like autoconf to get their package installed. Can't use "tar zxf foo.tgz", since Florian doesn't want GNU tar. Can't use anything but the most basic Posix commands, because again Florian doesn't want to use them.

If you want to say that the LSB should only specify Posix-compatible commands, why do you need the LSB? Just use Posix.

There may be a need for another specification for a cut-down Linux, something like the difference between hosted and freestanding implementations of ANSI C. But in this case, the standards folks are standardizing based on what is in place. Every GNU/Linux provider makes bash and GNU tar available. People with special needs may want to install alternatives, but in this era of boxes with a Pentium 3, 20 Gb of disk and 128Mb for $800 or less, it makes no sense to make the lives of application developers harder to satisfy a few dissidents who want to save a few kilobytes.

Also, remember that the LSB is only a minimum standard. Developers who want to be more robust, and portable to BSD and Unix as well as Linux, will continue to be more rigorous in assuming only Posix features.

It's not enough

[IGnatius T Foobar]

Go ahead and mod this into the toilet if you want to, but it's a serious criticism and something I feel strongly about:

The LSB is not enough to offer a single target for ISV's.

It is missing two important things:

• A standard package format (RPM or DEB)
• A standard desktop framework (KDE or GNOME)

Until the coordinators of the LSB get "ballsy" enough to actually dictate these things (and rest assured it will anger 50 percent of the Linux community), we still do not have a single platform target for app installations.

If you look at the ISV's who have ventured into Linux so far, the single target is (and I believe, until these issues are resolved, will remain) Red Hat.

When users install desktop apps, they expect the following things to happen:

• The installer needs to be easily startable (ok, we might be doing ok there)
• Icons and menu items are automatically added to the desktop
• Resources such as printers, fonts, etc. need to be connected to automatically
• If updated system libraries or components are required, find them and offer the opportunity to install them

The LSB is a good start, but it's not a comprehensive binary target. I believe that you can't make everyone happy -- some truly serious decisions such as package manager and desktop framework need to be made.
--

Re:It's not enough

[mwr]

The dependency system works fine, and RPM is nicer for packagers , since you don't have the same one-patch limit imposed by .deb.

There's not a one-patch limit. There's a pristine tarball and a .diff.gz file, sure, but that doesn't mean there's only one patch involved. The .diff.gz shows the difference between the original source tree and the Debianized one.

For example, in the Debianized Apache source tree, there's a whole directory of patches which are applied to the upstream sources during the build process:

mwr@ch208h:~/apache-1.3.20/debian/patches$ ls
ab_round_robin_support phf_dot_log
apxs_assumes_dso regex_must_conform_to_posix_for_LFS_to_work
debian_config_layout server_subversioning
debian_ps_is_brutal suexec_of_death hurd_compile_fix_for_upstream
usr_bin_perl_owns_you mime_type_fix

Each can be selectively applied if you edit the build/make scripts, too. Not every package uses this selective patch method, but the really complicated ones often do (X, libc, and Apache at least, and those are just the ones I've seen personally).

Re:It's not enough

[akmed]

If you read the 1.0 standard, RPM is the official package format.

http://www.linuxbase.org/spec/gLSB/gLSB/swinstal l. html#PKGFORMAT

Not that I personally agree with RPM but I've heard that the RPM format is getting more robust and might actually offer all the things needed to have a unified packaging format. It'll be interesting to see if Debian and Slackware (along with other smaller non-RPM distros) go along with this though.

-Mike

Re:It's not enough

[interiot]

The "Standard" in LSB won't be accurate if there's still large contention among linux users as to which implementation of feature X is the best. IMHO, LSB's role is to standardize things which have already been long hashed out and it's mostly obvious that there's one good winner. Standardizing things too early leads to a stifling of innovation (why do I feel dirty when I use that word now?).

I don't think LSB's role should be to lock things to arbitrarily just to get a common platform. If large-scale forced standardization is your thing, go with that other OS.
--

Re:It's not enough

[runswithd6s]

I am a Debian developer, but I have not involved myself with policy decisions as of yet. I can tell you my biased opinion on the subject, however. We've all heard the arguments before, why one packaging system is better than another, so I won't go into an evangelistic rant about why deb's are better. I will say that I doubt very highly that Debian will drop debs any time soon. To be compliant with LSB, Debian will continue to package rpm and alien.

That should be sufficient for allowing software vendors to feel comfortable packaging for Debian with rpm's. Of course, the use of a packaging system does not alleviate the problems with dependency resolution and binary to library incompatibilities. Vendors will still need to be careful to recompile their rpm's in the environment they expect to deploy the software. One thing that is nice about LSB is that we will know where to find the software files when they ARE installed.

--

Re:It's not enough

[Dr_Claw]

It is missing two important things:
* A standard package format (RPM or DEB)

Mmm, kind of - the important thing is that the same versions of files are installed in the same places... how they got there isn't so important. However, I agree - people distributing software for Linux don't want to have to package up binaries in several formats. Hence the frequent complaints from Debian users that $COMPANY has used RPM. This is certainly something I'd like to see addressed.

* A standard desktop framework (KDE or GNOME)[snip]
* Icons and menu items are automatically added to the desktop

Argh. Standard framework - yes. Plain choice of KDE/GNOME - no. There is a reason some people use different window managers - they like the different feels of them. Personally I use Enligtenment, and I like the idea behind E17 of being a desktop shell - not trying to be a big collection of packages like KDE/GNOME. However, just because it's valid for several to exist, it doesn't mean they should be devoid of standards - far from it.

Let me take the example above... icons on desktops (presumably shortcuts that launch applications). I really hate icons on my desktop - I use menus or launch apps instead. However, whichever camp you're in, the data is the same! So what we should be using is a standard way of storing this data, which your WM can turn into menus or desktop icons as your prefer. It's so stupid that KDE and GNOME create their own menus. I then have my various internet related apps split across the two menus - why!!. It's little things like this that need to be improved. Along with standard ways for apps to interact (drag and drop for example - yes I know people are working on this one).

That said, I look forward to the LSB being taken up and progressing to address these issues.

Re:It's not enough

[rgmoore]

It is missing two important things:

• A standard package format (RPM or DEB)
• A standard desktop framework (KDE or GNOME)

I think that this is slightly off the mark. The difference in packaging formats is, IMO, a comparatively trivial complaint. It should be comparatively straightforward for just about any software supplier to provide both DEBs and RPMs for their software. It's not even a matter of recompiling, just repackaging. This shouldn't be enough to slow things down much at all, and the number of projects that allready do so is evidence of the fact. IMO the difference in package management needs to be resolved eventually, but I think that it's small enough that this is not the time for one side to ram it down the other side's throat.

OTOH, the lack of a standard desktop environment has the potential to be more of a problem. It's not trivial to make a package that plays nice with both KDE and GNOME, not to mention all of the people who will want to skip desktop environments alltogether and use just a lightweight window manager. IMO, though, the long term solution is not going to be forcing people to choose one or the other. Instead, GNOME and KDE will develop to the point that they interoperate smoothly, and disk space will get cheap enough that people won't complain about needing to keep both on their boxes to run arbitrary software. You can already run KDE apps on a GNOME desktop and vice versa (so long as you have both installed), so I'm not sure whether this is a really serious flaw, anyway.

Re:It's not enough

[iomud]

It seem's pretty RPM centric to me. A standard shouldn't become a standard because a lot of people use it. It should become a standard based on it's technical merit and objectively evaluated.

I don't know how you can look at dpkg and apt and not be impressed. Maybe people are afraid it will effect their business model's because debian is doing for free what other folks are charging for. Is either perfect? No. But that should only serve to raise the bar for each package management system. Then again splitting hairs dosen't do anyone any good, I just hope we can pick the best choice becase it _is_ the best choice.

And yet I hope both LSB and FHS triumph....

[Medievalist]

The primary reason to prefer linux over traditional unices (for me, as a sysadmin and user) is the clean separation of configuration files from the binaries they control and the data those binaries use.
By this I refer to the way one can simply back up the /etc directory structure and capture the entire configuration of most linux distros, without getting anything else. This is extremely useful. Similar tricks can be played with /var on nameservers and DHCP servers.
Traditional unices (the most egregious example being that hideous train-wreck of a Unix, HP-UX) scatter configuration files and binaries willy-nilly across the file systems, every program having its own unique hidey-hole. People steeped in Unix lore become inured to this, and start to think it is desireable because they are used to it. [Reality Check - BINARIES SHOULD NOT BE IN /etc AND rc FILES SHOULD NOT BE IN /sbin! - If that isn't obvious to you, you need a long vacation.]
The LSB specifies the use of FHS 2.2 which seems to be a more elegant version of the old linux file system standard. The FHS standard specs an /opt directory for the installation of major 3rd party applications - that is, the kind of applications that you dedicate a server to, like databases or digital data aquisition systems.
The problem is, the majority of the application vendors ram their code in any old place they want, and then their apps don't run without those specific locations. Symbolic links are the best compromise you can usually get, without forking off your own source base, and sometimes even that won't work. Then, to make matters worse, they often require specific versions of various libraries - usually obsolete and/or insecure ones, in my experience.
So, the major distributors may get off their asses and implement LSB eventually, which will be a Good Thing [TM] and will mean finally getting real total compliance with FHS, but application servers will still be wonky as soon as a big app (like tina or datastage - blech!) is installed. The LSB will supposedly address this by marketplace adjustment and app vendors without clues will fail commercially. I personally am not convinced this will happen seeing how Solaris and the patently inferior HP-UX still command market share today. Commericial needs require applications which require systems, and not the other way 'round.
Me, I'll be happy when the ancient cruft like /etc/exports (I have a link named /etc/nfs.conf on the few machines where I am forced to run insecure crap like NFS and NIS) falls by the wayside. Until then no *nix standard can be both widely used and internally self-consistent.
--Charlie

Eric Dennis (Spothead Lex Animata) says the secret to happiness is lowered expectations.

Re:Needs something like Windows....

[JabberWokky]

What makes a good Windows application good is the UI, and Linux need a document like the following: (MS URL snipped)

You mean somthing like this:

http://developer.kde.org/documentation/standards/k de/style/basics/index.html

This was found at the KDE developer Reference Guides section (http://developer.kde.org/documentation/library/in dex.html), which is distinct from their Standards section (which details industry standards and Gnome-KDE and WM-KDE interoperability standards), and their excellent tutorials, archetecture guide and the 540 page book that is available online and in print that details the KDE interface and programming guidelines. The online version has user annontations.

I would imagine that Gnome and Apple OSX have a similar set of documents. I've been a subscriber to MSDN for years - they *do* have some good resources, but they don't have the only set of good resources. And so, to answer your questions, yes: Linux Desktop environments *do* have UI standards.

--
Evan

Re:why only for those?

[jfunk]

It doesn't mention SuSE either, who have been striving for compliance. Starting with 7.1 (I think) the distro has been compliant to whatever state the LSB was in. The next release (7.3 or 8.0) will, in all likelihood, be compliant to LSB 1.0.

As for Red Hat, I don't know. They've been pretty divergent on a lot of things. They put init scripts in /etc, for example. /etc is for configuration files only. In SuSE, init script are in /sbin/init.d and there is a symlink in /etc if you install the 'eazy' package (that way, you have a simple choice).

They also place commands in pre/post-(un)install scripts that are not available on all distributions.

One big thing that freaks me out about the use of RPM is the naming in the 'provides' and 'requires' fields. One package may 'require', say, python-gtk, while only 'pygtk' is provided. The right software is there, but naming is a PITA.

What is a standard anyway?

[Jagasian]

Honestly, what is a standard? I claim that Debian Linux is just as much of a standard for Linux, as is the LSB. Debian is not controlled by a company, and it even provides a reference implementation of the standard.

I guess the question is, do Linux users base their decisions on the technical merit of a Distribution or do they make decisions based on the herd mentality?

Re: RPM, LSB did the right thing

[Jagasian]

Britney Spears is just so much more popular, so she is the best choice!

Lets try to keep the discussion based around technical arguements.

1.0 Release

[JBowz15]

Everyone knows 1.0 releases suck. We should probably wait for at least standards version 1.1, when more of the bugs have been worked out.