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."
Why is Linux not gaining on the desktop? Because there is no "perfect Linux desktop container". The properties of such a container is that it should be standardized, easy to accept new client programs from a wide variety of sources, have easy to use services and a well known API that is well documented and defined so that programmers can easily write to it.
Instead we have a bunch of fragmented containers (KDE, Gnome, lots of lesser known desktop environments) that are incomplete and immature. Heck, its a pain in the ass sometimes to get simple brain-dead stuff such as printing and mounting a drive working. So you have projects like OpenOffice having to write their own container!!! And Miguel (bless his heart) making a version of Microsoft's .NET container (Mono) for Linux that is still incomplete and sits with an incomplete container -- Gnome, which is sitting on top of an incomplete desktop container -- Linux.
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).
At least Linux as a server container works, because it has the same API as standard UNIX.
Newsfollow.com
Yes Linux is better in how it handles hardware(ONE reboot AFTER install is complete is all I ever seem to have to do with a linux install, windows has at least 2 for JUST the os, leet alone dirvers, updates, etc.). But it's lacking in several other areas that would scare developers away.
What exactly is the purpose of the LSB spec these days? When I last worried about it, I was under the impression it was so that ISV's could distribute software packages in such a way that they would work and integrate well on a variety of distributions, and nothing more. That is, it wasn't about providing consistent functionality across distributions in general, or about standardising things for standardisation's sake. The "Purpose" section in the LSB spec doesn't seem to clarify this for me, but rather describes what the LSB is composed of, rather than why it's composed that way.
The big one is will it run out of the box, right now the way compatability between distros and even versions of the same distro work the odds are against it. The would probably have to ship a game with a spare cd containing all the variations on the binaries needed just to work on most of the mainstream distros.
And as much as I laud and love the way Linux distros install in one go without reboot hell, and deal well with hardware changes, Games need good vidcard drivers and that requires getting ati and nvidia on board with optimized linux drivers Though this last point is somthing of a chicken/egg problem as is the next point.
Linus still does not have installed user base to make porting a worthwile effort for many game/app developers.
The concept behind the LSB was a good one and a step in the right direction even if the implementation had its detractors.
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.
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."
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 ?
A number of things that make up the LSB have been in dispute as to whether they're the best way to do something or not. The one that comes immediately to mind is RPM-based package management. -I- prefer APT or compiling directly from source, but there are a dozen different ways to do it and they've all got their merits and pitfalls.
These are Holy Wars, they'll never be solved, and they'll keep certain people from using an LSB system alone. (here it comes:)
"Oh, but then you just install XYZ and you can do it your way."
So you start with an LSB system, then install all these other apps and utils to bend it to your will. Now, ask yourself how different that is from what we've got now with all the 750 fragmented Linux distros?
There are other things that are harder to change, i.e. filesystem layout. Once again, it's a holy war. The community will *never* come to an agreement.
There is no "one size fits all" linux, and there never will be. Different people have different needs, and most linux users (well, or at least this used to be the case) have some extraordinary needs. That's why they use linux.
Most of the people who would want a standardized base like that probably use a BSD. This is not a criticism of anyone or any system, it's just an observation.
do() || do_not();
"Example of what is wrong with F/OSS: 2005"
DAMN YOU OCTODOG! DAMN YOU TO HELL!
And don't think that these nice universal GUI software installers won't go away if Linux ever catches on for the desktop. At some point the quantity of software available will make it unfeasable to continue this kind of software delivery system except for the most basic OS components. Much like Windows already has under "Add/Remove Windows Components".
Windows lacks this type of thing because its popular, not because it is flawed.
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
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.
The LSB people would write the standard...
The various distributions would adopt that standard...
The various ISV's would develop to that standard.
I'm sure everyone can see the problems, right?
#1. The LSB people couldn't get a complete standard written and published. Their current "standard" still doesn't include GNOME or KDE so it isn't going anywhere on the desktop.
#2. The various distributions are different because the people running them have different approaches to solving the same problem. What incentive IS THERE RIGHT NOW for them to wait and adopt the LSB? That's right, they need an incentive.
#3. The ISV's, seeing the delays, skipped the LSB and formed partnerships directly with the distributions (like Oracle did with Red Hat).
So, what we have right now is a bunch of ISV's who are not writing LSB apps forming partnerships with distributions who are not abandoning their old ways to support the LSB which has not released a workable standard for either the ISV's or the distributions.
The LSB, as it is currently focused, will always be a failure. Even if they managed to release a standard, it would only hold back the current speed of development.
What the LSB really needs to do is focus on the things that would make a huge difference right now.
#1. Fix the FSB. Right now, the location of a file depends upon how I install it. If I compile it myself, it goes in one directory. If I apt-get install it, it goes in a different one.
#2. Expand the FSB (part 1). Standardize the naming of each file, right down to the version number. If some app depends upon libfoo-1.0.0.3 then that should be the same file, with the same name on each distribution.
#3. Expand the FSB (part 2). Standardize the packages that contain the files that were standardized in #2. Package foo-1.0.0.3 would be named the same for each distribution and contain the exact same files of the exact same versions.
#4. Get rid of the RPM requirement. Instead, specify the BASIC functionality that the package management system will have and the basic information contained within a package and the format. That way, the various systems can ADD that functionality to their existing systems.
And the best thing is that those can be implemented over time. No more waiting for the LSB standard to be published BEFORE the distributions can become compliant BEFORE the ISV's can write and TEST their apps on those LSB compliant distributions.
In the end, the apps can have stated dependencies that should be easily verified because of the file and package standardization.
the average businessman doens't know what GNU is or stands for, but most have heard of linux. Kleenex doesn't mean tissue under the Kleenex brand anymore, it's any tissue you use for the sniffles these days. Words have meanings, and they change. Linux is now an OS as far as most people are concerned and the linux kernel is just a part of the linux OS. Suse, Red Hat, Mandrake, Yellowdog, Debian... they're all linux flavors or distributions. You can call Linux whatever you want, but people will just look at you funny like they did the speaker at a state college near here when he referred to Microsoft's new C# language as "See Pound". When meanings of words change, they usually get another entry in the dictionary. I wouldn't be surprised to see Linux defined as a Unix-like operating system in your average dictionary soon. Oh, no wait... American Heritage already has one... I'd expect more soon Linux -- A trademark for an open-source version of the UNIX operating system.
No. Windows lacks this type of thing because it operates in a completely different culture. The Windows world is dominated by a culture of control and marketing.
First off there is the issue of proprietary software. Even when things are "free" as in "no fee", there is often some degree of control reserved for the distribution and even use of said software. That alone puts a damper on the "hundred thousand entries" you're expecting. But it goes further than that.
While something may be available because of the functionality - it is also likely to be there because of marketing or sales strategies. That covers your dig at Microsoft's recent trouble over multimedia. But also includes finding Yahoo Search installed with Adobe's Acrobat reader.
That's not to say that all of the above is "bad". It's simply a different environment. And it runs by a different common culture.
And that's not to say that Linux is imune to this culture either. You're not likely to find UT2004 available after your next "apt-get update". And if you do install Adobe Acrobat Reader 7 for Linux, you're going to find it comes with Yahoo. But then, I can "apt-get install evince" and have a nice PDF reader for a ~1.7M download vs. the ~98M that I need to pull for Adobe's version.