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."
I have heard of LSB.
I have not heard of LSB.
If I'm the producer of a linux distro and I want to make it as easy to use/run apps as Windows/Mac, why do I need LSB? I'll just do it myself.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
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 will admit that the idea of LSB is nice, compile once - run everywhere, however, in practice, it doesn't pan out. Much like Java was suppose to cure all the worlds programming problems, write once - run everywhere. But, as we all know, Java, while a nice idea, simple doesn't live up to the hype; and possibly never will.
Suppose you comply to a standard and the standard doesn't evolve very fast as well as the process for improving the standard being long-winded.
This creates a situation where developers feel restricted and many open source developers develop for the fun and achievement. If they want restrictions, rules and regulations then they will program commercially.
I'm not against standards but there must be reason for the slow adoption of this standard. We have to look and see who the standards are created by, who they serve best (commercial interests) and if they hold back innovation and modernisation.
One word: Freedom. Linux is free, as in speach. The LSB restricts that freedom. It also has some negative aspects, like an RPM requirement. Basicly LSB sucks.
-73, de n1ywb
www.n1ywb.com
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.
They can't be bothered and/or don't care. I'm willing to bet thats 9/10s of it.
LSB is a bunch of people tyring to make themselves relevant by imposing restrictions on how Linux should develop.
The strength of Linux is it's flexibility, ability to react to users needs quickly, LSB would be an unnecessary burden then.
Also, it is not like Linux developers can not agree between themselves on major things anyway.
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?"
Redhat and Novell have their own ecosystems around their distributions - why should they want to swap that for a common standard?
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....
Well, LSB is a good idea, but it is really redhat centric, meaning that a LSB application would not run on deb/gentoo/distro x. Its kind of a catch 22. vendors don't want to make packages for every distro/version out there, but having many distributions with their own way of doing things is really needed for innovation.
I recently switched to Linux. I expected to do some learning in spite of some previous Unix experience, but I agree with the OP here. Why should I need to find packages for a specific distro? That was a rhetorical question for those inclined to offer technical explanations. I would argue that LSB is not quite up to snuff. I like that the debian port to AMD64 assumes everything is native 64bit. This contrasts with my FC3 install which has /lib and /lib64. I prefer the debian thinking on this, but that's not the LSB way. I guess this provides one reason not to conform.
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.
You'll note that LSB presumes a 2.4 series kernel. Most distributions are based on 2.6 kernels. You'll note that if you install Mandrake 10.1 and select installation of the LSB package, it will warn you that it will install a 2.4 kernel in place of the 2.6 kernel (with a decent explanation as to why).
A newer LSB should be along any day now, and non-compliant distributions will likely release an LSB2 compliance package.
As far as becoming "certified"... There are about 350 Linux distributions. Many of them published by very small groups. If they have to pay or do anything too ornerous to get certified, they won't. If it's a matter of running a test-suite and sending the results to an authority for verification, then they will likely do that...
POSIX was a standard, but didn't include enough.
LSB might work for many programs, but new ones will come along that use some new nifty language or library, and people will want it, even if LSB does not address it.
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."
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.
Please forgive me if I am wrong, but I think that statement not true due to multitudes of incompatible library versions and such, although I do think LSB is a step in the right direction. The best we can hope is that LSB compliance will guaratee source level compatibility (and even that is probably unattainable goal due to differences in gcc versions)
Why has this been modded troll? It's fact... look at the mini you stupid mods
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
I am not trolling . I think the Linux community will be very difficult to adapt standards because the thinking is very individualistic. If we don't like something then we will make our own and by golly no one should tell me what to do. I think developing a distro so that things are as easy to do in windows yet secure is close to impossible. Not one likes change. Especially users that are not very tech savvy. They would have to grow to understand a technology that they would rather just use. It is also very difficult for developers to get in the heads of non tech end users to develop a product they can comprehend. It is a constant challenge to speak in layman's terms to end users on how to use a windows product. Even harder to develop something for a new platform where every command and action is new. I am not against attempting these standards. I just have a doubtful feeling about it. I hope I am wrong and we can see Linux spread to the corporate and home users desktop soon.
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();
OS.
Linux is a kernel.
It would be nice if distribution makers stopped calling their distributions Blah Linux, and started calling them Blah OS.
It will be worse on commercial software developers for sure. And it could be bad for small niche open source apps. But, the benefits would be huge.
I have seen many times people complain that they can't install a Mandrake RPM properly on Red Hat and vice versa. You shouldn't be able to. They are different OSs.
SuSE OS, powered by Linux is more correct than SuSE Linux.
LSB certified software would only promote close-source binaries that link against a specific set of libraries on an LSB certified system. Anyway... It's never stopped commercial software companies from shipping their own libraries with the product (though that negates the benefits of such a system as Linux/UNIX). LSB certified software promotes "standards" that are extremely centric to a handful of commercial distributions (e.g. RPM as a primary package container). Not that there is anything particularly wrong with RPM, but I prefer a different package for my system. LSB certified software limits freedom of choice to innovate and try new things with indivual distributions. If the majority of distributions were LSB certified, and a company only makes software that works on LSB-certified machines, would that not hinder distribution maintainers from trying something new (perhaps better) that deviates from the LSB standards? It's not surprising that so many people are reluctant to adopt this. There is very little that it will do to actually benefit a platform that's largely built upon opensource software.
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
I have looked.
The total cost of the three of the PC's that I own (and all their spare parts) is less than the cost of one Mac Mini.
Exam 4/C again. Maybe I'll do better this time.
While I agree that the GP post in certainly not a troll, Macs are still more expensive than your standard PC. I *could* get a miniMac, which is about the same price as many PC's, but why should I go for something that has less than I would get if I bought a PC for around the same cost?
DISCLAIMER: I happen to like Macs.
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.
You must have some real piece of crap PC's. Maybe if you had combined the money and bought just one, you'd be better off.
But I'll bite. $167 per PC? Amazing.
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.
Mac Mini and iBook are not expensive by any stretch of the imagination. If anything, the parent is a reply to Flamebait started by the Poster.
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.
The LSB might be attractive to some, but the real issue is creativity and the ability to innovate withouot having to worry about "standards." That is one of the things that attracted me to Linux in the first place. I say LSB might be good for some, but I don't think that Linux or Open Source as a whole will benefit from it. Microsoft sure as hell doesn't have a "standard" unless that standard is to suck as many resources from your system and leaving you as vulnerable as possible is a standard.
I'm not a troll, but I play one on Slashdot.
In that light, what does LSB buy me? An easy escape route for my customers to switch distros.
(used Redhat in this example, but I think it pretty much applies across the board).
UnitedLinux is what killed the LSB.
Distro maintainers were presented with two standards to choose from: UnitedLinux or the LSB. Two standards is no standard.
Then SCO killed UnitedLinux and no one was interested anymore.
- Hail to our fearless misleader! Fool speed ahead!
Disclaimer: I have more b0xen running Linux and BSD than I have running Windows.
/usr/bin vs. /usr/local/bin and stuff like that, libraries that one should expect to find, initialization commands for services, appearance and functionality of the desktop, etc. Remember, most users don't want a lot of choices - they want one standard one that works. On the Kernel side, they should slow down and make sure that stuff doesn't break during a stable Kernel series. Yes, all the new features and bugfixes between 2.6.x and 2.6.x+1 are nice (and now we have 2.6.x.y - great), but it's nearly impossible to run a stock kernel on a production server because you never know if something subtle or not-so-subtle will be broken (hello OpenS/WAN). It doesn't matter if the bug is in the Kernel or the Application, most of us just want stuff to work.
Because the situation (I won't call it a problem, but it is for some) is that Linux development, especially the areas of the Kernel and non-commercail distros, is about what the developers think is cool, rather than what makes a practical and stable (in terms of applications running from kernel version to kernel version) OS. In many ways this is fine for a hobbyist OS, and liveable as an enterprise OS if you have someone like SuSe or RedHat (I use both) to keep things somewhat managed.
However, and you can flame me / mod me down / whatever you want for saying this, Linux will never be a great Enterprise or Desktop OS for the masses until some stuff gets standardized. On he distro side, little things, like what goes in
For those of us that don't have full-scale test labs mimicing our production environment, we can use SuSe or RedHat to have a decent OS that's far better than Windows. But it's frustrating because it's not nearly as good as it could be if things were more disciplined. Linux is probably OK on the desktop for many large organizations that have users doing specialized tasks that can be run without Windows (call centers, dispatchers, billing clerks, etc), however in order to get them using Linux the cost needs to come down - there needs to be a decently stable and standardized free distribution to help us admins crack that nut. The problem is that commercial desktop licenses are not sufficiently cheaper than Windows, and it's impossible to sell it (in most situations) to the beancounters on soft costs like stability, reliablity, ease of administration, and productivity because, let's face it - thoes guys got burned horribly five years ago on all kinds of bullshit promises (unrelated to FOSS) in projects relating to CRM, ERP, etc. They're still gun-shy, and from their perspective wisely so.
My $.02 - OSDL should make LSB testing free for most distros. If LSB needs to be loosened / tightened / whatever, then let's get it done. If Linux users really want to start making the OS mainstream, then standards within the community will be crucial. If they want it to be a cool alternative for people willing to learn a certain amount of expertise, then that's cool also - but they'll have to accept the marginzalization that will result. RedHat and SuSe can't do all the work here - everyone needs to get on the horse.
Help save the critically endangered Blue Iguana
and say that no distro that is not LSB certified can call itself Linux or Linux like, or anything relating to Linux.
I am the Alpha and the Omega-3
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
For around $200, you should be able to find around a 2 ghz P4 with something bigger and faster than a laptop hard drive.
Not the cost of being compliant. The cost of being compliant is the time and effort of getting a bunch of people to make sure it works before going to be tested. How much does a team of people cost on an ongoing basis?
Deleted
How is the POSIX standard and LSB differnt?
Wasn't POSIX suppose to be the standard so you can take some code from one unix(or unix like) system and put it on annother system and it would run?
I want MSB!
LSB = Least Significant bit.
MSB = Most Significant
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
developers favouring a particular distro:
"Here's a deb, but I'm never going to roll an RPM for you RedHat freaks!"
or the debian "version" of a program being several versions behind the "rpm" version because nobody's bothered updating the repository, or the third-party RPM maintainer has retired.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Isn't it just to differentiate removable storage from other mountpoint types like NFS?
This isn't really related, but since Slashdot refuses to actually post submitted stories about Novell/SUSE stuff these days, I thought I'd share this anyway Details about the release
it is as you say, the "general public" would benefit greatly from a standard. But it's not the "general public" that assembles the distributions. Maybe the LSB is not so beneficial to those who spend time and effort on creating the distributions. After all, the more standardized the distros are, the fewer reasons there will be to choose one distro over another. And presumably the distributions are competing and this is a good thing. Competition entails differentiation, it's a necessary implication of it. The alternative would be a single distribution with many "resellers" who would only compete wrt services, but that's clearly not the landscape we have today. In short, it's not really in Red Hat or SuSE's interest to bring their distributions in line with each other, it just robs them of "unique selling points."
Mod Parent Up. In the days of Qt/Java/Python/C#, why would I want to code directly to libc or libm for application development? Maybe LSB is for device driver writers but for the rest of us, it is DOA.
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.
1) A software installer comes along that blends portage with apt-get. Compiling from source will not go away. Downloading binaries will no go away. So there needs to be one that does BOTH at the user's preference.
2) Distros want to play ball with one another. I want to physically abuse every developer that goes "Distro X sucks ass" "Distro Y does this some retarded way" There's alot of ego, elitism, and ignorance preventing cooperation out there... and it needs to stop. When the big players representing all aspects of Linux deployment (Red Hat, Mandriva, SuSe, Gentoo, Debian, Slackware, Ubuntu, Xandros, Linspire) all get together and decide to REALLY be competitive on the desktop market... and stop the bickering crap... that's when things will progress. The distros need to realize, and Ben Franklin did long ago... "We must hang together, or assuredly we shall all hang seperately." Together the distros yield the power to standardize and push deep into the heart of M$ market share. Seperately, they possess the power to waste alot of effort battling each other, much to the delight of M$. And yes, this means some distros will have ground up reworking to do. The rewards justify the work. So stop your bitching.
3) It becomes high enough priority to begin rejecting software binaries / ebuilds that do not comply. It needs to take an act of Linus .. errr... God... to get non-compliant software included.
The Peanut Gallery, Ubergeek, Biblically Sober
NCAAbbs.com: Thousands of fans, Hundreds of teams, Just one place
This is why I'm a Mac developer. My code will run on any Macintosh system running OS X. The user doesn't have to compile for their distro, they don't have to install a bunch of libraries (hell, I can pack libraries into my application myself if needed), and they don't even need to run an installer. They just download, double click, and go. On Linux for the best compatibility, I'd probably distribute the source, require the user to build (which can take a while on a slow machine), and then they'd have to install it. This is assuming the user didn't have to download 3 or 4 libraries. Distributing binaries would mean compiling for every single Linux distro out there. And guess what? Using any solution that involves the terminal in any way, shape or form would be a bad thing. The average user is scared by a terminal. A huge problem on Mac OS X is getting old school Mac users even comfortable doing basic operations in a terminal. Terminal = scary text place for the average user. A nice solution would be to wrap make in a nice GUI for distribution with programs, but again that requires the GUI be compiled on the machine depending on the distro... oh crap... problem not solved.
In my opinion LSB is sort of a super-distro. By this I mean that it tries to dictate what distributions should include, at least the basic components.
Personally, I see this as an insult to the distributions. The distributions should have control of what goes into the distro (and they do). Mainly they want the same things inside as LSB wants inside, so there's no problem. On the other hand if there is a disagreement, no one really cares about LSB.
The solution to the problem is repositories. In this realm, distributions rule; LSB has no place.
Tharkban (It is a signature after all)
The biggest advantage I see from having a standardized linux is that of support. Many companies will not support linux because there is so many variations of how things are done. If there was one standard that was guaranteed to be available, no matter what the distribution, it would go a long way towards second party linux support.
"I'm not impatient. I just hate waiting." - My Dad
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.
I mean only RedHat, Suse, Debian, Mandrake, etc are LSB certified. I wish the big 4 would get it together. Oh wait.
Anyway call me jaded but I'm just going to chalk this up as yet another "Linux needs to do X to go mainstream!" article which doesn't talk about anything we haven't heard a million times before.
In reality what keeps the distros "different enough to be a hassle" is that they all want to be unique. If every distro looked exactly the same, used the exact same software, all ran the same exact kernel, and could all interchange packages with zero effort then that would be a real problem for the various distros. It would be a problem for the commercial distros and a problem for the community distros. Don't kid yourself, everyone wants to be number 1, even in OSS.
People thinking that there is going to be some sort unified single megadistro that everyone gets behind are delusional.
If you wanna get rich, you know that payback is a bitch
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...
Its called FreeBSD, and you use the ports system..
No dependency problem, no wondering if package X works with linux distro Y.
It just works..
And yes, i fully expectto be modded as a troll, as i wasnt blindly supporting linux... bad me..
---- Booth was a patriot ----
IMO it's way easier to install software on e.g. Debian than it is on Windows - and when it comes to keeping a system up-to-date... Fuhgeddaboudit!
On windows you have to either find the software on some obscure website or have a cdrom with it - and then when you need to update the software, you need to go back to that obscure place again. Fortunately many programs are starting to ship with an "update self" feature - but still...
On my Debian box I simply search the apt repositories I've put in my configuration, when I find the software I want - install it and Debian takes care of the rest. And if I want to update my system... 'apt-get update && apt-get upgrade -y'. And if I'm not comfortable with the command line I'll just use a tool such as Synaptic.
I know several non-techy people who has made the switch from Windows to Linux and all of them have been very impressed and delighted with Debian and it's package-system.
"Live free or don't."
People like the grandparent poster and RMS chase people away from linux. They are not interested in the success of the platform. Their only concern seems to be maintaining the status quo and their status within the movement.
It's funny how linux advocates so often accuse mac users of be elitist snobs.
Jesus was a compassionate social conservative who called individuals to sin no more.
If its LSB version X runtime environment Y compliant, it will run on any distro that is LSB version X runtime environment Y compliant.
_ Runtime_Environment_IA32_20_PS.html
X being the version (currently 2.0) and Y being the architecture (like IA32/X86)
Here is the LSB 2.0 Runtime Environment IA32 standard: http://www.opengroup.org/lsb/cert/docs/PS_2.0/LSB
...Distro wars...
...Always two they are, TAR.GZ and TAR.BZ2...
...my own, you mean my own (L)ight (S)a(B)er...
Darth Vader: What are thy biddings, my master?
Emperor: rm -rf /
...May the Source be with you...
sex is better than war!
Why is LSB not seeing greater adoption?
"Provided by the management for your protection."
Linux is never going to palatable to the general public. There's almost always going to be a sizable learning curve that accompanies Linux do to the nature of most of the Linux applications and developers. There aren't many LSB distributions because the Linux community, for the most part, doesn't really care about the general user base.
Not to sound elitist or anything but, I really don't want "incompetent", Windows-esq users polluting the Linux community. I like that Linux is difficult to learn and master. That difficulty is what makes our user base strong and committed. If you run Linux, you're going to have to really want to run Linux. And that means... learning to use it. Think of it as a sort of litmus test. If you can't pass... tough. After all... the programmers hobbyists, and system administrators that made Linux what it is today really don't need these "simplified" standards. We already know what we're doing. We know how to compile an application and modify it as necessary to fit our needs. After all, it was that very ability to modify source code to fit our needs that made Linux popular in the first place.
To hell with rpm's and deb's and other such standards, just give me the source. I believe that having one grandiose, de facto standard will ultimately kill Linux through the slow death of conformity. If we begin walking down this road, Linux will end up just like every other user-friendly piece of garbage you see sitting on the shelves of your local computer store.
Anyway, that's just my $0.02.
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.
I'm curious about what sorts of problems you ran into. I was under the impression that configure scripts were designed to at least make source code portable, by dynamically finding the various libraries and such that the application requires. Now, my experience in building and installing nonstandard software has been limited to small, simple command-line utilities like optipng or dvipng, which I built, tossed the binary into ~/bin, and left there forever.
I really am curious about what sorts of problems are run into, and what steps would need to be taken to make the inter-distro porting process closer to trivial.
--grendel drago
Laws do not persuade just because they threaten. --Seneca
Linux anti-virus is run on mail/file servers to protect vulnerable Windows boxes from other vulnerable Windows boxes.
AMD 2400+cpu, 128M ram, 40gig HD, Case, Power Supply,
Motherboard (with serial,parallel, video,usb,ethernet, sound, 56k modem),
Keyboard, mouse, speakers, Linspire OS (SuSE 9.2 installs just fine)
$179 @ Fry's on sale every couple of weeks.
I have two.
The ones that don't still use the LSB and FSH (File System Hierarchy) test suites, like Debian does.
So, exactly what distributions are we complaining about? Seems like the LSB and the FSH standard are seeing pretty widespread adoption to me!
I develop commercial software on Linux and I feel the pain.
LSB is badly needed to enable the birth of commercial applications on Linux. Even with the amazing things that open source hackers have written, there are lots of application areas that just aren't sexy enough to attract people to develop them after they've put the kids to bed in the evening.
Commercial applications cannot sell if they just offer Red Hat RPM packages. On the other hand it is prohibitively expensive to make packages for every distro out there including all their versions from the last 5 years.
The way I see it, Linux is still a hobbyist OS that just isn't mature enough. I would much rather develop for Solaris or OSX, but amazingly the customers shy away from these platforms and love the penguin instead.
... the number of open soruce projects out there would create an overflow of validation requests, especially while it's getting started up.
"...why should I go for something that has less than I would get if I bought a PC for around the same cost?..."
Maybe, because, you want a small, quiet box? This assumes, of cousrse, it's expandability and performance meets your needs.
### but I think that statement not true due to multitudes of incompatible library versions and such
LSB is specfically for binary compatibilty, everything else would make little sense, since for most part its a standard for commercial vendors, less for the free software guys, which I think is one of the reasons why its adopted rather slowly. I have actually *never* seen a single LSB-conforming RPM in the wild, only once I know are examples on the LSB webpage itself.
But the sentence you where refering to is still incorrect, LSB doesn't mean that when you compile an app that it will magically run on another LSB system, LSB only means that you can run a LSB conforming binary, it says nothing (or little?!) about compiling stuff. To compile LSB binaries there is lsbdev, which is a collection of library stubs (kind of a mini-distri) against which you can compile, everything not provided by them you have to include in your binary.
### The best we can hope is that LSB compliance will guaratee source level compatibility
Source level compatibility is already a pretty much solved problem, heck, if you use portable libraries you can even more or less out of the box compile many stuff on Win32 or MacOSX. Sure, source compile is not always that beatifull, ie. pkg-config hacks instead of MacOSX-like '-framework', but it still works rather well.
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.
This is the operative sentence. Yes, it would be great for the general public. Unfortunately, a commercial entity wants to be able to differentiate itself from every other entity doing the same thing, otherwise there is no reason to pay them. They want to be in a position where all the other vendors are forced to implement their [defacto] standard.
As for the geeks that a doing it for fun, discussing and/or implementing a standard generally does not fall into the category of "fun things to do". (Sort of like documentation).
It's no surprise that no-one's doing this.
Why blame the distros? If the various apps didn't cater to all the blatant incompatibilities, most of them would start going away. If you want a standard to work, get the non-os developers to support it. If _all_ word processors and text editors look in /usr/local/text/editors/macros/ or /usr/local/text/processors/macros/ or some such location for macros.idx then eventually, the os makers will include skeletons for that.
/usr/local thing specifically, just using it as an example. Why not start an "application standardization" project, with utilities to create any needed files and and directory hierarchies, set permissions, etc, without relying on the distro to do it?
I'm not advocation the
For that matter, why not include a registry system in that, to locate needed resources like libraries, binaries, documentation, again independent of a distro? That way the system wouldn't be limited to just Linux... the BSD's, Solaris, etc could be included and improve cross-platform consistency.
A well defined standard for this kind of thing, especially if it encouraged portable coding practices, might be a better solution than going to the distro makers. After all, didn't all this grow out of the grass roots anyway?
The status quo is a sign of success of the platform.
It is an opinion that will always have different views. Some will think that once you ad propriatary stuff to the distro it no longer is free and you alienate them. Others will whine that it is too hard and thier brain hurts and won't use it either. Still others will view comments like ours and say why should i even try it.
What the real problem seems to be is user X is complaining that he isn't using windows when using linux. Companies are complaining that they don't want to test thier product on linux but rather on redhat and it is too hard to make somethign on redhat work on something else almost identicle in the working sence. Your complaining that people are complaining and i'm complaingin because you don't se the same way i do.
When we get down to the root of it, we are expressing opinions of ours and others opinions and have the freedoms to be different enough to compare opinions. Microsoft and Apple don't give you this choice. Thats why we have what we have now. You see it as a draw back and i see it as a plus. I'm not concerned with everyone using linux on the desktop. I don't see that as a sign of success. How i measure success is that i can do anythign i would do with a windows box and hope those tasks aren't more difficult then working on a windows box. If other users find simular results and want to use it, more power to them. Replacing microsoft as a desktop isn't exactly what linux is about. If it happens then so be it but i don't think it is or should be a primary goal.
ok, for users who migrate from windows, but are too ignorant or in-experienced with linux (or simply lack reading comprehension + google skills), they can simply use Fedora/RedHat/SuSE/Mandrake/Etc.
The LSB is adopted in MOST of the widely used distros, but also enables them to be easily exploited (theorectically), compared to a customized system that doesn't rely on the LSB.
I prefer linux to not use the LSB, as I prefer to compile and configure things according to MY needs, not the needs of the mass. (just my personal preference)
the only permanence in existence, is the impermanence of existence.
You just got added to my friends list.
Le français vous intéresse?
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
how about rebooting so you're running the installed system and kernel rather than that of the install cd in RAM?
Linux is about freedom.
Freedom has a price, in this case the price is RTFM (Read The Fucking Manual).
I am portuguese. If you think my written english is bad, try posting in portuguese!
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.
Seems to me that would defeat the purpose of having a distro company in the first place. Maybe the distros just don't want to contribute to their own demise?
Seriously, I don't see the point. We've already got POSIX for the interface to the libraries and the kernel. We have FHS for the filesystem hierarchy standards. Pretty much anything else, or any deviation from those standards, is being done intentionally by the kernel or distro developers.
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 believe 1) has been done a long time ago by FreeBSD. It has ports (source) and packages (binaries), the packages are built from the ports, and it doesn't matter if you use a port or a package to install something.
Given portinstall, you can specify things like "install koffice and dependencies, use a package if the available one is as new as the port, otherwise compile from a port", or "install koffice and dependencies, use packages when one is available, even if it's older than the port".
(The commands are "portinstall -P koffice" or "portinstall -PP koffice".)
Portage is inspired by ports, but from what I've heard, it missed this very useful functionality.
What is this crap every time? "don't want to pay for Mac".
/. users all such incredible cheapskates that a few dollars difference makes a person choose a system, completely disregarding functionality, included software, build quality, design etc.? Is price the all detrmining factor, even when the price is down to a few tanks of gas? (A new Mac costs the same as 6 tanks of gas here in the Netherlands).
PLEASE come with plauable arguments against the Mac or any other system. You can get a mac for 420,-. Are
If that is your only buying criteria, you're all a bunch of idiots, and deserver whatever junk is loaded on you by the pigolpolists, whoever they are.
You want the short answer? No one gives a sh*t about the LSB.
Oh, wait, that was the long answer.
Why Standarize when you can improve
Yes, that's right who needs stupid HTML 4.01 conformance? Let's add a blink tag! No, wait, let's add Document.Layers! And Document.All! And Iframes! And Marquees! And ActiveX!
Who needs standards, anyway? </sarcasm>
7
No, it's a retorical question!
8
I run a business. My business isn't anything high tech, but it revolves around software. I, as a business owner, am in no way going to trust my entire business, my livelihood, and the livelihood of all of my employees to software that we can only get to work on one distribution. No way in hell. Red Hat, arguibly the largest distribution maker out there is still entirely too new, entirely too unstable (as a company), and provides an insanely support time period for their products. If I knew that Program X that we need to run our business will run on ANY distribution, then I'm a lot more likely to consider something Linux-based. Right now, I'm not going to trust my business to a tiny startup, and pray that A. They don't fold B. They continue supporting my product C. Don't force me to buy a new version every year and D. Program X will always be supported on that distribution. To do so would be short-sighted, and a terrible business decision.
I don't respond to AC's.
I too have been looking for a decent GUI-based fax program in Linux. Most of the ones I see are pretty good for usage on the command line, but people who aren't experts at computers would have major problems using or initially configuring them. It would be great if someone made a Norton Winfax-like GUI to hylafax or efax or something for Linux.
You bet! I think it's very appropriate that you used the plural of ``standard'', since standards are what seem to be emerging.
The commercially-oriented distributions, such as RedHat and Suse, seem to have settled on RPMs. Most of the hot non-commercially-oriented distributions (e.g., Ubuntu, Knoppix, DLS, Debian) seem to be based on Debian, and use debs. Looks like two perfectly good standards are growing from the grass-roots.
If you are a proprietary software vendor, you can compile your Linux application with static linkages, and be pretty sure that it will run everywhere with minimal dependancy problems. Make a deb and an rpm, and your problems are pretty much over. I suspect that's what Adobe does, though I've never bothered to check.
If you want dynamic linkage, you can either try to keep up with one or more distributions, or you can try to let the distributions do the compilation and packaging themselves, as NVIDIA does.
Right now, installing a new application which is available as a deb is trivially simple, and it makes the hoops the poor windows users have to jump through seem positively primitive.
I just tried to get the software (from PalmOne) to sync my handspring installed on Windows XP at work. I had our office Windows expert sitting at my desk for half the morning, and he got the software intalled, finally, but it still hasn't actually sync'ed my Palm to the work machine. Making it work will be another mess entirely, I guess.
On my Debian Sarge machine at home (which supposedly isn't ready for the desk top), I googled for some search term like ``hotsync debian'', found out that I should be using something called jpilot, typed apt-get install jpilot and was hotsynced in minutes. Ease of software installation is no longer an area where Windows has a edge: quite the opposite, in my experience.
See what I've been reading.
UNIX : LSD-certified since forever.
(Don't believe me? I'm not the one saying it: "There are two major products that come from Berkeley : LSD and UNIX. We don't believe this to be a coincidence." -- Jeremy S. Anderson)
Hello! I'm a disaster waiting to happen!
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.
You could ask the distro maintainer to create a statically linked binary, but guess what? He has better things to do on the gazillion apps he's distributing.
There really isn't any problem with the software distribution systems that exist for Linux. It's just that there are too many of them. For instance, there's nothing in particular wrong with Debian's system, and Debian's system doesn't force developers of apps to do something that they don't want to do.
Find free books.
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.
I can't speak for the GP, but not being a proponent of the LSB has nothing to do with being geeky. I figure if the LSB was such a great idea, all the distros would have signed up en masse. I'll leave it up to the true geeks, the people who build the distros, to decide how best to do it. Personally, I think a little diversity between distros might be beneficial - it makes it tougher for Linux to become a breeding ground for malware like that other OS.
Perhaps giving every file (or logical unit of information really. Doesn't have to be a "file") created a globably uniqe id would be a step in the right direction. Then, when an app needs a file (library or data file) to run, it doesn't need to know where the file is. It just tells the OS (or some layer on top of the OS) "Give me the file with ID foo". The filesystem finds it, no matter where it is because every file written to the file system has its globally uniqe id indexed.
Doesn't .net do something like this?
Red Hat & Suse have enough of a lead, that all they get by agreeing to LSB is to create a more level playing field for the dwarves. The dwarves may join, but in the absence of one of the major players also joining, this in and of istelf will not be sufficient to push the dwarves into widespread commercial acceptance.
While the share of the pie may be smaller for the big distros, the pie itself will be bigger with standards thus helping all distros.
FalconShould there be a Law?
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.
As far as I'm concerned, that's the biggest problem in the business *world*, they feel they need to maximize profits for the short term and don't care much about the long term. Such an attitude isn't very sustainable.
FalconShould there be a Law?
Please go back and read the LSB standard. There is nothing in it that specifies what package format the distribution must use for its own packages, it merely specifies what single package format must be accepted for 3rd-party software.
Debian already has debs that provide LSB support (that you can choose to install or not) and it supports the installing of LSB rpms (using alien):
It is sad that so many people keep harping on this non-issue.
I don't want RPM /opt
I don't want PAM
I don't want
Is my distro still LSB?
The LSB does not mandate a package format for the base system. It specifies a distribution format for 3rd-party packages. Allowing a developer to distribute a single binary package format for all LSB-compliant systems is a good thing.
For further proof that your RPM fears are unfounded, log-in to a debian system and run "apt-cache search lsb". You'll see plenty of packages for installing LSB support, for installing LSB 3rd-party packages, and even for creating LSB-compliant RPMs.
Since when did the dark side ( us ) care about our choice of *nix becoming adopted by the general public? If The LSB becomes widely adopted I still dont think it'll matter much to the general public anyhow. They apparently like being midless sheep and being vulnerable. And if this LSB gains momentum would we see a push for it on the BSD side as well? I just don't see the need for this. You could also say that without a standards base in place it weeds out the general public which in my opinion is good.
Step out of the box and enjoy life
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.
See subjet.
/mnt. I like mounted devices under /mnt because it's called mnt. LSB says I must clutter root with /cdrom and /floppy and so on. I'm sure they had good reasons, but I don't like it, it makes no sense, so I wont do it.
/opt? Why give it a stamp of approval by making it standard instead of squishing it out like the poor hack it is?
LSB is great only if by "Standard" you mean "Take everything every group does and OR them together."
Then there's the things it gets wrong, like
Distro makers doubtless feel the same on one or more issues. The whole FHS thing is mostly bogus, since it allows almost anything to be put almost anywhere. And, really...
Some things are good, such as the object format stuff. Either it's good or I don't know enough to critique it, which I don't. Some of the utilities LSB demands are the wrong way to solve the problem. All of the crap about init scripts and booting is annoying and wrong. The RPM requirement is just stupid.
People don't support LSB because it makes no sense. Roo many rules about all the wrong things. Personally, I'd like to see a new LSB which did not attempt to include everyone but just did what seemed logical. A standards base which actually makes rules fixing things which tend to differ, rather than codifying differences and calling that standard.
If it were me I'd just declare whatever Debian does to be standard and heckle people who deviate. But I do bow to the alter of Debian, and I understand why some would not be comfortable with that.
I want my Cowboyneal
a) RPM
.spec format is beyond horrible in all sorts of different ways. I advocate crucifiction for whoever came up with the idea of sub-packaging from within a spec file in particular...this "feature" alone tends to make specfiles for glibc in particular an incomprehensible nightmare...and I can also virtually guarantee that this particular feature almost exclusively is responsible for every mangled RPM-based system anyone has ever read about...it is also responsible for the inability to compile single non-RPM based applications on an otherwise RPM based system. In short, sub packaging was an almost indescribably bad (not to mention completely unnecessary) idea, and IMHO should be removed from RPM.
I'm assuming that the fact that RPM is even part of the specification is due to Red Hat's influence, nevertheless it most certainly should not be. For one thing, RPM's
In addition, the standard macros are also completely opaque...you've got no way of knowing what on earth %setup -q T b does unless you've looked it up.
b) Economic theory
Economic theory says that in order to sell something, it is ideally desirable to have what is called a Unique Selling Point...i.e., to have something unique which nobody else has, which is the reason why someone is going to buy from you, and not the zillions of other companies in the world. Thus, being non-standard is actually the *only* means a Linux vendor company has of creating an incentive for a consumer to purchase from that particular company, rather than any other. Standards (at least beyond a certain degree) would end up meaning that every vendor sold a completely identical, generic product...and therefore, no consumer would have any incentive to buy from any one vendor in preference to any other. *Customers* might want that, and vendors pay lip service to it because they know customers want it...but the vendors themselves in reality do not want it, because it would be very bad for their business...so beyond a certain point, complete standardisation ain't going to happen.
c) Standards aren't *always* a good thing. Standards are primarily a good idea when talking about communication. The Web is a good example. Because the Web itself relies on standard protocols/specifications, (HTML, HTTP and so on) the idea is that individual computers, sometimes with radically different operating systems *internally*, can reliably communicate with each other *externally* on the Internet. But for each one of those computers to always be identical *internally* can be an extremely bad thing, security wise...Microsoft's woes in terms of virii, worms, and trojan horses provide all the evidence needed to prove this point.
d) An operating system/standards monoculture is only really desired by people who are seeking an excuse to be able to avoid using their brains. Such people want things to be so completely simplistic that they can perform any task on rote, and most especially, so that they can perform any task without the truly horrifying prospect of needing to actually *think.* This is not to suggest that I am completely opposed to anything being user-friendly...quite the opposite. But I *am* aware that there is a very large segment of the computer using population who are willing to put Eric Raymond's "luxury of ignorance" ahead of virtually every other aspect of software design in terms of importance, including security. "Give us one single operating system, and do not allow the complexity of any aspect of it to be greater than a retarded five year old's ability to deduce!" Such is the rallying cry among these souls, and I hear it on an almost daily basis, albeit normally somewhat veiled.
You could just statically link everything and then your program should run on all distros on that architecture. :-)
:-) means I'm joking.)
(The
Coder's Stone: The programming language quick ref for iPad
I don't think the OS should be designed in a way that makes the file system format as strict as LSB makes it. You should able to have a folder called myOS.os or otherOS.os boot to it and it should work.
Programs should be like they are on a Mac. You open myProgram.app and it runs a programs. No complex directry structure. Whatever the user wants.
Libraries should have folder in the OS folder one per library.
The linux standard base and what everyone else uses is more complicated then it needs to be.
Obviously, something is seriously wrong at your company if the CEO is "trying to get things to work together properly" on your IT systems. And you are probably not the admin, or at least not a good one.
I feel so sig.
and put into your foes list. This post is copied from other posts
Now I'm fairly open-minded, but I doubt that Church-going Joe Average from Iowa would support LSBian adoption...
--All your stolen base are belong to Rickey Henderson
Indeed, and the best thing about such standards is that there's so many of them to pick from.
i don't want numbskulls using linux, make it difficult, good. the less idiots out there setting up open relays and vunerable servers the better.
If you mod me down, I will become more powerful than you can imagine....
... but it doesn't have to for Linux.
We have several advantages now. First, we have the hindsight of what happened to UNIX, and a general understanding that it was bad for everybody involved.
Second, the licensing is crucially different. Linux is more amenible to standards because of its licensing - vendor extensions like those that killed UNIX can't be kept proprietary.
Additionally, there is a culture of co-operation among Linux vendors and developers. That's really important. For example, one of the Scribus developers works regularly with all the major distributions to help standardise and improve issues of importance to Scribus (less patched-and-hacked versions of Qt, bring GhostScript out of the stone age, etc). Basically all the major vendors contribute to and co-operate on core toolkit and kernel work. It's not perfect, but it's a heck of a lot better than it was for proprietary UNIX.
With these advantages, I doubt the fragmentation will ever get too bad. The frustrations and maintainance costs of fragmentation its self will become a force to bring everything more into line. For the commercial vendors, customer pressure and pressure from ISVs will help too.
I think life is easier now for an application developer than it was a while ago. The major toolkits have quite stable APIs and even maintain a stable ABI unless built with dumb compiler options. gcc's ABI & API stability is improving constantly, and is already pretty much there for C code. RPM is widely supported, required by the LSB, and where it's not the native format users know how to handle that ('alien' and friends).
Things could suck a lot less. Easy ways to discover installed libraries and versions. A F***ING STANDARD WAY TO FIND OUT WHAT DISTRO YOU'RE RUNNING ON. More careful co-ordination of build options and compiler options for key toolkits and libraries to improve ABI compatibility across distros. There's lots more, too. Overall, though, I don't think it's too bad.
Perfect compatibility just won't happen. There will always be people who want to do things differently. That's fine, but they have to realise they will sacrifice compatibility. If their work produces good ideas, others can integrate those ideas so they can be relied on by everybody. A binary LSB distribution that can just be dropped in place on any distro would make a big difference, though.
I'm sure that in the egalitarian world we live in that your thoughts are exactly correct and that grassroots efforts always succeed.
Wait: we *don't* live in such a world? Oh.
What the *$#@! are you talking about? Free/Open Source software *is* an egalitarian world. You're casting the poster's comments into an extreme light that requires they be absolute and universal truths, or nonsense. He said open standards *can* come about, and that they *do* benefit the end user.
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.
So are you saying commercial UNIX vendors are playing the same game as the Linux distro makers? The differences from UNIX to UNIX are far greater than the differences from Linux to Linux. I also find it hard to believe that RedHat and SuSE are trying to come up with ways to more or less 'lock in' their users. What they're trying to do, which does run counter to the LSB, although not for the reasons you describe, is make their distro just that much better than the next--to give it that "RedHat" style (and the "Debian" style, the "Mandrake/Mandriva" style, etc).
I also don't get what you are saying about CDE. Do you mean that the LSB will create a Windows 3.0-era GUI/Desktop? It just doesn't follow.
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.
Very few Linux companies are really "companies" in the dog-eat-dog style world you are describing (if I were feeling sarcastic, I'd give a similar intro to the one you gave "aristotle-dude"). Ubuntu, Knoppix, and about a million other distros are based on Debian, and are more compatible with Debian than I think the LSB would make Debian and RedHat to each other. Yet there are sufficient differences to gather users.
For Linux, the license isn't the money maker, it's the extras, like a pre-pressed CD/DVD, and "corporate" support. RedHat still has a positive corporate image, so even if tomorrow all Linux distros became LSB compliant, corporations will still pay for the RedHat (or SuSE or Mandriva or whatever their favorite is) version to get the RedHat (or whoever) support, hackers would still use Debian or Gentoo, and desktop aficionados would still use Ubuntu/Kubuntu or whatever's popular at the time.
In short, you're wrong that corporate "screw you-ness" is the main reason holding back the LSB, but more of the fact that the LSB, at least on the outset, will shackle innovation--each distro maker has their own way of doing things, and many of these "ways" aren't random, but deliberate choices about how things should be done. The open (and egalitarian) nature of Linux encourages this. Eventually, though, expect the LSB to become more standard. User demand will always trump developer laziness in FS/OSS in the long run, especially since the developers are also the users, and vice versa.
"I also find it hard to believe that RedHat and SuSE are trying to come up with ways to more or less 'lock in' their users."
Then you are a completly out-of-the-reality moron.
Who are the two big players? Red Hat and Novell?
You may be interested to learn that RHEL 3 and SUSE 9.2 are LSB-compliant.
The original complaint of the article submitter seems to be that the two big players are the only ones that conform to the standards.
WeRelate.org - wiki-based genealogy
The reason that things are more difficult in Linux than Windows is not because of the OS - it's because of the vendor lock-in. It's because of a monopoly that prevents really open standards from flourishing. There is nothing that prevents my 2.6 kernel and Gnomad2 from identifying my Creative Zen Mp3 player except for Creative.
Most people use email, web browsing, and an office suite. Do you really think that those tasks are out of reach for a planet-full of developers?
90% of everything is crap. Also, crap is relative.
Actually it is more of why should red hat/Suse etc risk there market lead in order to create a level playing field. Such an approach may see them become irrelavent. It is smart business tactics and protects them long term. Sure it may not be best for users, but face it, they are a company, they must make a profit and do everythign they can to ensure they continue to make that profit.
A miss conception I run into frequently. The primary function of a business is not to be the biggest player in the field, instead it is to maximize profits. Many tymes that means making the pie bigger for long term profits.
FalconShould there be a Law?
Most of what the LSB says is very, very basic stuff. The file system hierarchy says where to put files in the directory tree. Your revolutionary graphical interface can present whatever it wants to the end user. It doesn't -matter- to the end user if you put programs in "/Linux System/Program Files/" or in "/usr/bin". The end user isn't going to be poking around there anyway unless something already went deeply wrong.
It also talks about your basic system libraries... err, unless you had a revolutionary new way to implement libc? Without the ANSI standards, maybe? Or perhaps your libm will use the 'New Math'?
It talks about authentication, users, groups and such... were you going to replace -that- in your revolutionary new system? Maybe not bother with passwords or file permissions, that'd be easier?
C'mon, be real, the stuff you're blathering about building is all up in the GUI layer, and has -zero- to do with the LSB. But if you follow the LSB you'll have a bedrock for your revolutionary new system that can have a vast amount of infrastructure compiled and added on instantly.
There's really no good reason -not- to follow the LSB.
--Parity
'Card carrying' member of the EFF.
There is no way it is a troll.
It is a humorous comment on the "moronitude" of the grand-parent.
l/2
Truly challenging Sudoku puzzles
If Windows can't find a DLL, the install is over. If yum or apt-get can't find a dependency, it'll find and install it.
GUIs are available for both, apt-get's is better developed.
What are the problems?
Tech Public Policy stuff
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.
LSB is really insignificant compared to MSB.
I would take you seriously if:
1 22 92122
1) You were not cutting and pasting the same drivel in unrelated stories:
http://slashdot.org/comments.pl?sid=146731&cid=
2) It were true that standards are not being followed. Free desktop has done wonders for desktop Linux. I have transitioned hundreds of people in small and not some small NGOs to Linux over the past 3 years, particularly the last year and a half. Never have my support problems been so few. Want prove that Linux works as a desktop today? Many of the people who get Linux at work call me asking whether they can get the same stable environment on their home computers. Of the people who have switched their computers at home, only two have asked me to put Windows back on it. Others greet me with hearfelt gratitude, more than it is actually deserved, because they feel like they finally got their computers back after years of fighting the ongoing insecurity and the never ending issues that they used to experience with Windows.
Pragmatism as an ideology is not particularly pragmatic in the long term. Keep it in mind when you dismiss Free Software
So, you can have RPM installed side by side with APT...
Just like having Windows installed side by side with Linux. It's not going to work for those of us who don't want Windows. You can't have Windows installed and not have Windows installed at the same time.
Same for the Redhat Package Manager.
Would you please check some very basic facts first? They (the "big" Linux companies) DO certify against LSB!
l /t echnical/lsb.html
http://www.novell.com/products/linuxprofessiona
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.
Please explain POSIX, a UNIX standardisation process so successful that even Microsoft were forced to follow it by the market.
Just buy a MiniITX machine. Smaller, cheaper, just as quiet, more software options.
I agree that package managers are good, but a user doesn't want constant downloads just because a random text editor needs GTK of version $his+0.0.1
.PM, a .so and a man page. And it can work over the network, so it MUST NOT depend on the server part. (Yes, it may depend on libpq but again, why won't it work with an older version?)
:) I'll start this Saturday -- find a random source and make sure it goes well with not-the-last stuff.
What distro makers need to do is verifying package dependencies so that each package requires oldest possible setup it runs with. I know it's a load of work, but still...
Yesterday I typed in
# urpmi perl-Pg
and guess what? It reinstalled Postgres-*, a bunch of libs, and Ocaml to boot. The packege itself contained a
Yes I know I could run rpm --nodeps, but why should I care? So, installing stuff would become easier if every packager made sure the package work on oldest possible configuration, and does not depend on optional components.
In fact, the thing that made development of GNU/Linux project possible is relative independance of packages, so that bash can be developed without knowing the status of ls and cp projects.
We should strive to make a flexibility heaven out of dependancy hell
WYSIWIG, but what you see might not be what you need
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.
Thank you for the response! This explains quite a bit. So it's really the applications which are bad about interoperability. What could distributions do to fix this? It seems that
And for people insisting on rolling their own everything, I think D. J. Bernstein is the king of that, what with his daemontools and all. I suppose it's a good idea, though I can't say that with any authority... it just seems a bit odd that he's decided to add things to the root directory. To the root directory! What balls!
Anyway, this all seems like it's a problem that application developers simply don't use the tools provided for them to make their programs platform-independent. How would changing the platforms themselves fix the problem---at least, the one you were having?
--grendel drago
Laws do not persuade just because they threaten. --Seneca
...then LSB would be a good thing if distros adopted it. Gone would be the days of binaries needing to be compiled for 10 different distros. That being said, in order for a distro to migrate to the LSB standard, it will take time, if they even plan to do that. Interoperability is a great thing, and I really think the community should embrace this idea. To the previous poster who said, "I'll just do it myself." you have to remember who the LSB is aimed at, and what its purpose is. You might be able to do it yourself, but "Joe User" hasn't got a clue when it comes to /home vs. /var vs. /usr/local/share....it's my understanding the LSB will help standardize that so that the learning curve isn't going to so great, to make distro's more able to play nice with eachother, and so that if one person gets sick of madrake, and decides "hey, let's try ubuntu"...the change can be made with relatively little study.
Who cares about the ozone layer?...thanks to CFC's I can write my name......IN CHEESE!!!
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!
Do you think that IBM (or Sun, or...) would say, "Yeah, we're trying to lock in customers with AIX (or Solaris or...)"? Or do you think they just might say exactly what you said: "We're just trying to make AIX just that much better, but unfortunately, it's just a little bit different than Solaris..." Why is one lock-in and the other isn't? You can't have it both ways.
In short, you're wrong that corporate "screw you-ness" is the main reason holding back the LSB, but more of the fact that the LSB, at least on the outset, will shackle innovation--each distro maker has their own way of doing things, and many of these "ways" aren't random, but deliberate choices about how things should be done. The open (and egalitarian) nature of Linux encourages this. Eventually, though, expect the LSB to become more standard. User demand will always trump developer laziness in FS/OSS in the long run, especially since the developers are also the users, and vice versa.
I see. IBM and Sun are evil companies who set out to screw their customers by locking them in, but Red Hat and Novell are egalitarian companies unmotivated by profit and just trying to innovate? IBM and Sun completely ignored their users and fragmented the UNIX marketplace for no technical reasons, purely motivated by greed and a desire to screw the users, while Red Hat and Novell will listen to their users and happily hold hands and sing in peace, love and harmony?
Last I checked, IBM and Sun happily sold *millions* of copies of their UNIXes to willing customers. It's not like there weren't alternatives. It's not like there weren't *dozens* of attempts to unite under a common standard. So how was what IBM and Sun did *not* for the users? And why will Red Hat and Novell be able to overcome 30 years of actual *history*? Just because they want to?
You have a (very small) point about Debian/Ubuntu/Gentoo. Given their near total lack of ownership by a corporation, they are more likely to embrace user-driven standards. But the great thing about standards is there are so many to choose from. After all, I'm sure they all use compatible installation packages already, right, because users want that. Right?
Oh, wasn't there an article on /. just a couple of days ago about package incompatibilities between Debian and Ubuntu? Let me guess: Ubuntu was just 'making stylistic changes to make their distribution better'. For the users. Think of the users.
Linux IT Consulting and Domino Development in Michigan
Thanks for the article reference!
It's close to a "Mini-LSB"; it's unfortunate that it doesn't address the ability to turn off all interfaces not in the standard to trigger compile time errors in non-binary-compatible code. 8-(.
I still think there would be a great deal of resistance to this sort of thing for the reasons cited in my initial post; it would probably take an "artistic license"-style license change to enforce compliance with something like this across vendors.
I don't think that's something we are likely to see happen, given the huge backlash against things like SCSL.
-- Terry
http://refspecs.freestandards.org/LSB_3.0.0/LSB-Co re-generic/LSB-Core-generic/swinstall.html
"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."
"Applications are also encouraged to uninstall cleanly."
"The distribution itself may use a different packaging format for its own packages, and of course it may use any available mechanism for installing the LSB-conformant packages."
What the fuck does that mean?
Also, does this mean Debian (or even Ubuntu) can never be "LSB compliant" because it doesn't use Redhat's shitty package system?
Thanks, but no thanks.
-Joe
Your whole post is nonsense.
/. just a couple of days ago about package incompatibilities between Debian and Ubuntu? Let me guess: Ubuntu was just 'making stylistic changes to make their distribution better'. For the users. Think of the users.
I'm not calling IBM or Sun evil, and I've never said RedHat wasn't motivated by profit.
RedHat and others aren't eschewing the LSB just because they don't want to be compatible with each other! That's foolishness, and ignorance, as RedHat, SuSE, IBM, Sun, and many others are actually members of the Free Standards Group (the group that heads the LSB).
RedHat is not to SuSE as Solaris is to AIX. The differences between them are not for the same reasons. Your black-and-white world is an illusion. Just because two companies are motivated by profit does not mean both are equally likely to take similar measures to lock-down their product from competition.
Do you know you have the legal right to freely download RedHat and sell it? You can even change the name to "TMassix" if you want. In fact, SuSE and Madriva are based on RedHat.
That's *not* lock-in.
This, in particular, deserves a response:
Oh, wasn't there an article on
Yes, moron, that's exactly why they did it (except the changes weren't just 'stylistic', but bugfixes, and other enhancements as well). They also offer all changes back to Debian. They aren't trying to lock you into Ubuntu.
You truly do not understand how Linux works, nor do you seem willing to question your social-darwinistic view of business.
LSB is not embraced, because it's an attempt at faciliationg a distribution method that just doesn't match the way things are done on GNU/Linux.
Application programs coming with an "installation program" that tries to take care of everything, in the hope it will not break in most cases, is the Windows way of doing things. That's a different world. The GNU/Linux world is the world of apt-get, emerge, urpmi.
The ones who do not understand that, are those who think of GNU/Linux as just another Windows. Those who know how GNU/Linux works, and would have the ability to change it, are not interested in doing so -- those who understand GNU/Linux, are able to appreciate the distribution method as one of the major *advantages* over Windows. They will happily take the pain of having to build from source, in the rare case that they need some obscure application not packaged by their distribution, in exchange for everything else working about 10 times easier and better than on Windows.
No place for LSB.
All my comments get moderated +-0, spotless.
I think there is an implicit assumption here which is a bad idea which is that Linux should be the platform. I don't agree. I think the distribution should be the platform. Naive end users should in every practical sense be RedHat, Mandrake, Debian, Suse... users not Linux users. They should be getting their software from the distribution.
Look at the situation with Debian based distributions. The fact is that modifying Xandros with generic Debian stuff screws up the reasons you picked those distributions to begin with. Similarly a generic Debian getting Ubunto stuff tends to create a wave of dependencies which destabilize the system.
The purpose of the LSB is to make it easy for people to distribute binary software. Why do we need true binaries, that is software that isn't available to the distribution maintainers as source?Ensuring binary compatibility will eliminate many of the advantages that Linux currently has. And for what? Better games? A few extra business apps? Windows is a really good platform for people who want binary compatibility with large quantities of legacy software, do we really think that's the front we want to challenge Windows on?
Far better are things like choice and features. Have distributions to full niches. High security distributions, very small, very large, easy to use desktops, power users systems, systems designed around foreign languages, systems designed for 2 languages at a time (for people who have to work in bilingual environments). Systems with modules like Progeny or Morphix, etc...
Also the ability to bundle a huge amount of software in freely is an advantage. An advantage we lose the moment we start trying to appeal to people who market niche commercial apps.
Just as IBM lost the hardware battle to 1000 gray box companies each making a box tailored to individual customer's tastes this is a strategy that is very hard for Microsoft to compete with. Once we insure binary compatibility among distributions especially across time we lost the flexibility and then we are challenging Windows on which is a better binary application platform.
1) Loss of editorial control
:)
That's a big one. The Unix wars were between hardware vendors. The Linux distributions (with some exceptions) are idealogical in nature. Debian has very very different ideas than does RedHat. Linux has developed a culture of "an OS for everyone's tastes". Its much more like the computing environment of the 1980s when there were tons of systems which had real differences between them, and even core business applications were more experimental.
In the early 90's everyone lost their individuality in exchange for lower prices (and the price drops were huge to get people to conform). But Linux is already free. So what is the big plus?
2) Commoditization
A very good argument. Why should the major vendors want to become commodities? If they survive solely based on their interfaces they are basically software companies writing OS utilities for a living.
Having the same binary apps kills competing on features.
3) It's too big to be meaningful in any real sense
I don't agree with that one. I think its defining the wrong stuff, trying to be like Posix. This is Linux you can outright mandate applications
So you have "LAMP standard"
You must include Apache, with the following configurations as defaults.....
You must include PHP with the following modules
You must include MySQL
Now its fairly easy to write a webapp that is generic across distributions.
POSIX existed in a world where you couldn't throw applications on so they definied libraries. We live in a GNU world.
Oh if only this were true. If .ini file in that same application directory and
1. installation of Windows resulted in locked down C;\Windows directories and a locked down registry and
2. all applications would run from c:\Program Files\ and
3. specific application information resided in an
4. A single global ini file in c:\ contained a one-line pointer for each directory containing "installed" applications,
then
1. Hash files could finally secure windows from mal-ware.
2. With a simple directory copy, applications could easily be moved from one system to another without cumbersome "installation" processes."
3. Applications could be cleanly and completely removed merely by deleting the application directory and the one line reference in the root ini file.
The concepts here could probably even more easily be implemented in Linux at the distro level.
I vaguely remember a Microsoft executive's amazement at how long it took to "move" from a WindowsME box to a WindowsXP box due to hours and days of re-installing applications from one machine to another.
I would probably buy a new PC every year if not for the nightmare of re-installation. Between work and home, I always seem to have two Windows PCs in one location two Linux PCs in the other. In each case, one is my slow, "primary" PC and one is my "Real Soon Now" unit, with the latest OS and applications in some varying and weird state of installation. The cutover is never pretty and they pain of cutover means I only really make a move every 24 to 36 months. If Intel wants to sell more boxen this is certainly an area that it would be in their best interest to contribute to.
Live Long and Prosper - Thanks Leonard. You are missed.
You truly do not understand how Linux works, nor do you seem willing to question your social-darwinistic view of business.
No. It has nothing to do with understanding business. It has everything to do with the ORIGINAL POINT OF THIS THREAD! The point is, free or non-free, different products from different vendors tend to be different. Period.
The whole *point* of this entire discussion is that LSB has been poorly supported. My point was, why would anyone expect differently? 30 years of UNIX has shown us that such efforts are extremely difficult. Why would Linux be magically different?
You keep trying to say that the magic of Linux will overcome 30 years of recorded history. Yet you then keep coming up with counter-examples: the fact that not one but two major distributions sprung up as incompatible modifications of the original parent, and that the most significant non-commercial distribution now has a popular offshoot that is now generating packages that are incompatible with the parent.
Why, again, is Linux going to magically overcome not only 30 years of history, but 5 years of their own actions? This is not just my darwinian view. This is actual reality. Again: why are they going to do it in the future, when they haven't done it in the past?
Linux IT Consulting and Domino Development in Michigan
The point is, free or non-free, different products from different vendors tend to be different. Period.
Wow, that's the point? Really, no kidding? I thought your point was that the LSB wouldn't succeed because companies want to maintain competitive advantage, and even if it did succeed, somehow Linux would become like the CDE.
But, OK, that's your new point. I concur, but being different and adhering to the LSB are not mutually exclusive.
You keep trying to say that the magic of Linux will overcome 30 years of recorded history.
Linux != UNIX.
Again: why are they going to do it in the future, when they haven't done it in the past?
"They" didn't exist 30 years ago. Linux and the Free Software/Open Source model are based on fundamentally different rules than the proprietary software model.
No one *EVER* claimed that the LSB would remove all differences, or all incompatibilities, but what it *does* do is make it possible for Real (for example) to write one installer for each arch (x86, PowerPC, IA-64, etc) that can reasonably be expected to run on any LSB-compliant distro.
No. It has nothing to do with understanding business.
Then what, exactly did you mean by this?:
"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."
If the LSB does not succeed, it won't be because of the profit motive at all but because there are too many opinions on how things should be done, and the differences are too large to overcome, or its superseded by something else. The LSB doesn't appear to be so far reaching as to run into those problems, so, eventually, it or something like it will emerge naturally.
I don't ever expect all Linux distros to conform to the LSB, but for the LSB to be effective, they don't have to. All the LSB aims to do is increase the number of assumptions all parties can make about any given LSB compliant Linux system.
He has sucked the cock of Jesus Christ! Talk about Holy Water!
He has sucked the cock of Jesus Christ! Talk about holy water!!