Why Aren't More Distros Becoming LSB Certified? 651
mydoghasworms asks: "I have done much thinking lately about Linux Standards Base. The idea makes lots of sense: Adopt a standard which will ensure that if some piece of software is compiled on one LSB-compliant system, it will run on any other LSB-compliant system.
This would be great for members of the general public who are looking for an alternative to Windows, don't want to pay for Mac, but are looking for a platform where installing and running software is as easy as on the platform they are used to. Seen in that light, if LSB lives up to its promise, it could be the step in Linux's evolution that could see it adopted by the general public. That leaves the question: Why is LSB not seeing greater adoption?"
"Is it because it is not marketed well enough? Is the certification process too difficult? Are there perhaps technical challenges to LSB certification not often discussed? If people agree that LSB is in fact what Linux needs right now to ensure widespread adoption, what should be done to create awareness of LSB? Should communities developing Open Source/Free Software projects be encouraged to provide LSB binaries? Your input would be most welcome here."
Cost (Score:5, Informative)
In case anyone else is curious, from this 2002 article [mozillaquest.com]:
I didn't find this info on the Open Group's website...That's not what LSB does (Score:4, Informative)
Re:What role does LSB play? (Score:5, Informative)
Re:Linux needs a standard container (Score:3, Informative)
For some reason I always get modded down for saying this, but I'll say it anyway. I can't ever figure this opinion out. I have problems almost daily in Windows XP trying to print to a network printer (it randomly decides I don't have permission to print), but I never have a problem with this in Linux. I've also never had a problem mounting a drive. For example, I can plug my new Seagate external HD into the firewire port and an icon for the disk appears on my desktop. Where is this mythical "pain in the ass"?
the new CEO (and me too), were sick and tired of people trying to get things to work together properly.
You know what I'm sick of? I'm sick of FUD about how things "don't work right" in Linux and vague statements about it being "incomplete" when there is no basis for these claims in reality.
Re:Linux needs a standard container (Score:5, Informative)
LSB isn't the answer (Score:5, Informative)
DISLCAIMER: IAADM (I Am A Distro Maintainer)
put simply, LSB doesn't solve the desktop problem. It wasn't meant for that.
The LSB was written to make sure that all those booming distros back in the days they were booming, were somehow unified by a comming file system structure, library setups etc.
They really only mean to cover the (B)ase. This base was since then widely adopted and almost any distro conforms to this (B)ase more than 95%. Only outliers like slackware diverge, and often only minimally.
This puts the burden on distro maintainers to get a certification on something that is completely obvious, and non-beneficial. It's like getting a prep school diploma when you're in high scool already.
Also, the LSB is needlessly strict on some rules that hinder progress (init handling - chkconfig etc), where we should have moved to completely new solutions already (I loved that Makefile approach).
so, expect more from freedesktop.org than from LSB...
the herd misunderstands (Score:2, Informative)
example: Slackware, a distribution wholly unlike any of the big names on everyone's lips, chooses a BSD-like init design and manages packages with a relatively simple set of shell scripts. BUT, for the sake of maintaining standards (particularly the Linux File System [slackware.com] standard), Slackware has symlinks compatible with a SysV install and includes rpm! was that really so hard? did that inhibit the "simplicity and stability" mantra, or stop Slackware fans from creating a [jaos.org] variety [freaknet.org] of interesting [mutagenix.org] projects? no.
the freedom to experiment exists and is encouraged and adopted within Slackware, while it still maintains standards compliancy.
Re:Reality check... Bounced. (Score:5, Informative)
That's what LSB wants to do - codify the "resonably standard" locations for things into the "LSB standard" locations. Then you can be sure you're looking in the correct place for things, rather than having to have your make procedure guess at it.
Re:What role does LSB play? (Score:4, Informative)
LSB is for consistency across distro's (Score:2, Informative)
What exactly is the purpose of the LSB spec these days?
Basically, to define a reference platform with a specified set of functionality. As in: If "distro XYZ complies with the LSB", then "functionality A, B and C is guaranteed to be present, and working". See it as a sort of certification, a la Red Hat enterprise distro. Something application builders can use as a guaranteed base to build on, and distro's that choose to comply with it, should then be guaranteed to run these applications.
It doesn't mean every Linux distro should support it. But between Linux distro's that DO, there would be better consistency across distro's. So that it's easier to move an application suite from one LSB-compliant distro to another LSB-compliant distro. As opposed to making a shitload of changes to adapt your app to another distro.
If you're a distro builder, I'd say: support the LSB as far as you can, if it isn't too much trouble, and helps your user base. If you're an application builder, make sure your app works according to LSB guidelines, if it isn't too much trouble, and helps your user base.
If you're looking for a "one size fits all": forget it. There is no such thing in Linux land, and while useful, having that may not even be a Good Thing(tm). Developers should just pick appropriate standards to support. Nothing more, nothing less.
Re:Reality check... Bounced. (Score:3, Informative)
How long do you want to wait for the packages? Even things like PHP and Postgres tend to take a while to be packaged. How long for something like XFoil or GrassGIS?
Re:Reality check... Bounced. (Score:5, Informative)
gpx2shp - convert GPS or GPX file to ESRI Shape file
grass - Geographic Resources Analysis Support System
grass-doc - Geographic Resources Analysis Support System documentation
libgrass - GRASS GIS development libraries
libgrass-dev - GRASS GIS library development files
Re:Linux needs a standard container (Score:3, Informative)
Re:Cost (Score:3, Informative)
I didn't find this info on the Open Group's website...
Have a look here: http://www.opengroup.org/lsb/cert/docs/LSB_Fee_Sch edule.html [opengroup.org]
Re:the LSB is RPM centric (Score:3, Informative)
The tarball comes with a self-customizing install script. You type:
./config to run the self-customizing script
make to compile
make install to finish installation
Dependencies do exist, but config checks for you and gives you a nice list. The real problem is when your dependencies have dependencies...this is where Debian's apt-get can really shine (although I believe modern RPM systems can likewise deal with this...Mandrake's system pops up a window of the dependent additions and asks if it is ok to install them also.)
Re:Linux needs a standard container (Score:5, Informative)
Points 1 and 3: Linux distros typically put settings in
Points 2, 4 and 8: Any modern Linux distro has a package handling system. You don't use the tar.gz files yourself, or even at all. These keep track of all software on your system and keeps it all up-to-date.
Points 5, 6 and 7: That's the work of the desktop app.
Finally: No-one NEEDS to do anything to get Linux out to everyone. OSS is not a product it's a process; you can join now or in a year or never. If you want to change what is happening then involve yourself in the process of making it happen.
Re:Reality check... Bounced. (Score:2, Informative)
how long does it take a package maintainer to:
- notice bug report for version bump
- change filename on the package's
- ebuild foo.ebuild digest
- submit to portage tree
(I believe this is about how things work, correct me if I'm wrong)
Gee, I dunno (Score:5, Informative)
Applications shall either be packaged in the RPM packaging format as defined in this specification, or supply an installer which is LSB conforming (for example, calls LSB commands and utilities). [2]
[2]
Supplying an RPM format package is encouraged because it makes systems easier to manage. A future version of the LSB may require RPM, or specify a way for an installer to update a package database.
Which is basically use RPM, or you might be forced to use it in the future to remain in compliance.
There really shouldn't be a requirement to use a particular package management system in the spec, unless there happens to be a quality, proven, popular system to choose from. Unfortunately, there isn't, and rpm really doesn't fit the bill. I'm not going to get into a debate over the shortcomings of rpm (suffice to say that I packaged software using it and hated it with a passion) as my feelings on it aren't important to the point. My point is there are valid reasons why multiple distros are trying their own package management solutions rather than settling on rpm. Forcing a particular solution arbitrarily (and the selection of rpm is arbitrary) is not going to encourage adoption of a standard.
Add to this a number of other valid concerns from a whole bunch of people (flick through the replies above for a ton of examples) and you may start to find reasons why LSB hasn't been more warmly received.
Except that it is only the Majors that bother (Score:5, Informative)
Most of registered ones are RH and Novell/SUSE, with a few others like Mandrake, SGI and Sun JDS.
See it is just the reverse of your hypothesis. It is only the commercial interests that are interested. That and you need to support the Red Hat way of file system and init and RPM.
The minors only get to play if they pony up some bucks (negligible for a Corp but significant for a non-profit volunteer org) and change things so they are done the RH way. It involves significant changes for any non-RPM based distro to get certified.
Re:They tried this already (Score:3, Informative)
LSB is a Good Idea as it lets commercial developers release binaries that Just Fucking Work on a machine that would otherwise be running Windows XP. People releasing software for low-MHz devices or massive parallel processing systems will not be releasing MS Word replacements and accepting LSB as a global standard allows them to build for LSB instead of "Linux and some libs we hope you have".
Re:Linux needs a standard container (Score:2, Informative)
You can mount a NTFS partition as a directory.
FUD indeed.
Re:Reality check... Bounced. (Score:3, Informative)
Your first step is critical. Many devs, myself included, simply don't have the time to be checking for updates to all the packages we maintain. Please do file bug reports for new versions, and you can even assign them to the dev listed in the package's metadata.xml, which will bypass seemant and the other clumsy bug-wranglers ;-)
Re:Linux needs a standard container (Score:3, Informative)
Unfortunately that quite simply isn't true, since the majority of the world runs Windows on the desktop both at work and at home. Compatibility issues arise. Also, if there's a problem, there's a good chance they'll have to deleve into a command line interface to fix it, or call in external help. Lastly there are only a handful of flavours of windows but there are dozens of common distros, and everything from configuration to command line utilities tends to differ with the distros. It's a mess and a minefield for the non-techy user.
Re:RPM not an issue (Score:1, Informative)
Please go back and read the LSB standard. There is nothing in it that specifies what package format the distribution must use for its own packages, it merely specifies what single package format must be accepted for 3rd-party software.
Debian already has debs that provide LSB support (that you can choose to install or not) and it supports the installing of LSB rpms (using alien):
It is sad that so many people keep harping on this non-issue.
Misunderstanding RPMs in the LSB (Score:1, Informative)
The LSB does not mandate a package format for the base system. It specifies a distribution format for 3rd-party packages. Allowing a developer to distribute a single binary package format for all LSB-compliant systems is a good thing.
For further proof that your RPM fears are unfounded, log-in to a debian system and run "apt-cache search lsb". You'll see plenty of packages for installing LSB support, for installing LSB 3rd-party packages, and even for creating LSB-compliant RPMs.
Re:Linux needs a standard container (Score:3, Informative)
Re:Linux needs a standard container (Score:2, Informative)
Re:the LSB is RPM centric (Score:3, Informative)
Oh, good grief, rpm's work just *fine* on non-rpm-based distributions. (Try apt-get install rpm on a debian box some time.)
--Bruce Fields
Re:Linux needs a standard container (Score:3, Informative)
It sounds like you DIDN'T try (Score:3, Informative)
It sounds like you tried to install some oddball, distro-specific RPMS to me. Next time, use apt-get to install the *debian package* for LSB-compatibility to your debian-based distro. After that, try installing *LSB Compliant* RPM packages and "sometimes" will turn into virtually "all the time" in terms of success rate. That is the whole point of the LSB people--it provides a consistent environment (filesystem and set of tools and libraries) on which to base software packages. If you require extra dependencies not in the specification, those must be included in the RPM or it is NOT an *LSB* RPM package. Dependency hell is virtually eliminated....that is the idea anyways.
And to everyone out there who that the LSB is really just Redhat has no idea what they are talking about. Yes, the packages must be RPM format....but NO, the LSB does NOT specify that RPM must be the native package manager, nor does it have to be the only one supported by the LSB-compliant OS. Debian can be made LSB-compliant by installing a NATIVE DEBIAN package that provides the LSB environment. Hell, even the LSB REVERENCE PLATFORM (LSB-si) isn't even red-hat based! (The LSB-SI was built from the ground up using the documentation and tools provided by the people at "Linux from Scratch"--the LSB-si OS is compiled and installed without the useof a single RPM)
The problem the LSB faces is that they MUST make some choices that will bruise egos--stuff like what directories hold what files, how init scrips are maintaines and what format is used to package apps are pretty fundamental and are the subject of religious wars--it doesn't mater what they picked someone would not be happy with the choice.
IMHO that is why installing software on Windows works relatively well--everything installs from a "setup.exe" and must conform to quite rigid guidelines to get the blessing from MS. When adding and removing programs doesn't go right it is pretty much ALWAYS because the unstall or uninstall did not conform to those rigid guidelines.
I guess LSB3 is going to take on the desktop now...It'll be interesting to see how they navigate the no-man's land between the GNOME and KDE front-lines in that battle.
Re:Linux needs a standard container (Score:2, Informative)
enter freedesktop (Score:3, Informative)
1) d-bus
2) d-vfs
3) mime-handling
nuff said for me, this is truly cross-DE standards that is making it into both GNOME, KDE and (my favorite) Xfce. Freedesktop has the power to uniform not only linux but all unix flavours out there!