Slashdot Mirror
Linux Foundation Promises LSB4
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."
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
You should wonder about will it run.
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.
POSIX has multiple components -- kernel APIs, command line utilities, shell scripting, libraries, etc -- so there's more too it than just the linux kernel.
Do you even lift?
These aren't the 'roids you're looking for.
It does use RPM.
Do you even lift?
These aren't the 'roids you're looking for.
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.
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.
One piece of this was that simple commands had different names and different options depending on the variety of UNIX. I am talking things like lp vs. lpr, options for ps, and so on. Also, some things were hidden in really weird places (X on Sun is/was under an "openwin" directory, I think). Writing cross-platform scripts is a pain when you first have to test for the OS and then redefine command names, options, and paths accordingly. In theory, under the LSB you always know where commands and libraries are.
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.
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.
I am TheRaven on Soylent News