From the article: I cut out 480 x 270 sections showing the band's bassist, Flea, because the full images won't fit on this page. I used Microsoft's Digital Image 2006 editor to crop the images and convert them to JPG from PNG format.
The images posted are PNG, but did they go through a JPEG conversion at some point?
The reviewer may have a point, but I can't take anybody seriously who talks about image quality, then converts the sample images from PNG to JPEG.
The last thing you want to do when talking about compression artifacts is run the samples through something like JPEG compression, which introduces edge artifacts of its own and makes existing sharp edges worse.
For those who didn't read the article, the software publisher discovered about the piracy at Sony because a Sony employee called tech support for the product.
A surprisingly large amount of corporate software piracy is discovered via tech support requests.
I guess MS kind of tried to evolve C++ on its own via Managed C++ but the managed C++ syntax (carrots (^) anyone?) makes me want to vomit.
Yes, "Managed C++" was awful. It's the ultimate demonstration of the fact that destructors and garbage collection do not play well together. Microsoft implemented all the hard cases, including "re-animation", which means an object can be destructed more than once. Sometimes I think "Managed C++" was created to kill C++ in favor of C#, which is sort of Microsoft's Java.
We do need better hard-compiled languages, for when you don't want all the excess baggage of ".NET" or Java. Modula 3 was probably as good as it ever got, but Modula 3 came from DEC Research, which did some great work but was killed off after the Compaq acquisition.
Of course nobody is reading newspapers any more.
There's so little news in them.
In the SF area papers, the "Food and Wine" section is thicker than the "News" section, and the "Cars" section is thicker than both together. What's the point? Especially since, if that's what you want, there are better sources for information about food, wine, cars, sports, and classified advertising.
The whole point of newspapers is that they send people out to dig up stories, and you pay to read the results. That's fine. As advertising-delivery vehicles, they're obsolete.
That's true. I was once talking to one of the first designers of ink-jet printers at HP, and he mentioned that intuition about fluid behavior totally fails at that scale. They had to do simulations that modeled the interatomic forces to make inkjets work well.
Yeah, array/pointer ambiguity is a key "broken" feature of C++, although at the same time it's exactly the kind of thing that makes it possible to use the same language for code running on a microcontroller and for a full-blown GUI.
Not really. I'm not asking for array descriptors. I'm not proposing to change the run-time representation of arrays. What I'm talking about is a generalization of array declaration syntax.
Until C99, array declarations always had to have constant array sizes. C99 introduced on-stack arrays, so in C99 you can write:
int fn(size_t n);
{ float tab[n];/* on-stack array, sized based on fn parameter */ ...}
This was the first syntax which allowed a run-time variable in an array definition, and it was a big help, because it saved a malloc call inside of number-crunching libraries. (Numerical Recipes in C had this problem, and FORTRAN didn't.).
The next logical step is to allow that syntax in more places, like function parameters. This doesn't require passing an array descriptor. The programmer gets to specify the expression that defines the array size. So there's now a way to talk about array size that the compiler understands. Checking becomes possible.
Of course "sizeof" and "lengthof" should be extended to such arrays, so you can write:
int status = read(infd, buf, sizeof(buf));
Giving up pointer arithmetic is too much to ask C and C++ programmers, but restricting pointers to iterator syntax (valid values are NULL, a pointer to an element of the array, and one past the end of the array) makes them checkable. There are checking iterator implementations, so this is possible.
Once the compiler knows what's going on with arrays, subscript checking can be optimized.
This is well understood. In particular, subscript checks within for loops can usually be optimized ("hoisted" is the term compiler writers use) so that there's one check at the beginning of the loop, and often that check can be folded into the loop termination condition. So the checking cost in matrix-oriented number-crunching code is usually zero.
There's more to this, and it isn't painless to remove this ambiguity, but if we had a "strict mode", where the checkable forms have to be used, there's a transition path.
If all code running as root had to be in "strict mode", we'd be way ahead.
Mechanical vibrations at 4.5GHz. Just think about that for a moment. A tiny piece of silicon, like a little tuning fork, wiggling back and forth 4,500,000,000 times every second.
Without breaking or wearing out. It's not just electrons moving; this is a solid piece of material vibrating.
The big problem with C++ is Strostrup. He's in denial about the fact that the language is fundamentally broken. But he's still influential in C++ circles. Thus, no one else can fix the mess at the bottom.
The fundamental problem with C++ is that it has hiding ("abstraction") without memory safety. This is the cause of most of the world's buffer overflows. No other major language has that problem. C has neither hiding nor memory safety, so it is still vulnerable to buffer overflows, but they're to some extent visible at the place they occur. Pascal, Modula, Ada, Java, C#, and all the interpreted "scripting languages" have memory safety. C++ stands alone as a language where you can't see what's going on, and the compiler doesn't have enough information to check subscripts.
The reaction of the C++ standards committee has been to try to paper over the problems at the bottom with a template layer. That didn't work. The template classes just hide the mess underneath; they don't make the language memory safe. There are too many places that raw pointers leak out and break any protection provided by the templates. The template language itself is deeply flawed, and attempts to fix it have resulted in a collection of "l33t features" understood and used by few, and too dangerous to use in production code.
The fundamental cause of the trouble comes from C's "pointer=array" equivalence. That was a terrible mistake, borrowed from BCPL. The trouble is that the compiler knows neither which variables are arrays nor how big the arrays are. You can't even talk about arrays properly. I mean, of course,
int read(int fd, char* buf, size_t len);
That's just trouble waiting to happen. "read" has no information about how big "buf" is.
C++ added references to C, and should have added syntax like
int read(int fd, char& buf[len], size_t len);
to go along with it, so that arrays became first-class objects with sizes. But it didn't. There are some other things that have to be done to the language to make this concept work, but this is the general idea.
This is the elephant in the living room of C++, and Strostrup is in denial about it.
Every time you have another crash from a buffer overflow, every time you install another patch to fix a buffer overflow, every time you have a security break-in from a buffer overflow, think of this.
Wikileaks is back up. I've seen "Fitna"; it looks like a YouTube mashup, zooms over stills and all. There's little original footage.
A much better comment on militant Islamic types, The Burqa Project, is down, though. That's a delightful little piece from 2005 showing three French models running around Paris in flowing, see-through burgas. Google still has thumbnails up, but the video site is now password protected.
As Heinlein liked to point out, religion needs a good belly-laugh once in a while.
the thirty second warning is little better than "duck and cover" if it cannot be communicated effectively.
Actually, a 30 second warning is quite useful, but not to humans. There are such warning systems in California. When the warning system trips, elevators stop at the nearest floor, subways and BART trains stop, gas valves at schools and mobile home parks close, and some hazardous processes shut down.
But the data from that comes from fixed seismic stations, not somebody's random accelerometer.
I'd like to see a similar report on religions. Catholic churches should have warning signage: "No unattended children beyond this point". Religions prone to fanaticism, from Islam to Scientology, need "Warning - Do Not Use More than 1 Hour Daily" to prevent overdosage.
There are far worse things than anything that runs on an XBox 360.
For a brief period, there was DeviceBay. DeviceBay is a standard for slide-in hard drive carriers, with power, USB, and FireWire connectors that mate on slide-in. There's even a mechanical interlock so the computer can keep the device from being pulled until the drive is unmounted. There's full support for DeviceBay in Windows XP.
The Cell isn't really an exotic parallel machine. It's a regular multiprocessor/multicore machine (like a ten year old desktop Mac) except that some of those processors are special purpose.
No, it's a non-shared-memory multiprocessor with limited memory (256K) per CPU. It belongs to roughly the same family as the nCube, although the Cell has a block DMA-like path to main memory rather than relying entirely on CPU to CPU data paths like the nCube.
It's typically used like a DSP farm; data is pumped through each Cell processor, crunched a little, and pumped out the other side. It's only good for problems that fit that model. Audio guys love it. Physics programmers, not so happy.
What's the point of more residential bandwidth? All most people will do with it is watch TV. Why should national policy be devoted to helping people watch TV, which is a fundamentally nonproductive activity?
Once you get to 1Mb/s or so, you can do everything most residential users do that isn't video-oriented. What's the problem?
The "gigabit connections" of some of the high density countries are illusory. You may have gigabit Ethernet to your apartment, but your 1000-unit apartment complex doesn't have a terabit pipe going out.
We know three kinds of parallelism that work: clusters, shared memory multiprocessors, and graphics processors. Many other ideas have been tried, from hypercubes to SIMD machines, but none have been big successes. The most exotic parallel machine ever to reach volume production is the Cell, and that's not looking like a big win.
Graphics processors are the biggest recent success. They're still very difficult to program. We need new languages. C and C++ have the built-in assumption that all pointers point to the same memory space, and don't address concurrency at the language level at all. That's not going to work. The "dynamic languages" (Javascript, Python, etc.) have too much overhead. Special purpose graphics languages (Renderman, etc.) address the high concurrency issue, but only for a limited class of problems. None of the traditional parallel languages (Occam, etc.) have enough of a user base to make them compelling. Interestingly, what does look promising is compiling Matlab to GPU code; the big matrix operations of Matlab translate well to GPU-type machines, and number-crunching engineers like and use Matlab.
If your problem isn't a good match to either Matlab or RenderMan, though, it's all uphill right now.
Penn and Teller once had a game produced, "Desert Bus", in response to complaints that video games were too violent.
The player gets to drive a bus from Tucson, Arizona to Las Vegas, Nevada in real time at a maximum speed of 45mph. The game cannot be paused. The bus contains no passengers.
The road is empty. Nothing happens. If the player makes it to Las Vegas, they score one point. Then a supervisor characters shows up and says "You want to pull a double shift?" The player can then drive back to Tucson. On the return trip, it slowly gets dark. That's it.
If you run off the road, the bus stalls, and eventually a tow truck shows up and tows the bus back to the starting point. In real time.
Somebody got six points once. This is believed to be the record.
If you're using Amazon for hosting, you can't switch hosting services; their system is too nonstandard. Do you want to be in a position where they can raise prices or cut off your air supply?
For those of you not following the SCO debacle, the SNCP deal was being pushed as a last desperate attempt to head off what's coming next month:
U.S. District Court - District of Utah
Court Calendar
Honorable Dale A. Kimball
Room 220. Tuesday, 04/29/2008 08:30 am. SCO Grp v. Novell Inc 2:04-cv-00139-DAK-BCW Bench Trial
This is SCO's upcoming Really Bad Day. The issue of whether SCO owns the UNIX copyright has already been decided - they lost on that issue. The only issue for trial is how much money SCO owes Novell. Which may be more than SCO has left.
SCO went into bankruptcy late last year to stall that trial, the Friday before the trial was to start on Monday. That didn't work; the bankruptcy court un-stayed the Novell trial. SCO tried the York deal to transfer their assets to York. That didn't work. Now they're trying the SNCP deal, which looks very unlikely at this point.
That's a very funny collection of filings. It doesn't stop with the comments about SCO, either. Remember, the proposed deal now is that Steven Norris Capital Partners (SNCP) proposes to buy SCO's assets for $5 million plus a "loan guarantee" of $95 million at somewhere around 20% interest to cover future claims by IBM, Novell, Red Hat, SuSE, etc.
So who is SNCP? The filings tell us.
In filing 412, Novell says "The Disclosure Statement says that SNCP was founded by Steven Norris and & Co. Capital Partners for the purposes of this transaction". So SNCP is a shell corporation. "It has a brief statement about SNCC's partners, Steven Norris and Mark Robbins, and sweeps breezily through a short statement of some of their past activities, making some very general grand claims about their past successes."
In filing 408, IBM points out, "the Partnership (SNCP) does not seem to have any operational or investment history."
Filing 414 points out, "Also, SNACCPLP failed to pay its annual tax assessments, and it thereby allowed its status to lapse to "CEASED GOOD STANDING" back in June 2006 (see Ex. 7). Thus, it is unlikely that the Florida LLC, formed in July 2007 (see Ex. 7), was truly "formed by Stephen Norris & Co. Capital Partners, L.P. for the purposes of this transaction." (Incomplete Disclosure Statement at (V)(B), p. 18)."
This is not looking good.
Steven Norris himself had a great reputation in finance until this month.
His big claim to fame was the Carlyle Group. They created Carlyle Capital, which just went spectacularly broke, losing about $21 billion. If the main asset of SNCC is the reputation of Steven Norris, it's worth far less than it was a month ago.
Santa Clara County, California used to have a weather modification program. It's Silicon Valley now, but it used to be a prime agricultural area; it has great topsoil. But it doesn't get quite enough rain.
So, for about thirty years, when rain clouds were passing over but it wasn't raining, the call went out to all the silver-iodide stations to start up their generators. These were basically oil burners that put out a smoke column with silver iodide in it.
It helped a little, enough to be statistically significant, but it wasn't spectacular.
Beijing is putting in about 100x the effort to cover about 1/10 the area of the Santa Clare Valley effort, so they might get a useful effect.
The problem is engineering cost, not silicon cost. Most servers have a display controller that will never output to a display, an audio controller that will never be connected to a speaker, and maybe even a 3D graphics engine that will never fill a single polygon.
Mainframes are still around because the engineering is better.
There's no secret about how to do this. It wouldn't even add much cost to servers to do it right. Here's what's needed.
All the hardware must self-check. CPUs need checking hardware. Mainframe CPUs have had this since the Univac I. All memory, including the memory in peripherals, needs to have parity, if not ECC. Connections to peripherals must have checking. All faults must be logged and automatically analyzed. CPU designers are wondering what to do with all those extra transistors. That's what.
Peripherals have to go through an MMU to get to memory; they can't write in the wrong place. IBM mainframes have done this since 1970. The PC world is still using a DMA architecture from the PDP-11 era, and it's time to upgrade.
The OS has to be a microkernel, and it can't change much. The amount of trusted code must be minimized. IBM's VM has been stable for decades now, even though the applications have changed drastically. The QNX kernel changes little from year to year; Internet support, from IP up through Firefox, was added without kernel changes. This is incompatible with Microsoft's business model, and the UNIX/Linux crowd doesn't get it. So we're stuck there.
Additional hardware support for debugging is helpful. Unisys mainframes at one time had hardware which logged the last 64 branches, and on a crash, that was dumped.
All crash dumps are analyzed, at least by a program. Why did it fail? Someone has to find out and fix it. We need tools that take in crash dumps from server farms and try to classify them, so that similar ones are grouped together, prioritized, and sent to the correct maintenance programmer.
Once you have all that fault isolation, you know which component broke. This produces ongoing pressure for better components. It empowers customers to be effective hardasses about components breaking. With proper fault isolation and logging, you know what broke, you know when it broke, you know if others like it broke, and you probably know why it broke. So you know exactly which vendor needs the clue stick applied. There's none of this "reinstall the operating system and maybe it will go away" crap.
Slashdot Mirror
From the article: I cut out 480 x 270 sections showing the band's bassist, Flea, because the full images won't fit on this page. I used Microsoft's Digital Image 2006 editor to crop the images and convert them to JPG from PNG format.
The images posted are PNG, but did they go through a JPEG conversion at some point?
The reviewer may have a point, but I can't take anybody seriously who talks about image quality, then converts the sample images from PNG to JPEG.
The last thing you want to do when talking about compression artifacts is run the samples through something like JPEG compression, which introduces edge artifacts of its own and makes existing sharp edges worse.
For those who didn't read the article, the software publisher discovered about the piracy at Sony because a Sony employee called tech support for the product.
A surprisingly large amount of corporate software piracy is discovered via tech support requests.
I guess MS kind of tried to evolve C++ on its own via Managed C++ but the managed C++ syntax (carrots (^) anyone?) makes me want to vomit.
Yes, "Managed C++" was awful. It's the ultimate demonstration of the fact that destructors and garbage collection do not play well together. Microsoft implemented all the hard cases, including "re-animation", which means an object can be destructed more than once. Sometimes I think "Managed C++" was created to kill C++ in favor of C#, which is sort of Microsoft's Java.
We do need better hard-compiled languages, for when you don't want all the excess baggage of ".NET" or Java. Modula 3 was probably as good as it ever got, but Modula 3 came from DEC Research, which did some great work but was killed off after the Compaq acquisition.
Of course nobody is reading newspapers any more. There's so little news in them.
In the SF area papers, the "Food and Wine" section is thicker than the "News" section, and the "Cars" section is thicker than both together. What's the point? Especially since, if that's what you want, there are better sources for information about food, wine, cars, sports, and classified advertising.
The whole point of newspapers is that they send people out to dig up stories, and you pay to read the results. That's fine. As advertising-delivery vehicles, they're obsolete.
That's true. I was once talking to one of the first designers of ink-jet printers at HP, and he mentioned that intuition about fluid behavior totally fails at that scale. They had to do simulations that modeled the interatomic forces to make inkjets work well.
Yeah, array/pointer ambiguity is a key "broken" feature of C++, although at the same time it's exactly the kind of thing that makes it possible to use the same language for code running on a microcontroller and for a full-blown GUI.
Not really. I'm not asking for array descriptors. I'm not proposing to change the run-time representation of arrays. What I'm talking about is a generalization of array declaration syntax.
Until C99, array declarations always had to have constant array sizes. C99 introduced on-stack arrays, so in C99 you can write:
int fn(size_t n); /* on-stack array, sized based on fn parameter */
...}
{ float tab[n];
This was the first syntax which allowed a run-time variable in an array definition, and it was a big help, because it saved a malloc call inside of number-crunching libraries. (Numerical Recipes in C had this problem, and FORTRAN didn't.).
The next logical step is to allow that syntax in more places, like function parameters. This doesn't require passing an array descriptor. The programmer gets to specify the expression that defines the array size. So there's now a way to talk about array size that the compiler understands. Checking becomes possible.
Of course "sizeof" and "lengthof" should be extended to such arrays, so you can write:
int status = read(infd, buf, sizeof(buf));
Giving up pointer arithmetic is too much to ask C and C++ programmers, but restricting pointers to iterator syntax (valid values are NULL, a pointer to an element of the array, and one past the end of the array) makes them checkable. There are checking iterator implementations, so this is possible.
Once the compiler knows what's going on with arrays, subscript checking can be optimized. This is well understood. In particular, subscript checks within for loops can usually be optimized ("hoisted" is the term compiler writers use) so that there's one check at the beginning of the loop, and often that check can be folded into the loop termination condition. So the checking cost in matrix-oriented number-crunching code is usually zero.
There's more to this, and it isn't painless to remove this ambiguity, but if we had a "strict mode", where the checkable forms have to be used, there's a transition path.
If all code running as root had to be in "strict mode", we'd be way ahead.
Mechanical vibrations at 4.5GHz. Just think about that for a moment. A tiny piece of silicon, like a little tuning fork, wiggling back and forth 4,500,000,000 times every second. Without breaking or wearing out. It's not just electrons moving; this is a solid piece of material vibrating.
The big problem with C++ is Strostrup. He's in denial about the fact that the language is fundamentally broken. But he's still influential in C++ circles. Thus, no one else can fix the mess at the bottom.
The fundamental problem with C++ is that it has hiding ("abstraction") without memory safety. This is the cause of most of the world's buffer overflows. No other major language has that problem. C has neither hiding nor memory safety, so it is still vulnerable to buffer overflows, but they're to some extent visible at the place they occur. Pascal, Modula, Ada, Java, C#, and all the interpreted "scripting languages" have memory safety. C++ stands alone as a language where you can't see what's going on, and the compiler doesn't have enough information to check subscripts.
The reaction of the C++ standards committee has been to try to paper over the problems at the bottom with a template layer. That didn't work. The template classes just hide the mess underneath; they don't make the language memory safe. There are too many places that raw pointers leak out and break any protection provided by the templates. The template language itself is deeply flawed, and attempts to fix it have resulted in a collection of "l33t features" understood and used by few, and too dangerous to use in production code.
The fundamental cause of the trouble comes from C's "pointer=array" equivalence. That was a terrible mistake, borrowed from BCPL. The trouble is that the compiler knows neither which variables are arrays nor how big the arrays are. You can't even talk about arrays properly. I mean, of course,
int read(int fd, char* buf, size_t len);
That's just trouble waiting to happen. "read" has no information about how big "buf" is.
C++ added references to C, and should have added syntax like
int read(int fd, char& buf[len], size_t len);
to go along with it, so that arrays became first-class objects with sizes. But it didn't. There are some other things that have to be done to the language to make this concept work, but this is the general idea. This is the elephant in the living room of C++, and Strostrup is in denial about it.
Every time you have another crash from a buffer overflow, every time you install another patch to fix a buffer overflow, every time you have a security break-in from a buffer overflow, think of this.
Wikileaks is back up. I've seen "Fitna"; it looks like a YouTube mashup, zooms over stills and all. There's little original footage.
A much better comment on militant Islamic types, The Burqa Project, is down, though. That's a delightful little piece from 2005 showing three French models running around Paris in flowing, see-through burgas. Google still has thumbnails up, but the video site is now password protected.
As Heinlein liked to point out, religion needs a good belly-laugh once in a while.
the thirty second warning is little better than "duck and cover" if it cannot be communicated effectively.
Actually, a 30 second warning is quite useful, but not to humans. There are such warning systems in California. When the warning system trips, elevators stop at the nearest floor, subways and BART trains stop, gas valves at schools and mobile home parks close, and some hazardous processes shut down.
But the data from that comes from fixed seismic stations, not somebody's random accelerometer.
I'd like to see a similar report on religions. Catholic churches should have warning signage: "No unattended children beyond this point". Religions prone to fanaticism, from Islam to Scientology, need "Warning - Do Not Use More than 1 Hour Daily" to prevent overdosage.
There are far worse things than anything that runs on an XBox 360.
For a brief period, there was DeviceBay. DeviceBay is a standard for slide-in hard drive carriers, with power, USB, and FireWire connectors that mate on slide-in. There's even a mechanical interlock so the computer can keep the device from being pulled until the drive is unmounted. There's full support for DeviceBay in Windows XP.
Never caught on.
The Cell isn't really an exotic parallel machine. It's a regular multiprocessor/multicore machine (like a ten year old desktop Mac) except that some of those processors are special purpose.
No, it's a non-shared-memory multiprocessor with limited memory (256K) per CPU. It belongs to roughly the same family as the nCube, although the Cell has a block DMA-like path to main memory rather than relying entirely on CPU to CPU data paths like the nCube.
It's typically used like a DSP farm; data is pumped through each Cell processor, crunched a little, and pumped out the other side. It's only good for problems that fit that model. Audio guys love it. Physics programmers, not so happy.
What's the point of more residential bandwidth? All most people will do with it is watch TV. Why should national policy be devoted to helping people watch TV, which is a fundamentally nonproductive activity?
Once you get to 1Mb/s or so, you can do everything most residential users do that isn't video-oriented. What's the problem?
The "gigabit connections" of some of the high density countries are illusory. You may have gigabit Ethernet to your apartment, but your 1000-unit apartment complex doesn't have a terabit pipe going out.
We know three kinds of parallelism that work: clusters, shared memory multiprocessors, and graphics processors. Many other ideas have been tried, from hypercubes to SIMD machines, but none have been big successes. The most exotic parallel machine ever to reach volume production is the Cell, and that's not looking like a big win.
Graphics processors are the biggest recent success. They're still very difficult to program. We need new languages. C and C++ have the built-in assumption that all pointers point to the same memory space, and don't address concurrency at the language level at all. That's not going to work. The "dynamic languages" (Javascript, Python, etc.) have too much overhead. Special purpose graphics languages (Renderman, etc.) address the high concurrency issue, but only for a limited class of problems. None of the traditional parallel languages (Occam, etc.) have enough of a user base to make them compelling. Interestingly, what does look promising is compiling Matlab to GPU code; the big matrix operations of Matlab translate well to GPU-type machines, and number-crunching engineers like and use Matlab.
If your problem isn't a good match to either Matlab or RenderMan, though, it's all uphill right now.
Penn and Teller once had a game produced, "Desert Bus", in response to complaints that video games were too violent.
The player gets to drive a bus from Tucson, Arizona to Las Vegas, Nevada in real time at a maximum speed of 45mph. The game cannot be paused. The bus contains no passengers. The road is empty. Nothing happens. If the player makes it to Las Vegas, they score one point. Then a supervisor characters shows up and says "You want to pull a double shift?" The player can then drive back to Tucson. On the return trip, it slowly gets dark. That's it.
If you run off the road, the bus stalls, and eventually a tow truck shows up and tows the bus back to the starting point. In real time.
Somebody got six points once. This is believed to be the record.
Users with strong privacy protections can't get past the stupid ad screen. Find another source, please.
If you're using Amazon for hosting, you can't switch hosting services; their system is too nonstandard. Do you want to be in a position where they can raise prices or cut off your air supply?
give credit where credit is due.
Yes, I posted that on Groklaw too, in slightly different form.
For those of you not following the SCO debacle, the SNCP deal was being pushed as a last desperate attempt to head off what's coming next month:
U.S. District Court - District of Utah Court Calendar
Honorable Dale A. Kimball
Room 220. Tuesday, 04/29/2008 08:30 am. SCO Grp v. Novell Inc 2:04-cv-00139-DAK-BCW Bench Trial
This is SCO's upcoming Really Bad Day. The issue of whether SCO owns the UNIX copyright has already been decided - they lost on that issue. The only issue for trial is how much money SCO owes Novell. Which may be more than SCO has left.
SCO went into bankruptcy late last year to stall that trial, the Friday before the trial was to start on Monday. That didn't work; the bankruptcy court un-stayed the Novell trial. SCO tried the York deal to transfer their assets to York. That didn't work. Now they're trying the SNCP deal, which looks very unlikely at this point.
That's a very funny collection of filings. It doesn't stop with the comments about SCO, either. Remember, the proposed deal now is that Steven Norris Capital Partners (SNCP) proposes to buy SCO's assets for $5 million plus a "loan guarantee" of $95 million at somewhere around 20% interest to cover future claims by IBM, Novell, Red Hat, SuSE, etc. So who is SNCP? The filings tell us.
In filing 412, Novell says "The Disclosure Statement says that SNCP was founded by Steven Norris and & Co. Capital Partners for the purposes of this transaction". So SNCP is a shell corporation. "It has a brief statement about SNCC's partners, Steven Norris and Mark Robbins, and sweeps breezily through a short statement of some of their past activities, making some very general grand claims about their past successes."
In filing 408, IBM points out, "the Partnership (SNCP) does not seem to have any operational or investment history."
Filing 414 points out, "Also, SNACCPLP failed to pay its annual tax assessments, and it thereby allowed its status to lapse to "CEASED GOOD STANDING" back in June 2006 (see Ex. 7). Thus, it is unlikely that the Florida LLC, formed in July 2007 (see Ex. 7), was truly "formed by Stephen Norris & Co. Capital Partners, L.P. for the purposes of this transaction." (Incomplete Disclosure Statement at (V)(B), p. 18)."
This is not looking good.
Steven Norris himself had a great reputation in finance until this month. His big claim to fame was the Carlyle Group. They created Carlyle Capital, which just went spectacularly broke, losing about $21 billion. If the main asset of SNCC is the reputation of Steven Norris, it's worth far less than it was a month ago.
Santa Clara County, California used to have a weather modification program. It's Silicon Valley now, but it used to be a prime agricultural area; it has great topsoil. But it doesn't get quite enough rain.
So, for about thirty years, when rain clouds were passing over but it wasn't raining, the call went out to all the silver-iodide stations to start up their generators. These were basically oil burners that put out a smoke column with silver iodide in it.
It helped a little, enough to be statistically significant, but it wasn't spectacular. Beijing is putting in about 100x the effort to cover about 1/10 the area of the Santa Clare Valley effort, so they might get a useful effect.
The problem is engineering cost, not silicon cost. Most servers have a display controller that will never output to a display, an audio controller that will never be connected to a speaker, and maybe even a 3D graphics engine that will never fill a single polygon.
Mainframes are still around because the engineering is better.
There's no secret about how to do this. It wouldn't even add much cost to servers to do it right. Here's what's needed.
Once you have all that fault isolation, you know which component broke. This produces ongoing pressure for better components. It empowers customers to be effective hardasses about components breaking. With proper fault isolation and logging, you know what broke, you know when it broke, you know if others like it broke, and you probably know why it broke. So you know exactly which vendor needs the clue stick applied. There's none of this "reinstall the operating system and maybe it will go away" crap.