Linux Foundation Promises LSB4 194
gbjbaanb writes "Ever thought it was difficult to write software for Linux? For multiple distros? InternetNews reports that the LSB is making a push for their next release (due out later this year) that should help make all that much easier. Although the LSB has not lived up to expectations, this time around Linux has a higher profile and ISVs are more interested. This is to help persuade them to develop applications that will run on any LSB-compliant Linux distribution. If it gets adopted, LSB 4 could bring a new wave of multidistribution Linux application development. 'It is critically important for Linux to have an easy way for software developers to write to distro "N," whether it's Red Hat, Ubuntu or Novell,' [said Jim Zemlin, executive director of the Linux Foundation.] 'The reason you need that is because we don't want what happened to Unix to happen to Linux in terms of fragmentation.' The LSB defines a core set of APIs and libraries, so ISVs can develop and port applications that will work on LSB-certified Linux distributions."
Jim Zemlin needs to read the GPL. (Score:2, Insightful)
He needs to read the GPL and understand how it differs from the various PROPRIETARY licenses that caused the *nix fragmentation.
ABI (Score:1, Insightful)
Why cant we have binary compatibility too :(
Re:What did happen to UNIX? (Score:3, Insightful)
See this graph [wikipedia.org] for more information.
Mutation !== Evolution (Score:4, Insightful)
"The reason you need that is because we don't want what happened to Unix to happen to Linux in terms of fragmentation."
What makes you think what happened to UNIX was bad? It's called evolution. Things change.
Let me remind you, my friend, that evolution means SUCCESSFUL ADAPTATION to an environment. What happens when a change (mutation) results in inadaptation? Extinction.
Evolution refers to a species. But in Linux what we have is not a single species, but a genus [wikipedia.org] (a set of different species): Redhat, Debian, etc. "DNA" recombination is impossible in these. The resulting software would be inoperable.
LSB4, hopefully, will be a further step in the evolution of Linux: The convergence to a single species that will be able to share one single configuration.
In other words, yes, change is necessary, but there needs to be a period of stabilization. Just as stable/unstable releases in software. And LSB is providing this stability. LSB is, in fact, evolving.
Re:Jim Zemlin needs to read the GPL. (Score:4, Insightful)
maybe you mean something different, but I'm not sure how your statement relates to this issue. Afaik the LSB is about standardizing directory layouts and configuration files, and while sure under the GPL any linux distro CAN be made to follow those guidelines, almost none of them DO, so the difference between nonstandardized linux systems and nonstandardized UNIX systems is a philosophical one and not a practical one.
(Although on Linux it's a fair bit easier to remedy)
Re:What did happen to UNIX? (Score:5, Insightful)
Yes, that's kind of the whole point of the LSB.
Customers choose OSes based on many criteria. One of them is how much of the software they need will run on each platform. Now, this is rarely actually determined by the quality of the platform -- it's mostly a question of which platforms were already popular enough to be targeted. In theory, LSB will make it easier for new Linux-based OSes to run existing software, and will make it easier for ISVs to write software for Linux-based OSes in general.
Those OSes can then compete on more interesting metrics like performance, stability, scalability, price, and quality of support. How is this not a good thing?
Didn't we try this once? (Score:4, Insightful)
LSB4 is all very well, but if RHEL does not follow (does anybody really think they will?) it will not amount to a hill of beans.
Isn't this what Shuttleworth was getting at? (Score:3, Insightful)
As I've said before [slashdot.org], software vendors like Oracle would love this because it would simplify their support.
Now if only LSB would stop the cluttering of
Unified Protocol and MIME Registry (Score:5, Insightful)
Other than eliminating conflicting directory structures, the most important standard for Linux distros to completely unify would be a single API to data protocols and MIME types. Like the one FreeDesktop.org has managed to sync (in principle) between GNOME and KDE Desktops, but for all distros (including servers).
A registry of which app to hand off a URL to given its protocol part, to retrieve the data. A registry of which app to hand off the data to once it's retrieved. Different data handler lists for displaying, editing or executing (the usual Linux RWX modes) the content, depending on the use case triggering the registry access. The registries could include prioritized lists of different apps, depending on user selection or settable default preference. And of course any single app could be registered to either registry, in any mode it will function properly.
Then the OS is performing its main task of connecting processes to the hardware and to each other. In a very simple and clear architecture. That every single app can use, without having to anticipate how the other apps will agree with it.
If LSB4 can pull that off, using the existing attempts as a starting point, it won't just make a unified Linux target for developers across distros. It will make LSB4 itself more quickly and completely adopted, because its benefits will be so compelling.
Re:What did happen to UNIX? (Score:5, Insightful)
It already happened (Score:3, Insightful)
We don't want it to happen?
It already did.
Distribution compatibility and package management is a big problem for most, if not all developers, and has been for a very long time.
Re:A simple explanation for ISVs: (Score:5, Insightful)
But you see, they dont want to write for distros foo, bar, etc... they want to write an app for linux.
They dont want to "collaborate" with dozens of distros, all of which will tell them that "in our distro, the proper way of how to do this" is different than the other ones...
Re:Isn't this what Shuttleworth was getting at? (Score:4, Insightful)
Well, from what I've seen, /usr/local and /opt were reserved for the local sysadmin to manage, and the package management system generally stayed away from that. This meant that custom software and distro packages didn't have file conflicts.
Now, I like the way that works, a lot. But I don't have any objections against further partitioning of that scheme.
Re:A simple explanation for ISVs: (Score:5, Insightful)
Classic zealot response. Pretend the entire world is moving to GPL-only software and neglect to address the concerns of anyone who disagrees.
It's about freakin time (Score:1, Insightful)
I've hated this whole fragmentation thing all along. It would be so much nicer to have a unified system like LSB4 claims to offer. This can't come soon enough.
Re:What is LSB, you ask? (Score:2, Insightful)
Do we want LSB? (Score:2, Insightful)
I've never had any need for a standardized linux environment except when I had to run Civ3 using libc5. The kernel never really freezes AFAIK.
The beauty of linux, progress continues, just switch distros. If you need something comfy and reliable, use Debian.
+1 as a developer (Score:2, Insightful)
Re:It'll never happen. (Score:5, Insightful)
COO: so, we've developed a new widget, brilliant. When can we ship it.
DEV: today, its all tested. I've run it myself on my Debian box.
COO: sure, it'll run on Customer B's Redhat environment won't it?
DEV: Ummmm.. well, not straight off.
COO: ok, so what do we need to do to make it work?
DEV: well, alter a couple of paths, recompile, change the dependancy for package Z and build a rpm
COO: and how long will that take?
DEV: a week, maybe 2 with testing.
COO: so, that's 2 weeks development costs on top of what we've already spent. We wouldn't have this kind of problems with Windows!
and I'm not trolling either - standards are good, making extra work for yourself for no good reason is bad. Its not as if a common directory layout, ABI or programming libraries need to affect open source linux in any way. The Kernel is a standard, and no-one complains they don't have a choice of kernels to develop against.
Re:Do you have an example? (Score:3, Insightful)
Re:What is LSB, you ask? (Score:3, Insightful)
"Not that anyone uses it, as it is a complete waste of time."
I don't know if it's a waste of time. I don't even know what the original motivations for the LSB were.
But I do know what is meant for now: is an intent from some distribution vendors to make easier to coaligate with privative source vendors. Not that I think this is a good or bad thing for them to do, but I do know that's not a goal I'm interested in, so I don't give a damn about LSB.
Making better/easier portable configure-like tools? Sure.
Making stronger the LFH (Linux Filesystem Hierarchy)? Certainly.
Giving more visibility to stronger engineering practices so evolution of (specially) libraries APIs is more stable, predictible and backwards compatible? Yes, no doubt.
Giving a binary base for privative software vendors throwing their software wherever they like to, with half-assed start/stop scripts and without integration with the native package management tools of my distribution of choice? Really, what for?