Slashdot Mirror
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'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...
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 LSB standardized on RPM. This was a rather contentious blow to distros that use a different packaging system. I *think* Debian achieved compliance by including the Alien package manager, but they specifically do not claim compliance.
Under the influence of Post-Cyberpunk Gonzo Journalism
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...
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?
Read what Ulrich Drepper thinks of the LSB here: http://udrepper.livejournal.com/8511.html.
If so, they sure are ignoring us. The last release of their Linux driver package (NIDAQ) was in 2005. 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 into our product.
Finally discovered that their "register-level driver" is way more efficient and easier to integrate into a software package. Even open source! We're using it and are happy with it, but unfortunately due to the fact that they are using a "BSD license" (although it doesn't actually say that anywhere on the product, they confirmed it in a forum post.. the software just says "copyright national instruments") GPL-incompatibility issues are stopping us from adding new features, like for instance having it play nice with udev.
After contacting them they seemed interested in rectifying the issue but since seem to have dropped it.
I dunno, they just don't seem to be able to keep up with Linux. You'd think compiling against the latest distro and putting out a driver update or two in a 2-year period wouldn't be so hard for a company that's all about hardware.
A good side of course is that their hardware is fully documented. It's possible that a community effort like comedi is just a better solution in the long run. But I'd prefer it even more if there were an effort to get a standard interface for multifunction DAQs into the Linux kernel. Basically, the OSS model of long-term reliability is to play well with others and contribute your drivers to a larger project instead of trying to do everything yourself. That way everyone helps to port things forward when interfaces change. I wish more companies would realize this, but instead they fall back to NIH syndrome over and over again, making more work for themselves than necessary, and complaining that Linux support is too hard.
Meanwhile, is it _really_ necessary for the Windows driver package to be a freaking 1 GB DOWNLOAD!? When all I need is a couple of DLLs and some header files.
Whatever clown moderator picked "Funny" certainly isn't seeing as far as he ought to.
Really, what will happen if a central body, such as LSB, becomes a defacto "standards boss" for Linux?
With a slew of distros, you have redundancy of creativity. Vital if you're being targeted by enemies.
I really don't want LSB to get TOO successful, else it may become a "single point of failure" upon which merciless special interests may lean with all their weight.