How the LSB Keeps Linux One Big Happy Family
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.'"
I don't think I've even heard the LSB mentioned in the last five years. (Most of the distro-related squabbling and fretting died down after the number of meaningful distros contracted from the days of Corel Linux boxes at the aisle ends in CompUSA.) If they've been quietly doing something useful all this time, kudos for them!
What I'm listening to now on Pandora...
I'm very curious to see where this goes. The biggest issue I see is with adoption. There are so many distros out there, each with their own purpose and personality, and each one is focused on developing functionality first and foremost. I think it will be hard to convince all of them to pause that and shift their entire back end onto a standardized framework. Plus, the biggest strength in Linux is its diversity and flexibility. Adding such a standardized base might kill some of that flexibility. As I said, we'll see where it goes...
But does it support Linux?! Ummm, wait... DOH!
I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered. My life is my own.
But they really mean it this time. Honest. In fact, Duke Nukem Forever will be ported to Linux.
Source already seems to be an acceptable de-facto standard for distributing programs in the least OS-specific way. Let's stick to that :)
...to create a binary-level interface that PRIVATIVE-LICENSED application developers can use to create software which will run on any distribution of Linux.
There, corrected for you.
LSB brings the distros all together--it gives them something in common to ignore.
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 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?
The kernel API also needs to be stable (or so do vendors like National Instruments think).
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 "sarge"), this issue evaporates under closer scrutiny (i.e. the end-user just needs to use Debian's "alien" program to transform and install the foreign RPM packages in the native package format).
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
... 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?"
"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 alienize a RPM will almost surely fail in subtle manners. It's as simply as that if I, as a user and sysadmin, wanted to install RPMs, I'd be using a RPM-base Linux distribution.
And then, the only packages I've seen that LSB compliancy made sense were privative-licensed and binary-only distributed, so no amount of LSB-compliancy would make me happy to use them.
"The idea is that it will no longer matter what distro you use"
Almost true but then, if it makes no difference why should I use any other? That's why Red Hat is the strongest pusher of the LSB among distributions: they hope that if they can convince enough people that indeed it makes no difference their dominant position and the network effect will sweep out rivals eventually. Then it won't be that it doesn't matter what distribution you use but that there will be just one distribution to choose from.
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.
Because the LSB is not based on Debian, but it should be. Debian is the OneTrueWay(tm), all other distros are wrong.
The really sad thing is: I'm not being sarcastic. I bet most people reading this will scoff, but what other distro orders things so consistently and logically?
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>
Nope, it would be -1 Redundant. No need to state the obvious.
"...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.
Why doesn't the gene pool have a life guard?
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.
I believe the opposite is true. Greater compatibility leads to more choices, not less. You eliminate vendor lock-in and allow easy migration to other distros. Microsoft knows this; it's what prevents people from leaving Windows.
Let's face it: if Wine were 100% reliable, Windows would be dead. The LSB seems to accomplish much the same thing.
Bender: Blackjack and hookers?
(On second thought, forget the Blackjack!)
It must have been something you assimilated. . . .
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. And most of the ones that aren't in the repos usually either A) Are minor software projects that very few people use B) Have .deb and .rpm files available for download C) Maintain a private repository to easily download software or D) have a binary that you can just click and it runs.
There is no need for yet another "standard" to install programs on Linux. And honestly, having RPMs and DEBs keeps all the major distros happy and most of the other distros that don't use RPM or DEB files for package management are either specialty distros where little software is installed or aimed towards experienced users where compiling software by hand isn't hard for them.
Taxation is legalized theft, no more, no less.
People have been arguing about which text editor is better since before there was a Linux. Arguments aren't a symptom of anything in the free software world, they are a fact of life and sometimes even healthy. Gnome -vs- KDE, Vi -vs Emacs, Linux -vs- BSD, etc, etc..
You misunderstand, but it's not designed to work on everything either. Basicly, LSB is primarily (I'm just talking out of my understanding here) to be used by packages that just want to run on distros, but not be part of any dependency tree. A typical example would be an application that requires KDE/Gnome over version x.y - it basicly just wants to know if you meet the minimum requirements to run it. For that you would only need a LSB package that would install on any distro. The whole set of libraries, circular dependencies, pins and whatnot is still better left to RPM and APT - LSB is trying to create a simple cross-distro top layer so that 3rd party applications outside the repositories can be easily installed. I may be getting a little spoiled though, but it does not seem to be a big problem for applications to package it up in several different distro-specific formats.
Live today, because you never know what tomorrow brings
One of the main problems I see with adopting linux as a standard is that the distros vary too much from each other. One uses init.d, another event.d, one uses Gnome, another KDE, one uses LVM, another doesn't. I can see why companies don't want to support linux - there are too many variables. Linux is a mess.
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.
When our name is on the back of your car, we're behind you all the way!
>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.
Posted from my Android phone. Oh, I can change this? There, that's better...
Logic is in the eye of the beholder. As a programmer, I can tell you that what one person thinks is logical, another person thinks is a piece of crap. The LSB has something to offer, what's the harm in supporting it?
I disagree; I've seen a fair share of "Windows Sucks" first posts over the years that also tend to get modded down troll or flamebait. While there's a tendency towards groupthink here that can't be denied, it's not really that bad.
>I hate it that my otherwise fantastic Mandriva 2008-1 system can't be (easily) upgraded to Firefox 3.
I agree with your posting, but that is not the best example. I upgraded to FF 3 under 2008.1 fairly easily. Backports was added to my sources, and I just used "urpmi firefox3", wham, it was installed (and works, and doesn't break the firefox2 install). If you want it to replace ff2, then cd /usr/bin; ln -s firefox3 firefox and you are done. Granted, it COULD have been easier, but not without breaking FF2.
it would be nice if they could do something about unifying the audio subsystem on linux
openal esd pulseaudio etc etc
its a mess
back in the day we didnt have no old school
"I believe the opposite is true."
It truly depends on moment and situation.
"Microsoft knows this; it's what prevents people from leaving Windows."
But Microsoft is a 'de facto' monopoly. Of course it neither needs nor wants choices. What for?
But then, on an already diverse market, like it's the case for Linux, specially if you are in front for a head, as it's the case for Red Hat, you truly want to seem like you interoperate and then fail to do so in subtle manners (Microsoft knows that too and so it proves when trying to go into a new market): your apparent cooperation makes easy for the users from your competitors to migrate to your solution; your subtle incompatibilities retain those already in the net (have you seen those nets that have an ample entry but once you are in, the exit way is just a tiny hole?) so (hopefully) you grow your userbase at a exponential rate.
What does this have to do with what I posted: making a post that says only "Microsoft Sucks" will get you modded troll, just as quickly as making one that says "Linux Sucks". This has nothing to do with the modding issues you have had. If your post here is indicative, I suspect that the cursing and insulting might have more to do with the downmodding than your stance against linux or apple.
nope, that's just a bunch shilling baloney.
Ubuntu 6.06 has a compatibility layer that gives it LSB 3.1
That's it.
status of any later Unbuntu version is unknown, according to Linux Foundation
Debian says they're planning on it. Everyone hold their breath.
You've just said, if a KERNEL kills windows...which is nonsense.
a distribution is a complete operating system. there are many operating systems based on the Linux kernel. sure, many are very similar Yes, they do compete in a sense (and borrow from each other in a happy incestuous orgy that benefits everyone).
but the fact is use of Linux based OS is growing, even in spite of all this arguing that bothers you so much. tough.
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.
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.
Ignore this signature. By order.
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,
It's just the normal noises in here.
Am I the only one that thinks of Least Significant Bit, for the acronym LSB?
--why?
Read what Ulrich Drepper thinks of the LSB here: http://udrepper.livejournal.com/8511.html.
API is stable. ABI isn't. Every program distributed as source will be compatible with every future version of Linux (at least the 2.6.x series). Only those distributed as binary won't be compatible.
Are they still insisting on RPM, and acting surprised when the adoption rate is so low?
What about those of us who have a need for a good database on a good OS, and need it now?
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
use postgresql on GNU/Linux or NetBSD
Tried to type this ('lsb_release ...') in on my ubuntu box, and accidentally typed in lsd_release -a.
Sadly, nothing happened, which makes me believe the brown distro is bad.
Bullshit. The quicken using public doesn't care about Windows, they just want to use Quicken and not be harassed by malware, viruses, anti-viruses, spyware, spyware removers, etc, etc..
They can do that in Linux.
What is the problem with Cent/RedHat Enterprise?