Wrong. Solaris and Win32 were the base platforms for the Oracle database starting roughly in 1999 (maybe even 1998... it's been a while). There was a lot of development done on Windows, because compared to an UltraSparc PCs were three times faster and cost a third as much, and the portability layer insulated you very well from the differences between unix and Win32, thank you very much. There was a lot of hue and cry about everyone not being allowed to upgrade from Office 97 to Office 2000, but a lot of work got done on Windows.
Oracle never owned nCube; it was Larry's personal investment when he bought in. Larry is one of the last few true believers in MMP (massively multiprocessor) architectures, or at least he still was last year.
The big advantage of the nCube for serving video was the massive IO bandwidth between CPU nodes. This allowed you to stripe video across disks connected to each CPU node (for better availability). Of course, these days you can get the same level of disk access from SAN architectures; SANs don't necessarily give you the CPU to CPU bandwidth that the nCube has, but for video serving you don't need that anyway.
Anyway, Oracle had a solution for doing server-side PVR before liquidating its video server group, and I think nCube and/or thirdspace (no, you've never heard of them and you're never going to) is selling this solution now. In 1992, many companies (cable and telco) were promising that they would be installing fiber to the curb or fiber to the home, and Oracle and nCube built a system for delivering 3-ish megabit/second content over that network. RealNetworks and the gaggle of streaming companies that Microsoft bought bet that compression and IP delivery would be dominant over broadband for quite a while, and they turned out to be right.
Animats is right, the server side of this has been done and rewriting it from scratch wouldn't even take that long, but the bit pipe into the home isn't there and isn't going to come any time soon.
I'll second that. Grunts was a truly horrible book, the kind of book that is so bad that it can generate the "simmering antipathy" that hyacinthus names. I followed the link thinking, hey, this might be an interesting book, then saw Gentle's name and winced.
Comparing streaming video compression formats to messaging protocols isn't fair because there is a very real difference in the performance of the formats for video.
MPEG is absolutely the standard for TV-quality video compression (see DVD, DSS, DVB, digital cable, etc.). And there are plenty of companies that build streaming MPEG solutions; I work for one of them. MPEG-1 and MPEG-2 are fine at 1+ Mbps but they look like crap at low (300kbps) bitrates, and getting something decent in the 300-800kbps takes some, uh, clever encoding that has only emerged in the last year. MPEG-4 is a good competitor (G2 and Microsoft's "MPEG-4" codec are both very similar to drafts of MPEG-4), but it isn't a standard yet, and interoperable implementations haven't started appearing yet. Real and Microsoft have done a great job of providing products that work in the insanely bandwidth constrained reality of the internet that most people use. And as capacity has increased an MP-3 server like Napster has caught on for audio streaming.
As the bandwidth goes to DSL/cable modem levels, if MPEG-4 is standardized and works well, I think you can expect to see several companies put out product in that space.
Our legal architecture only provides one definition of guilt: "Beyond a reasonable doubt". IMHO that's not enough when you're going to kill somebody. For the death penalty, you should have to prove guilt beyond even an unreasonable doubt, beyond any damn trace or shadow of a doubt whatsoever.
Beyond a reasonable doubt is the strongest measure you can enforce. An "unreasonable doubt" is the nagging suspicion that it was really aliens that came down, performed the crime, and then framed the accused. It is unreasonable because it is irrational. Capital crimes in the U.S. always have guilt and sentencing determined by a jury, and precisely because there is no chance to say "sorry" after the fact, in theory any juror would want to be quite certain before condemning the accused. In practice, those on death row are disproportionately black and poor, but that is a separate problem, or perhaps several problems.
The American justice and penal systems do not have a Mission Statement of the variety that all our corporate organizations seem so intent on wrting these days. In some order, they are meant to provide:
punishment (from society)
revenge, or retribution (nominally on behalf of the victim)
deterrence to others who might commit a crime
rehabilitation
threat removal (removal from the general population via jail or execution)
Different people have different priorities; your's seems to be threat removal, and that's not a bad one to pick. I think historically the people who have taken the most interest in the system are much more in line with the punishment or revenge angles, and that produces the system that we have.
The 'grisly' angle to capital cases in the U.S. is an important one to note. Capital punishment provides little (well, no) deterrent, rehabilitation, threat removal, or economic advantage compared to life imprisonment without parole. It does, however, provide a measure of revenge. Personally, I somewhat uneasily endorse the death penalty in these cases, and recognize it for the revenge (under the cloak of righteous indignation) that it is.
Carmack is saying that the data is used to model the user community, then by correlating that data with the support requests you can tell which platforms are unusually buggy (or stable). The Slashdot summary is being unfair when it characterizes the data as "...useless for support purposes."
Carmack quote from the LinuxQuake page: "It has mostly been for tracking the amount of support we give by video card vendor. For instance, 3dfx and nvidia are about equal in players, but we get 10x the support email for 3dfx users. [...]"
However, this is addressing the question of usage (and even then only with the "mostly" qualifier), not the question of intent. Based on the datagram, the intent is to be able to model the user community, and it is very similar to the data any website could collect about their user population from http headers.
Slashdot Mirror
Wrong. Solaris and Win32 were the base platforms for the Oracle database starting roughly in 1999 (maybe even 1998... it's been a while). There was a lot of development done on Windows, because compared to an UltraSparc PCs were three times faster and cost a third as much, and the portability layer insulated you very well from the differences between unix and Win32, thank you very much. There was a lot of hue and cry about everyone not being allowed to upgrade from Office 97 to Office 2000, but a lot of work got done on Windows.
As Lessig says, "Something is going terribly wrong with copyright law in America."
Oracle never owned nCube; it was Larry's personal investment when he bought in. Larry is one of the last few true believers in MMP (massively multiprocessor) architectures, or at least he still was last year.
The big advantage of the nCube for serving video was the massive IO bandwidth between CPU nodes. This allowed you to stripe video across disks connected to each CPU node (for better availability). Of course, these days you can get the same level of disk access from SAN architectures; SANs don't necessarily give you the CPU to CPU bandwidth that the nCube has, but for video serving you don't need that anyway.
Anyway, Oracle had a solution for doing server-side PVR before liquidating its video server group, and I think nCube and/or thirdspace (no, you've never heard of them and you're never going to) is selling this solution now. In 1992, many companies (cable and telco) were promising that they would be installing fiber to the curb or fiber to the home, and Oracle and nCube built a system for delivering 3-ish megabit/second content over that network. RealNetworks and the gaggle of streaming companies that Microsoft bought bet that compression and IP delivery would be dominant over broadband for quite a while, and they turned out to be right.
Animats is right, the server side of this has been done and rewriting it from scratch wouldn't even take that long, but the bit pipe into the home isn't there and isn't going to come any time soon.
I'll second that. Grunts was a truly horrible book, the kind of book that is so bad that it can generate the "simmering antipathy" that hyacinthus names. I followed the link thinking, hey, this might be an interesting book, then saw Gentle's name and winced.
Comparing streaming video compression formats to messaging protocols isn't fair because there is a very real difference in the performance of the formats for video.
MPEG is absolutely the standard for TV-quality video compression (see DVD, DSS, DVB, digital cable, etc.). And there are plenty of companies that build streaming MPEG solutions; I work for one of them. MPEG-1 and MPEG-2 are fine at 1+ Mbps but they look like crap at low (300kbps) bitrates, and getting something decent in the 300-800kbps takes some, uh, clever encoding that has only emerged in the last year. MPEG-4 is a good competitor (G2 and Microsoft's "MPEG-4" codec are both very similar to drafts of MPEG-4), but it isn't a standard yet, and interoperable implementations haven't started appearing yet. Real and Microsoft have done a great job of providing products that work in the insanely bandwidth constrained reality of the internet that most people use. And as capacity has increased an MP-3 server like Napster has caught on for audio streaming.
As the bandwidth goes to DSL/cable modem levels, if MPEG-4 is standardized and works well, I think you can expect to see several companies put out product in that space.
Beyond a reasonable doubt is the strongest measure you can enforce. An "unreasonable doubt" is the nagging suspicion that it was really aliens that came down, performed the crime, and then framed the accused. It is unreasonable because it is irrational. Capital crimes in the U.S. always have guilt and sentencing determined by a jury, and precisely because there is no chance to say "sorry" after the fact, in theory any juror would want to be quite certain before condemning the accused. In practice, those on death row are disproportionately black and poor, but that is a separate problem, or perhaps several problems.
The American justice and penal systems do not have a Mission Statement of the variety that all our corporate organizations seem so intent on wrting these days. In some order, they are meant to provide:
- punishment (from society)
- revenge, or retribution (nominally on behalf of the victim)
- deterrence to others who might commit a crime
- rehabilitation
- threat removal (removal from the general population via jail or execution)
Different people have different priorities; your's seems to be threat removal, and that's not a bad one to pick. I think historically the people who have taken the most interest in the system are much more in line with the punishment or revenge angles, and that produces the system that we have.The 'grisly' angle to capital cases in the U.S. is an important one to note. Capital punishment provides little (well, no) deterrent, rehabilitation, threat removal, or economic advantage compared to life imprisonment without parole. It does, however, provide a measure of revenge. Personally, I somewhat uneasily endorse the death penalty in these cases, and recognize it for the revenge (under the cloak of righteous indignation) that it is.
Carmack is saying that the data is used to model the user community, then by correlating that data with the support requests you can tell which platforms are unusually buggy (or stable). The Slashdot summary is being unfair when it characterizes the data as "...useless for support purposes."
Carmack quote from the LinuxQuake page:
"It has mostly been for tracking the amount of support we give by video card vendor. For instance, 3dfx and nvidia are about equal in players, but we get 10x the support email for 3dfx users. [...]"
However, this is addressing the question of usage (and even then only with the "mostly" qualifier), not the question of intent. Based on the datagram, the intent is to be able to model the user community, and it is very similar to the data any website could collect about their user population from http headers.