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!
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.
I have heard of it. I thought it was illegal, and if you drop too much, it can lead to permanent psychosis.
I have heard of LSB
Leisure Suit Bill...(Larry's Cousin)
This sig has been removed pending an investigation.
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?"
I don't see that for Linux to become accepted it has to go to one standard, bacuase it's becoming accepted without one standard. Part of it is most likely the whole RPM choice, though Debian based Distro's can do alien and format them to a .deb package other distro's don't have that option. But this brings up the whole point of splits from a base, like last week with Debian vs Ubuntu, ubuntu is using the new debian models and there are more Ubuntu destops being used then Debian though Debian is still you're choice for a server. Each distro takes on its own core optimizations and users can easily find a distro which suits them best. Why go for standardization when a specific distro makes better sense than one for all and all for one.
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!
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
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 ?
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!
if you drop too much, it can lead to permanent psychosis.
Think you're confusing it with BSD.
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
Because of the complexity and differentiation of linux platforms and whatnot, LSB will likely never be fully adhered to in a consistent manner by all vendors/distros.
What I'd really like to see is a much simpler subset of really basic standards, with a different name, that would be relatively easy for all the vendors and distros to be compliant with. For example, I would expect this to be the nature of things it enforces:
* Documentation other than man pages is always in
* Man pages are always in
* Init scripts should always exist in the location
* The following environment variables are always set to some correct-ish value in the default environment based on user configuration of the OS: TZ, HOSTNAME, PATH, USER, etc
* The following basic *nix commands are available in
* The following list of common shells and language interpreters will always be installed in these pathnames: [bash, pdksh, perl, python, etc] (There might be an alternative "lite" version of the standard which excludes a requirement like perl or pythong or specific shells, for minimal/embedded environments).
You get the idea - these are things that *most* distributions already do *mostly* the same anyways. After a few quick tweaks any distro should be able to re-release themselves as compliant with this standard. And once it's popular, vendors have a document to look at that tells them certain things they can rely on when writing linux-specific applications at the operating system level (aside from the stuff at other levels, like the linux and glibc and whatever else API/ABI stuff).
11*43+456^2
I would build a Linux box for any noob (read person who really doesn't do anything on their machine but email, surf the web, type the occasional letter, and print photos) computer user. I can build a machine and throw Linux on it, save hundreds on the OS and productivity software, and it will be the perfect machine for grandma or other non-techie person. For example, Fedora 3 comes with Firefox, an email client, a good messenging client, a media player, and a good word processor. That is pretty much all you want for a person with the needs stated earlier.
People always say "Oh, but installing is oh so hard!!!" But how often does your every day user install anything? THe last time my mother-in-law installed anything on her ancient P2 system was to put Norton AV on there. Which you don't even need under Linux.
Standardizations aren't what Linux needs (though it is wouldn't hurt) to get average user marketshare. What it needs is marketing. I want to walk into a software store, see a box for Fedora (or whatever the most user friendly version is) for $20 bucks. The box needs to say that it will replace Windows, work faster, more secure, and so on. It needs to be a box that if I'm a noob, I'd buy it. It needs to be something that average Joe will recognize as legit and good.
Don't take life so seriously. No one makes it out alive.
Why does nobody care about Linux Standard Base?
1) A standard has been arrived at already already- it is known as POSIX (http://www.knosof.co.uk/posix.html)
2) Linux Standard Base is yet another self appointed 'governing body' comprised of corporate 'industry leaders'. In other words, LSB hsa nothing to do with those who have made linux great, and therefore their 'ideas' will continue to be met with indifference.
Why do you have such a big problem with commercial software? Why do you have a problem with "open standards"? Open Source software without open standards offers little utility for the average end user.
You either work for MSFT and want linux to fail or you are an elitist geeky snob who wants to keep linux usage to the elite. Perhaps you are afraid that if it goes mainstream, you will not be seen as "cool" by the linux community.
Jesus was a compassionate social conservative who called individuals to sin no more.
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...
i'm reading a lot of backlash against standards, and i suspect that most people responding don't understand the first thing about them. the LSB does not a vanilla linux installation make. it's a standard by which, hopefully, one can download a binary and it will "just work", whether you're on a "by hackers for hackers" distro or one that holds your hand. and complying to the standard doesn't necessarily inhibit creativity or progress, as the end-user/sysadmin is the ultimate authority.
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 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 variety of interesting projects? no.
the freedom to experiment exists and is encouraged and adopted within Slackware, while it still maintains standards compliancy.
They're not expensive, just overpriced.
sup
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
I'm not trolling.
I have zero problems with commerical software.
I'm saying that the commercial linux market is "owned" by 2 players who have no motivation to level the playing field for competitors.
Are customers clamoring for open standards? No. If they were, RH & Novell would be scurrying to become compliant.
I do not work for MSFT nor am I an "elitist snob".
I am far beyond worrying about being seen as cool by the linux community or anybody else, than you.
Read your history. Look at what happened in the past when various consortiums tried to standardize UNIX, standize the UI, etc... Do you think that just because we're talking about companies that make Linux instead of UNIX that they will magically stop behaving like ongoing commercial concerns?
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Isn't it just to differentiate removable storage from other mountpoint types like NFS?
Hell, makefiles generally take care of that.
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.
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.
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?!'"
I've always thought of LSB as more or less a joke. It provides people with a roadmap of where to expect most of the usual commands. The vast majority of Linux distros are based on GNU tools (i.e. the whole GNU-Linux debate). GNU tools are generally built into the same directories. Almost all Linux distros can rely on a good basic /usr /usr/bin /bin /sbin /usr/sbin /etc structure. They almost all share the same tools that are spelled out by LSB, and considering they almost all use the same libraries (glibc, etc) they pretty much share the same library interfaces and so on.
There's nothing LSB offers that isn't already there by nature of the tools that most linux distros use. Linux distros pretty much migrate toward a standard just due to the very nature of it's Unix/GNU inheritance. Why spend the money to certify?
Now, especially add to the fact that the majority of software vendors don't sell you products for LSB-certified Linux distributions. Instead, they certify specific versions of RedHat or Suse or whatever, and in some very annoying cases, they spell out specific glibc and kernel versions. I.e. go beyond those, and their technical support will tell you to go away.
Software vendors don't care about "standards compliance" in the sense that they want their product to work. They don't want to deal with any unknowns. Any unknowns puts their QA reputation at risk. Just because someone is compliant to a standard doesn't mean it works the exact same way. If Vendor A were to create Product X, and wanted to support Linux Distro Y and Linux Distro Z and both distros happen to be LSB complaint, they aren't going to gain anything from it, since they're still going to have to test against both platforms to ensure that they work. If they don't, and for some reason something not specified in the LSB standard (or hell, even an implementation of something specified) causes a compatibility problem, and customer C happens to be a multi-billion dollar company with lawyer-happy executives buys the product and finds the problem, the shit can really hit the fan.
I work for a relatively large software company, and I've seen lesser things trigger lawsuit threats.
This is why the LSB is useless. You have to pay to get it. For you to justify paying, there has to be a financial interest. Financial interest generally means, they want to run some vendor's commercial app. That vendor is going to re-certify the platform no matter if it's LSB certified or not. And unfortunately, vendor's are going to look for the biggest bang for their buck (i.e. redhat or suse), so if Joe Blow Linux distribution goes LSB, the vendor still isn't going to support that platform.
In line with what KDE and GNOME do (e.g. `gconf-config --libs-dirs`), why not have a single program that reports where different things are supposed to go? This would save the difficulty of having to having these companies/orgs actually agreeing to things, and would make it easy to make sure things always go in the right place (e.g. a makefile can simply do 'sys-config --install-bin-dir' to figure out where to install the resulting binaries). You don't even need to get the distros to agree, as these things can be fairly easily maintained by a third party. All you need to do is make sure this program always goes in the same location (e.g. /sbin/sys-config). Might even be able to replace autoconfig/automake by letting the program advertise the capabilities of the system (i.e. programs can register/unregister capabilities).
Just a thought...
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.
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
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
It seems perfectly reasonable that distributions collectively agree on what and where things are going to go. Standards directory struc. (beyond just /etc, /bin, /sbin, /usr, etc.) so that libraries go HERE and programs go THERE, etc. It is fine to have system apps in /sbin and /bin, and user apps be in /usr/bin, etc. but PLEASE just keep it to that. Every other commercial OS has been able to do this succesfully (windows, Mac OS classic and OS X, etc.) and it has worked well for them. Sure, even a moderate linux geek will be able to tell you what is where, or at least where to find it, but my grandmother won't unless it is right there in front of her. Having standard environment variables, paths, directory structure, even (dare I say it) a standard package system could only help linux. How is the average user supposed to tell the differance between an RPM based distro, or .deb, portage, or any other obscure not-so-commonly-used package system -- further still, how is my grandmother to understand that an RPM isn't going to 'just work' on debian or gentoo. Windows users know .exe and that makes things easy for everybody to download and install anything fast without ever having to know where lib*.so is, or what arguments to tag onto %sh ./configure --*. Why should anyone have to sit and stare at a list of distros and weigh what package system they should go with to make their experiance as easy and fast as possible? Shouldn't such decisions only arise for IT directors and system administrators? It is these issues that will easily keep linux on the server, or the geeks desk. Don't get me wrong: I love my choice of distros, and like the variety between RPM, .deb, portage, etc. (some systems I just find easier and work better than others to throw on a server here, or workstation there) -- but I wouldn't mind having 4 or 5 distros that I could throw in a computer and know where everything is, all the time, with little-to-no variation. Maybe a situation where I can just go over to versiontracker.com and download a package, double click, hit next, and be done with it.
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
I was at a talk on LSB at linux.conf.au yesterday. It really made me think... LSB is all about the ELF binary format, the GNU toolchain and runtime libraries and so on. It really has nothing to do with "Linux", and (reportedly) several non-Linux systems like Solaris, HP-UX, and *BSD can be made to pass all the tests.
It seems like "LSB" is one of the more outrageous cases of using the word "Linux" to describe GNU or Unix things entirely outside the kernel. So this is not a case where "GNU/Linux" would be a better name -it's a case where just "GNU" would be a better name!
LSB in effect says nothing whatsoever about your kernel, it is all about binary compatibility though user-space linking policies, library versions, and executable format - not your kernel. And guess what - in a GNU/Linux system those things come entirely from GNU parts and the ELF standard.
All an LSB-compliant OS needs to do is to make a way to install these foreign, third-party application packages. Debian uses the software "alien" for this, for instance.
I'm not really sure where you're going with this. In the windows world, you have to know where the executable is to run it. In linux, you just open up a console or "run" dialog and type the name of the program. And any good package manager is going to take care of this for you. Who cares where the executable resides if the package manager is taking care of it? And a good package manager should also put the icon in the menu for you. Basically, this doesn't have much to do with GNU/Linux, but how your distro and the package manager deal with things.
Alright, I've said package manager enough.
We as the Linux comunity should care....the more users an OS has, the more potential for development...thus the more job for developers, the more possiblity for for competition thus leading to innovation.... if a set of standards are adopted, what distros do you think compinies will write software for, the ones where they have a map to making it work on as many deaktops as possible. now you may argue that this could also be the end of OSS development, but think of a linux halo effect, similar to that of the ipod halo. start small, work your way in and around.
I tried. Not once. With everything (hand, apt, alien, whatever). Sometimes, you can work it out. Sometimes, not.
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.
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.
Don't get me wrong. There are a lot of people and a lot of companies moving in the right direction with Linux. But I can't help thinking (and believing) that there are still a considerable number of people in industry who are very comfortable with the fact Linux is not as easily manageable (as a desktop OS) as Bill or Steve's products.
I'll be the first to admit, it massages my ego to think that I can use (let alone administrate) Linux when the majority of the population (and it is a significant majority) still consider it something that is beyond them. It's not something I hear advocated often, but I honestly believe there is some truth in this observation. If the Linux community *REALLY* wanted to make the OS as (dumbass) user-friendly as Windows or MacOS they could have done it years ago. Its not like they don't have the development skills or the resources.
It's not just that Windows has the marketing budget and the PR machine. It's the fact that it's aimed squarely at the average man/woman in the street who doesn't have the time and frankly doesn't care about anything other than being able to point and click half a dozen times to perform practically any operation.
I just wish more people would wake up to this. If Linux is ever going to seriously make a dent in Gates' desktop monopoly it's a sacrifice that's gonna have to be made.
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!