Slashdot Mirror
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."
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.
---
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.
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
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.)
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
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. /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.
/etc AND rc FILES SHOULD NOT BE IN /sbin! - If that isn't obvious to you, you need a long vacation.]
/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.
/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.
By this I refer to the way one can simply back up the
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
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
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
--Charlie
Eric Dennis (Spothead Lex Animata) says the secret to happiness is lowered expectations.
If you read the 1.0 standard, RPM is the official package format.
l l. html#PKGFORMAT
http://www.linuxbase.org/spec/gLSB/gLSB/swinsta
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
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.
--
assert(expired(knowledge));
Britney Spears is just so much more popular, so she is the best choice!
Lets try to keep the discussion based around technical arguements.
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.
There's no point in questioning authority if you aren't going to listen to the answers.