Slashdot Mirror
Why Aren't More Distros Becoming LSB Certified?
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."
LSB-certified rootkits for the bastard.
Striking fear in the authors of godawful fanfiction, I am here, appearing in darkness, Tuxedo Jack!
I have heard of it. I thought it was illegal, and if you drop too much, it can lead to permanent psychosis.
I see Linux as a kernel, not the OS there is a Popular Linux based OS like GNU-Linux which has many distributions. But all based on the same design. With the Linux kernel you are able to make your own Linux Based OS that is not like GNU-Linux and works more like Windows or BEos or Mac OS. TiVo is a good example. It is a OS but I wouldn't call it GNU-Linux it is its own OS based on the Linux Kernel to handle all the grunt work of the kernel but how files are handled and interfaced is completely different. If you are forced to follow standards the amount of innovation you are allowed is cut back. Linux is great but there is still room for improvement and being forced to follow standards may force a person to work inside a box they may not necessarily want to be in. It is like saying the TiVo should use X11 as its method to display, not its own ones although theirs are optimized for the job of video playback. Why should working with Red Hat and Suse be so similar why can't they be different OSs with the same kernel. As for adoption if a person who doesn't like Red Hat the chances are they are not going to like Suse because they are so similar. Perhaps they need an OS that fits their way of thinking. Linux will be far better adopted when it is no longer though of as Linux but as what ever OS it is controlled (powered by Linux)
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
They tried this before, more than 10 years ago with other UNIX systems.... Didn't end up working then, and it won't end up working now.
People will always want to change things, and make their products "different" or "better". Whether or not they really do it or not... well, that's up to the people that end up buying and using what they come with.
Certification costs money. To have credibility it must be peer reviewed, or reviewed/audited/approved by an external body. Then there's the QA and testing process. And this activity is not a one time activity, but a long term commitment to regression testing "every patch".
Given that many linux distros are pretending to be enterprise-ready w/o enterprise sales or revenue would indicate that they are unable, uncapable, or unwilling to be certified. Basically they can't afford it.
Of course I am speaking in general terms about linux distributions and the industry in general, there are numerous examples which can be used to refute my generalisations. However I think there's ALOT of consolidation required in the Linux world yet to achieve some of the more lofty goals of open source.
John Maynard Keynes: "When the facts change, I change my mind. What do you do?"
In case anyone else is curious, from this 2002 article:
I didn't find this info on the Open Group's website...Ha! I kill me!
I was once playing UT04, and all of a sudden the hard-drive went crazy, the frame-rate dropped and I rolled my eyes - obviously Linux was misbehaving again. It subsided after a minute or so (I kept on kicking ass the whole time, by the way, as I am hardcore :)) and a while later I quit. I then had a brainwave, and checked through the "Office" section of the K-menu - sure enough, OO.o was there. Turns out, I'd done an urpmi openoffice a while before playing UT, left it downloading, forgot about it completely, and the hard-drive thrashing while I played was the download completing and the installation taking place. I'd installed an entire fucking Office Suite without even lifting a finger. Cool stuff :)
Of course, if you want something that is not in your repository, then prepare for the worst pain ever or go without. It would be nice if some measure existed to ease the burden on packagers, as it seems that keeping them up to date is a tedious and thankless task.
It helps that if you use distro A, and I use distro B, and I write some software on my distro, we already know that it'll work on yours if they're both certified.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
If you're the producer of a Linux distro, do you want to have to recompile and patch EVERY SINGLE PACKAGE you put in your distro, EVERY TIME you update it? Or else require all the users to do the same if they want to run apps you didn't include, or update them when you haven't?
Admittedly, this is a worst-case scenario; no distro will be incompatible with ALL apps. Nonetheless, this is the situation that prevails when you don't have a standard base to use. Having a standard reduces the effort for everyone involved. Things will "just run".
I've just spent 3 days installing some esoteric science packages on a Linux distro they weren't certified for, and I could never have succeeded if I weren't an uber-geek. This is not the experience we want Linux users to have, regardless of whether we are commercially oriented or just wanna rock Open Source.
I hope this sheds some light on why a standard is needed...
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
I have heard of LSB
Leisure Suit Bill...(Larry's Cousin)
Wasn't he President a few years back?
Because we're talking about the average Joe getting away from Redmond. Some of them are looking for a solution where they can use their current machines and rid themsleves of the Windows fueled joys called Spyware.
/usr/bin/ and others in /etc/program/ while the more restricted programs reside in /home/usr/bin/, how is a person new to the world of Linux supposed to know what goes where!?
If you are a producer of a linux distro and you do things your own way, that's fine; but don't look for many people merging to your own specific way of 'doing things'. People like things that they're at least semi-familiar with. If developers of linux distro's keep changing 'standards', nobody will want to switch to linux, because as far as they can tell, SuSE is as far different from Fedora as Windows is to FreeBSD.
Microsoft has kept a tradition of 'C:/Program Files/' for installed applications which makes it easy for any windows user to jump from one MS platform to another. These relatively simple standards are just another security blanket that people refuse to let go of when they're tempted to switch operating systems.
Forgive my lack of knowledge in the numerous GNU/Linux organization structures, but if one has to install some applications in
I believe the entire movement of a standardization process creates this much needed security blanket that so many desktop users have been reluctant to let go of.
Once again, if you're a producer of a linux distro, you're not the average desktop user, you are not a majority. There is no need to put down a solution that you may never use, which has great potential to the masses.
-Xtrvd
Not all of them, obviously. But there are some horrible things in the LSB standards. IIRC it mandates FHS compliance, which requires the utterly horrible /media. Also, on the apps front, LSB apps have to be mostly static, where good dynamic binaries and libraries is linux's greatest strength, and necessary since every app including qt or gtk would be nightmarish - your ram goes poof. And yet you can't make these part of the LSB standard, because important distributions don't have them installed, and don't want to. LSB needs a way to have apps depend on libraries, and it needs to take a serious look at where distributions aren't meeting it and why, because often it's because the standard is wrong and should be changed. The suggestion of multiple levels of LSB compliance could improve things a bit, if they can specify dynamic qt and gtk in one for a start.
I am trolling
Why would linux aim to have just that ?
if you drop too much, it can lead to permanent psychosis.
Think you're confusing it with BSD.
We use the LTSP project with about 45 users network booting to a XFCE desktop right now. They browse the web, access our exchange 5.5 server using Thunderbird and have a LDAP directory with auto-name completion as they type email addresses. They access our 5250 iSeries system, and use OpenOffice for word / excel needs on a Windows NT shared drive. We love it, works great. Some more 'advanced' end users chafe some because they cant download their own screen savers or games, but frankly we LOVE that part of LTSP!
No I didnt spell check this post...
It's a pain in the ass to get simple brain-dead stuff like printing and mounting drives working in Windows, too.
For printing, my home desktop needs new (and uncertified) drivers from Brother. My brother's computer can't share the printer hooked up to my sister's computer and I've spent a couple of hours trying to figure out why. All the sharing _seems_ to be set up correctly, it just doesn't share.
And at work, I had to write up a document showing how to remap drives when my coworkers plug in removable drives to their systems. Windows kept on assigning drive letters that were already in use. Why on earth do we still use drive letters, anyway?
NONE of these things are things I would expect average users to be able to do. Linux certainly has plenty of problems, but so does Windows.
Oceania has always been at war with Eastasia.
Also, let's not forget how easy software installation on Windows and MacOS is.
Download setup.exe, install, run.
No dependencies (except a few possible dll's, which can be included with the application), no compiling, no need for 50 libs on your system to match a certain version number. It just works. More often than not anyways.
For many users it would make the transition to a Linux desktop much easier if (desktop) Linux software could be installed as easily. Just a simple package which doesn't have to care about the rest of the system.
Yes, Java/Python/.Net etc. are a possible way to go, but those applications still often depend on a bunch of libs and aren't known for their cpu and memory friendliness either.
The path I walk alone is endlessly long.
30 minutes by bike, 15 by bus.
The LSB is RPM-centric. It also has other flaws (in filesystem organization, to name one, although that is improving).
.debs, Source Mages uses tarballs+spells, Gentoo uses portage, etc.
... welcome to hell. If you think a little integration work in a heterogenous environment is hard, just wait for what Redmond's incompetence has in store for you. Your CEO won't be the one suffering, you (or the poor schmuck who replaces you after the next round of worms/trojans/viruses and other Microsoft goodies goes around) will be. *BSD and Linux aren't perfect, but their a damn sight better and easier to administer than Windows, and have the added benefit of working as well. Frankly, if you and your CEO were so hell bent on having something easy to integrate and use, and are obviously so willing to exchange flexibility to get it, you should have chosen to go with Apple for both your clients and servers. You would have traded less of your flexibility away, ended up with something much more solid and reliable than windows, and much easier to administer, and prevented a whole lot of heartache down the road. But then, I suspect your post is more of a dig at Linux and promotion of Windoze than it is a true history of some company actually being stupid enough to dump Linux for Windows.
Different distributions use different package schemes. Debian uses
The "perfect container" is a tarball. Anything else you want to do (install wizard, compile script, install script, what have you) belongs outside of the package container. Need a one-click installation procedure? Include the script in the tarball, and provide a GUI that reads the contents of the tarball and lets you run a program from within the tarball (KDE has apps that can do this, for example).
RPMs are flawed in various ways, and centric to particular distributions who happened to have representation early enough in the LSB process to push through a standard favoring their way of doing things over the broader, more portable standars (tar.gz).
Until the LSB becomes a standard that is no longer Red Hat/Suse centric, its adoption by other distros will be lackluster at bets, and rightly so.
As to your 40+ workstations that have been switched to Windows
The Future of Human Evolution: Autonomy
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...
Wait: we *don't* live in such a world? Oh.
There has been 30 years of UNIX. In that 30 years, the closest we ever came to that kind of cross-platform standardization is CDE. Do *you* want to use CDE? Me neither.
While the advantage to the *user* might be great in the long run if everyone followed LSB, there is a great deal of disadvantage in the *short run* for companies. And that's why we see little success with LSB.
Linux IT Consulting and Domino Development in Michigan
The main problem is that LSB specifies some stuff that people think are broken. (In particular, RPM and a C++ ABI that is both obsolete and newer than what people actually use). To the extent that the things LSB specifies are not broken, all the distros do things that way, and you don't need any certification to know you can use them. For applications, they only care about standardization if they need something that can't just be assumed, and these things aren't covered by LSB.
It is, however, useful, but only really as documentation of common practice. You don't have to wonder whether you're ahead of the curve on adopting a version of zlib, because the LSB says what version you can expect.
Dude. I know it's probably nit-picking, but you really should cite someone you're quoting, and save the plagarizing of yourself for when you're alone and in private. ;)
by esconsult1 (203878) on Wednesday April 20, @01:07PM
I know this is a rant, but my shop recently switched back to Windows from Linux desktops (about 40 people), why? Because the new CEO (and me too), were sick and tired of people trying to get things to work together properly. We were sick of not having an Exchange replacement (don't get me started on the open source ones now "available"). And new hires and our clients were just plain used to using the dominant containers out there (windows/mac).
by esconsult1 (203878) * on Wednesday April 20, @07:23AM
I know this is a rant, but my shop recently switched back to Windows from Linux desktops (about 40 people), why? Because the new CEO (and me too), were sick and tired of people trying to get things to work together properly. We were sick of not having an Exchange replacement (don't get me started on the open source once now "available"). And new hires and our clients were just plain used to using the dominant containers out there (windows/mac).
"What do you think?" "I think 'What, do you think?!'"
You do have a point about Windows having the very same problems. You don't have a point about people pointing out Linux's shortcomings as FUD.
I have trouble printing to some of my MS printers all the time. There are people in my office, on the same network, with the same admins, that don't have any problems.
If you don't have a problem with something, it doesn't mean there isn't a problem, it means you haven't had enough experience with that to have had to deal with the problems.
If you want to know where "it doesn't work right", go ask the people that can't get it to work right. Don't ask the guy that has 5 computers in his basement, with 1 user, and says he has no network problems at all. Ask the people that have to support 40 workstations, with 40 users, all who poke and prod BEFORE they call someone who knows what they are doing, and then deny it like some child.
Things don't work right all the time. Whether it is perception, or reality, they seem to work right more often in Windows.
Think you're confusing it with BSD.
No, BSD is legal, but merely frowned upon in our current sexually repressive culture.
Just remember to use a safeword.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
You have no idea what you're talking about, right?
/etc. That's your "registry", only human readable and you can back it up and restore (relatively) effortlessly or move to another computer.
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.
One gem from the LSB:
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.
Go check for yourself.
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.
Just a Tuna in the Sea of Life
I'm really disappointed with this discussion.
There are a couple of posts that get part of the answer to the question being asked and none of them has been moderated to higher than a 3 (and that one was somewhat off topic).
A few years back, I tried to do something similar to what a part of what LSB attempts to do, and it was like pulling teeth to get anyone to even talk about it. The initive was called FABIO, for "Free Application Binary Interface Objective". The intent was to get all the x86 Linux and BSD distributions to sync up with a single ABI, hopefully derived from a commercial ABI - the front-runner at the time, by far, was Solaris.
Nobody would do it, and it's for the same reasons that FABIO was stillborn, and the LSB is significantly more far-reaching than FABIO ever was:
1) Loss of editorial control
This is a big one for some projects. What if the LSB suddenly includes a library with a license that Debian can't live with, for example? What if I'm building an enterprise version of Linux, and I don't *want* to include graphics drivers that are part of the LSB 3.x specification? This is much less about what to put where as it is about what to include or not include in a distribution, and the acceptable per-distribution licensing policies and practices. The LSB throws in the kitchen sink.
2) Commoditization
If everyone conforms to a standard, what differentiates one product from another? This was touched on in that other posting. So far, no one has used the phrase "UNIX Wars", so I will. The UNIX Wars were about product differentiation. The other posting suggested that this was a result of market forces toward stratification, where different products rise up to meet different sets of needs. This is incorrect. FABIO only intended to standardize ABI - far less than the ambitious LSB. Further, it wanted to pick an existing commercial UNIX to standardize against, and finally, it wanted to define two levels of compliance. In the lowest level, you would be guaranteed that the standardized APIs were present. In the highest leve, you were able to turn off all APIs which were not standard: a guarantee that you could write code without unwittingly using a vendor extension, making the resulting binary non-portable. A mass exodus of developers to level 1 compliant platforms (to obtain the largest possible market) was expected... *if* FABIO made it. Neither the Linux nor the BSD camps bought into the idea: it would have rendered them commodities, differentiated only by philosophy and license. This is the same thing that drove the UNIX Wars: "I can't/won't compete against Microsoft, so I'll drive this other UNIX vendor out of business and take his market instead".
3) It's too big to be meaningful in any real sense
The LSB is too big to implement everything, and if you don't implement everything, you aren't LSB compliant. Face it, it's a superset of POSIX, and there's not one Linux yet that can claim full POSIX conformance for their system, let alone add in the other parts of the specification to get to LSB conformance. It's too damn big, and you can't turn off those things that are optional (you can barely do this with POSIX, using unistd.h, and if you do that with too many things, your system is useless anyway:. There's no agreed upon mandatory subset that lets you turn off the non-mandatory parts, and not get them at all, and know that all other mandatory compliance is there. POSIX has this problem in spades; the unistd.h mechanism is really poor at letting you pick interfaces to *NOT* be there: you can't. You also can't know, without a lot of research, what things are mandatory for conformance with standards built on top of POSIX - this is left as an exercise for the developer, who can say "if this interface is there, use it", but can't go anywhere and ask "what interfaces can I safely use, always, as long as a platform is conformant with standard XXX?". The LSB does a worse job: it includes POSIX, and then adds things on top of