Posted on 10/19/2009 9:34:56 PM PDT by Ernest_at_the_Beach
Unix code claimant SCO Group has jettisoned its controversial captain, Darl McBride, as part of the company's latest scheme to emerge from bankruptcy.
The serially litigious SCO's executive ousting was revealed in a filing today with US regulators, although corresponding paperwork gives McBride's actual dismissal date as October 14. The decision to remove McBride was done under the auspices of the Chapter 11 bankruptcy trustee assigned to SCO by the US Justice Department. That leaves COO, Jeff Hunsaker, CFO, Ken Nielsen, and General Counsel, Ryan Tibbitts grappling for the helm.
According to the filings with the US Securities and Exchange Commission, SCO's remaining management will still continue to push forward with its long-running intellectual property lawsuits against IBM and Novell. It also stated the company expects to finalize details of the restructuring and to reach cash flow break-even for core operations within the next month.
McBride was the architect and voice behind SCO's troublesome legal crusade against Linux. It began when Novell sold Unix trademarks and other assets to SCO — and the company assumed the deal included copyrights to Unix code. In 2003, SCO sued IBM for handing over the allegedly copyrighted technology to the Linux kernel and ultimately demanded that just about any company using Linux must purchase an IP license.
(Excerpt) Read more at theregister.co.uk ...
Just unreal that they haven’t died.
Darl McBride Out; SCO Looking to Sell "Non-Core Assets"
*************************************EXCERPT*********************************
ars technica says the litigation will continue:
In a statement issued by SCO's new leadership, the company indicates that it plans to continue its litigation efforts and will move forward with the appeals process. The company also says that it plans to continue supporting its UNIX products. This potentially indicates that SCO has given up on trying to unload its UnixWare assets, a plan that has fallen through several times now as various proposed deals have evaporated.Sad when getting rid of you is deemed essential for a company's survival. But I doubt this is the end of the Cowboy. He has reportedly said that there could be a shareholder revolt and litigation against the Chapter 11 Trustee. And none of the above tells us what the folks who have backed SCO from day one will do. If you recall, in the Pelican Equity complaint, other defendants with McBride allegedly called him their puppet. So... who is the puppet master?"These actions, while difficult, are essential to SCO becoming a more agile and efficient company, not just for this year, but for years to come," said Hunsaker in a statement. "This restructuring plan reinforces SCO's ability to continue to sell and support its products while servicing the needs of our customers and partners on a worldwide basis through the stabilization of our financial situation."
There is another allegation in footnote 2 on page 12 of the First Amended Complaint [PDF]:
2 McBride met Norris while he was working for AIP. The conclusion of the venture to take control of SCO Group bore similarities to that of the stock loan business. Norris, McBride, and Brazell took the opportunity for themselves to the exclusion of Robbins. After Norris and Robbins established a joint venture to purchase SCO out of bankruptcy with McBride's assistance, Norris and Brazell excluded Robbins' company from that entity and replaced it with Brazell's company, Gulf Capital Partners, LLC. Not coincidentally, Bryan Cave also represented Gulf Capital Partners. In connection with that endeavor, McBride unlawfully made a $100,000 payment to Norris, which he obtained through a home equity loan that he bragged was fraudulent, to make up for fees that the bankruptcy judge had forbidden SCO to pay Norris.Now, this is an allegation, not evidence. You can say whatever you want in a complaint, and it's only later in litigation that you find out who is telling the truth or who is in the right. Both McBride and Bryan Cave have filed motions to dismiss the complaint, which are pending. But while it's important to caution about not jumping to conclusions, the fact that such incendiary allegations are out there now in public could be at least part of what may be happening behind the scenes, I would imagine.
I find it hard, I guess, to understand the reasoning behind firing McBride and then continuing the litigation unless there is some other factor. Litigation is his best skill, in my view. But then, SCO never did take my advice. Think how much trouble they could have saved themselves, and the rest of us, if they only had.
P.S. SCO's litigation will eventually fail, in my view, because of the GPL. They released their Linux products under the GPL. It's the fundamental flaw that will sink that ship no matter what else they are able to do. I've been saying that since Groklaw began, and it's still my opinion.
Here's the SCO statement in full, attached to the 8K as Exhibit 99-1:
Behold: The wonders of Unix!
I’ve said it before and I’ll say it again...
I remember when SCO actually made and sold software. Somewhere around here I’ve got a set of SCO Xenix 386 floppy disks, sn, AND the activation key! Plus their office software. I also have a copy of SCO UNIX, ODT, and even a copy of Informix 4gl Rapid Development System... Somewhere in my basement!
I set up many a turn-key systems for small businesses (using Mitsubish MP386 systems), and I also remember that one of the earlier manufacturers of grocery store POS scanners (Sweeda) used a “hacked” version of SCO Xenix to run the system. It was terrific.
Mark
Actually, yes. It is so well designed and documented with a public interface that it has long since been defined away fron “whatever runs on Ken Thompson’s desktop.”
The most important fact about Unix (as versus Plan 9) is that Unix was originally distributed as a precursor of Open Source. I had access to Unix source code in 1981 in college.
I checked http://linux.about.com/od/commands/l/blcmdl8_restore.htm
but could not find the appropriate restore command that SCO used ;-)
Was it boot: McBride
SCO should become a poster boy for “loser pays”.
I hope you mean "point of sales" :-)
I think that's the other SCO.
It is. SCO Unix started off life as Xenix, the Microsoft branded Unix. The earliest versions were pretty good for their time. They failed doing anything sensible with X11 (SCO Open Server was little short of a disaster) and floundered until they sold the company and its assets (but not the people) to Caldera.
Caldera started off life as a fairly decent Linux distro. They branched out and bought the bones of Digital Research including the DR DOS lawsuit. Nothing interesting came out of that despite the fact that they could prove that Microsoft Windows had code in it to detect when it was running on top of DR DOS and fail. Following that, they bought SCO and assumed the name.
Other than producing Caldera Linux over a decade ago, this incarnation of SCO hasn't done anything other than pursue lawsuits and tarnish the name of a once proud company.
Just because it is defined doesn’t mean that I agree with the underlying design-philosophies... the super-user idea, for example, is a GIANT security-risk as all one has to do to compromise the entire system is gain that root-access.
The star-expansion requirement for shells is, IMO, a pain in the ass. For example, you can’t see if the user typed in “*.pdf” on the command-line vs “Doctorate.pdf Thesis.pdf ugh.pdf”. This means that the primitive file-management command “rename” cannot be used sanely on groups of files; rename *.c *.cpp does NOT rename all .c files to .cpp
Another thing that I personally don’t like is the unhelpfulness of that OS-family; it shows great similarity to the C/C++ tradition of unhelpful errors and ‘surprises’... and given the relation between *nix and C/C++ it is unsurprising.
This has been corrected in later iterations with finer grained permissions via capabilities.
Oh and I'm not at all pleased with the way Mac OS X deals with this issue.
The star-expansion requirement for shells is, IMO, a pain in the ass.
It's a good thing and a bad thing. On the one hand, it frees applications up from having to do their own globbing (which will always lead to inconsistencies) on the other hand (as you point out) it leads to an uncomfortable implementation of a general rename program.
Zsh has the `noglob' built in that suppresses automatic shell globbing. I'm not sure whether that's a standard.
Another thing that I personally don’t like is the unhelpfulness of that OS-family
That's purely an application issue. The most organized approach was the one taken by VMS where you registered error numbers and severity. It also has been dead for a couple of decades. :-)
My guess is that we'll always have issues with error messages.
The "current" SCO has morphed into a lawyer employment/legal harassment firm from the original "Santa Cruz Operation." The actual software developers split off many years ago. But they still have the name, and that makes me sad.
Mark
>>the super-user idea, for example, is a GIANT security-risk as all one has to do to compromise the entire system is gain that root-access.
>
>This has been corrected in later iterations with finer grained permissions via capabilities.
I’m unsure if that’s actually a “standard” or implementation-optional thing. The university’s set-up (which I’m most familiar with) doesn’t seem to operate in that mode at all (super-user XOR local-user XOR connected-user) seems to be the granulation it takes.
>Oh and I’m not at all pleased with the way Mac OS X deals with this issue.
I’ll admit I’m not sure how Mac’s OSX deals with it; I’m unfamiliar with the system. What is their solution?
>>The star-expansion requirement for shells is, IMO, a pain in the ass.
>
>It’s a good thing and a bad thing. On the one hand, it frees applications up from having to do their own globbing on the other hand it leads to an uncomfortable implementation of a general rename program.
Actually, I think the whole issue would be a non-issue if program/file-grouping would have been placed in a general-use [static, or dynamic] library originally. {Which actually makes a lot more sense to me than as is normally done.}
>>Another thing that I personally don’t like is the unhelpfulness of that OS-family
>
>That’s purely an application issue. The most organized approach was the one taken by VMS where you registered error numbers and severity.
In my experience with Linux the problem is, somewhat, also in the error-code returning. {Some programs don’t return error-codes at all, IIRC tar is one.} So, it’s a chance you’ll get an error-code at all.
Some of what I term unhelpfulness I could point to as fully-embodied by C/C++ compilers; General rule: ignore ALL other error-messages besides the first. The systems are designed dumb, and to stay dumb... that is instead of looking at-all into the future and planning, it seems the whole thing is a mess of unplanned “quick-fixes”.
Some of it stems from, what I observe to be the Unix/Linux/C/C++ obsession with text. Text isn’t bad, by any means, but it is a horrible way to implement IPC/Piping or even abstract-exchange; and consider that is what many utilities use for their mode-of-communication (especially the command-line). And in reality c++ generics are _just_ text-substitution.
No root password, good. Separation of privileged (admin = sudoer) and unprivileged accounts, good. Default setup results in running as an admin, bad. Ownership and permissions in the Mac OS X equivalents of /usr/bin and /usr/lib are sloppy, very bad. On host network services mostly default to off, good.
Actually, I think the whole issue would be a non-issue if program/file-grouping would have been placed in a general-use [static, or dynamic] library originally. {Which actually makes a lot more sense to me than as is normally done.}
You're being over critical over what was then a brilliant innovation (and was still addressed about a quarter century ago). The Version 7 Bourne shell was the first fully programmable user interface. The 2nd Unix shell, the Korn Shell, distributed with the AT&T toolchest did include the globbing code as a separate linkable library. The Korn Shell also included the command line editing and history code as a linkable library. Furthermore, the command line editing and history features were available inside of user written shell scripts.
In my experience with Linux the problem is, somewhat, also in the error-code returning. {Some programs don’t return error-codes at all, IIRC tar is one.} So, it’s a chance you’ll get an error-code at all.
Oh, yes. That's absolutely a weak point that programmers still do not do well.
My #1 Linux peeve is the KDE practice of not including man pages.
Some of what I term unhelpfulness I could point to as fully-embodied by C/C++ compilers; General rule: ignore ALL other error-messages besides the first.
Sadly, that continues to be true. What's interesting to me, is that on the first day of my compiler design class (which I took in 1983), the first thing we were told was that by far the most important feature of a compiler was a combination of good diagnostics and good run-time debugging support.
Taking that to heart and finding in Davie and Morrison an excellent error recovery algorithm during parsing, I built my parser so that it could reliably detect multiple errors in source code. The gist of it is that in addition to specifying allowable transition states you also supply context sensitive synchronization tokens. When you encounter a syntactic error, you discard further input until you reach the synchronization token. This works extremely well in practice.
Most compilers today use LR techniques not LL techniques and filling in error states in LR tables is something I've never seen well-automated.
Text isn’t bad, by any means, but it is a horrible way to implement IPC/Piping or even abstract-exchange; and consider that is what many utilities use for their mode-of-communication (especially the command-line).
In a strictly single language, homogeneous environment, perhaps. Do I take it that you're a fan of ASN.1 or XDR? Plain text as a transfer medium has the property that it is remarkably portable - computer language and architecture neutral. It is also straightforward to implement.
Thank you for the info on the OSX. Duely noted.
>>Actually, I think the whole issue would be a non-issue if program/file-grouping would have been placed in a general-use [static, or dynamic] library originally.
>You’re being over critical over what was then a brilliant innovation (and was still addressed about a quarter century ago).
But that it (and its progeny) STILL has the defect is rather surprising.
>The Version 7 Bourne shell was the first fully programmable user interface. [snip] Furthermore, the command line editing and history features were available inside of user written shell scripts.
But that the thing was created in c and uses the cout/cin[/cerr] model from the stdio header, would it have been overly difficult to “snip-out” the globbing into, say, a globbing header? If that HAD been the case then I would wager that ALL [non-toy] shells would have avoided the problem.
As for shell-scripts... I have mixed feelings on them, generally I’d say they’re bad because of the dependencies they pick up from version to version & flavor to flavor of unix/linux; I’m of the strong opinion that high-level languages should allow you to, as much as possible, work with general disregard to the underlying hardware-architecture. {There will always be dependencies to be mindful of, but by defining your problems within the terms of the hardware’s acceptable finite subsets you should be completely free from trouble; i.e. all single byte-sized modular integer arithmetic results may be held in 16-bits.}
>{Some programs don’t return error-codes at all, IIRC tar is one.} So, it’s a chance you’ll get an error-code at all.
>
>>Oh, yes. That’s absolutely a weak point that programmers still do not do well.
What about the wonderful [/sarc] allowance of assignments in the condition-test for control structures? I HATE that, been bitten by it too many times... and it encourages the sort of programming prone to buffer-overflow errors: while ((c = getchar()) != ‘\n’) buff[i++] = c;
buff[i++] = ‘\000’;
>What’s interesting to me, is that on the first day of my compiler design class (which I took in 1983), the first thing we were told was that by far the most important feature of a compiler was a combination of good diagnostics and good run-time debugging support.
I really enjoyed my compilers class; partly because I could “argue” against the routes we taking, though I “won” a lot of the debated it was “only a single semester class.”
I completely agree with that assessment of the compiler, the diagnostics should be top-rate as well as the debugging. After-all, it makes sense to eliminate or prohibit errors as early on as possible; like above’s byte-example, or Pascal’s then statement allowing the detection of a missed parenthesis or Ada’s endif which prevents the dangling-else problem. {True the last two are language-design, but the design principle still applies.}
Another Ada feature that I like is the Array’Range looping; if you use that you’ll never access an invalid index in that array... which IMO would help to write more correct & stable code than having to worry about the underlying representation (indecies).
>Most compilers today use LR techniques not LL techniques and filling in error states in LR tables is something I’ve never seen well-automated.
LL v LR... I’ve heard of them, but haven’t really investigated. I probably should, but I’m getting ready to graduate. (So mayhaps after.)
>>Text isn’t bad, by any means, but it is a horrible way to implement IPC/Piping or even abstract-exchange; and consider that is what many utilities use for their mode-of-communication (especially the command-line).
>
>In a strictly single language, homogeneous environment, perhaps.
Well, I was thinking if it was handled at the OS-level, well defined, and outside-linkable like c’s stdio (I’m sure I could think up a better example) {maybe outside-interfacable would be stating it better} would make it a lot easier to work-out... that is grow it with the OS.
>Do I take it that you’re a fan of ASN.1 or XDR?
I haven’t actually heard of them. Why do you think I’d be a fan?
>Plain text as a transfer medium has the property that it is remarkably portable - computer language and architecture neutral. It is also straightforward to implement.
Oh, I agree; those are good qualities. However, text itself [unformatted/unrestricted] isn’t really suited to passing along objects... I mean you could pass them as, say, scheme objects, but then you’re imposing a formatting and restricting your operating-set. (Same with XML and so-forth.)
I’m somewhat disappointed in the state of OSes right now. It seems they’ve plateaued off in terms of functionality and (in the case of Windows Vista) are more concerned with “looking pretty” then being usable. {I will say that Mac had the right idea when they designed things for the user... Interesting side-note is that they used pascal for a lot of their interfaces and some of the OS-Code. I imagine that the range-checking, assuming they had it enabled, helped prevent errors like the [array-]buffer-overflow.}
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.