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
Web devs, python devs, etc likely don't find it that difficult.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
"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. If UNIX was all that, it would still be at the top of the food chain. It ain't. It couldn't perform.
Now, "UNIX The Philosophy" is alive and well, having transcended its earthly manifestation to become a mindset. It loaded itself into wetware. Pretty goo feat if you ask me.
Ultimately, let the best software win. The rest can go to bit-afterlife.
"Piter, too, is dead."
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."
Why cant we have binary compatibility too :(
"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.
I was under the impression that Linux was based on the POSIX spec from the get go.
"Ever thought it was difficult to write software for Linux? For multiple distros?"
No. For Windows? Yes. At least Linux has an organized filesystem, with Windows, headers and libraries could be anywhere.
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
If you want to write for distro foo, you release the source code and get to work collaborating with distro foo. Someone will package your program, and you'll be fine.
If you don't release source code, you can expect endless pain, and I hope that doesn't change.
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
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.
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.
I've hated this whole fragmentation thing all along. It would be so much nicer to have a unified system like LSB4 claims to offer. This can't come soon enough.
Sure. You just have to tell everyone what the BEST way is.
Actually, it has EVERYTHING to do with it.
Each distribution can take whatever path it thinks is BEST and the results will speak for themselves.
If it succeeds, then others can copy the improvements made by it.
It's easy to look backwards and see what you believe to be a straight path of development. But if you look at each point in time, you'll see LOTS of different approaches.
It's impossible to look forward and choose the best path TODAY for development of features that will take 2 years to implement.
Until you can do that, telling distribution X that it is wrong for choosing a path different than distribution Y is beyond silly.
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...
#!/bin/python Whoops! Doesn't work on distro Foo!
/usr/bin/ on distro Baz!
#!env python
Whoops! env isn't in PATH on distro Bar!
#!/bin/env python
Whoops! env is in
So on and so forth. Which is why the LSB is important to people like Python developers.
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.
Distribution compatibility and package management is a big problem for most, if not all developers, and has been for a very long time.
Debian focused on and solved this problem with their FHS (the whole lwn discussion on LSB4 is here), and take packaging and interoperability seriously (they also take distribution seriously, but other distros do that too). But IMHO, Debian represents the amount of rigor, effort, and time it takes to get these non-glamorous 'administrative' things right. In particular, a commitment to 'must pass defined installation/filesystem/interoperability test suite' over 'rpm -i seems to drop stuff in place ok' is historically sufficient to make installation reliable, and you could moot the point as to whether it's necessary now, and importantly, in the future.
If developers provided hints (in the form of a skeleton debian control or rpm spec file) describing even roughly
I think it would go a long way towards helping distribution authors. Even a text file (README.packagers.txt) with a couple paragraphs of prose describing this would give a big boost to packagers, and in turn, to the interoperability of the software with others as a good distro constituent. Debian recognized this, and IMHO the sooner developers visualize helping distribution creators by feeding this kind of information forward, the sooner distributions will converge on internal interoperability, leading to higher quality distributions, and subsequently to FLOSS maturing faster.
Actually, PHP uses both != / !== and == / === as comparison operators.
== / != checks that the values are "equal" (same value, but not necessarily the same type; ie. 1 == "1" is true)
=== / !== checks that the values are "identical" (same value and data type; ie. 1 === "1" is false)
See http://php.net/operators.comparison
So far, so good.
Huh? I run "bash" on all kinds of distributions. Not to mention Apache. And Samba. It's trivial to run the same code on different distributions.
Again, Apache, Samba, bash, etc.
We're already there.
The GPL rocks.
PHP... pheefff... I was talking about manly, virile languages such as Assembly. :P
Don't ruin my wisecrack with facts! :)
Send your spendthrift head of state this
!= in assembly?
Since when?
...there are a lot of distributions, good (not necessarily too popular) ones, apart from ubloatuntu, red hat etc, which are in use and new ones are being developed all the time...how do they expect to keep up with all of these and vice-versa ? Who's complaining anyway ? Everybody's in awe of open source and Linux. Introducing standards , man it sounds evil.
Except for the fact that it isn't at all in the FHS which already has enough problems with it being very open to interpretation (and sometimes extended... RHEL, what's /net, how does it differ from /srv). Symlink farms mean that you're doing something wrong.
/srv/httpd to /var/www, because that's where apache has been for the last fifteen years! If you have a place for servers, then, what belongs in /opt and what belongs in /srv? If it's a network server, does it go in /opt, /srv or /net? If it's over NFS, does it go in /export/home, /data/home or /home? You cannot separate directory structures by use because much of the data we have has multiple uses.
I've already seen distros symlinking
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
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.
.. is that you just cant try out software quickly without a lot of hassle. For ex. there is a new software that can do $cool_thing, on windows I just download, install, try it, either uninstall or keep it. In Linux if its not packaged for your distro you cant do that quickly, even if its GPL'ed etc.. Most of times they'll give you source and let you compile it by yourself which takes way too long and for most end users is far from convenient. Heck its easier to quickly test new software in WINE rather than to wait till its packaged for your favorite distro.
They don't want what happened to UNIX happen to Linux?
"But, Doctor Evil, that already happened."
The horses have escaped and had children.
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)
The problem with the *nix community has been and always will be the very thing that makes *nix so attractive: open, availability for forking, etc...
As a code monkey, I have been a fan of linux as long as I can remember. I can also say that in all that time, THIS issue, more than any other, has always kept *nix from gaining real traction in the biz world.
CIO: "So I can't REALLY switch between distros because of library differences"? ... and no, I'm not trolling.
DEV: "Yeah thats right."
CIO: "Then what exactly is the difference between this and windows, other than lack of support?"
DEV: "Ummm.... well we can see the OS code and change it"
CIO: "We make widgets not OS's right?"
DEV: "Yeah..."
CIO: "So who cares?"
DEV: "Ummm...."
Opinion:=TMyOpinion.Create(Me);
RHEL, what's /net, how does it differ from /srv
/net is for mounting remote network filesystem shares, while /srv is the opposite, that is local content being shared with remote hosts through various protocols. So as an example, the NFS server could use a subdirectory of /srv for exporting local files, and a client could mount that remote share in a subdirectory of /net.
Don't write your code to rely on v 2.3b of some obscure library that some other obscure programs may need a different version of and may not exist on some systems anyway. Stick with core libs like libc etc and you can't go wrong. Or even better just distribute a statically compiled binary.
"Each distribution can take whatever path it thinks is BEST and the results will speak for themselves.
If it succeeds, then others can copy the improvements made by it."
Yea, they've had some time to work this stuff out and it hasn't happened. You assume that the best solution will win, and in Linux that isn't the only deciding factor. People choose distros based on things ranging from "i hate novell" all the way to "it had blue wallpaper".
How about all these distros agree on something beforehand? This community spirit stuff is supposed to enable people to work together, not go in 50 different directions and hope something sticks to the wall eventually.
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.
OK, that actually makes sense. I've always mounted network file systems under /mnt/hostName, but /net is a better solution. Thank you!
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
So? If it works, it works.
Because that requires something known as "prescience". They have to know BEFORE THEY DO IT which options are best.
Again, when you know the future so well that you can tell everyone the best approach, feel free to build the ultimate, perfect distribution.
Until then, the experimental approach has worked so far.
And an example of that would be ... ?
And what is this "guarantee" that you're talking about?
So your evidence that the GPL doesn't prevent fragmentation is ... the GPL preventing fragmentation.
What you are claiming as "fragmentation" is more correctly known as a "fork".
The GPL encourages forks. That is how different concepts are tested.
Yeah, you need something like the GAC and SxS in Windows. Even the Java guys have identified this ancient problem and are taking steps to mitigate it. What have Linux done? NOTHING!
A "liblsb" doesn't sound like a bad idea at all. Let the distros implement something in whichever way they want, and let liblsb abstract it.
Hardly applicable to all the problem areas, but it sure could help in some, like such as your "getPathForUserInstalledSoftware()"-example.
The trouble is, LSB would essentially turn into ICANN in that regard. How do you determine what qualifies a library for inclusion in LSB except by charging like we do for domain names? Of course, there could also be a vetting process, but one person decides that the vetting process is not working for them, and suddenly you have an alternate version of libSSL floating around that's required for a specific program, and before long the entire thing falls flat.
We need things to be as much as possible the same. That way, all we have to do is a few autoconfig hacks, which hopefully will disappear soon enough (to be replaced by other dissimilarities we need to standardize.)
From my own experiences the only thing that has been a problem with commercial applications has been those that either outright refuse to install if it isnt "distro X 0.2.3" or those that relies on a specific version of a library instead of just linking it in statically. In all the cases i have banged my head against package management has been the least problem.
Most games for linux seems to run just fine on pretty much any distribution i have thrown them at. Some, like Urban Terror, Firefox or for example Tremolous doesnt even require an install. I have had the same installs of many apps through countless distributions and upgrades without problems. Why this isnt possible for commercial vendors is beyond me. Since size mostly isnt an issue just tossing the libraries needed with the application isnt much of a deal.
While i do agree that some form of standard is good i dont think it should be very big or extensive. The bare minimum to put your own libraries, binaries and config files on and nothing more.
Right now a big drawback of LSB is that it uses rpm while the most widely used distribution uses deb. It would be better to spend that part of LSB time and effort on making settings and files end up in the same places. That way packaging would be easier no matter what package management is used and making packages for many different package management system wouldnt be that much work.
HTTP/1.1 400
I don't know about you, but I have run VMWare server and workstation on Red Hat, SuSE and Ubuntu.
Yes, I have. I'm still running VMWare server on my Ubuntu box (Hardy Heron). It works. I have to run a script every time I upgrade the kernel, but that is all.
I have also run Apache, Samba, BIND and many others on different distributions. Without any problems.
I dont think on a technical it's so hard to build for multiple distros. You can pretty easily search for where things are and should go. I'm amazed how often 'alien' works to install rpm's or whatever on deb systems. Its just all the possibilities for libs to use in an app and all the versions of each. If you standarize too much, then whats the point of distros anyway? But LSB will make it easier for projects/companies decide to port or build for linux. To give them warm fuzzy manual and shrink the learning curve, on paper. Whatever if it is good it'll be good, if it sux no one will follow it. go darwin go!
Support bacteria, the only culture most people have.
Standardise on one and only one distribution. Dont give a %&& about the others.
Release the application as a virtual appliance for the virtual enviroment of choice. Go have a coffee and scoff at the poor sods who have to build their apps for several versions, languages and servicepacks levels of Windows etc.
HTTP/1.1 400
So? Fragmentation would be when they did NOT work.
Since they DO work, that is not fragmentation.
Yeah ... so it does work.
Again, fragmentation would be when it did NOT work. Not when it DOES work. Okay?
Why are you bringing that up? If the code runs, the code runs. You're trying to introduce things like EULA because ... ?
And since you've already admitted to the fact that they DO run ...
There is no fragmentation and the GPL still rocks.
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)
CMake.
But inclusion of a library should not mean that any distributions should have to include it. It just mean that the program can query "is this library installed". So the only thing they really need to agree on is what to call the library. I think they can agree on that.
So if you have a minimum linux distribution that just include the kernel and a static linked bash, you might have a correct implementation, that just return null to any library query.
But the point is that there are 2 different and independent problems that need to be solved.
1: How do an application query about the existens of software(library, compiler, awk and so on), default paths and other operations that differ from distribution to distribution.
2: How do we ensure that the distributions include needed libraries.
My solution would only solve problem 1, but I really think that is the big problem. Most distributions are good at including libraries, and when I run into problems with applications needing a library, the problem for me is not "Hmm, is this included in Fedora core" but more like " I know this library is here someware, but I really have no knowledge about what package contain it. ).
If a user is running "Fedora core 2" which only include qt3, and my program require qt4 the only solution is to tell the user to upgrade his linux distribution, or install the library himself.
Also, having this library, would make it easy for an 3. party developer to find out what distributions have all the needed library, so the "Get all distributions that have all needed libraries" could be a simple, but very helpfull tool. Then the developer can either do a "This is good enough" or static link the libraries that are not common enough. But having to static link to the qt3 library, because the application can't ask the distribution to install it if it is missing(With user accept ofcause), or because there are so many places the library can be located. That is stupid.
And once someone have implemented this library, it would be easy to define a set of "Standard Desktop linux 2008 libraries and tools" that the distributions could support.
Cross-distro binary compatibility? If so, and if it does happen, then we can finally claim the Year of the Linux desktop. GNU/Linux needs a single package manager, this will make it easier for users and developers.
GENERATION 25: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
And how exactly is competative feature evolution between distros meant to help improve the situation for developers? Survival of the fittest feature, as you advocate, is anathema to providing the distro neutral development environment the LSB are aiming for and developers would love to have.
The real danger of Linux fragmentation has nothing to do with licensing and everything to do with NIH syndrome. Having everything GPL has done little to pull the Linux distros together. It's the urge to have a competative advantage, to one up the other fella that forces the distros apart. This is why the LSB is so important: it helps to counteract that!
How stupid are you? Oh, I get it. You're some uninformed kid who's trying to dig himself out of the hole he's argued himself into.
I copied Apache from Debian Sid to Ubuntu Hardy Heron. It worked.
I copied Apache from Fedora 9 to Ubuntu Hardy Heron. It worked.
Looks like you don't know shit about what you're talking about. But what did I expect?
Why? It amuses me to mock kids like you in public. I have facts, you have your opinions. Sucks to be you.
It's funny because you keep trying to bail yourself out with rhetorical questions. Because you don't know the answers and you're hoping that I don't, either.
Sucks to be you. The modules get recompiled because they need the exact kernel version number. That's all. That's why the same code will compile on each kernel update. 100% of the code is the same.
Let me guess, you're still living in Mom's basement.
Yeah, sure you did. LOL
I'd stop trying to pretend that you know anything about what you're talking about.
You're confusing 3rd party libraries and the vendor's support for them with Linux.
Linux is the GPL'd portion. You can fix bugs in Linux.
With a vendor, you're fucked. And if you DID work on such a project you would KNOW that. LOLx2
Keep talking. It's hilarious. :)
So Linux is "fragmented" because your 3rd party vendor's EULA states that they only support Red Hat 4. LOLx3
And, as I've already shown, Apache DOES work. But feel free to say that it MIGHT not. LOLx4
LOLx5
But ... somehow ... Apache can handle it. And Samba. And BIND. And dozens of OTHER apps.
But YOU ... you have PROBLEMS ... therefore Linux is "fragmented".
LOLx5
When a thousand other people are doing exactly what you claim CANNOT be done ... sorry, I'm going to have to go with the thousand who can do it. Sucks to be you. LOLx6
It's like you're retarded or something. You CANNOT see the difference between your 3rd party vendor's EULA and Linux.
Oh, it's because you're too stupid to understand the difference, isn't it?
The LSB have been trying that since 1998.
They've failed for 10 years.
Yet people like you (stupid people) STILL claim that the LSB is needed because Apache and Samba and others CANNOT do what they've been doing for YEARS.
I have facts. You have your opinions.
The facts contradict your opinions.
Linux is NOT the same as a 3rd party vendor's EULA.
Sucks to be you.
LOL
Ahh this seems like such a good time to mention this again: Too many CHOICES in software not always a good thing, kids.
LSB is trying to remedy the Fallacy of Choice.
It won't succeed, because the devs simply don't care about usability -- they care about things only developers care about and 99% of the rest of the world doesn't.
(Thus, Linux has 1% market share on the desktop. Funny how that works.)
I'll get marked as a Troll for this, but it's true. I'm a Linux fan, but I'll take a working desktop (Windows, Mac, doesn't matter) over the Linux desktop any day of the week, and DEFINITELY on patch/upgrade release day.
+++OK ATH