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.'"

Comments

Hmmm....

[Otter]

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!

Re:Hmmm....

[Jeremiah Cornelius]

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 on the inside?

Re:Hmmm....

[Anonymous Coward]

I don't think I've even heard the LSB mentioned in the last five years.

Try reading Slashdot. There's six years just in first-line results of the first page.
http://slashdot.org/search.pl?query=lsb

Re:Hmmm....

[3p1ph4ny]

I don't think I've even heard the LSB mentioned in the last five years.

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 an authoritative source for all things Linux, but I am an enthusiastic user).

Re:Hmmm....

[Anonymous Coward]

alex:/home/steve# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 4.0 (etch)
Release: 4.0
Codename: etch

hahaha!!

Re:Hmmm....

[cyphercell]

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.

Re:Hmmm....

[CronoCloud]

[CronoCloud@mideel ~]$ lsb_release -a
LSB Version: :core-3.1-noarch:core-3.1-ppc32:graphics-3.1-noarch:graphics-3.1-ppc32
Distributor ID: YellowDog
Description: Yellow Dog Linux release 6.0 (Pyxis)
Release: 6.0
Codename: Pyxis

YDL6 is based on CentOS and thusly RHEL so that's why it's got LSB 3.1 compliance. And yes, mideel is a PS3. I chose YDL because my first Linux was the PS2's funky Kondara-ized Red Hat 6 and I wanted something Redhatty but with reasonably good online support via message boards and the like and good support for the PS3.

Re:Hmmm....

[Anonymous Coward]

Has anyone else noticed that all the best Insightful posts start with Hmmm...?

Re:Hmmm....

[Anonymous Coward]

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.

Re:Hmmm....

[xenocide2]

jldugger@jldugger:~ $ 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

Perhaps it's not as simple as you'd think.

Re:Hmmm....

[Anonymous Coward]

I don't think I've even heard the LSB mentioned in the last five years.

You want to know why? It's because Ubuntu came along and somehow eclipsed usage of all other Linux distros combined. There's your standard: Ubuntu.

A poignant graph: http://www.google.com/trends?q=ubuntu%2C+suse%2C+gentoo%2C+fedora%2C+slackware

Re:Hmmm....

[Yfrwlf]

And that's one of the biggest problems right now with Linux is packaging, and the LSB is aware of it, and they're trying to do something about it. Whether this is the best solution, I don't know, but any solution right now is better than nothing. I'm just appalled that ODF has such a march behind it, yet having at least one intelligent (upgradeable, removable, integrated with package manager) package format work across distros (all or most all existing managers made compatible with the format) gets completely neglected.

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.

Re:Hmmm....

[McGiraf]

Steve has is home on Alex ... hum.

Re:Hmmm....

[Anonymous Coward]

This one is better: http://www.google.com/trends?q=ubuntu%2C+suse%2C+gentoo%2C+fedora%2C+debian&ctab=0&geo=all&date=all&sort=0

Re:Hmmm....

[jbolden]

This argument has been on /. for the last dozen years. The Microsoft / Sun model of software distribution is:
software creater -> reseller / OEM -> customer which allows for commerce.
The Linux model is:
creator -> distribution -> customer which allows for an integrated and functional system.
There is no reason to bring to free software a distribution model intended for software sales.

Re:Hmmm....

[Yfrwlf]

That was the biggest total miss of my point I've ever seen. All software should be easily accessible so anyone and everyone can use it. If you're a developer and you don't want anyone using your software though, that's fine, few will then I'm sure.

Re:Hmmm....

[jbolden]

No it isn't a miss you are just failing to see why things are the way they are and what would be the consequences of changing them. You want users to have access to software from developers the linux model is distributions take software from developers. There is supposed to be a middle man there.

Re:Hmmm....

[Yfrwlf]

The middle man is the problem, and you should not need them. I want to get my software directly from the developers if I choose to do so. There is absolutely no need whatsoever for additional assholes getting in the way of this aside from presenting nice software bundles and offering support. Linux needs to be truly open and accessible, and for that to happen it needs to modularize itself in every way and free itself from proprietary distributors. I'm talking about freedom here, and I use Linux to have it, not to be locked into a specific software repository.

Doing this is very possible, all it does is require more intelligent programming, with standards and such in mind like with what the LSB and Freedesktop has tried to help promote, but it simply needs a little more communication with software packages, that's it. If you think there's some magical mystical barrier that prevents this from happening, why this is impossible for software to do, explain it to me. For DEBs and RPMs, most of each of them work in their respective package managers, yet neither managers have been made compatible with the other, even though all it takes is some additional communication. But go ahead, tell me why this communication cannot be done, why it's impossible to have at least one format that works with both systems? Technical details, please.

Klik exists, Zero Install exists, and of course not to mention Windows and OS X exist, so this can be done, all it takes is clear communication and at least one packaging format that the existing major managers are compatible with.

Distro companies wanting to fragment Linux by not working to resolve this issue are greedy assholes trying to pull users to their company by providing proprietary software that hooks you into having to get it from them and them alone, creating this Linux teat for their users that gives them the crack they need. Fuck that. Linux should mean freedom, not proprietary vendor lock-in.

Re:Hmmm....

[jbolden]

The issue is simple. Unix and Linux software are not self contained bundles designed to run in isolation. They assume chains of other related components. However they are flexible in a way that commercial software is not. To for example EndNote which is being discussed has a plug in for Word but not for OpenOffice, Pages, Lotus Word Pro.... Linux users want flexibility. So Linux software allows for flexibility in issues like dynamic linking of libraries to server dependencies to dozens of configurations. But, the distributions differ from one another in how they handle things. As a result configuration files need to be changed in complex ways between distributions.

The alternative would be some sort of unified handling which prevents distributions from being radically different than one another with respect to their core offerings: for example unified configuration managers.

Windows and Mac don't offer this sort of flexibility so they don't experience this type of complexity. They do have a base of standard components and don't offer complex towers of applications supported from different vendors. A good example is looking at Oracle which installs its own webservers and perl under Windows and Mac because it can't be sure of what is there.

While it is certainly possible that binary software directly to the end user might sort of kinda work in the end a system designed for flexibility will never be as uncomplicated as one that is not. For the same reason that Windows gaming is so much more complex than console gaming.

What you want is that something that by and large the Linux rejected early in the 1990s and has never been willing to make the trades for. You have freedom under Linux to get software from outside your distribution you just are expected to be skilled when you do it. The Unix platform that supports good binary compatibility is Solaris and OSX.

Re:Hmmm....

[Yfrwlf]

Thank you for your response.

As a result configuration files need to be changed in complex ways between distributions.

Trust me, dependency issues can be dealt with. Interactions between programs can be dealt with. That's the thing, is that they need to start being dealt with, instead of closing out interoperability issues by slapping users with proprietary software stacks. No, that's not how things should be, Linux should not become fragmented. I should be able to install the newest version of Firefox directly from Mozilla, and if Linux packaging was standardized, I'd also receive my updates directly from them as well, if I choose to do so. By keeping user's programs proprietary, they become isolated and dependent on the distro company, and that's what these companies want, and it prevents programs from being able to learn to play nicely with each other too. Many users are so suspicious of Microsoft and their lock-in tactics, yet Linux interoperability has been getting some neglect. If programs are designed well, they can function with other programs, they can resolve all their problems with cooperating with other programs. My main point here is that cooperation simply requires communication, and that's not a barrier that should exist anymore now that the Internet exists, the only barrier is more intelligent programmers.

Linux is powerful, and part of that power is it's flexibility, but it's very possible to retain that flexibility and power by being more modular. Basically, there's no reason that you have to have the configuration of programs centered around compilation, you don't have to have settings set at that level, you can instead have plug-ins and modules, etc. As far as specific settings which allow inter-program communication, again, communication and intelligent programming can resolve all these issues.

The alternative would be some sort of unified handling which prevents distributions from being radically different than one another with respect to their core offerings: for example unified configuration managers.

Communication of some sort certainly needs to happen. I'll tell you one thing developers hate though, is when they have to worry about a certain version of their software on a certain distro has been tampered with when users come to them crying about bugs. It's incredibly annoying for them to deal with that, and rightly so. When a program has been modified from the original code in any way, it's only polite to call it something different so that it won't get confused with the original. If Firefox was ever somehow compiled differently using different libraries or whatnot, Mozilla shouldn't have to support that version as it's a different version, because if those changes in library versions cause problems then it's the library developers who are at fault for not having a stable library API, etc.

The default main program and it's settings need to be tested more and it help the program to get more attention, and that's what should happen, and it also allows users to easily swap out the program with newer versions of the original program from the creator's website and not have to worry about special configurations. I'm not saying that distros need to ship all programs with the default settings, but clearly communication needs to occur here so that different programs can interact with each other. For example, the move to XML-based configuration files helps to standardize things so that any other program can pull up the configuration of another program. If one program uses another, quite simply, they need to be able to properly communicate and this is always true and is a problem that will never go away. So clearly here you need intelligent programming in such ways that allow programs to be aware of the requirements of another one, or for settings to be dealt with through the dependency tree system, or some method, so that this inter-program communication can occur without fucking up settings

Re:Hmmm....

[jbolden]

I read the articles, Ian Murdock is obviously reputable. But the key thing here is he is talking about binary compatibility without integration. In particular not handling things like dependency resolution, not supporting uninstall/upgrade in any clean way, not integrating into Linux configuration tools.....

Yes this is possible. And that is what I've been saying you can have binary compatibility that sorta works and integrate poorly. So I agree with the articles and I agree with everything Murdock said. It may be that you and I are simply defining compatibility differently. IMHO not integrating with all the tools is very similar to when I run a Windows app on a Mac or a Unix app via. cygwin on Windows.

But anyway if that is what you are aiming that I think is possible. Ian is a terrific community leader for almost 15 years.

Re:Hmmm....

[Yfrwlf]

I don't quite understand what you mean, I thought integration was exactly what he is talking about. He wants Linux to be a targetable platform, and so do I. I want software developers, both open and closed ones, to be able to release one package or one CD/DVD or whatever, and have it install and integrate easily regardless of the user's distro of choice. Like he said when he said there needs to be transferable apps not just programs, so not just binary compatibility is needed but package manager integration so that you can do all the installation and updating and such. That was exactly what the articles were about though I did read them a while back, but I'm pretty sure. Integration to me means iteroperating, inter-program communication, and that's just a communication problem. So, if the LSB wants to help function as a standards body, much like W3C for web standards or the Open Document Foundation for the ODF format, great, I hope that some Linux packaging standard gets adopted and soon, at least one, with more to come later, because I see software accessibility as the leading barrier to entry for Linux users right now. Most people are stupid, it's a fact, and if you don't like that word then unlearned, or ignorant, but regardless most of them will not ever learn to compile, and I want Linux to beat both Windows and Mac and everything else that's proprietary into the ground.

I see this problem as the only real proprietary thing on Linux right now, and it needs to be done away with with some simple planning and communication.

Re:Hmmm....

[Yfrwlf]

I mean don't get me wrong, DEB and RPM are great, I guess, but someone needs to make a format or a subsystem that will allow some kind of package to be cross-distro, so whatever it takes to make it happen, great. By using dependencies the way they should be used, you should be able to install anything. As long as it gets those libraries installed that the program actually needs, then there's no reason it shouldn't be able to run. If everything it needs can be placed as a dependency, in an organized way so that reuse of existing packages can be done if possible, then there's no problem. I think one of the issues is getting everyone to use a solid naming convention, and if that's all it is, that's just a simple communication issue. If I have to post up on a board someplace that I'm using the package name "awesomeness_program" for my program, so be it. If the organization running that system decides to be a jerk and start charging for name registration? Big whoop, you just update the packaging format standard to be able to use another naming standard, or change package formats altogether. Point being using standards doesn't mean lock-in, it just means consistent communication, and I know that if I were making a program, I would definitely want that consistency so my program could reach the masses as best it could.

Re:Hmmm....

[jbolden]

Read the article Ian is specifically saying he can't provide that level of integration. He gives examples like automated uninstall and upgrade as well as management system ( Red Hat Network and Novell ZENworks) as things that still wouldn't work under his scheme.

In other words I'm agreeing with Ian Murdock, what I was arguing LSB would not accomplish he is saying it wouldn't accomplish either even under his scheme.

In other words he agrees with you (as do I) that ISV want to treat Linux and not Debian, RedHat, Suse... as the platform and his feeling is that is possible provided you aim only for self contained apps that don't use the management systems. I agree that is possible.

Re:Hmmm....

[jbolden]

Take a look at the articles. Dependency resolution is one of the things that LSB doesn't offer. It provides a small set of dependancies already resolved and everything else is provided with the app.

Re:Hmmm....

[Yfrwlf]

Yes, but for package formats, name standardization is usually something which is wanted. DEB has it's own naming convention system for example. So, if the LSB wanted to be more helpful, they should consider becoming a standards body for a particular format of application packaging, and I'd guess they will if the Burgdorf format takes off.

Re:Hmmm....

[Yfrwlf]

If you read in part 2, he talks about registering the program with the package system, but not providing for dependency resolution other than the one big LSB compliant resolution, as well as some additional LSB "pieces", but to limiting it to that instead of worrying about the thousands of other packages, so you're half right. I don't really understand this though, because once you have the dependency system in place, you don't really need to "worry" at all. Sure, having a base set of packages I guess can be helpful, but I believe the package format and manager together could provide all the solutions needed to resolve any kind of problems with getting software.

I'm frustrated that decentralized package resolution development is occurring in "top-down" programs such as Zero Install, and not in the base package systems where they should be. Using decentralized packaging, you have URLs for all dependencies, and you could have multiple locations from which packages were available, and the system also incorporates key signing and hash checking to protect users from file fraud. Using this system a developer could actually make all the dependencies they are using available from themselves if they didn't want to point anyone elsewhere, but only the dependencies the user didn't have would be downloaded, instead of installing the whole whopping software bundle. In other words, it would allow you to utilize dependencies and save bandwidth and storage space (though both of those things aren't AS big of an issue now days as they have been) while not running into any kind of problems with "worrying" about the base package installation.

Any way, just the base implementation is good enough for now so that all Linux users will have SOME way of installing any software, but I believe there is a lot of room for improvement and that they should really take a look at all the things Zero Install is accomplishing.

Re:Hmmm....

[jbolden]

They might be able to do that, though to modify your suggestion slightly I would suggest LSB "virtual packages" be standards. That allows the distribution to continue have very different things in their actual packages and the LSB just guarantees the dependencies get resolved.

Re:Hmmm....

[Yfrwlf]

Oh, I think I see what you're saying, or in other words have packages have more than one name. Or perhaps more simply, they need to have a standardized name somewhere in the package metadata is all. You have a particular packaging format be standardized and in that you have a standardized name, LSB_Package_Name="blah" or whatever. Yeah I think that's definitely needed for decentralized package distribution, even if the naming convention part has to be somewhat centralized. Like I said, even if things went down the crapper with the naming somehow, they could just switch to either a different package format or a different naming convention solution.

Re:Hmmm....

[jbolden]

Yep a virtual package is a package with no contents but dependencies. So for example in RH you might have

virtual package apache minimal - minimal apache required to run (install 5 packages)
virtual package apache complete = everything for apache
(install 4 of the above 5 + 26 others)

Re:Hmmm....

[jbolden]

Remember zero install is designed for users not administrators to install. That's something right now that none of the systems: Windows, Mac or Linux handles particularly well. IMHO Mac is probably the closest with drag and drop install into user applications. Unix's make does a good job here but requires quite a bit of knowledge.

So I'd see what Zero is accomplishing as quite important but not necessarily the same sort of problem. I'd agree though that is LSB got it to work for admins Mac/Zero approach might be successful for non admins

again

[Anonymous Coward]

Let's re-invent UNIX ?

This should be interesting...

[EvilIntelligence]

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...

Re:This should be interesting...

[Otter]

FYI, the LSB started in 1998, the first Year Of Linux On The Desktop.

Re:This should be interesting...

[jedidiah]

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.

Re:This should be interesting...

[InsaneProcessor]

Linux On The Desktop? When did that happen? I am still trying to get linux to work as a M$ replacement and it still isn't even close to as easy to setup and use. Just try installing Flash to work in the browser. On the desktop means user friendly, which it still is not.

Re:This should be interesting...

[Otter]

Have no fear, good sir! Red Hat 6.0, with the GNOME 1.0 desktop, will solve all your problems. In the meantime, would you like to read an essay by Eric S. Raymond where he brags about how rich his LNUX stock has made him?

Re:This should be interesting...

[turbidostato]

"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 standard looks so much like "whatever is shipped on current RHEL"); but then, privative software vendors feel they need much more confidence in order to certify to a platform than a "of a kind" standard, so they are not strongly pushing for it either.

End result? Well, it's been -how many? six years? and LSB it's only known to a bunch of freaks.

No wonder, did I say that yet?

Re:This should be interesting...

[sir fer]

Slackware is not a good place to start. Try Debian.

Re:This should be interesting...

[spitzak]

WHOOSH!

Re:This should be interesting...

[goarilla]

huh just unpack the flash_player.tar.gz and
move/copy/rsync/whatever the files to your own profile's
Plugins dir or in the system wide Plugins dir

Re:This should be interesting...

[dotancohen]

Plus, the biggest strength in Linux is its diversity and flexibility. Adding such a standardized base might kill some of that flexibility.

Each distro can be as flexible as it wants to be within it's own native package manager's format. However _in_addition_ to that format, they would ideally all support a lowest common denominator. That way, software houses could package for that LCD and have it work on any distro.

Just this week I am fighting with LabView, trying different versions of OpenSuse, Mandriva, and Ubuntu trying to get it to install along with daqmx. What a pain! Projects like the LSB attempt to make this as easy as with Windows.

Re:This should be interesting...

[Shulai]

> 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 particular app. And then, software producers being able to provide binary packages themselves without caring about distro X or Y, just providing an easy to install package just as they do for Windows, including lots of FOSS apps available for Windows. Well, better than Windows I expect... zeroinstall is the most close to this, but neither zeroinstall, click, LSB or whatever else got any real traction...

Re:This should be interesting...

[Barsteward]

I think his point is that the install should automatically put all plugins into a standard system-wide directory (with an advanced option to allow it to be installed into your profile) and not rely on a move/copy etc afterwards. The issue appears to be with the plugin installers. If plugins were installed in to a standard system wide and/or your own profile plugin directory then things would be simple to configure and then a lot more user friendly. This location needs to be the same for all distros and all browsers should use them by default but should also give the more advanced user the option to set up they way they like.

You can also have flash work happily in one browser version and then it not work in another, i have that situation with Opera, Firefox 2 and Firefox 3. I just can't be arsed to sort out FF3 flash as i sorted of expected it to work straight away as FF2 and opera were working. I'll probably sort it out when i finally decide to uninstall FF2

konquerer takes the cake for searching all locations for plugins by default, there are 14 combinations of Mozilla, netscape and firefox local and system wide directories. Its madness.

Realplayer, flash plugins all seem install into different locations, i.e. their own directory structure rather than a standard system wide directory so you have to arse about with putting in loads of search paths in the browser config to find all the plugins.

Re:This should be interesting...

[bickerdyke]

What I like most about linux (or miss on my windows box) is the centralized software management that a distribution provides. Just compare a simple 'emerge -u world' (and a few hours wait ;-)) or 'apt-get upgrade' with Adobe Updater, Norton Updater, RealPlayer-Updater (and EVERY OTHER SOFTWARE under Win) either cluttering your taskbar with update-manager-processes or your screen with "do you want to search for upgrades now".

Re:This should be interesting...

[turbidostato]

"just providing an easy to install package just as they do for Windows"

I always find awesome that kind of stupidness and how it can be so prevalent among windows zealots.

What is the "multiplatformness" of Windows? Zero, nada. You can seemlessly install binary packages designed for Windows on Windows... because, heck, it's Windows! Installing Debian-designed packages on Debian is even easier than installing Windows-designed packages on Windows. On the other hand, installing Debian-designed packages on Windows is as much impossible as installing Windows-based packages on Debian (and even then, on Debian you have Wine).

Why people rise so utterly different expectations between Windows and any given Linux distribution is absolutly beyond me.

Re:This should be interesting...

[jbolden]

Flash isn't Linux software. It doesn't follow Linux standards. Linux has always had problems with closed source software and probably always will. The model for Linux is open source, binary compatibility is a low priority even if you follow things like LSB.

Where Linux systems kicks but is integration of open source packages. What open packages do you use that you had trouble using under windows?

Re:This should be interesting...

[jbolden]

Under the Linux model end users aren't supposed to be doing this. Labview should be distributed from the distribution not directly to the customer. The problem is Labview doesn't want to offer their software the Linux way, they want to do it the Windows way and that doesn't work so well.

Re:This should be interesting...

[dotancohen]

Under the Linux model end users aren't supposed to be doing this. Labview should be distributed from the distribution not directly to the customer. The problem is Labview doesn't want to offer their software the Linux way, they want to do it the Windows way and that doesn't work so well.

I am not sure that I follow you. LabView is closed source, so how could it be included with the distro?

What is "offering software the Linux way"? Simply offering an .rpm package or .deb? They do offer a simple .rpm package for Labview, but getting the a2d data acquisition unit working was (is) the real problem.

Re:This should be interesting...

[jbolden]

What would happen is that LabView would contact the distribution and the distribution would create a distribution specific version of LabView for them (possibly at some marginal charge like $500-1000). So you wouldn't use LabView .rpms but rather LabView RH Enterprise, or Enterprise Suse .rpms. This is how for example db2 used to be distributed when IBM was pushing it (before Oracle switched over from Sun).

Most likely some sort of license manager would be needed to use the .rpm or whatever license scheme LabView prefers.

I don't know anything about a2d but integration is easily handled at the distribution level.

Re:This should be interesting...

[dotancohen]

I will contact Labview, Canonical, and Suse to ask about this, thanks. I understand that Suse is an officially supported platform for Labview.

The a2d (analog to digital) bit needs a kernel driver for the pci / usb data acquisition hardware.

LSB - just say no

[rubycodez]

It's for rpm based commercial distros. Debian doesn't fit, and the "alien" program doesn't work on everything. 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.

Re:LSB - just say no

[myrdos2]

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?

Re:LSB - just say no

[turbidostato]

"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.

Re:LSB - just say no

[Anonymous Coward]

if an LSB application works in Red Hat, you know it will also work in Debian. Why is that a bad thing?

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?

Re:LSB - just say no

[Stan Vassilev]

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>

Re:LSB - just say no

[Anonymous Coward]

Debian 4.0 Etch was released year and half ago -- 04/07. And according to this mail (http://www.mail-archive.com/debian-lsb@lists.debian.org/msg00542.html), it's actually LSB 3.1 compliant, just nobody got to really certify it.
Current planned version is Lenny, which was to be released in September 2008.

Re:LSB - just say no

[myrdos2]

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.

Re:LSB - just say no

[Curtman]

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.

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..

Re:LSB - just say no

[Kjella]

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.

Re:LSB - just say no

[Rob Y.]

>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.

Re:LSB - just say no

[moderatorrater]

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?

Re:LSB - just say no

[Anonymous Coward]

Let's face it: if Wine were 100% reliable, Windows would be dead

I like you. You make me laugh.

Re:LSB - just say no

[markdavis]

>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.

Re:LSB - just say no

[Anonymous Coward]

It's for rpm based commercial distros. Debian doesn't fit, and the "alien" program doesn't work on everything. 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.

http://wiki.debian.org/DebianLsb

http://packages.ubuntu.com/hardy/lsb-base

It isn't really about the packages at all. It is more about Linux becoming "desktop agnostic". It is about how to have a library (call it the "lsb" library if you will) such that a program written to call that library can access standard elements of the desktop, such as the taskbar, the clipboard and the file open/save dialogs.

It is all about making it easier for developers to write an application for the Linux desktop that will work regardles of what desktop and what distribution the user has installed.

If you actually install any application written to this standard on your Debian system, then apt will automatically install the Debian lsb package for you as a dependency. So you don't have to "worry" about it at all, it will "just work".

How one packages such a cross-distribution program for desktop Linux is another isue. There are solutions for cross-distribution packages, but really it is simpler for the application provider to simply write the application to lsb standards, and then make an .rpm package **AND** a .deb package (from the same source) for binary distribution purposes.

Re:LSB - just say no

[Anonymous Coward]

Yeah, but that really means cloning Windows (and I mean also the kernelspace), making a shelf-ready product and offering all service and support that MS does.

Re:LSB - just say no

[turbidostato]

"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.

Re:LSB - just say no

[rubycodez]

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.

Re:LSB - just say no

[rubycodez]

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.

Re:LSB - just say no

[rubycodez]

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:LSB - just say no

[shish]

What about those of us who have a need for a good database on a good OS, and need it now?

Re:LSB - just say no

[rubycodez]

use postgresql on GNU/Linux or NetBSD

Re:LSB - just say no

[Curtman]

That's a lot of stuff. Enough to run a nice EEEpc. But not enough for the general Quicken-using public to use.

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.

Re:LSB - just say no

[jbolden]

What is the problem with Cent/RedHat Enterprise?

Obligatory...

[Phizzle]

But does it support Linux?! Ummm, wait... DOH!

Re:Obligatory...

[moderatorrater]

Ask not if LSB supports your Linux - ask if your Linux supports LSB.

Re:Obligatory...

[shentino]

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.

Re:Obligatory...

[moderatorrater]

I don't see the answer to that problem being stopping LSB, because having the ability to precompile things for Linux would be a big step towards getting people to develop for it. Why not just have a rival body try to standardize as well? There's no reason that the serious distros couldn't support both, and it would make the whole concept more resilient to outside influence. Worst case scenario, the threat of this happening should help keep the LSB from becoming a corporate pawn.

Re:Is this teh year?

[Anonymous Coward]

But they really mean it this time. Honest. In fact, Duke Nukem Forever will be ported to Linux.

Source code

[TehZorroness]

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:Source code

[Paradigm_Complex]

Yummie coincidence: I've got a box in arms reach right now make installworld'ing.

While there are numerous benefits to using the source code directly rather pre-compiled packages, there is good reason to standardize pre-compiled package systems. Most prominently, there are cases where compile time / cpu cycles really shouldn't be wasted unnecessarily.

Re:Source code

[Anonymous Coward]

Oh... you mean like the .src.rpm format? 100% source code, and converts to a binary .rpm format in the time it takes to type 'man rpmbuild'. I for one think we need a .src.rpm ->.deb convert/build tool, or something. :-) at least then we'd be standardised at the source level as the parent suggests.

Re:Source code

[cerberusss]

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:Source code

[Excelsior]

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 Gentoo for years). Source is provided by a developer, not a maintainer, someone who isn't concentrating on making sure its going to work properly on your system.

Source is a great thing(tm). Don't get me wrong. But it is not a good format for distribution - at all.

Re:Source code

[bickerdyke]

works not too bad on my gentoo box....

Re:Source code

[cerberusss]

For other distributions, it would be a pain. I totally agree that Gentoo does this well.

The Linux Standard Base is the grand attempt...

[Anonymous Coward]

...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.

Re:The Linux Standard Base is the grand attempt...

[Nicolay77]

And the problem is?

Yes, they all happily ignore it

[harlows_monkeys]

LSB brings the distros all together--it gives them something in common to ignore.

LSB is not enough

[slashdotlurker]

The kernel API also needs to be stable (or so do vendors like National Instruments think).

Re:LSB is not enough

[Anonymous Coward]

It is. Or did you think the 2. in 2.x.x was just for fun? :>

Re:LSB is not enough

[Anonymous Coward]

Well, fuck NI, their software is worse than Microsoft's. Try installing the drivers for one of their simple Digital IO devices to know what *real* pain is, even on the oh so user-friendly Windows platform.

Re:LSB is not enough

[slashdotlurker]

Easy to talk big unless you need it. Its not as if there are other vendors that make anything comparable. No, the linux-gpib project does not cut it.

Re:LSB is not enough

[moosesocks]

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:LSB is not enough

[slashdotlurker]

Yes, they are. They need to support certain hardware beneath their own hardware abstraction layer (KAL/VISA).

Re:LSB is not enough

[Klivian]

And NI are absolutely writing kernel-level drivers, since they in addition to software for measurement and automation they offers a huge number of different hardware. So to support all their measurement, dataloging and automation hardware, they have to write drivers for PXI (PCI eXtensions for Instrumentation), VXI, PXI- and PCI-based modular instruments and GPIB bus controllers. Their Linux offering have been rapidly growing for years, so obviously their userbase already have a strong interest in Linux.
Even if I disagree in that NI's hardware are considerably less complex than the hardware of NVidia and AT. For some I think actually the opposite are true, but it does not matter. What makes it hard for NI are simply the huge amount of different hardware they have to support, most likely many more than any other hardware vendor doing Linux support. Combined with the fact that their userbase expect support for far longer time than you can expect from the likes of nVidia or ATI. And very few, if any, of the regular kernel developers have or use any of their rather specialized hardware, makes it rather inconvenient and expensive when the kernel API changes. IMHO, the only strong reason for a stable kernel API are vendors like NI making specailzed, non-mainstream hardware.

Re:LSB is not enough

[radarsat1]

obviously their userbase already have a strong interest in Linux.

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.

Re:LSB is not enough

[Anonymous Coward]

The kernel API *is* stable. It's called syscalls, and most of the API is mandated by POSIX anyway.

You probably mean the interface kernel modules use. That's not the API (A means application), that's the internal interface. The internal interface will change to keep up with improvements in all areas of the kernel.

Re:LSB is not enough

[radarsat1]

Just to clarify... don't get me wrong, I am actually really happy that they support Linux at all and generally seem happy working with "non-standard" operating systems and making their register-level descriptions open.

This is a big improvement over other manufacturers. We had one data acquisition manufacturer who made us sign an NDA just so we could write a lean driver. (Which was significantly faster than the one they shipped.) This made distributing to customers particularly difficult since most of our software is a sort of "shared source". (Unfortunately not open source, but almost all our customers have access to the source.)

We're very happy not to have to repeat this now that we've moved to NI.

The main complaint is just that one of the things that convinced us to go with NI is their support for Linux, and then we discovered it really wasn't what we expected. Commercial companies seem to have a really hard time understanding how to support Linux--- I don't think this is exactly Linux's fault. They just need to understand that it's not Windows; distributing a big self-installing executable once every 3 years is not the way to go with Linux.

Linux - Band-Aids on Band-Aids on Band-Aids...

[Anonymous Coward]

LSB is nothing more than the top level Band-Aid on the giant stack of Band-Aids that make up Linux.

LSB, package managers, and rest of everything Linux. Why make the hard grown up choices that Commercial Software companies do every day when you can just come up with another Band-Aid and slap in on top of the giant stack of previous Band-Aids that make up the mess of an OS.

Re:Linux - Band-Aids on Band-Aids on Band-Aids...

[Barsteward]

If you are talking Bandaids, you are talking about Commercial Software company Microsoft's security cure for their badly designed operating system. I.e. they can't develop the security issue out of the OS so they plaster the OS with layers such as antivirus, anti malware, UAC.......

Re:Linux - Band-Aids on Band-Aids on Band-Aids...

[Anonymous Coward]

You're right, but of course you'll never get anyone on Slashdot to engage you in a meaningful discussion about it. This is either because they have no idea what is actually going on below the level of their desktop and so don't even begin to understand the reality of the modern Linux system, or because they are a fanboy and/or delusional, or because they have a vested interest in maintaining the status-quo (I.e. they work for a Linux company or are prominent in a large Linux project).

The sad thing is that the majority of clueless twits here on Slashdot think that their Linux distribution of choice is well designed and well engineered. It boggles the mind.

Corrections

[mpapet]

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).

Re:Corrections

[Darkness404]

Your quotes seem to contradict each other...

LSB compliance is important. Coincidentally, it makes the experience from one distro to another roughly equivalent.

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).

So wait, not only does the end user have to use the command line alien program (which I thought the entire point of all this stuff was to simplify life) but LSB programs become a pain to install. Where on the other hand with APT (and a GUI program) you simply click and install using a GUI and it works 100% of the time unlike alien.

Re:Corrections

[rubycodez]

except it's not true, lsb compliant rpms can and do fail with alien, as do many other rpms. So Debian is can be MOSTLY lsb compliant (if you install the layer)

It would make my organization...

[HogGeek]

... 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?"

Phase 1) Make binary executables

[CrazyJim1]

Phase 2) Bundle tons of free software with Linux packages
Phase 3) Become dominate OS.

Eh nm, dumb comment deserves flamebait

[CrazyJim1]

I'd mod my own comment down, but I can't mod in a thread where I posted a comment.

That is the idea.

[khasim]

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:That is the idea.

[Barsteward]

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.

i doubt that is the ISV's want as that only works when going to customers that use that specific distro. Whats the point of developing something that only works on Red Hat or Suse, they would want to sell that product to as many customers as possible on as many platform types as possible and only produce one version for Linux, one for Windows etc... not one for Red Hat, Suse, Mandriva - thats a administrative nightmare.

Re:Linux sucks

[Chiaro Meratilo]

Scored as a Troll in this situation, but what if he wrote "Windows sucks"? He'd be +5, informative.

Re:Linux sucks

[Anonymous Coward]

Nope, it would be -1 Redundant. No need to state the obvious.

Binary compatibility?

[Karellen]

"...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:Binary compatibility?

[Karellen]

Bollocks.

s/Linxen/Linuxen/

Re:Binary compatibility?

[hannson]

I think the idea is to be able to run the same binary package on multiple distros on the same architecture so all LSB (Linux/PPC) certified software would run on all LSB (Linux/PPC) certified distos etc... Of course that is if the software vendor (open source or not) chooses to support your architecture.

Re:Binary compatibility?

[Anonymous Coward]

I don't care about running my software on multiple Linxen (who invented that term anyway? why not distributions?) when the fact that there is no standard base means there's no non-open-source software to run anyway. If you had even the x86-32 binary-level interface standardized, people who ship software would be so much happier, and so would the majority of Linux users, who happen to run on that platform. After that you can tackle Alpha and PPC and ARM and whatever. But you gotta start somewhere which is not "let's ask everybody else to make their thing open because we think it's a good ideology" if you want a stable platform.

Re:Binary compatibility?

[shish]

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*

Re:Binary compatibility?

[amorsen]

Or use Java :-)

That way you at least put all distributions on equal footing: None of them will run your program.

If only the "Write once, debug everywhere" joke was true. It would be a vast improvement on the current state of Java.

The first step would be dumping .rpm.

[khasim]

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.

Re:The first step would be dumping .rpm.

[Anonymous Coward]

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.

Agreed up until this point. No matter what OS/distro/whatever, I always like being able to quickly see what was installed as part of the OS/distro and what I've installed via external sources.

Re:The first step would be dumping .rpm.

[Anonymous Coward]

I should be able to apt-get install foo.lsb and have it SEEMLESSLY integrate

You can. It already seems not to integrate, right?

Re:The first step would be dumping .rpm.

[amorsen]

And they would be completely platform NEUTRAL which SHOULD have been their first goal.

RPM is a cpio-archive with a header. DEB is a tar-archive with a header. Why should LSB invent yet another tar-like format with a header?

Just guessing...

[fahrbot-bot]

How the LSB Keeps Linux One Big Happy Family.

Bender: Blackjack and hookers?
(On second thought, forget the Blackjack!)

I don't get this...

[Darkness404]

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.

Re:I don't get this...

[vidarh]

Try installing that RPM on 10 different distros or versions of distros, and tell me again we don't still have problems.

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.

Re:I don't get this...

[markdavis]

The problem isn't within the distro itself. Certainly all the RPM's in Mandriva's repositories will install just fine on Mandriva systems. And Fedora's on Fedora systems. But when you try to install a Mandriva one on Fedora, or a SuSe on Ubuntu... then the problems begin. Not just with dependencies, but with where the files are to be installed on the system.

But the real need for LSB really has nothing to do with a distro's own native packages, it is about cross distro development, distribution, and installation of COMMERCIAL packages that can't be part of a distro's repositories. So the commercial developers have to somehow figure out which base libraries each distro has, and where the important configuration files live, and then build separate packages for every distro and version. That is a real pain... it could mean dozens of packages to support just the top distros: Debian, Fedora, Ubuntu, SuSe, and Mandriva (take those 5 and then multiply by however many versions you wish to support... perhaps 4? = 20!)

LSB tries to ensure that most Linux systems will have a certain "minimum/base" set of similar libraries needed for non-statically linked binaries, and some standardization for configuration files. It is a good idea, even if it hasn't really caught on or turns out to be impractical to really implement.

Re:I don't get this...

[SL Baur]

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.

Re:I don't get this...

[sentientbrendan]

>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 basement, then you don't need to use any proprietary software that isn't shipped with Linux.

Re:I don't get this...

[bcrowell]

Most people will never need to download software that isn't in the Ubuntu (or insert favorite distro here) repositories.

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.

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 normally going to package software that doesn't meet the debian free software guidelines. But he's basically right, because (a) most people don't pick linux because they want to run proprietary software, (b) there is very little proprietary software available on linux, and (c) when proprietary software is available on linux, it's often so poorly supported and debugged that you don't want to use it. On my linux box, there are three closed-source apps I've used within the last year. I have adobe reader installed, and only use it once in a blue moon, e.g., to check that the pdfs I produce are compatible with it; xpdf and evince are better for everyday use. I have at various times had flash player installed, but currently I can't get it to work on my x64 machine. For a while I was using Amazon's mp3 album downloader app (required if you want to buy mp3 albums on amazon), but it was always breaking for obscure reasons, until finally I found out about an OSS command-line app called clamz that replaces it. Using proprietary apps on linux is a nightmare, and it's not a nightmare because of lack of LSB support, it's a nightmare because proprietary software houses know it's not in their best economic interest to put any serious effort into quality and support for an OS that's 1% of the desktop.

Re:I don't get this...

[RegularFry]

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 hasn't. I know that's not a scientific survey, but it does seem to be true.

These are problems that you just can't solve with the traditional repository-with-periodic-updates model, and generalising to say they're "minor software projects that very few people use" doesn't cut it. Everyone's a member of a fringe group, so cutting off the fringes damages everyone. I think we need a better ad-hoc decentralised repository model, but I haven't devoted much thought to it yet.

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

One very good way to break a Xandros install is to install Debian .debs on it. They both use the same installer format and tools, but packages from one should not be installed on the other. That's the problem LSB is trying to fix.

Barriers to adoption

[camperdave]

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.

Re:Barriers to adoption

[vidarh]

Gee, you've just described the LSB.

Re:Barriers to adoption

[SwedishPenguin]

The developers don't have to care about desktops, they just have to use the xdg utils for menu entries etc.
Application developers don't have to care wether the system is using LVM or not.
The package manager situation is being alleviated with PackageKit, which all major distributions will support.

Re:Barriers to adoption

[sentientbrendan]

>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.

That's exactly what the LSB is (except for the standard desktop part).

The problem is that distro makers only give the LSB lip service, and do the bare minimum to get supported, because they fear if there was true distro independence, they would lose their market lock in. Despite all of their talk of openness, Red Hat, Debian, Ubuntu, and Suze do a lot to prevent interoperability. They are all more focussed on keeping their tiny piece of the Linux pie than on baking a bigger pie.

Re:Barriers to adoption

[Kadin2048]

This is precisely why most commercial software that supports Linux, doesn't support "Linux."

Instead they support "RHEL 5.2", "SuSE 10", "Ubuntu 8.04", etc. Those are all specific, identifiable pieces of software that a user could conceivably go out, download or buy, and install on their hardware. Each of them have teams of people concentrating on making them into basically stable development targets (some moreso than others, sure). Supporting "Linux" could mean any number of things. If your software runs only on Ubuntu, is it really "Linux" compatible? Sure, in a way -- but RHEL users probably won't be pleased.

It's not unreasonable for a vendor to specify a particular distro, especially if you're talking about enterprise software (where the software generally dictates the platform/OS choice), and doubly so when the OS being dictated doesn't cost anything or come with any real strings attached.

Re:Barriers to adoption

[Anonymous Coward]

To solve your problem, just use a Microsoft OS. See, youre problem is solved. I'am afraid that this standardisation leads to one Linux distribution where some comity decides what is good for me. Different or difficult options are ignored. Gone is my freedom. Back to a Microsoft-like OS, which I dislike.

Re:Barriers to adoption

[bickerdyke]

...or have the different desktops all support a common subset of functions and call that OpenDesktop or dbus (IIRC thats what those two are for)

Re:Linux sucks

[thePowerOfGrayskull]

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.

Yeah but

[Anonymous Coward]

The MSB is bitchingly divisive.

Only pointy haired morons say "ISV"

[Anonymous Coward]

Enough said.

audio subsystem

[drfrog]

it would be nice if they could do something about unifying the audio subsystem on linux

openal esd pulseaudio etc etc

its a mess

Re:audio subsystem

[Ash-Fox]

Standard is ALSA in LSB if I am not mistaken.

Re:Linux sucks

[thePowerOfGrayskull]

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.

Re:Is this teh year?

[cp.tar]

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.

Tag it with me. leastsignificantbit

[Anonymous Coward]

leastsignificantbit

Java...

[NullProg]

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,

Re:Java...

[JonSimons]

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.

I share your sentiment. I might actually tweak it by saying "Code with what works today and is likely to keep working tomorrow".

Re:Java...

[dargaud]

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.

Hmmm. And on what grounds would they sue ? Even if you publish completely imaginary 'benchmarks', that would still fall under the 1st amendment (assuming you are in the US).

Re:Java...

[NullProg]

Hmmm. And on what grounds would they sue ? Even if you publish completely imaginary 'benchmarks', that would still fall under the 1st amendment (assuming you are in the US).

I dunno, every EULA states you violate their virginity or something by benchmarking.

This is a company that sued Mike Rowe Soft. http://www.cnn.com/2004/TECH/internet/01/19/offbeat.mike.rowe.soft.ap/index.html
Why wouldn't they start a lawsuit against me before public opinion changed their minds?

I'm not rich enough to afford a team of lawyers (let alone one lawyer) to defend my reproducible test results, so no, I won't test their EULA against my right to bitch or praise.

http://www.theregister.co.uk/2006/10/29/microsoft_vista_eula_analysis/
http://yro.slashdot.org/article.pl?sid=06/11/02/1751222
http://download.microsoft.com/documents/useterms/Windows%20Vista_Ultimate_English_36d0fe99-75e4-4875-8153-889cf5105718.pdf

Enjoy,

LSB Is Important To The SCO Group

[sk999]

In spite of SCO's reputation regarding Linux, it is a little-known fact that Darl McBride is a big support of the Linux Standard Base: http://ir.sco.com/releasedetail.cfm?ReleaseID=91330>

SCO and Mandrakesoft Achieve LSB Certification

"This is an important milestone for SCO," said Darl McBride, president and CEO of The SCO Group. "SCO is very dedicated to the development and promotion of standards. We see standards adherence as central to the growth and progression of the Linux industry, and are committed to again being LSB certified when we release SCO Linux, powered by UnitedLinux, this fall."

Computer Engineer

[flerchin]

Am I the only one that thinks of Least Significant Bit, for the acronym LSB?

All hail the LSB

[Anonymous Coward]

They call it the Least Significant Bit, but it decides between true and false, even and odd... and it makes families happy!

Propaganda

[JonSimons]

Read what Ulrich Drepper thinks of the LSB here: http://udrepper.livejournal.com/8511.html.

LSB?

[Anonymous Coward]

And here i was thinking it was the Least Significant Bit :D

Oh computer science, how i love thee

_AC

Take LSB's rules and the projects control the code

[Anonymous Coward]

LSB has done a good job of defining the rules of the game. Let the projects that produce the code use the rules to define how their code is packaged. Ex GCC version x.y.z is divided into particular way and each part has their own minimum requirements. If distros have a problem how the project handles it they can talk it over with the people in charge of that specific project. In the case a distro wants to bundle pieces than the package needs to be able to indicate that fact so other package dependent on a certain part are not confused. This reduces the confusion by creating an single set of authoritative packages (libs, daemons, etc) version. That way those created the code can determine the best places to split up their project in to manageable pieces and the versions of other packages they can happily coexist with.

-ArcaneOne

Kernel API is stable

[azrael29a]

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.

Still RPM?

[OverflowingBitBucket]

Are they still insisting on RPM, and acting surprised when the adoption rate is so low?

Re:Still RPM?

[amorsen]

Why does it matter which particular tar-like-format+header they use?

Re:Still RPM?

[OverflowingBitBucket]

Why does it matter which particular tar-like-format+header they use?

At the time when LSB was being heavily promoted initially (years and years ago) there was no clear leader (in terms of technical merit) in the packaging format arena, and worse, each of the leaders was somewhat flawed. Different distros used different formats for vastly different reasons. This was not an area in which they should have nailed things down to a single format as it would alienate too many distros. They did, and it did.

I could go on and on about the reasons why standardising on RPM was a terrible idea, but I'll just leave it at the three reasons I personally grew to hate RPM (on a Redhat system):

- No easy way to get the contents of an rpm out. The cpio tools at the time kept crashing randomly. I'd never even heard of cpio at the time. Why use that format?
- An assumption that you'll be running build scripts as root. What sort of thought process led to that?
- The RPM 4 upgrade RPM from Redhat, packaged in RPM 4 format. Think about that one for a while.

Of course, *using* RPMs is a different story. They do the job (mostly).

If you haven't had a play with rpmbuild, I suggest doing so. It's probably moved on since I last used it though, so perhaps they've cleaned up their act.

Re:Still RPM?

[amorsen]

- No easy way to get the contents of an rpm out. The cpio tools at the time kept crashing randomly. I'd never even heard of cpio at the time. Why use that format?

Because it's actually a standard, whereas tar is a bunch of different flavours (most of them very limited). Yes, cpio has a crap interface, but the archive format is excellent. pax reads it. Someone really should add support for it to tar.

- An assumption that you'll be running build scripts as root. What sort of thought process led to that?

There is no requirement that rpmbuild must be used to generate the rpm. It's just a cpio-archive with a header.

- The RPM 4 upgrade RPM from Redhat, packaged in RPM 4 format. Think about that one for a while.

That has nothing to do with the format.

If you haven't had a play with rpmbuild, I suggest doing so. It's probably moved on since I last used it though, so perhaps they've cleaned up their act.

I've packaged software for my own use since Red Hat 6 at least.

Re:Still RPM?

[OverflowingBitBucket]

Combining what you've said, and I've said, we have RPM as using a poor, not well-supported interface, the official tools (rpmbuild) perhaps not being the best for the job, and the people behind the format historically not doing the best job to use or support it- we probably disagree on the relevance of the last point though. There's also the build-as-root issue I mentioned too.

Might just be me, but that really doesn't seem much of an endorsement for RPM. ;)

If you've worked with RPM since Redhat 6 then there's a good chance we've had some similar experiences, and to a degree would come to similar conclusions. In fact, with this vintage you would have experienced the RPM 3->4 fiasco first-hand. This would have been circa 2002 or so, I think? I didn't mark it on my calendar. ;)

As originally mentioned, I just concentrated on my own personal gripes with it. If at this point we still disagree on the specifics of the relative merit of the format and tools, we probably aren't going to reach a quick consensus through swapping of personal anecdotes and dissection thereof. So I'll just leave it at that for now. At the least you're aware of the opinions of one person, and if the perception of RPM is important to you, you've now got some potential areas to attack to ensure its general approval, should you choose to do so.

Good luck!

Re:Still RPM?

[amorsen]

In fact, with this vintage you would have experienced the RPM 3->4 fiasco first-hand.

I don't recall it. I probably did rpm2cpio|cpio -I.

And anyway, RPM isn't my baby. I just think it's silly that .deb is thought of as such a superiour format, when in fact the archive format is worse and the header is practically identical. It's dead easy to generate both formats without using the official tools.

Re:Still RPM?

[OverflowingBitBucket]

I don't have too much to offer for debs either, I have had far less exposure to them. My knowledge on them was based mostly on other people's technical takes on it at the time, and from the sounds of it, neither deb nor RPM were really a clear leader. My original assertion probably came off as anti-RPM (and that is true, to a degree, due to my negative experiences with it), but my main focus was really on saying that there was no clear leader at the time, and each tool had advantages over the other, so standardising on one was a bad idea. Not everyone will agree, of course- just my personal opinion. Standards groups are such odd things. ;)

Why would you use Oracle?

[Anonymous Coward]

You *did* say you wanted a good database, didn't you?

The brown distro ... Re:Hmmm....

[vevel]

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.