Slashdot Mirror
Linux Foundation Promises LSB4
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."
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?
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.
--
make install -not war
UNIX fragmentation wasn't caused by anything other than all the proprietary, incompatible licenses. Whenever Sun made an improvement to UNIX, HP couldn't simply adopt it like they can with the GPL. With the GPL, if I take an OSS program and fork it, and change it radically, the original creators of the software can always add my changes back into the main branch. And yes it would be bad, if you had to write a program, say an HTTP server, you had to test it on every Unix imaginable, today, just release the source, package an RPM and a DEB, and it will be ported to the rest soon enough.
Taxation is legalized theft, no more, no less.
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...
Classic zealot response. Pretend the entire world is moving to GPL-only software and neglect to address the concerns of anyone who disagrees.
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.