Linux Foundation Promises LSB4 194
gbjbaanb writes "Ever thought it was difficult to write software for Linux? For multiple distros? InternetNews reports that the LSB is making a push for their next release (due out later this year) that should help make all that much easier. Although the LSB has not lived up to expectations, this time around Linux has a higher profile and ISVs are more interested. This is to help persuade them to develop applications that will run on any LSB-compliant Linux distribution. If it gets adopted, LSB 4 could bring a new wave of multidistribution Linux application development. 'It is critically important for Linux to have an easy way for software developers to write to distro "N," whether it's Red Hat, Ubuntu or Novell,' [said Jim Zemlin, executive director of the Linux Foundation.] 'The reason you need that is because we don't want what happened to Unix to happen to Linux in terms of fragmentation.' The LSB defines a core set of APIs and libraries, so ISVs can develop and port applications that will work on LSB-certified Linux distributions."
What is LSB, you ask? (Score:5, Informative)
The Linux Standard Base, or LSB, is a joint project by several Linux distributions under the organizational structure of the Linux Foundation to standardize the internal structure of Linux-based operating systems. The LSB is based on the POSIX specification, the Single UNIX Specification, and several other open standards, but extends them in certain areas.
http://en.wikipedia.org/wiki/Linux_Standard_Base [wikipedia.org]
Re:Distribution (Score:5, Informative)
Debian and Ubuntu use exactly the same packaging format (.deb). Try taking a debian package from a few years back and installing it on your system. Chances are, it won't work due to library incompatibilities.
Now you could probably rebuild it for your system, but depending on what it is, it may or may not work.
When you say "how hard it is going to bed to compile and update"...that's exactly what LSB is working on. It'll be trivially easy to compile a program written against the LSB specs on any LSB compatible distro.
Re:POSIX...? (Score:5, Informative)
Re:Didn't we try this once? (Score:3, Informative)
Re:Looks like the GPL haters got some mod points. (Score:4, Informative)
No we understand the GPL, but it has very little to do with the subject, namely that regardless of open vs closed, some distros remain incompatible with each other in small but significant ways.
If there is to be a stable platform to target with Linux, that crap has to stop. Simple being GPL software means very little toward that goal if distros continue to be arbitrarily different and the situation never really resolves itself.
Re:The difficulty depends on what tools you use (Score:4, Informative)
Wrong.
Any given distro will have to make a choice of what modules each program should support, this means even as a PHP programmer you have no guarantee your software will work with default installation of PHP under a specific distro.
Re:What did happen to UNIX? (Score:4, Informative)
Re:What did happen to UNIX? (Score:3, Informative)
If that's Unix_history-simple.svg (which it is), I'd hate to see Unix_history-complex.svg.
Here you go [levenez.com]. Well, not svg.
Re:Really? (Score:3, Informative)
Maybe it was Portage (Gentoo's Python-based package management system) then? I can imagine it being useful to be able to mess with packages (especially core ones like baselayout) in single-user mode.
Re:Really? (Score:5, Informative)
env should always be in /usr/bin. This will work on any POSIX.2-compliant system:
POSIX.2 doesn't even mention /usr. The location of env is not standardized.
Re:Really? (Score:5, Informative)
The first way is with a command like 'sh foo.sh'. sh will then read foo.sh and execute each command in it in order (if it's not a shell script, it will hopefully read the magic number and run it).
The second way is to just exec() it. The loader then reads the first few bytes of the file. This tells it what type of file it is. For ELF files, they will be ".ELF". For Mach-O binaries, they will be 0xFEEDFACE or 0xCAFEBABE, depending on the architecture. For scripts the first two bytes will be "#!".
If the loader encounters "#!" then it will read the rest of the line execute the specified command (and arguments) and pass the file to it as the last argument. You can see this in operation with the following script:
If you have a shell script that needs to run with the standard POSIX shell, then there's no problem. You just specify /bin/sh after the #! and it's fine. But what happens if you want to use some bash-specific features? On GNU platforms, bash is the default shell and /bin/sh is a hard link to bash, so it's in /bin. On other platforms it's a third-party thing and so will be in /usr/local/bin or /opt/something. This is where env comes in.
When you specify "#!/usr/local/env bash" you can safely hard-code the path of env, because POSIX defines where it is. Env then looks up where bash is and execs it with whatever command line arguments it was given. You can see this in action again like this:
If you just run 'env' from a command line to inspect the environment variables, you are most likely just calling a shell built-in command, which lists the things passed in to the third argument to main() and any set since the shell started. Env, however, can be used when you are not launching from a shell. If your program wants to run a shell script, you can just vfork() and exec() it, and the loader will find the correct interpreter. You could always inspect the environment yourself, but having every app do that whenever it needs to run a script is quite silly (especially since it means that the app also has to know the difference between a binary and a script and so on).
Some people still have a habit of hard-coding /bin/bash, and this is probably the kind of crap LSB will encourage ('bash is always in /bin on Linux, and I don't care about other platforms!') but the correct thing to do is use env.
Re:Distribution (Score:3, Informative)
Autopackage is essentially a distribution on top of the distribution. The autopackage guys basically built an autopackage base that they have ported to some of the more popular distributions. They then try and take care of the same packaging issues that Debian, Fedora, and the rest of the distributions take care of already. They have their own incompatible list of packages, with their own incompatible dependencies, their own naming scheme, and their own packaging format.
The only difference between autopackage and Debian's repositories is that A) Debian's repositories are much much larger, B) Debian's repositories receive far more real-world testing, and C) Debian's repositories come with a Linux installer.
If you don't like Debian you can replace Debian with Fedora or the distribution of your choice. Basically, everyone has more supported packages than autopackage.
Re:POSIX...? (Score:1, Informative)
POSIX doesn't say anything about the kernel. It just defines "system interfaces", i.e. the API exposed by libc, libm, and a few other core libraries (although it doesn't say which function is in which library).
Re:What is LSB, you ask? (Score:3, Informative)
Uh that's exactly what the LSB is trying to put a stop to. Currently, software installation sucks [ianmurdock.com] because it doesn't have integration with the native package manager. One of the reasons for forming a cohesive, extensible packaging API is so that any package can communicate with the package manager about it's existence. Normally, this isn't done unless you use packages for your specific version of your specific distro. This is beyond retarded, and will keep Linux fragmented and away from ordinary users who don't know what the fuck configure make make install means, not to mention have no clue how to solve problems in doing that when they arise.
Currently the Burgdorf API [linuxfoundation.org] is the incarnation of the LSB Packaging API and it would be nice to receive more help on such a critical issue. The article was spot on in saying that this will also lead to increased stability in other APIs as it's silly to install ten different versions of one library just because it's API isn't stable. Updating the library, that's mostly OK, but the rigidity of library APIs will become more apparent/annoying once Linux programs are actually portable (yes, I know binaries exist, I'm talking about packages for automatic updates, package manager awareness, etc).
Everyone should support good standardized APIs for Linux to help make this happen. While some users will be OK with never installing any software outside their own little world except for what their distro maintainers bundle up for them, many users are interested in having direct access to so-called "third-party" programs, not only for their binaries but for automatic updates among other things. Who's not satisfied with being stuck with version X just because they're using distro X of a program they love? I don't think most users are, and they shouldn't have to wait for the distro gift if they don't know how to compile, or the annoyances of running a "disconnected" binary in which they have to create manual menu items for and manually update.
If Linux is to ever be actually available to the masses, for it to gain momentum through the easy sharing of software outside the box which is the immediate software repository, and make it actually easy for Linux software developers to write software for any and all Linux distros without their blessed consent, this project is critical. Any user that wants free, unfettered, easy access to software has every interest in installing the LSB packaging API or using a distro with it already installed.
P.S. Yeah, there are other answers like Klik, Autopackage, Zero Install, and others, but an API to allow any package to be installed so that it will provide immediate integration with the package manager is much more helpful. Until the packaging API is finished though these solutions will help.