Slashdot Mirror

And the history behind your 'observation' is shown to you.

1) If linux is "the unix defragger", why is there 180 seperate Linux distros?
2) If you followed the workings of the X86open project. Their goal: A common Unix binary for X86 processors. Linux ELF was declared the winner.

It will esculate the trend for developers to only write code for Linux (when writing *nix stuff of course).

GOOD coders write code with portability in mind. What you are pointing out is there is a whole bunch of lazy/amature coders out there.

Now, given BSD/SCO/Solaris/QNX/etc all can run 'linux programs' on X86, a vendor can opt to produce 2 shrink-wrapped binaries. One for Windows, and the other for 'linux' and have almost 100% of the X86 market. (and, with the LINE project, you could have just one binary.)

For a company wanting to write once....they could. But the 'linux world' needs to declare SOMETHING a standard. LSB has proven to be useless due to infighting between the 180 linux versions. The simple solution: Point to an emulated environment and declare that the standard. (The famly wants to fight....go outside the family)

but this is indicative of Linux taking over the *nix ma
What, with the power of fragmentation?

Look through their mail archives, and you will find the leaders of the LSB are all focused on making it easier for COMMERCIAL software companies to write Linux software.

Bah. The *ORIGINAL* selling out happened long before.
Just like the 1980's "Great Unix Unification" effort, when UNIX was going to have 'one interface' and be able to act as 'one market', the common binary on X86 effort was to obtain Unity. With this Unity, developers could be approached and told "write once, to this standard. Run all of these places."

The in-fighting and "use our implementation" ended up with "linux ELF" as the "standard". Ok fine.

The LSB group will NEVER obtain a workable standard because it is not SEEN to be in the interest of the bigger players in the linux market to allow the smaller players a "software stamp of approval". The "runs on redhat" stamp makes the use of RedHat a "supported option" instead of unsuported in the case of the other 180+ linux distros. And to choose "supported" or "unsupported" is an easy choice.

The LSB will only obtain the reluctant approval of RedHat and their bretheren when some outside force makes them feel their existance is threatened. At the moment, nothing like this exists. And the feeling that "Open source will take over - hence Linux will take over" makes a waiting game a win for RedHat and the other big players.

The LSB (or whatever standard replaces it) should be a standard anyone can Bake-Off their binary application against. And, any of the linux distros of the week should be able to run said application that was Baked-off VS the LSB.

If the "Linux community" (as opposed to the GNU/Linux community) wanted to show they had some balls, they'd:
1) Pubically throw up their hands and say "for 2+ years of effort, we have nothing to show, therefore this process is a failure."
2) Admit that "The goal however is worthwhile"
3) Point to the Linux emulation/compatibility modes of SCO/BSD/Sun and state "These are your bake off targets" under the idea that "If your Linux binaries can run on these machines, they should run anyplace else." Becasue for all the talk about how 'quickly' the 'open source world' can move, movement on the LSB has not happened. Code exists to provide a 'bake off' standard.

At a minimum, a "standard" would allow for more companies to have one less excuse to *NOT* produce programs that run on the "non Microsoft, non Macintosh" platforms. At a maximum, RedHat and others would see such a declaration as a 'threat' and actually MOVE to publish a "sanctioned standard". A standard the SCO/BSD/Sun would be able to get behind. A standard that can GROW the whole market.

Your criteria is "small, fast, and compatible" not to mention "freely hacked"

Yet BSD is a BETTER choice based on your criteria.
Small - PicoBSD is a fully functioning Unix OS on a floppy.
Fast - BSD on benchmarks runs FASTER than linux. 10-30% faster.
Compatible - The result of the X86Open group (creation of a common binary format for X86 unixes) was a Linux ELF format. Thusly products like FreeBSD can run Linux binaries. And, FreeBSD can run Quake III linux binaries FASTER than Linux does. And, it is well known and accepted that NetBSD is ported to more platforms.

And, "freely hackable", the BSD license allows the user of the code to commericalize their product without the worry of having to release the IP the company uses in the product. The code is MUCH more free to do what a human wants to than other licenses.

Looking at 2 'linux' projects that are willing to admit they used the pioneering work of NetBSD are the dreamcast port (acknolodge the boot code is NetBSD inspired) and Linux on WinCE

Linux may 'work well', but in the world of computer code, the BSD tree is BETTER!

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?

My point is that companies providing linux applications *clearly* have the source to their own programs, and we should be advocating that they port their software to as many platforms as possible. We should *not* be advocating that they port to some non-existant "linux compatibility binary standard".

The fact that there currently isn't a Linux-compatibility binary standard neither indicates that there never will be one nor that there should never be one.

I suspect those companies would prefer that "port[ing] their software to as many platforms as possible" not mean "porting it to Red Hat and porting it to SuSE and porting it to TurboLinux and porting it to Debian and porting it to Slackware and...", and, quite frankly, I don't particularly care to dispute their preference.

The site the person to whom you replied referred was the 86open site; they abandoned that project when various x86 OSes started adding Linux binary compatibility packages, on the grounds that this was making the Linux/x86 ABI a de facto ABI, as per

With these announcements, the need for a distinct common binary standard is gone. The operating system vendors, one way or another, have chosen a common binary format -- the Linux ELF format, which is now supported on the systems of all the developers which originally joined 86open.

Unfortunately, there isn't necessary a Linux/x86 ABI; that's at least part of what the Linux Standard Base is attempting to fix.

If the LSB comes out with a reasonable standard, then the suppliers of various Linux distributions, and of other OSes, have a choice - they can make their OSes, or the Linux compatibility environments thereof if they're not Linux distributions, conform to the LSB specifications, or not. If they do, it imposes restrictions on them, but may make it more likely that some random shrink-wrapped application will run on their platform; if they don't, it allows them more freedom, but may oblige them to live with some shrink-wrapped applications not working on their OS. (Yes, this does put the burden on the OS vendor, as per your

Look, linux is a moving target, and the linux distros try valiantly to keep up. If other platforms want to continue to be binary compatible with that target, they are going to have to track it and keep up with it.

which is fine with me; the advantage of something such as the LSB, if it comes to fruition, is that it could provide one "it" to "keep up with" that's at least written down and testable. It would presumably evolve over time.)

Much better to impress upon vendors the importance of cross-platform source compatibility.

And why exactly is it important to vendors? "It's the right thing to do" may, or may not, be sufficient; they may well choose to say "fine, we just don't care, there are enough {Red Hat, LSB-compliant, whatever} platforms that we're willing not to have our software run on the other platforms".

And, when the Linux community gets done with the in-fighting over a common binary, BSD/SCO/Sun will be there with a mode to run them.

How did we end up with a Linux binary as the 'compatibilty standard'?
86Open was an attempt to create a standard X86 op-cde unix binary. And, lo and behold, the in-fighting killed that. Most of the people involved in the project came out with a Linux compatiblity mode.

The people asking for shrink-wraped binaiers need to ask for binaries that work EVERWHERE, not just RedHat. Because people are content to accept redhat only binaries, RedHat has no desire to change this.