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
He needs to read the GPL and understand how it differs from the various PROPRIETARY licenses that caused the *nix fragmentation.
The quote in the summary reads:
'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,"
Personally (as a Linux on the desktop user), I'm a lot more concerned about easily acquiring installing software, than whether it has problems with my distro. For the most part I can get software to run, but it can be a huge pain in the butt. I wish LSB would focus on extending and standardizing package formats and creating advanced standards for package managers to simplify that part of my workflow. I never wonder, "will this run on Ubuntu," so much as "which package format is this in, or how hard is it going to be to compile and update."
UNIX fractured into a large number of incompatible variants including BSD (fractured further into Open/Free/Net BSD), Solaris, IRIX, HP-UX, SCO Unix, etc., etc..
See this graph for more information.
"The reason you need that is because we don't want what happened to Unix to happen to Linux in terms of fragmentation."
What makes you think what happened to UNIX was bad? It's called evolution. Things change.
Let me remind you, my friend, that evolution means SUCCESSFUL ADAPTATION to an environment. What happens when a change (mutation) results in inadaptation? Extinction.
Evolution refers to a species. But in Linux what we have is not a single species, but a genus (a set of different species): Redhat, Debian, etc. "DNA" recombination is impossible in these. The resulting software would be inoperable.
LSB4, hopefully, will be a further step in the evolution of Linux: The convergence to a single species that will be able to share one single configuration.
In other words, yes, change is necessary, but there needs to be a period of stabilization. Just as stable/unstable releases in software. And LSB is providing this stability. LSB is, in fact, evolving.
Yes, that's kind of the whole point of the LSB.
Customers choose OSes based on many criteria. One of them is how much of the software they need will run on each platform. Now, this is rarely actually determined by the quality of the platform -- it's mostly a question of which platforms were already popular enough to be targeted. In theory, LSB will make it easier for new Linux-based OSes to run existing software, and will make it easier for ISVs to write software for Linux-based OSes in general.
Those OSes can then compete on more interesting metrics like performance, stability, scalability, price, and quality of support. How is this not a good thing?
LSB4 is all very well, but if RHEL does not follow (does anybody really think they will?) it will not amount to a hill of beans.
The masses are the crack whores of religion.
It relates to his statement that I quoted.
That shows how clueless he is regarding the history of *nix.
It was the various PROPRIETARY licenses that caused the fragmentation because an improvement made by HP had to be specifically licensed by Sun to be included in Solaris.
But with the GPL, the improvements made in one fork are available to ALL forks.
Therefore, the fragmentation will not happen because if a feature is worth it, it will be ported to the other forks. Without the need to coordinate licenses with HP or Sun or anyone else.
The GPL rocks.
All the distrubtions use the same basic set of Gnu tools (like GCC, binutils, bash) and common programs like the perl binary. So why not have all the contemporaneous (i.e. released in the same time-frame) distros use the same tools? Shuttleworth was basically advocating an extended version of this (although he phrased it in terms of a coordinated release cycle) to be policy across several distros and to include higher-level applications like GNOME, KDE, and OO (besides the low level stuff like binutils).
/usr/bin with non-system programs and put user install apps in /usr/local or /opt where they belong. ;)
As I've said before, software vendors like Oracle would love this because it would simplify their support.
Now if only LSB would stop the cluttering of
Other than eliminating conflicting directory structures, the most important standard for Linux distros to completely unify would be a single API to data protocols and MIME types. Like the one FreeDesktop.org has managed to sync (in principle) between GNOME and KDE Desktops, but for all distros (including servers).
A registry of which app to hand off a URL to given its protocol part, to retrieve the data. A registry of which app to hand off the data to once it's retrieved. Different data handler lists for displaying, editing or executing (the usual Linux RWX modes) the content, depending on the use case triggering the registry access. The registries could include prioritized lists of different apps, depending on user selection or settable default preference. And of course any single app could be registered to either registry, in any mode it will function properly.
Then the OS is performing its main task of connecting processes to the hardware and to each other. In a very simple and clear architecture. That every single app can use, without having to anticipate how the other apps will agree with it.
If LSB4 can pull that off, using the existing attempts as a starting point, it won't just make a unified Linux target for developers across distros. It will make LSB4 itself more quickly and completely adopted, because its benefits will be so compelling.
--
make install -not war
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.
UNIX fragmentation wasn't caused by anything other than all the proprietary, incompatible licenses. Whenever Sun made an improvement to UNIX, HP couldn't simply adopt it like they can with the GPL. With the GPL, if I take an OSS program and fork it, and change it radically, the original creators of the software can always add my changes back into the main branch. And yes it would be bad, if you had to write a program, say an HTTP server, you had to test it on every Unix imaginable, today, just release the source, package an RPM and a DEB, and it will be ported to the rest soon enough.
Taxation is legalized theft, no more, no less.
We don't want it to happen?
It already did.
Distribution compatibility and package management is a big problem for most, if not all developers, and has been for a very long time.
But you see, they dont want to write for distros foo, bar, etc... they want to write an app for linux.
They dont want to "collaborate" with dozens of distros, all of which will tell them that "in our distro, the proper way of how to do this" is different than the other ones...
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.
Classic zealot response. Pretend the entire world is moving to GPL-only software and neglect to address the concerns of anyone who disagrees.
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.
I have been mentioning this for years
Yes, I've seen you post here often!
hrm, maybe we could have an /setc for boot-critical config? Similar to how we have /bin and /sbin. For people who like the old way of one massive /etc, you could just symlink one to the other and there would be no practical difference.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Sorry, but when expressing inequality != is the correct operator.
You're not really a programmer, security, please escort this gentleman to Digg, please. :-)
Send your spendthrift head of state this
I've never had any need for a standardized linux environment except when I had to run Civ3 using libc5. The kernel never really freezes AFAIK.
The beauty of linux, progress continues, just switch distros. If you need something comfy and reliable, use Debian.
"Binary Compatibility" is one of those horrendously ugly catch-alls that, in the end, really doesn't explain anything. Strictly speaking, every distribution out there uses the same ELF executable format, so they're all "binary compatible". Of course, there's library compatibility (usually not a big factor), and package format/package manager incompatibility ("I tried to install a Ford Escort starter in my Chevy Malibu and the bolt holes don't match up!").
Jesus is coming -- look busy!
LSB isn't needed, Linux distros just need to implement 16-year-old standards. I think most do put env in the right place, although some also put it in /bin (which should only contain binaries needed to boot the system in single-user mode).
I am TheRaven on Soylent News
What makes you think what happened to UNIX was bad? It's called evolution.
I COMPLETELY DISAGREE WITH YOU! Linux, SunOS, Solaris (Not an evolved SunOS!), BSD, etc were magically created out of... erm.. random bits generated from some pseudo-random generator in DigiGod's image. Proof? DigiBless.com
</satire>
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.
Every project needs a code name. For this, I propose "Bullwinkle", and their slogan can be "This time for sure!".
As a developer I've considered this one of the (if not the) most important issue in linux. I am happy to hear it's finally getting the attention it needs. Many applications (especially games) will only be released for linux (and work out-of-the-box without tweaking), once there is a decent way to build 1 release for any (LSB compliant) linux distro. I myself build java applications (on Ubuntu) that work perfectly fine on linux, but because of this problem, I simply don't bother building a release package for linux. No matter how hard is, get it done. And make an extensive test kit to assure Red Hat, Ubuntu and Novell are compatible.
If that's Unix_history-simple.svg (which it is), I'd hate to see Unix_history-complex.svg.
I put the 't' in electrical engineering.
If that's Unix_history-simple.svg (which it is), I'd hate to see Unix_history-complex.svg.
Here you go. Well, not svg.
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
Instead of trying to make all the distributions the same, why don't they make a library that abstract away the difference?
Example: If my program need to link to a ssl library(Such as openssl), version 2.3 or newer, I should call a function .so file, or null if the file is not installed. There could then be a
findLibrary("ssl",2,3) which would return the path to the needed
function to also ask the os to install the needed library if it were not there.
Each linux distribution should then implement the library in a way, so that the Redhat version, might forward the call to rpm, while the debian version of the library would query the dep database insted.
And instead of the infinite debate on /opt vs /usr/local the program could just call getPathForUserInstalledSoftware();
And getDefaultCompilerPath() instead of the current autoconfig hack.
Then a linux standard base, would just be a specification of the needed functions in LinuxStandardBaseLibrary.
And we would newer have to use the autoconfig hack. (The library might ofcause also be implemented on Solaris, and maybe even cygwin/windows)
Exactly!
The world does not revolve about GPL software. It works about *working software*. I don't care if I use GPL to get my work done, $50 software or if I use a $20,000 a seat software. Whatever makes sense is what is used.
If Linux community expects ANY sort of commercial software released for Linux distributions, they need to get the LSB implementation done and ready. LSB is like an SDK towards building apps for ISVs. If you don't have it, you end up with app not for Linux, but for Debian 3.0, RHEL 2.0, Slackware 10, or whatever. With LSB, you end up with software for all Linux.
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.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
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.
COO: so, we've developed a new widget, brilliant. When can we ship it.
DEV: today, its all tested. I've run it myself on my Debian box.
COO: sure, it'll run on Customer B's Redhat environment won't it?
DEV: Ummmm.. well, not straight off.
COO: ok, so what do we need to do to make it work?
DEV: well, alter a couple of paths, recompile, change the dependancy for package Z and build a rpm
COO: and how long will that take?
DEV: a week, maybe 2 with testing.
COO: so, that's 2 weeks development costs on top of what we've already spent. We wouldn't have this kind of problems with Windows!
and I'm not trolling either - standards are good, making extra work for yourself for no good reason is bad. Its not as if a common directory layout, ABI or programming libraries need to affect open source linux in any way. The Kernel is a standard, and no-one complains they don't have a choice of kernels to develop against.
Softimage's XSI, VMWare, many other softwares that can't be recompiled, tested and tech supported in many distros or that need libs that are guaranteed on a platform. You think everything can come from a repository and that every bug in every distribution can be supported, tested and fixed consistantly?
Of Code And Men
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