Slashdot Log In
How the LSB Keeps Linux One Big Happy Family
Posted by
Soulskill
on Mon Sep 22, 2008 04:22 PM
from the behave-or-i'll-turn-this-distro-around-right-now dept.
from the behave-or-i'll-turn-this-distro-around-right-now dept.
blackbearnh writes "The Linux Standard Base is the grand attempt to create a binary-level interface that application developers can use to create software which will run on any distribution of Linux. Theodore Tso, who helps maintain the LSB, talked recently with O'Reilly News about what the LSB does behind the scenes, how it benefits ISVs and end users, and what the greatest challenges left on the plate are. 'One of the most vexing problems has been on the desktop where the Open Source community has been developing new desktop libraries faster than we can standardize them. And also ISVs want to use those latest desktop libraries even though they may not be stable yet and in some ways that's sort of us being a victim of our own success. The LSB desktop has been getting better and better and despite all the jokes that for every year since I don't know probably five years ago, every year has been promoted as the year of the Linux desktop. The fact of the matter is the Linux desktop has been making gains very, very quickly but sometimes as a result of that some of the bleeding edge interfaces for the Linux desktop haven't been as stable as say the C library. And so it's been challenging for ISVs because they want to actually ship products that will work across a wide range of Linux distributions and this is one of the places where the Linux upstream sources haven't stabilized themselves.'"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Hmmm.... (Score:5, Insightful)
Re: (Score:3, Funny)
Proust on a poodle!
Yeah. Doesn't the this have the nostalgic ring of soft, chewy, John "Maddog" Hall on the Slashdot front page, and crunchy goatse.cx [googlegoatse.com] on the inside?
Re: (Score:2)
That, and arguably the largest distribution (Ubuntu) doesn't have any LSB modules available:
tycho@mittens:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.04.1
Release: 8.04
Codename: hardy
I think this is a good idea, but for a project that has been around for 10 years, it doesn't have the highest adoption rate. I only just read about it the other day on a mailing list (not that I'm
Re:Hmmm.... (Score:5, Interesting)
Parent
Re:Hmmm.... (Score:4, Insightful)
It's ironic, because ultimately access to software so you can get done want you want to get done is the basis for the open source movement. Everyone gets all up in arms about "proprietary software", yet no one cares about proprietary distros and those issues with software lock-in. Why should I have to upgrade or change my LINUX OS just so I can use some LINUX software? Of course no one should. Or changing to a newer distro version just to have access to some drivers? That's total crap. The kernel was designed to have modules to allow it to be more modular, but obviously it's not modular enough yet, and/or because of the packaging mess, you just don't see driver packages shared out and such like you should.
Linux won't be as successful until users start being able to have easier and more flexible access to software they want, so I wish the LSB luck in bringing order to that chaos since no other groups have really stepped up to address interoperability issues like they have that I know of besides the Freedesktop.org group.
Parent
Re:Hmmm.... (Score:4, Informative)
The truth is ubuntu doesn't have any LSB modules available by default. BUT, don't be lazy, open Synaptic Package manager, search for lsb package, select it for install and than:
petar@aurora:~$ lsb_release -a
LSB Version: core-2.0-ia32:core-3.0-ia32:core-3.1-ia32:core-3.2-ia32:core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-3.2-noarch:cxx-2.0-ia32:cxx-3.0-ia32:cxx-3.1-ia32:cxx-3.2-ia32:cxx-2.0-noarch:cxx-3.0-noarch:cxx-3.1-noarch:cxx-3.2-noarch:desktop-3.1-ia32:desktop-3.2-ia32:desktop-3.1-noarch:desktop-3.2-noarch:graphics-2.0-ia32:graphics-3.0-ia32:graphics-3.1-ia32:graphics-3.2-ia32:graphics-2.0-noarch:graphics-3.0-noarch:graphics-3.1-noarch:graphics-3.2-noarch:languages-3.2-ia32:languages-3.2-noarch:multimedia-3.2-ia32:multimedia-3.2-noarch:printing-3.2-ia32:printing-3.2-noarch
Distributor ID: Ubuntu
Description: Ubuntu 8.04.1
Release: 8.04
Codename: hardy
So next time, before writing something, check your facts first.
Parent
This should be interesting... (Score:5, Interesting)
Re:This should be interesting... (Score:4, Informative)
Parent
Re:This should be interesting... (Score:5, Funny)
Parent
Re: (Score:2)
WHOOSH!
Re:This should be interesting... (Score:4, Interesting)
Yet none of this stops Oracle RAC from installing on
Debian or Ubuntu if you are stubborn enough to lie to
the installation GUI.
If the LSB makes it easier for a Loki installer to
"work everywhere" then it matters. Otherwise it
really isn't that meaningful. A lot of the stuff
that people tend to complain about really doesn't
matter so much in the end.
Although better alien package handling all around
could be beneficial to everyone.
Parent
Re: (Score:2, Flamebait)
"Yet none of this stops Oracle RAC from installing on
Debian or Ubuntu"
True. Yet no ammount of LSB stops Oracle to only certify this or that platform (like RHEL 4u2 or Ubuntu Strange Scarab, or SUSE 10 or whatever) instead of, say, LSB 2.0.
So, the LSB is mainly aimed at attracting privative software like Oracle to Linux (who else need guaranteed ABI compatibility when you can recompile?), no wonder so many distributions don't care so much (especially when the "middle ground" that it's the basis of the stand
The first step would be dumping .rpm. (Score:5, Insightful)
I don't care if their "standard" only requires a "sub-set" of the RPM format. Just dump it.
Write the specifications for a .lsb install format.
Then encourage the other package systems to include your format in their systems. I should be able to apt-get install foo.lsb and have it SEEMLESSLY integrate with Debian's package management system. And the same file with rpm -i foo.lsb and so forth.
There, the first problem is solved. People can easily identify the LSB packages and install / remove / upgrade / back-rev / whatever them.
And they would be completely platform NEUTRAL which SHOULD have been their first goal.
So, now that you can install their packages ... they need to start identifying which libraries and such are required by foo. Is there any reason that those libraries would not also be distributed as .lsb packages? Meta packages if necessary?
And don't even get me started on where Apache gets installed vs where they tell you a commercial web server should be installed. Apps is apps. It doesn't matter whether the distribution shipped it, you built it from source or you bought it from an ISV. Unless you're the LSB. Then it matters.
Parent
Re: (Score:3, Insightful)
> So, the LSB is mainly aimed at attracting privative software like Oracle to Linux (who else need guaranteed ABI compatibility when you can recompile?),
At this time I'm convinced that having to rely on distributions (or worse, 3rd party distro specific packages) for software is stupid. I'll be happy when I'll be able to install any binary package, free or privative, with source available or not, not being constrained by using distribution X or using the version and tweaks distro X provides for that part
Source code (Score:4, Insightful)
Source already seems to be an acceptable de-facto standard for distributing programs in the least OS-specific way. Let's stick to that :)
Re: (Score:3, Insightful)
You're kidding, right? Or at least trolling?
Ever tried to upgrade or remove a package compiled from source? Even if 'make uninstall' was provided in the first place, it's now gone when you removed the original source.
Re: (Score:3, Insightful)
Wow, insightful? Suggesting source is the standard way is just awful. Source doesn't resolve its own dependencies. Source can result in a several day install. Source isn't appropriate at all for underpowered devices and devices with very limited drive space, such as a Zaurus or an Asus EEE (and why shouldn't small devices be able to participate in a standard?). Source distribution is extremely network inefficient compared to binaries. Source has no guarantee of building on your system (trust me, I ran
Yes, they all happily ignore it (Score:3, Funny)
LSB brings the distros all together--it gives them something in common to ignore.
LSB is not enough (Score:3, Informative)
Re: (Score:2)
If NI are writing kernel-level drivers, then perhaps.
However, 99% of "normal" software shouldn't need to access the kernel directly. Even at that, modules seem to remain pretty stable. If NVidia and ATI can keep drivers for their hardware relatively stable, NI should be able to do the same, considering that their hardware appears considerably less complex. Similarly, one would think that a large percentage of NI's userbase would have a pretty strong interest in a Linux version.
Re: (Score:3, Interesting)
If so, they sure are ignoring us. The last release of their Linux driver package (NIDAQ) was in 2005 [ni.com]. Installing it on a recent version of Linux proved practically impossible. Finally after a few days of installing and reinstalling different distros I got it working on a 2-year-old version of SuSE. But basically determined that outside of personal use, this is totally impossible to expect customers to use if we are to integrate an NI board
Re: (Score:2)
It would make my organization... (Score:5, Insightful)
... A lot happier.
I'm really tired of having companies come in with some product that we are "dictated" to use (yes, I work for a US government organization), only to learn that my chosen linux platform isn't supported...
That is a battle I would love to sweep under the carpet with, "why don't you support the LSB?"
Binary compatibility? (Score:5, Insightful)
"...to create an x86-32 (and maybe, if you're really lucky, x86-64) binary-level interface that application developers can use..."
There, fixed that for you.
Best of luck getting your binary package to run on Linux/PPC, Linux/ARM, Linux/Alpha, Linux/Sparc, etc...
If you want your software to run on multiple Linxen, you need to make it open and let the distros compile it and build the packages. That's it.
Re: (Score:2)
Bollocks.
s/Linxen/Linuxen/
Re: (Score:3, Funny)
If you want your software to run on multiple Linxen, you need to make it open and let the distros compile it and build the packages. That's it.
Or use Java :-)
*ducks*
Just guessing... (Score:3, Funny)
Bender: Blackjack and hookers?
(On second thought, forget the Blackjack!)
Barriers to adoption (Score:5, Insightful)
I think things would be a lot easier if there was a minimum support standard that all distros held to. ie, a standard desktop, a standard filesystem hierarchy, a standard package manager, etc. I don't mean that these are the ONLY desktop, package manager etc, just that on supported distros they are guaranteed to be there.
Re:Barriers to adoption (Score:5, Insightful)
Parent
Java... (Score:4, Insightful)
Because I've given up on all the dual APIs with Gtk/Qt/Wx/GNUStep. I don't care anymore. Life is to short. Code with what works today.
A desktop Java program under Linux works just as fast as a Qt/Gtk based one. Java has insignificant load times on my minimal memory PII test platform compared against the Qt/Gtk libraries running under Window Maker (A simple Dialog program to read /proc). If I need to, I can go JNI. I'm tired of trying to author different Qt/Gtk wrappers for different versions. Enough said. All my programs work fine under the JVM for Mac/Linux/Windows.
Thank You SUN for Java 5 and 6. A much better VM platform than 10 years ago. Thanks to JavaME, I can run my programs on my Cell phone or my embedded Linux box.
DISCLAIMER: As a programmer, I can't publish load times/Performance issues with any product from Microsoft against any other. I will get sued for posting benchmarking results that show Microsoft Windows based systems, performance wise, SUCK compared to BSD/Linux systems on the same box.
My opinion and it doesn't matter. I reserve the right to be wrong.
Enjoy,
Propaganda (Score:4, Interesting)
Re: (Score:2, Funny)
But they really mean it this time. Honest. In fact, Duke Nukem Forever will be ported to Linux.
Re:Is this teh year? (Score:4, Funny)
Ported?
Dear sir, I am pleased to inform you that Duke Nukem Forever is being developed on Linux and will be available as a free download in both RPM and .deb formats as soon as Linux gains a majority share on the desktop.
Parent
Re:LSB - just say no (Score:5, Interesting)
It's for rpm based commercial distros. Debian doesn't fit, and the "alien" program doesn't work on everything.
I note that Debian Etch is listed as planning to become LSB compliant on this page: http://www.linuxfoundation.org/en/LSB_Distribution_Status [linuxfoundation.org] Ubuntu is already LSB-compliant. Neither of these appear to be "RPM-based commercial distros". Once Debian is LSB compliant, the alien program will work on any LSB-certified application.
Since I use Debian on servers and Debian-derived on desktop, I don't care about the LSB, I care more about the standards of the Debian project.
The idea is that it will no longer matter what distro you use: if an LSB application works in Red Hat, you know it will also work in Debian. Why is that a bad thing?
Parent
Re: (Score:2, Troll)
"I note that Debian Etch is listed as planning to become LSB"
Well, AFAIK is mostly compliant if not completly compliant but for the paper. But this compliancy is basically of the kind of POSIX compliance on Windows NT: good to put it on a brochure and almost nothing else. Installing a LSB-compliant package on Linux means basically forget about the whole distribution (since it'll be a RPM package that won't integrate on the standard package database) or lose both compliancy and working ability since alieni
Re:LSB - just say no (Score:5, Insightful)
Let's face it: if Wine were 100% reliable, Windows would be dead. The LSB seems to accomplish much the same thing.
Parent
That is the idea. (Score:2)
But the reality is that they've been working on this for over a decade and have yet to show a single ISV who supports it.
Their approach is flawed.
What the ISV's really want is what they've been doing for years. They "partner" with a distribution and, officially, support very defined releases from that distribution.
Re: (Score:3, Interesting)
Corrections (Score:2)
I care more about the standards of the Debian project.
Which, is compliant-ish, which is about as good as it gets in regards to many industry standards.
LSB compliance is important. Coincidentally, it makes the experience from one distro to another roughly equivalent. This makes the whole distro universe a heck of a lot less like buying a used car. (I couldn't resist another car analogy)
Wikipedia to the rescue, Since Debian already includes optional support for the LSB (at version 1.1 in "woody" and 2.0 in
Re:LSB - just say no (Score:4, Insightful)
It's for rpm based commercial distros. Debian doesn't fit, and the "alien" program doesn't work on everything.
I've always known it: if Linux eventually kills Windows (somehow), Linux users will just turn "against their own" and start attacking other Linux distros than their current favorite, starting with the big companies that maintain a distro on their own.
But I have to say it's scary to see the symptoms of this so early when Linux doesn't even have some respectable % of the desktop market. This is not a winning behavior for sure.
<teary_eyes>Can't we just get along?</teary_eyes>
Parent
Re:LSB - just say no (Score:4, Interesting)
>People have been arguing about which text editor is better since before there was a Linux...
Perhaps, but nobody's suggesting that anybody build large commercial apps using vi or Emacs as an application framework. That said, people (including in this thread) are asking the likes of Oracle to support multiple Linux distros. At that point, havint the kind of silly 'vi vs. emacs' argument you mention as harmless is anything but.
Until something like the LSB really takes hold, Linux will be great for
1. open source stuff distros can include in their distro-specific repositories.
2. Non-gui stuff, where the libraries *are already* largely standardized.
3. Low-level gui stuff (coded at the X11 level) like Flash, which doesn't need lots of specific desktop libraries around.
4. Statically linked stuff, like Acrobat and OOo that can be released with no dependecies.
That's a lot of stuff. Enough to run a nice EEEpc. But not enough for the general Quicken-using public to use.
Hell, even Firefox has so many desktop toolkit dependencies that it needs to be integrated and released by the distros, whereas Opera can put out a statically-linked QT-level version that works for most distros. I'd like Firefox to be releasable that way too. I hate it that my otherwise fantastic Mandriva 2008-1 system can't be (easily) upgraded to Firefox 3. With a stable GTK+ implementation, standardized across distros, that would be a snap. But it doesn't look like we'll ever get there... or that we're even trying.
Parent
Re: (Score:3, Insightful)
maybe Oracle shouldn't run on Linux. maybe people that want such a dbms can buy their $760,000 DBMS and run it on HP/UX or windows. fuck 'em. meanwhile the open source DBMS feature set grows and soon will bite Oracle in the ass.
Re:Linux sucks (Score:5, Funny)
Parent
Re: (Score:3, Insightful)
Re:Obligatory... (Score:5, Funny)
Parent
Re:I don't get this... (Score:4, Insightful)
I've dealt with dependency problems far more than I'd care to - often even being able to rebuild a source RPM on a newer version of the same distro turns into a nightmare, much less trying to massage a binary RPM into place.
Parent
Re:I don't get this... (Score:5, Insightful)
I honestly don't get the need for LSB. Perhaps 10 years ago when we still had problems with RPM, but not today. Most people will never need to download software that isn't in the Ubuntu (or insert favorite distro here) repositories.
LSB specified file system layout when I was in the business about 10 years ago (I shared in the pain of converting Turbolinux from /usr/man -> /usr/share/man, etc. etc.).
Library version numbers are still important. C++ binaries are notoriously sensitive to gcc version and we must be able to support truly alien (ie non-distro software).
We will have truly arrived as a desktop O/S when it is possible to buy from Blizzard a World-of-Warcraft.tar.gz tarball that will Just Plain Work no matter which Linux distro we are using. Never mind packaging issues, though it would be nice to have RPMs of WoW.
Parent
Re: (Score:3, Interesting)
The GP is basically right, even though he's technically wrong. He's technically wrong, because theoretically people want to run proprietary as well as free software on Linux, and, e.g., Ubuntu isn't n
Re: (Score:3, Insightful)
>Most people will never need to download software that isn't in the Ubuntu (or insert favorite distro here)
People who are using Linux to make money almost invariably use it in conjunction with proprietary software, like databases, custom apps, etc. Until recently, you needed to download Sun Java binaries for any serious Java development. Also, some of us are *writing* proprietary software for Linux.
But sure, if all you ever do with Linux is write a dinky php home page that you serve out of your mom's bas
Re: (Score:3, Insightful)
Most people will never need to download software that isn't in the Ubuntu (or insert favorite distro here) repositories.
This is one of those maxims that sounds right, but inevitably isn't in practice. It's truer to say that all people will mostly only need software that's in the repositories. A stunning array of functionality is covered, but most people have at least one package they need that isn't. That can either be because it's proprietary (like Skype), or because it's too obscure, or because the version that is included is out of date. I've personally had all these problems, and I can't think of anyone I know who ha