Slashdot Mirror
Linux Standard Base 2.0 released
prostoalex writes "Linux Standard Base 2.0 has been released by the Free Standards Group. The release will allow application developers to ensure their product works on multiple flavors of Linux. FSG keeps a list of compliant distributions on its Web site."
It should be stated that the gcc c++ abi for 3.4 series is incompatible with later versions.
Why do companies need to pay to be registered as compliant?
Why not use an open/free option?
Who would have thunk it...
Has two products listed on the compliancy page. Caldera set to expire near the end of this week, and SCO Linux Server set to expire next month. I wonder if they'll try to get renewed.
All your standard-base are belong to us!
Try the Google cache.
Which versions of the various distros will be compatible with LSB 2?
I am thinking somewhere around Fedora Core 6 or so. Anyone want to hazard a guess? This could get sticky with so many options and yet another standard to abide by...
BLING BLING. Meet the architecture that's changing everything.
I'm kind of disappointed looking at the list of compliant distributions - there aren't many on there, especially when you consider how many distributions there are out there.
With that in mind, how much can this "allow application developers to ensure their product works"?
Easy? Bah! I want spend 30 hours searching for HOWTO's! I want to type "apropos -k" until my fingers are numb! I want to scan scripts until I hallucinate ascii!
Bah! Bah I say!
If they're not on this list, I have a hard time taking this list serioulsy
All of the certified distros are commercial products. Where are the community distros in all of this?
Could it have something to do with the Fee Schedule? The fees don't seem that steep.
Can't read the article of course, but will this be the next big push for linux on the desktop? Or is it more for the server crowd?
Being able to install apps without going into a dependancy hell should boost the public's view of the user friendliness of linux.
Standards like the LSB are absolutely useless as long as the vast majority of distributions do not fully implement them. Even worse, is when the big distributions don't.
Interoperability is a great goal, but is anyone addressing patching/updating? Currently, it seems that these updates are handled as follows: download new packages, remove old packages, install new packages.
That seems fine for smaller bits of software but for a KDE bug fix or an OO.o update, downloads can go to the 100MBs or more. Fine on a DSL line, but dial-up users are still going to get hit hard.
I understand that OSS is better at fixing bugs and that's great -- but between Mandrake 10CE and now, it feels like I've downloaded another distro worth of updates. Is there something being done (maybe the whole binary diffs thing mentioned before) to decrease the size of update files?
I'm posting this as part of an LSB thread in the speculation that binary compatibility may one day lead to (smaller) patches that can be applied to LSB-compliant distros...so a KDE bug stays a KDE bug and not a MDK bug, SUSE bug, RH bug, Debian bug, etc.
This makes it quite hard to follow a general howto for a general *nix nox, while using emerge to get the packages.
[blue] - The Ministry of Information approved this message...
I mean what are they going to come up with next, a standard packaging format?
Jesus, they're just taking all the fun out linux.
considering the fact that gentoo is a source based distribution, it really can't. However gentoo trys to stay as similar as possible when it can for minimal pain
I wish Solaris was LSB compliant even though it's not Linux. Here's a good reason for standards:
There is a killall program on Linux, it kills all processes that have a processname that matches the argument you pass to it.
There is a killall program on Solaris, it doesn't take any arguments and will kill every process running.
On sale this week for only $3000.
Debian is listed as a "Silver Member" on their group member page.
Really, I know what I'm doing...Ohhhh, look at the shiny buttons!
A Beowulf Cluster of Linux standards? Don't we already have that?
No, you're thinking clusterfuck.
When you get to hell -- tell 'em Itchy sent ya!
I presume that LSB is simply spec'ing existing practice, correct? Or have things changed since that posting? Is this really an issue, even, since a system might be able to support an "old" and "new" C++ ABI by having both the "old" and "new" libraries installed?
Also: if the C++ symbols will be stored as (name space + package + class + method) in that order, ELF is used, and there are many hash collisions, this might create a lot of overhead loading large C++ libraries. The reason: while linking, you'd have to compare a lot of text before matching, because so many symbol entries would have a common prefix that you'd have to keep matching over and over again. Am I reading this correctly?
- David A. Wheeler (see my Secure Programming HOWTO)
Certification of gentoo is almost certainly out of the picture, as you can't know from one system to annother which libraries are installed.
This might be an interesting use for slots though. Someone could build a series of ebuilds that require the specific library versions that the LSB specifies, and keeps them in slots (so they're not unmerged when they're upgraded). Then a Gentoo user who has emerged "LSB-Base" would have a decent chance to be able to run any LSB 2.0 requiring binary package.
"For payment terms please contact The Free Standards Group"
Read the date on your link. Terpstra worked for Caldera in 2001, when they were a Linux company. As far as I can tell, he never worked for SCO, new or old.
Try Google. You may have heard of it. He now works for PrimaStasys, Inc.
I'm disgusted that you attempted to link someone who has done so much for Free software with SCO.
First off, you have to make sure your new standard SOLVES AN EXISTING PROBLEM and does so without creating new problems.
The LSB doesn't solve any problems for the Open Source developers (they're restricted to outdated libraries).
Nor does it solve any problems for the current users.
But it needs both of those camps to adopt it so that the commercial ISV's can write to it.
But that is not in the best interest of the various commercial distributions (Red Hat, SuSE, etc). Their best interest is to form partnerships with those same ISV's by offering those ISV's incentives to certify for their distribution (sharing the porting costs, the support costs, marketing costs, etc).
Guys don't give me this crap about companies feeding off the work of Open source. These companies have worked hard on their closed source applications and want to be able to port their software as binaries to Linux. This is a good thing.
To use that analogy, would a developer releasing software for windows be feeding off the hard work of MSFT? This standard will help create a symboitic relationship between commercial developers and the linux platform.
The average joe does not want access to the source, all they care about is compatibility and interoperability of software. Open standards are something the average joe might support but they could care less about the source.
Jesus was a compassionate social conservative who called individuals to sin no more.
Sorry, I seriously doubt that, as any software written for Intel will probably work for AMD as well. Also, don't agree that all commercial software is evil, nor that binaries are evil.
Finally the Linux guys agreed that there SHOULD be a standard (even if it's not implemented yet).
.os hell mentioned earlier. (No more recompiling! Halleluyah!!)
Seriously, saying Linux is 1000 times better than Microsoft is kinda being hypocritical when they make MS's same mistake: Despising standards in favor of proprietary implementations. (NO, i DON'T mean open vs closed source. I mean standard vs proprietary).
Anyway let's see if in a couple of months, this resolution helps programmers deploy Linux binaries that run on _ALL_ compliant Linux distros, ending to the
Firstly the LSB covers several platforms nowdays, secondly its goal is to create common packages. That means getting the same package running on Red Hat and SuSE regardless of whether its proprietary or free software.
Oh, and provide your rationale to those (like Rusty and Dan) who actually set the standards. Whining about it on Slashdot is hardly the way to achieve any change.
Here's what the FHS says about /media, by the way: