Not all Linux distributions are made with the same components, which can make it difficult for software developers to write applications for multiple Linux distributions. That’s where the Linux Standards Base (LSB) comes into play. For years the LSB has not quite lived up to its full potential. That could all change with the upcoming LSB 4.0 release.
I kind of like the variety, I like creativity of different distributions and I would really hate if they all had the same package manager, the same filesystem structure etc. Sometimes different doesn’t mean worse.
But, seriously – it’s great for some main distros to follow the same standards, and it’s certainly good for 3rd party software developers.
this will not cause all distros to act as one and kill diversity. what it will do is create a unified set of instructions and requirements that disro’s that want to be compient need to follow. this makes life much easier on people like myself who write software having a standard base that is followed by the major distributions.
I am really looking froward to this. this is jsut what linux needs to go mainstream, or at least this is a great step in the right direction.
I would really welcome this. Coming from a BSD environment, it’s no matter, for example, if you are on FreeBSD, on PC-BSD or on DesktopBSD. All of them have the same base OS beneath any additional stuff. This is how the BSDs keep it: Have a basic OS (“just the OS”) and let the user install what he needs, or put it preconfigured onto the OS as installed packages (“everything else”). I think Linux does this different: It’s the business of the distributors what software they include, for exmaple, if they consider awk to be in the “base OS” (allthough Linux does not have something like the “base OS”) or not. Get me right: That’s nothing bad per se, so I won’t say “it’s Linux’ problem”, but just the way it is done. There are different directory structures, different places where installed applications go, different package managers and different concepts (e. g. system startup). With a good LSB, you simply can rely on the presence of certain commands, functionalities or interfaces, you don’t need to check each required one manually.
A LSB that can be followed by the creators of a distributions is a very good step. As it has been mentioned before, it will make the life of programmers, technicans and administrators more happy. And, of course, if you’re making a “niche Linux distribution”, you don’t need to comply with the LSB requirements. It may be seen as a kind of “quality certificate” which will, in my opinion, help Linux getting more usage share, and oh joy oh market share. 🙂
I kind of like the variety, I like creativity of different distributions and I would really hate if they all had the same package manager, the same filesystem structure etc. Sometimes different doesn’t mean worse.
It doesn’t destroy the variety or creativity. It just ensures there’s all the needed base libraries, they are accessable in a pre-defined way and that if your application works with one LSB distro it should work on all of them. It does NOT have anything to do with boot-up, themes, applications included and so forth. Those are left to distros themselves.
Fundamentally important.
ISVs are the future of Linux success.
Say what!? That’s massive. Must have cost a fortune. I for one welcome our new Linux Standard Base Overlords. In Soviet Russia you don’t hire workforce… workforce hires you. All your Linux Standard Base are belong to us.
Hopefully in the future instead of releasing software for Redhat or Novell, they give requirements as “requires a distro of LSB 4.1 or better”. That will be the day when apps will work across distros without having to worry about incompatibilities.
I don’t, honestly, ever see that happening. At least not in the distant future.
Companies that produce commercial packages for linux that specify RHEL or SLES will be able to engage Red Hat or Novell for support if any issues arise with compatibility. That’s the whole point behind targeting those distros.
Applications might be produced to be LSB x.y compliant, but few commercial ISVs will stake their support on generic distros. Though at least having LSB compliant packages produced will be a start, it will just leave the customer to fend for themselves on support issues if they’re not using a pre-approved distro. Red Hat, Novell, Gentoo, Arch and Ubuntu might all provide library foo.bar, but that doesn’t ensure it will operate identically in each environment. THAT is the support nightmare ISVs will try to avoid.
Still, I think standardization is a good thing, since it points in the right direction. But things will certainly not change overnight, even with a standard in place.
I for one have to agree (sadly). No matter how much tests you will write compatibility issues will show up the more likely the more complex your software is. Without cooperation of target distros you simply cannot be sure it will operate correctly.
The gain of LSB is hoverer that its establishment will lower the barriers of entry for not that much established distros. That is having sw product certified for RedHat which (I assume) will be LSB v4 compliant and stepping carefully with LSB in mind developer has great chance it will run smoothly on say Ubuntu (assuming ubuntu likes LSB4 too).
The blood sweet and tears of retesting the whole thing on each supported distro will not be removed by any standarization. No prof. with shade of responsibility will touch such product on uncertified distro.
The only problem I see is that mainstream distros will willfully delay LSB4 compilance to make it DOA.
If I remember correctly, LSB used to specify RPM to be the standard tool for packages. I hope they’ve fixed that by now. Practically every distribution has its own package manager; there’s no reason for any of them to switch to RPM.
This is a tired argument, but rpm the package-format was specified, not rpm the package installer. Even rpm-based distros don’t rely exclusively on rpm as a package installation method.
And before anyone mentions it, .deb is a proprietary package format for Debian-based distributions. It doesn’t matter if there are 700 different Debian-derived distributions on the planet.
And before anyone mentions it, proprietary doesn’t have to mean closed or non-free. The point is .deb is designed for Debian distros. Period.
.rpm is, at least, distro agnostic.
Has nothing to do with package managers. You can use Smart with almost anything for instance, doesn’t matter.
Then they should have specified some lowest common denominator, like .tgz, which you can unpack with just tar and gzip.
And while you can certainly install whatever native package manager your distribution uses along with RPM (which is still the only way to install RPM’s) (okay, maybe alien counts), it’s going to be a long time before I see any reason why I might want to install two package managers on my system, especially when whatever native one my distribution provides is vastly superior to RPM.
.rpm isn’t really distro-agnostic. It’s a package format designed for Red Hat.
With one exception that I’m aware of (SuSE, which was originally based on Slackware), all distros that use RPM files are derived from Red Hat. They may have diverged many years ago, but there are a lot of them.
It’s actually pretty easy to read either .deb or .rpm package files without the associated tools. .deb files are just ar archives containing .tar.gz files of the actual software, and some metadata. .rpm files are cpio archives containing .tar.gz archives and metadata.
And what’s the problem with that? LSB is good for ISVs to have a stable base, and since most paying coorperations use RHEL or SLES that seems to be a fair choice.
No, it won’t. We’ll be having this same conversation when LSB 9 is being finalized.
I’m going to have to agree with you. Whatever the next version of LSB is will always be the one that standardizes Linux and the next version of Linux will always be the one that’s “ready for the desktop”.
Is the best thing that could happen to Linux. LSB Server, LSB Desktop, LSB Embedded. These distros would give PHBs something to understand and something for coders to use as a reference to get their product to work on. It would be more open than any of the commercially supported distros and less trouble than the ‘geek-oriented’ ones. Everything else is just fat, lonely, guys in their parent’s basement, f–king with the code to make some stupid distro that they can release and say; “Looky what I done! It runs on a toaster!”
I’d add LSB core for lowed common denominator of those three for sw with small requirements. Also certifying for those three should cost the same as for subset of them.
You really don’t need to say such negative things about the other distros. A lot of them exist to fill a niche or work on special hardware, like routers, supercomputers, mobile devices, etc. There is value in this and it is one of the strengthes, not weaknesses, of Linux. These people will also be aware that their distros are non-standard, but probably have the expertise to deal with the difference, so non-LSB compliance is not a problem.
It does not need to be ‘succesful’, or ‘mainstream’.
Linux does not need anything, and it never will.
No. The LSB hasn’t managed to make any meaningful impact whatsoever, and there is no reason for it to now. The test suites for the thing are a joke, and are one of the ridiculous things I think the Linux Hater gets right about the LSB. The only way to guarantee anything (and I think Ulrich Drepper mentioned this as well) is to use the same binaries. That’s not going to happen.
I also don’t know what on Earth these fifty full-time engineers have been doing. They certainly haven’t been writing code, and stuff like the Portland project is completely still borne.
The system that I am trialling right now is Mandriva 2009.0 beta 2. The desktop is KDE 4.1 (it works pretty well, too). There is an option for Mandriva to install LSB support (yes, that does mean code), and I chose to do that.
Right now in my system tray there is an icon visible for the hplip deamon.
http://hplip.sourceforge.net/
hplip is a GNOME/Gtk application. {Edit: correction, is is apparently a Qt application … but it runs equally well on GNOME oe KDE is the point}.
http://hplip.sourceforge.net/system_requirements.html
http://hplip.sourceforge.net/screenshots.html
… yet there it is in my KDE 4.1 system tray, running quite happily thankyou.
LSB support is the standard to thank for this.
Edited 2008-08-05 10:20 UTC
I don’t think you have any idea what the LSB project is about. It has nothing to do with interoperatbility between KDE and Gnome. Go read the documentation and article.
No it isn’t. That is thanks to the Free Desktop systray specification, which currently needs to be updated for the purposes of KDE 4 to stop systray icons looking completely awful in there:
http://freedesktop.org/wiki/Specifications/systemtray-spec
The LSB has done zilch for desktop harmony, apart from wank over what software they were going to make the ‘standard’ in the true Unix style of the early 90s.
er, no it is not. That’s a freedesktop standard
It is mostly a matter of awareness in the sense that customers/users of Linux distributions need to know about it and ask for compliance.
Right now the LSB is mostly corportate driven, which leads to things such as distributions being certified as compliant while infact they aren’t (at least not in their default installation).
As an ISV I’ll start to care about doing LSB compliant packaging if I can be sure that an LSB compliant distribution of a customer/user actually has all dependencies in place when my application is deployed and does not require distribution specific extra steps.
I think they have mainly been working on the test suites, especially the one for application testing.
This test suite is actually quite sophisticated, e.g. it can be used to determine how much non-LSB dependencies ones application has, etc.
While it does not remove the need for actual deployment tests, it is very helpful for creating a list of priorities for such tests.
The Portland project’s installation helpers are actually quite successful, even included in LSB 3.2 as a trial module.
The second phase, sometimes referred to as DAPI, has mostly been obsoleted by recent developments. More and more integration aspects are being implemented as D-Bus based service oriented infrastructure, both in user session and system wide.
Its properties make it a very good solution for an ISVs needs, e.g. its out-of-process nature makes it a detectable runtime dependency, its interface concept allows for long time backwards compatability, etc.
As it is now, with it’s extreme flexibility, Linux is great for devices, gadgets, set tops, etc. Also, thanks to RHEL and SLED (who make Linux into a consistent, certified, tested platform that can be counted on), Linux is great for servers.
But Linux has mostly failed on the desktop, sans geek usage.
That’s because it’s a moving, chaotic target for independent software vendors (ISVs) and independent hardware vendors (IHVs).
Every distro has a slightly different file structure. Every distro has slightly different locations and names for many common config files. Every distro has a slightly different binaries. Every distro has slightly different core library versions. Every distro has slightly different kernel builds. Every distro has slightly different init scripts and locations for those scripts. Every distro has a slightly different versions of essential services. Every distro has slightly different package management, and it’s own software repositories.
And for the most part, there is no good reason for the slight variances. Those variances don’t help distinguish the distro from the others. The only thing the variances do is make the distro, and all of the packages in it’s repository, an isolated appliance.
That’s horrible for ISVs and IHVs (and open source projects for that matter).
But if there is a core standard for binaries, core libraries, kernel version, file structure, config files and their locations, init scripts and their locations, essential services, and base package management, Linux, with most of the big distros being compliant to this core standard, could become more of a true platform and a true software and hardware ecosystem.
We could call this core standard the Linux core standard reference distribution. It could be released every 6 months to a year. Then distros could build on top of it, adding their own desktop versions and tweaks, their own package management front ends, their own GUI config tools, their packaging of proprietary drivers and codecs (or not), etc.
But the core would be the same. And ISVs and IHVs, and ultimately, users, would all be happier.
Then to make it even better, packages could be divided up between “core system” and “user applications”. The “core system” could be what I described above and in turn be handled by the distro’s own package management system and repo. But the “user applications” could be packaged in a sort of universal package management repository, that distros could support at their discretion. This could make it easy for both ISVs and open source developers to package into the universal repo.
And again, their is still plenty of room for differentiation, and innovation, outside the core reference distro, and the universal repository.
I do realize that I’m talking a real long shot for any of this to occur. But for Linux to be a success on the desktop, I think it’s all necessary.
But do we really need/want linux as a whole to be successful on the desktop? Why not just let the ISVs focus on the handfull of most commons distros (say redhat, suse, debian and/or maybe ubuntu), or maybe just pick one of them?. It would be up to the rest of the distros to provide compatibility.
Then again I don’t see such a chaotic scenario when there are already lots of closed source applications that work almost everywhere with a universal set of binaries.