Slashdot Mirror
The Linux Development Platform Specification : Beta
Daniel Quinlan writes: "The Free Standards Group is publishing a beta release of the Linux Development Platform Specification (LDPS) which tells third-party software providers how to best achieve binary-compatibility across different Linux distributions (well, at least until the Linux Standard Base is done). It's important to note that third-party software providers include not just the large vendors like Oracle and IBM, but also anyone who creates a binary package for use on more than one version of a single distribution."
If you want to use Sather-based applications on multiple distributions, then the tasks are twofold:
- Make sure that there are, ubiquitously-available, Sather RPMs or DEBs or whatever that will run on the various distributions.
- Make sure that the secondary libraries (stuff like a "libncurses-sather" or "libgtk-sather") has some well-thought-out location to be, that can be compatible across distributions, as well as suitable packaging.
- Make sure that there's actually someone still doing development work on Sather. (Last I heard, the sponsors at Berkley weren't working on it anymore.)
At any rate, the "killer apps" on Linux are largely written in C, and all this standard is doing is to recognize that. It is entertaining to note that the standard somewhat discourages the use of C++ in that the libraries still haven't "settled down."Oops. That's three things.
If you want to start deploying "killer apps" written in OCAML (and there are some interesting OCAML apps! ), the requirements will parallel what the "LDPS" provides, albeit by changing "C" to "OCAML."
Feel free to write the OCAML Development Platform Specification. No one will stop you, and if it's good, and is worth doing some rework of packages for, this may be a very good thing.
If you're not part of the solution, you're part of the precipitate.
...pure bigotry...
(snort.) Chill out. It's just a recommendation for people who are trying to get their application to run on as many Linux'es as possible. Most of those applications are written in C and C++. If you had read the document, you would note that most of the major distributions are already compliant. If you want to write your app in some other language, how does this document change anything for you?
This is a good thing. Now that it's out there, maybe people will use it instead of just releasing their app for Red Hat 6.2! That is the problem this document is addressing. Now, all the Pointy Haired Bosses who make the decisions will at least think about all the other Linuxes besides Red Hat.
For the rest of you, who have actually read the document... I have only one comment. I'm a little suprised that they recommend only X 3.3.6, and don't mention X 4.0.x. Are there backwards compatibility issues with the 4.0 series, or are they just not considered stable enough?
Torrey Hoffman (Azog)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
tells distributions what to do. Rather, it's a recommendation to
third-party developers about how they can create binaries that are
likeliest to be portable.
Not exactly totalitarian.
I'm seeing a lot of comments that find this proposed standard threatening. I think you should look for evil elsewhere... try MIME or X11 if you want to gripe about imperfect standards that everyone has to deal with. This one just looks like common sense.
From the phrase "binary-compatibility" I figured there wouldn't be much meat to this... and reading the beta, it seems to mostly be about which library versions to link against, and maybe which shell to expect. All quite harmless; nothing prevents you from having other versions of libc or bash lying around. And the idea of having a convenient checklist instead of actually testing your program on different distributions is nice, although I dunno if I would trust it myself.
I think the file system layout standards (standards efforts, last I checked) are more interesting, and (slightly) more likely to actually cause someone a problem... assuming that ttys can all be found directly inside /dev is more likely to *need* to change than anything addressed here. This effort seems aimed at making it less likely that novice users will have to play games with ldconfig to get some random package to run.
I have a linux box somewhere that still has libc4 programs running on it... only problem I've noticed in five years was due to a kernel change, and it was just poor coding in the app that kept it from handling some unexpected return values from sendto() gracefully. So from my point of view, things are fine anyway, and this will just provide guidelines for those that like official guidelines. The spec itself lists a bunch of popular distributions that meet it already, so it's not as if this was designed in secret and is now being forced on people... it's no more aggressive than documenting library calls in a man page, and offering developers some guarantee that said behavior is stable.
Java: the COBOL of the new millenium.
Something this spec completely fails to address is the problem of architecture independance. Many applications these days are written in an extremely x86-centric manner. The authors typically have nothing against their product being recompiled on other architectures (Like, say, the Alpha), but their coding methods prevent it.
I don't think authors need to test their product on every architecture out there, but if they would pay attention to certain good programming guidelines, it would allow their product to be ported much easier.
~whm
The real issue that we have to be concerned with is "forwards compatible". If we establish a written-in-stone set of rules for universal compatibility, advances by one or more distros that violate those rules may be squelched.
Permit me one more damn car metaphor. Imagine in 1970 that the government, in order to ensure that garages and mechanics were capable of working on all models of vehicles, set down exacting standards for all car manufacturers on the design and implementation of carbeurators. The results, in the short term, are good: parts are cheap and interchangeable, machanical knowledge is more widely applicable.
But then who would have dared introduce feul injection?
2 1337 4 u!