Ransom Love, Caldera Co-Founder Interviewed 237
rootmon writes "The interview focuses mostly on Ransom Love's views of SCO Group's current dispute with IBM and the Free/Open Source Software Community. It also provides some insights on why Caldera purchased the UNIX business of SCO and their joint Monterey project with IBM. In summary, Love's view is 'My belief is that Unix and Linux should co-exist and should look and feel the same to application developers. Fundamentally, I would not have pursued SCO's path. You see, the challenge is building business. Litigation, no matter what side you're on, tears down businesses. Only the attorneys win. Companies should focus their energies on building their businesses, not on lawsuits. I don't see any positive outcomes.'"
Huh? (Score:5, Informative)
I thought that we already had that, and that it was called POSIX. Am I missing something here?
consistant (Score:5, Informative)
LWN at Comdex 2000: http://old.lwn.net/2000/features/Comdex/RansomLov
Linux Journal, Aug. 2000: http://www.linuxjournal.com/article.php?sid=5406 [linuxjournal.com]
Speaking of Stock price... (Score:5, Informative)
Re:Huh? (Score:5, Informative)
Yes. Whatever standards compliance POSIX brings to various operating systems, it doesn't necessarily mean you have commen API/system calls, and definitely doesn't guarantee binary compatibility across systems. You've probably noticed that apps don't always make/compile across *NIX systems (let alone other POSIX compliant systems like WinNT) -- hence the need for autoconf and its ilk.
It sounds like their initial goal was to open up the UNIX stuff they got from SCO, building a better Linux in the process. When they found they couldn't do that without IP encumbrance, they changed their goal: to create a UNIX product which had whatever edges they thought they'd inherited but would also run Linux apps on IA32/64, no problem.
And when their plans with IBM went awry -- and it sounds like Love thinks IBM wasn't ethical -- they stopped, and the current folks decided to pick legal fights with IBM and the open source community.
Bullhonkey... (Score:5, Informative)
Reginald Broughton, the Senior VP of SCO, has made approximately $1,493,650 since June 20, 2003 in stock sale.
Man, I wish I had the balls/money to perpetuate this scam. The worst they'll get is a slap on the wrist. If the Enron execs have gotten as little punishment as they have, what makes slashdotters think that the Federal SEC is gonna give a crap. Especially since it's a puny company perpetuating a stock scam based on a computer OS barely anybody outside of the technical realm has heard of.
Not trolling, but at least it makes a lot of publicity for Linux in the business world and no publicity is bad publicity.
-non trolling sig- You're already read this...it's too late not to finish.
Re:Huh? (Score:4, Informative)
There's bound to be a number of issues with binaray compatability cross a number of chipsets.
Re:Huh? (Score:5, Informative)
Re:Open sourcing Unix (Score:3, Informative)
Exactly... I'll bet the current SCO/Caldera management has NO idea what's in the Unix code base that they "own." At the very least, that statement by RL makes it clear that there is considerable code that, while IN unix, SCO/Caldera does NOT own the copyright too.
After all, if it's so encumbered by other companies code that they couldn't open source it if they wanted too, that code base has to be a gigantic fucking mess from a copyright standpoint.
Re:ABI issues (Score:4, Informative)
You still have to deal with minor issues like:
- Which way does the stack grow?
- Which register is the stack pointer (not always dictated by the hardware, especially on RISC chips)
- Which register is used for globals? How is global data accessed? (TOC and GOT are two techniques; load-time address mapping is another one.)
- How are structure members laid out in memory? Padding and alignment requirements are influenced by the hardware, but that doesn't always mean the ABI is the most obvious interpretation of the hardware specs.
- What function arguments are in registers, which are on the stack? How are "ellipsis" functions handled? How are K&R argument promotions handled? How are aggregates passed? Are small aggregates (such as char[4]) are passed in a register, on the stack, or by pointer. Same with large floats, is a quad float passed by address or value?
- Setjmp/longjmp, how do they work?
- How does a stack frame look? If this isn't standard, exception handling can't unwind the stack, debuggers can't do a backtrace, and so on.
- Where's the heap? Register pointer, fixed segment, what?
While it is possible to have an ABI that is common across operating systems on the same CPU architecture, it is impossible to have the same ABI across CPU architectures. You just can't use R31 as a stack pointer on IA32; there isn't one. You can't use SPARC register windows on PowerPC. And so on.
Re:He sold his stock! (Score:4, Informative)
Moral fibre is not something I would have expected from him. Sometimes it's nice to be suprised.
Linux isn't quite POSIX compliant - deliberately (Score:3, Informative)
I thought that we already had that, and that it was called POSIX. Am I missing something here?
(In addition to POSIX not specifying an ABI, as has already mentioned in another post.)
Linux has a few deviations from the POSIX standard.
Some of them are accidental: Linus didn't want to shell out for the expensive POSIX document while a starving grad student hacking for his own enjoyment.
A very few are deliberate: For instance, there's at least one place where Linus thinks the POSIX standard is dangerously fouled up and needs to be done slightly differently.
And there may be other classes of differences.
Re:he's right and wrong (Score:3, Informative)
Re:ABI issues (Score:2, Informative)
Not entirely. Things like Java bytecode and .NET CLR are ABIs that are portable across CPU architectures, and even OS's. Both of them, however, severely limit what forms of access you have to the machine. Writing a driver in either of them would likely be nearly impossible (if not completely impossible on some types of systems).
The other problem is, even as simply an API, the POSIX specification leaves quite a few things up to the implementor. A function may do the same type of task on two different platforms, but perform it differently enough that a program written for one fails on the other. There are numerous combinations of parameters that have undefined meanings according to POSIX, and they may work just fine on some platforms, and completely bomb on others. In fact, Linux 2.6 changed some of this 'undefined' behaviour compared to 2.4, and broke some stuff (it had to do with combinations of O_TRUNC and O_RDONLY in open() calls). Things like this can be a bigger problem than even ABIs.