SCO v. Novell: stick a fork in them, they're done

It's official: the jury ruled in SCO v. Novell that Novell owns the copyrights that SCO was trying to claim. That pretty much puts paid to all of SCO's dreams of a litigation-lottery win in the IBM case too. IBM's not inclined to settle, and pretty much all that's left is IBM's counterclaims against SCO. SCO has a few scraps of claim left, but all the evidence they're presented put together doesn't amount to enough to make a porn starlet's bikini.

Here's the actual jury verdict form.

SCO v. world in a nutshell

To borrow from Darl's favorite cattle-rustler metaphor:

Darl had some cows on his ranch. He noticed that some of the cows on other people's ranches had the same brand as his, so he decided to get a posse together to go after those cattle rustlers who'd stolen his cows.

Then it was discovered that the brand wasn't Darl's, it was the brand of a completely different ranch that'd sold cows to just about everybody in the valley. And worse, as it turns out Darl hadn't even bought those cows, some of his own hands had found them wandering on his land and put them in with the rest of the herd. So now not only are the other ranchers mad at Darl for accusing them of stealing cattle when they hadn't, but some of them are accusing Darl of being the cattle thief.

But poor Darl's still positive that somebody somewhere had to have stolen some cows that should've belonged to Darl if he could've afforded to buy them.

Browser process models

Everyone's praising IE8 for it's new one-process-per-tab model. It's got many advantages over the threaded model used by most browsers, including the fact that a crash of one tab can't take other tabs or the browser down. What most people don't seem to get is that the multiple-process model isn't new with IE8, and in fact the threaded model was one adopted only over the strenuous objections of everybody else. You see, threads exist for one reason and one reason only: on VMS and Windows (which was designed in part by the guy responsible for designing VMS), creating a process is expensive. You need threads in those OSes because you can't create a lot of processes quickly. But Unix had cheap process creation from day one. You needed another thread in Unix, you forked off another process. Threads weren't needed. But everybody in the Windows community kept braying about needing threads and why didn't Unix have them, oblivious to the fact that they already had what threads did in the fork() call. So Unix finally, reluctantly, adopted threads with all their pitfalls. And programmers used them heavily when processes would've been more appropriate. Until the pitfalls finally became too much to live with, when they went from just driving programmers nuts to causing problems for the very users who demanded them in the first place. So now we're back to where Unix was 25 years ago, forking a new process when you need a new thread of execution.