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."
The majority of superior development enviroments that you listed add a layer of additional abstraction away from the native enviroment. As such, the number of conserns with the kernel and C library feature sets that remain consistent is not as much a consern. One of the few exceptions might be Java where the JRE for a newer kernel might provide certain capablities in relation to multi-threading which do not perform as expected on the older common kernel. But if you write a 100% Python application, then you shouldn't have to worry about which kernel or version of glibc is being used by the user.
Let's think about many superior development environments (in no particular order):
Face it. The year is 2000. The new millennium is 5 months away and the official Linux development spec is 20 years behind the times. This spec needs to address the requirements of other modern development tools.
Even if that weren't a problem, binary compatibility, were it implemented across various distributions, would only encourage more closed-source development targeting Linux. This just gives would-be binary-only vendors a good excuse.
Just say no to binary-only vendors' initiatives. And just say no to any distribution that goes along with it.
We've waited more than a year and this is what we get???
... eventually culminating in a standard desktop. Not one that couldn't be tweaked and reconfigured to one's heart's content, mind you, just a standard desktop so that users would have some chance of using Linux as easily as most can use Windows.
I was on the LSB mailing list during its first few months of existence. The traffic was, like, a message a day, if that. Now a year later I can see what you can accomplish with a message a day. A minimal spec which doesn't really do anything except to specify the base versions for some common software? Well surprise, surprise - all major Linux distributions already meet this "Linux Development Platform Specification". Guess they just surveyed what's out there, came up with a least common denominator, and called it a standard. Bah.
Now granted, I have no real right to complain as I could have been an active participant in the LSB and worked to make the result better, and I didn't. Still, I thought that the LSB was going to define real standards - standard APIs, standard ways for the linker to work, the filesystem to work, etc, etc
And this is what we get instead? Bah.
As always, I really blame RedHat et al., since they have the money to make real standards happen, but they can't seem to understand that the future of Linux will live or die by its standardization, or lack thereof.
Remember, the opposite of standardization is fragmentation. Linux will fragment, and die. Thanks LSB! Thanks RedHat!
OK. I'm an idiot. I retract my complaints. Thank you for pointing that document out ...
(well, at least until the Linux Standard Base is done)
At the risk of starting a flamefest over a now-obscure language, I have two words for the LSB: ANSI FORTH. Like many other standards, this one took so long to come to fruition and was so far from any existing implementation that it was largely irrelevant by the time it finally crawled out of committee because FORTH had been eclipsed by other languages.
I'm not saying that Linux will be obsolete by the time the LSB produces results, but if the LSB waits much longer, it will be obsolete. In the meantime, most of the larger vendors have fixed on Red Hat as the de facto standard, for better or worse.
The LSB is now about two years out of the gate. That's not an unreasonable space of time yet. But where will we stand at the three-year mark? Four years? C'mon, fnarking Mozilla will probably produce usable software before the LSB even has a partial standard at this rate.
Proud member of the Weirdo-American community.
This spec talks about how to get -distribution independence- of a -binary- package. You're not going to have an architecture independent binary package (ignoring Java, etc, for the moment.)
In any case, the recommendations in this specification look like they are compatible with a cross-platform application coding approach, though, naturally, there's more than just what's in the distribution-independence spec involved in cross-platform compatability.
In other words - I think you're criticizing this spec for not meeting a set of goals that have nothing to do with the purpose or intention of this spec.
--Parity
--Parity
'Card carrying' member of the EFF.
Draft Text of the LSB
The document cited in this article is -not- the LSB, and the reason all those things are already in most distributions is because they analyzed the distributions to see what they had in common! The LDPS is saying 'if you distribute a binary, compile it with this, because that's what people have' and 'if you maintain a distribution, make sure you have at -least- this, because that's the basics'.
--Parity
--Parity
'Card carrying' member of the EFF.
They want to standardize software versions across platforms. Don't be fooled into thinking that just because you conform to the spec, your x86 RPM is going to be useful to people running Linux on Alphas, PPCs, s/390s, etc. ad nauseum.
Its basically just a set of library dependencies.
A distribution maker (redhat, mandrake, debian) can make a dummy RPM package 'standard-2000' that has dependencies on the named libraries. An app developer makes sure their RPM depends only on this package. Voila, everything works.
The library numbering scheme means I can have multiple versions of libraries on my system.
A distribution can move to glibc-2.2 when it comes out, and place glibc-2.1 on the CD to be available for 'standard-2000' if a package requires it. And later you can repeat the process adding a 'standard-2001', etc package as required.
Then the CD box can say "Supports standards 2000,2001,.. " and the user knows that the third party app will work cleanly on this system.
Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist
Well, it didn't take long for that site to be cracked. As of 10:26 EST, www.geekflavor.com has a nice little ascii pengiun on it.
It's 10 PM. Do you know if you're un-American?
What's wrong with MIME? If I were to choose a UNIX standard as an example of something that wasn't broken, I'd have chosen MIME...
Does Slashdot read Slashdot? I guess no, because else they'd know that LSB = FREESTANDARDS.ORG (look here) ... /pyder.....
well... what the heck
ps this is not a flamebait, name it offtopic or insightful or something
_
/
\_\ sig under construction
Standards are supposed to be hacked on by lots of people and the more open they are the better. Microsoft fails to fulfill this requirement because most of the standards they push are designed to create inoperability so that they can get ahead.
Remember: Open Source does not imply chaos. I wish there was a universal "standard" for binary packaging for Linux and other free OSes, if we did the interoperablility between current distros would probably increase tenfold. Now the current binary packinging standards that exist are IMHO all Open Source, so yes, people can choose which one to use, but no, it's not trivial to move packages between different distros with the same kernel. I would think this is something you wouldn't want.
But I digress: standardization of library versions, basic files (now you did read the LDPS before posting didn't you?) is very much needed, especially for third party developers and brand new developers (such as myself). We can use this to make sure apps run on all distros that adhere to this, and given the list on the site, most do anyway. Also, the list of recommendations is basically what you would need create a usable Linux system, so you aren't forced into being compatible with something you won't use.
As Linux continues to grow, projects/organizations such as these will advance Open Source software, as Open Source development seems to revolve around Linux. It would be wise not to look for FUD where there is none.
Marcus
27 A conforming Linux Development Platform must contain the following packages:
28
29 * Linux kernel 2.2.x (x >= 14, use latest if possible)
30 ftp://ftp.kernel.org/pub/linux/kernel/v2.2/
And that is all very nice and sweet, but why exclude the Linux compatiblity modes of SCO/BSD/Solaris? BSD/SCO/Solaris have all worked hard to provide compatiblitly with this "standard" http://www.telly.org/86open/index.html
Why are these "linux initatives" (redhatisnotlinux.org is an example) exclusionary of GPL/anything not linux? What is wrong with trying to support EVERYONE who is willing to provide 'linux elf' support?
If it was said on slashdot, it MUST be true!
Do we really want some organization telling third-party developers how to achieve binary compatibility?
You are so right. That's why I hate TCP/IP too! We should all just be doing our own thing, work up all our own protocols, and use whatever we feel most comfortable with. Here we are, stuck with only 4 little octets for addressing. We shouldn't be so restricted by "the man" when deciding how we want to browse the web.
While we're at it, why do we have only one mark up language? I want 5 or 6 to choose from at all times so I don't have to deal with things being dictated at me.
Standards are just some way to have "the man" keep us down.
[Sarcasm:Off]
The line must be drawn here. This far. No further.
Nobody's telling anybody to do anything or forcing you to do anything or enforcing any rules. What they are doing is starting to put some ideas down in some sort of standard so that those people who want to can conform to it and state this fact. A standard isn't a regulation, it's just a flag you can wave that says "we do stuff this way".
the bad thing, of course, is that the standard turns out to be a pile of shite, nobody ends up using it, a whole ton of time spent is wated and we all go back to square one a little bit wiser.
the main point here is that nobody's pointing a gun at your head. literally. this means you have the choice whether or not to even think about this. you could, for all the rest of us care, switch off your computer and climb the nearest mountain, meditate on how misguided your life has been up til now, fast by way of repentance and starve to death, lonely and unloved.
the rest of us, however, will go on and enjoy a new era of cooperation between application developers on Linux. something that's been way too long in the making.
it will be a good thing, or it won't be a thing at all. stop being such a bloody pessimist.
Remember, one of the reasons we all switched to Linux from Windows or MacO$ is that Linux doesn't force people to conform to a certian standard -- the way that "Compatible with MacOS" or "MCSE Certified" stickers do. If we start setting a standard for binary compatibility, everyone will start basing their Linux configurations on that standard. And then nobody will achieve commercial success without sticking to that standard.
I'm not trying to say that there's some "conspiracy" out there. I'm sure everyone has the OSS community's best interests at heart -- but the road to hell is lined with good plans. As soon as we introduce specific standards into the Linux community, even by suggestion, developers and retailers will end up adhering to them. No, they don't have to, but economics dictate that they will, or their products won't be able to compete with the "Linux Development Platform Approved" products. And then we end up locked into generic, formulaic garbage, just like Wintels and Macs are.
This reminds me of that graphics card that lets players "cheat."
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.
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!