However, one selling point maybe the fact that this notebook is just $1,499 - which is quite cheap considering the configuration (and the fact that if you are a gamer, it comes with Nvidia's GeForce FX Go 5200 graphics card).
The FX 5200 Go is a SLOW graphic chip today nowadays, even for notebooks (it's still faster than integrated graphics of course). However, this notebook in fact has a FX 5700 Go, which is much, much better - in fact it competes with the ATI Radeon 9700 Mobility for fastest mobile graphic chip (the FX 5700 Go exists in two version, the "performance" version is definitely slower than the mobility 9700, the "desktop replacement" version might about tie it - don't know which version is used here).
But the Pentium 4 3E puzzles me. This thing consumes ~25W more energy (both under full-load and idle) than the old P4 3 Ghz, and it's even slightly slower (most of the time)! Why anyone would include a Prescott P4 instead of a Northwood P4 into a notebook (even if it's not meant to be thin & light) is completely beyond me.
Dual systems usually use Xeon DP, which are a LOT cheaper than Xeon MP (not to mention faster due to the faster FSB, despite having less cache) (the same is also true for the Athlons, the 248 is much cheaper than the 848, in this case the chips though are identical safe the HT links).
That "Xeons cost twice as much" statement is correct for the Xeon MP 3Ghz/4MB cache vs. Opteron 848, which was the primary focus of this article.
Seriously, what's the point? MP3 as a codec is outdated. All new codecs (be it aac, ogg, or even, god forbids, wma9) are a BIG step above mp3 in the quality / compression ratio department.
The only reason why everybody uses MP3 is exactly because of that, everybody uses it! But adding a DRM layer will make it incompatible to all existing (hardware/software) players, so why wouldn't you use a better codec for some shiny new drm scheme?
NO WE BLOODY WELL DON'T!! why dont people RTFM and find out that XFree86 have been writing their own accelerated (yes, 3D as well) drivers for ATI cards since time began... as they release the specs. sure, ati also make their own, but XFree86 also make them. and they also work on FreeBSD. also, incase you didn't notice, the linux kernel even ships with the radeon and ati Direct Rendering Modules.
That's only half the truth. The new ATI cards (those based on R300 and newer, i.e. radeon 9500/9600/9700/9800) have no open-source 3d driver, since ati did not release the specs. The open-source XFree86 radeon driver offers only 2d acceleration for these cards. And I can't see any signs that ATI would release specifications for these soon.
I'll agree with most of your points, but this one is wrong:
PCI express uses a VERY high-speed serial bus to carry the data. How high speed? One serial channel will carry more data than a standard 64 bit 66MHz PCI bus.
PCI 64bit 66Mhz has a transfer rate of 533MB/s (in either direction, but not simultaneously), PCI Express 1x has 250MB/s (in both directions simultaneously, so "combined" bandwidth of 500MB/s). No matter how you look at it, the bandwidth of PCI-Express 1x is not more than PCI 64bit/66Mhz - if you have only traffic in one direction, it's slightly less than half, if you have traffic in both directions it's almost the same (and PCI-Express could be faster maybe because of possibly lower overhead).
Of course, no desktop board today has 64bit/66Mhz PCI bus, all are limited to 32bit/33Mhz which is definitely slower than PCI-E...
I think the OP was refering to the linux kernel version. In fact, given the date of the register article (october 2003) it's probably safe to assume the comparison is against some 2.4.2x kernel. AFAIK the 2.6 kernel though has a quite improved tcp/ip stack, though I'm not sure if it's actually faster or just a cleaner implementation...
So this comparison is meaningless, you might argue that 2.6 isn't quite enterprise ready, but neither is Solaris 10...
This hasn't much to do with "free countries". It's a difference in jurisdiction, sure, but what's wrong with it? "Government abuse" isn't really possible, as the number of "retrials" is very limited (the case goes to a higher level court each time).
Missed? Please don't spread the FUD Nvidia produced further.
Fact is, pretty much every review site was at this Nvidia Editors Event where Nvidia accused ATI of cheating. Yet nobody except tom's hardware published it, why do you think they didn't? Maybe because they checked the facts first?
Ok, I'll address it point for point:
1. The UT2k3 issue: Yes, it's true that detailed textures are missing. To say it's a cheat is greatly exaggerated - it is caused by the (non-standard) default LOD bias (0.8) UT2k3 uses which causes the highest detail level never to be used. This is known since at least december 2002. You can change the LOD back to default (it's a bit unsure why EPIC chose a higher LOD anyway) in the.ini file, you'll lose something like 0.9% performance (btw nvidia loses slightly more if you change the LOD backs, some sites have measured it) and everything will look as it should. It's probably a bug in ATI's driver, but not even close to a cheat.
2. Aquamark: It's true the image rendered isn't entirely correct (neither is Nvidia's, btw), some areas are too dark. However, Tom's states "It seems that ATi's driver doesn't continue to fade out the textures until the blending ends, instead simply cutting out certain textures when a certain degree of fade-out is reached. This obviously saves memory bandwidth, leading to a higher framerate" - which is complete BS.
3. Halo: People tried to look for some discrepancies in the rendering output of ATI's graphic cars, but didn't found anything. Without ANY evidence, this makes this accusation plain FUD.
It's a really sad (maybe desperate) move from nvidia - they more or less openly continue to uhm, "optimize" for certain benchmarks (despite their optimization guidelines which aren't worth the paper they are printed on) and accuse competitors of cheating without any proof (in fact, I'm sure they KNEW those were no cheats, but simple bugs), though they didn't actually accuse ATI of cheating directly (simply saying there are "issues" with ATI's drivers), and let toms hardware do it instead.
You might also want to read ATI's response on these accusations (and some discussion about it) at beyond3d.
It's curious to me that large instruction words are considered inefficient when applied to EPIC but are efficient when applied to RISC.
I didn't say EPIC is inefficient because of large instruction words.
By scaling, the original author is correct. You simply don't understand his use of the word "scaling". He's referring to the ability of future processors to achieve higher performance through the same instruction set, not how many processors you can add to an MP box.
Possible I didn't understand what he meant with scaling, he probably should have made it a bit clearer (rereading it I'm pretty sure he refered to clockspeed), there are many ways you can use that word... But even then, I'd still say it's not true. It should be easy to add even more parallel execution units to the Itanium core, true, but that doesn't mean you get some decent performance improvement out of it (you'd need even better compilers). In case of the x86 chips, adding more execution units is just as simple, but instead of better compilers you need better scheduling logic (that's probably not an easier problem than better compilers, just different).
EPIC needs time to mature.
Maybe. But it's not really new any more, plus intel invested huge amounts of money developing it, so it should be quite mature by now already. Just hoping that the architecture will have an advantage in the future if you want to buy some server now doesn't sound like a very wise business decision.
Itanium is not held back by architecture but by process. With a 130nm process, Itanium is as fast as a Pentium 4 3.2Ghz in integer and far faster in floating point.
I really don't understand that. The Pentium 4 and the Itanium 2 use the same 130nm process (well as far as we know, I don't think there is information available if it's EXACTLY the same process), so what's the point? Both should scale to higher frequencies just as well with newer process technologies (yes I've heard of the rumoured trouble intel is having with the Prescott P4, but there is absolutely zero reason to believe a die-shrinked Itanium wouldn't suffer from the same problems).
Can't agree there. It's certainly not as bad as the first Itanics made it look, it has lots of interesting ideas, but overall it seems the architecture didn't reach the goals intel probably had.
Itanium requires good compilers. For now, that means compilers from Intel.
Certainly. However, it looks like it is very, very hard (if not impossible) to write a good compiler for it - intel certainly invested a LOT of time and money, and increased performance quite a bit (quite a bit of the performance difference in published spec scores between itanium 1 and 2 is just because of a newer compiler), but if rumours are true the compiler still isn't quite that good - after what, 5 years?
Lots of cache means lots of transistors means lots of heat.
Not quite true. Cache transistors aren't very power hungry - look at P4 vs. P4EE with an additional 2MB L3 cache, the power consumption hardly changed (5W or so isn't much compared to the total of 90W).
Intel is not fabbing Itanium with a state of the art process.
Well, their 130nm process sounds quite good to me. Nobody really uses much better process technologies yet - AMD might have a slight edge with their 130nm SOI process, which should help a bit with power consumption.
Itanium is "inefficent". This couldn't be further from the truth. At 1.5Ghz, it whoops *anything* else in SPECfp (by a margin of 1.5x or more) and matches the 3.2Ghz P4 or 2.2Ghz Opteron in SPECint.
The itanium makes up for its inefficiency with large caches (compared to P4 / Opteron). Compare the dell poweredge 3250 spec results with 1.4Ghz/1.5MB cache and 1.5Ghz/6MB cache, otherwise configured the same (unfortunately using slightly older compilers, so don't take the absolute values too seriously). The smaller cache (which is still more than Opteron/Pentium4 have) costs it (factored in the 6% clock speed disadvantage) about 20% in SpecInt (making it definitely slower than Opteron 146 and Pentium4, even considered the results would be higher with the newer compiler). In SpecFp it's about the same 20% difference, which means it still beats P4 and Opterons, but no longer by such impressive margins.
Itanium doesn't scale. Wrong again.
I'm too lazy to check the numbers, but the Itanium has a shared bus - granted, with quite a bit of bandwidth, but still shared (similar to the P4). 2 CPUs should scale well, 4 shouldn't be that bad, and after that you can forget it (meaning your 64 cpu boxes will be built with 4-node boards). The Opteron will scale much better beyond 4 nodes - its point-to-point communication is probably overkill for 2 nodes, should show some advantages with 4 nodes, and scale very well to 8 nodes - too bad nobody builds 8-node Opteron systems...
Or do you mean scaling with clockspeed? In that case, the bigger the cache and the faster the system bus and ram, the better will it scale, but the cpu architecture itself is hardly a factor.
Itanium uses *fewer* transistors and does *more* instructions per clock than a RISC architecture.
Unfortunately I haven't seen any transistor numbers of a Itanium2 core. But I think it's not true. The Itanium saves some logic on instruction decoder, but has more execution units in parallel (which should lead to better performance, but ONLY IF it's actually possible to build a well optimizing compiler which manages to keep the execution units busy, and it's completely feasible that this is just not possible in the general case).
EPIC scales better than RISC architectures.
I really don't think this is true. Scaling is independant from the cpu core architecture.
I will agree that EPIC (which, btw, isn't quite intels invention, it shares most of the ideas with VLIW) is a nice concept, but for some reason it just doesn't work in practice as well as it should.
I've personally fried a board by reattaching the PS2 mouse while the system was running - neither mouse nor keyboard worked afterwards.
That said, "fried a board" is not entirely accurate - all (?) boards have a fuse for the PS2 ports, which I just replaced (typically these are soldered microfuses, hard to spot and need soldering to replace, but certainly doable).
And I'll have to add it was an old board (the legendary asus p55t2p4, the ps2 mouse port was only optional), I've reattached ps2 mice to newer boards without incident.
This comparison is exectued really, really poorly - the results gathered are completely meaningless.
1. He uses completely different systems (in favor of the IDE system). Though, if he's picked a task which is really I/O dependant, it shouldn't matter much - but without further analysis, you can't know that.
2. MUCH more important: What about file system types? Both the same or not? Couldn't find that information. This alone could probably account for a VERY large difference between the tested systems.
3. Similar to 2, partition size. Depending on the file system used, could have a very large performance impact - e.g. a smaller partition might have fewer inodes (or in case of FAT based systems, might use 32KB instead of 4KB blocks)!
That said, I have no trouble to believe that, if the test setup would be properly configured, the SCSI drive would still be faster. But, I'd say that's because of the harddisk itself, and has not much to do with the interface. SCSI drives rock in access times (doesn't have anything to do with SCSI, just with the market the drives are built for), which is very important for accessing lots of small files - transfer rate is just no factor. The difference in cache size could also make a bit of a difference.
(SCSI has of course other advantages too, it's possible to have 15 devices on one bus, it has that nice disconnect feature, it still causes slightly less cpu load (though I'm not sure that's SCSI inherent or just because of better / more expensive controllers), but these don't matter in the context of this "comparison".)
The article has some more funny things:
Note that the controller is an Ultra160 and is a 64-bit card put into 32-bit PCI slot. The drive itself is an Ultra320. The speed increase would be higher if I were to purchase an Ultra320 controller with a motherboard that supports 64-bit PCI slots.
Don't think so. PCI-64 will help if running multiple drives together with Gigabit NICs or something similar - but the drive alone can push only 66MB/s so there won't be any performance increase by using a faster controller.
Also remember ohmic heating is proportional to the square of the clock speed
This is not true. Power dissipation is linear to clock speed - it is square to the voltage.
And, in fact, that's not the whole story either. Today, current leakage is a very serious issue (I haven't seen concrete numbers for 90nm process technology, but the leakage gets larger the smaller process technology you use, and the power dissipation due to leakage gets comparable to the power dissipation due to the transistor switching), and the current leakage is completely independant of clock speed. So, part of the whole power dissipation is independant of clockspeed, and the other part scales linearly with clockspeed.
It looks like the stock market didn't follow sco's logic neither - down 9% today (could of course be because of other things going on, but this is the only sco story today I've seen so far...)
You must confuse that with KT333. KT133A was really not that good, at least not the southbridge that came with it, for instance non-existant pci performance, problems with the ide interface (eventually bios updates fixed the data corruption issues at the cost of even worse pci performance).
SSE is single-precision (32bit) floats only, so pretty useless for scientific calculations (usually require doubles).
However, I believe the intel compiler uses SSE2 (which can handle 64bit floats) exclusively for float code, since the P4 legacy fpu is just slow. Of course there are compiler switches for the compiler so the code also runs on good old Athlon, Athlon XP, PIII (which lack SSE2, the Athlon also lacks SSE) - and those aren't exactly slow doing float calculations neither.
Pretty much all cards with dvi connectors can do 1600x1200 per connector nowadays, though it should be mentioned that all consumer ati radeon cards only have one dvi connector. However, all newer Matrox cards (Parhelia, P650, P750) as well as some nvidia consumer cards, including dirt cheap GeForce4MX (not all of them have two dvi ports of course, but some do) can easily do 1600x1200 with both dvi connectors.
However, the FX2000 (and FX3000, but no older nvidia workstation graphic cards) indeed have an advantage in that area - all other cards have dvi ports which can do a maximum of 1600x1200 (at 60Hz), because they all use so-called single-link TMDS transmitters. The FX2000 and FX3000 however have one single-link and one dual-link port (thus 1600x1200 on one monitor but 2048x1536 on the second monitor).
No, you can't disable RPC in w2k (well you can but almost nothing will run afterwards, not even the service manager which you need to get RPC working again, thank god regedit still runs...). Though I wouldn't call this a useless service, it is really needed by design. You can, however, easily disable DCOM (with w2k only sp3 or later) on your non-networked box, which should fix that RPC hole too if I read that advisory correctly (same workaround as with the last rpc vulnerability, the two bugs seem to be really almost exactly the same).
Must have been a very old monitor. This "too high frequencies can destroy monitors" is more urban myth than anything else nowadays. You can destroy your 20 year old 12" vga monitor, perhaps even very early multisync monitors, but I'm confident it won't work on any monitor built in the last 10 years or so - they'll just switch off, giving you that "hsync out of range" (or similar) message.
Contrary to the hysterical claims you read in/., Europe is not free of software patents now.
It is true that a lot of software patents were already granted by the EPO. However, they were granted clearly against the letter of the current directive. The funny thing is, the EPO says something along the lines they are expecting a newer directive to allow software patents so they grant them already, and in this new directive exactly these existing software patents are now used to show that the new directive is merely here to preserve the status quo...
However, I'm not aware of ANY lawsuits concerning any of those software patents. IMHO nobody is crazy enough to sue someone else, because chances are the courts would just invalidate the patent (because it contains just non-patentable stuff according to the law). Remember, the patent office GRANTS the patent, but the COURT decides if it is VALID.
Recently? That post was done in October last year according to the time stamp.
No, you got that wrong. Oct 2002 is the date Catalyst Maker registered, the post was made Aug 11, 2003 - I'd call that recently...
And ATI Linux drivers are *still* horrible. I'm yet to be able to properly play a game on my 8500. Neverwinter Nights client locks up at the title screen, Unreal Tournament has some really weird artifacts...hmm...I haven't tried any other games, but as we all know, the choices are not plentiful. Not to mention I can't use tv out...
You should try the drivers here: http://www.schneider-digital.de/html/download_ati. html . This site has always newer drivers than ATI's own site, and the latest driver apparently fixed the nwn lockups (on 8500/9000 cards) for some people. (Though currently there is an even newer driver available than that at the suse download site.)
That's certainly not to say the drivers are perfect, however they do get better.
MS removed both JNI and RMI. They also altered some core classes, though iirc they just added some features to them (which would of course cause programs to fail on the true java version if you used those features).
Slashdot Mirror
But the Pentium 4 3E puzzles me. This thing consumes ~25W more energy (both under full-load and idle) than the old P4 3 Ghz, and it's even slightly slower (most of the time)! Why anyone would include a Prescott P4 instead of a Northwood P4 into a notebook (even if it's not meant to be thin & light) is completely beyond me.
Dual systems usually use Xeon DP, which are a LOT cheaper than Xeon MP (not to mention faster due to the faster FSB, despite having less cache) (the same is also true for the Athlons, the 248 is much cheaper than the 848, in this case the chips though are identical safe the HT links).
That "Xeons cost twice as much" statement is correct for the Xeon MP 3Ghz/4MB cache vs. Opteron 848, which was the primary focus of this article.
Seriously, what's the point? MP3 as a codec is outdated. All new codecs (be it aac, ogg, or even, god forbids, wma9) are a BIG step above mp3 in the quality / compression ratio department.
The only reason why everybody uses MP3 is exactly because of that, everybody uses it! But adding a DRM layer will make it incompatible to all existing (hardware/software) players, so why wouldn't you use a better codec for some shiny new drm scheme?
Of course, no desktop board today has 64bit/66Mhz PCI bus, all are limited to 32bit/33Mhz which is definitely slower than PCI-E...
I think the OP was refering to the linux kernel version. In fact, given the date of the register article (october 2003) it's probably safe to assume the comparison is against some 2.4.2x kernel. AFAIK the 2.6 kernel though has a quite improved tcp/ip stack, though I'm not sure if it's actually faster or just a cleaner implementation...
So this comparison is meaningless, you might argue that 2.6 isn't quite enterprise ready, but neither is Solaris 10...
This hasn't much to do with "free countries". It's a difference in jurisdiction, sure, but what's wrong with it? "Government abuse" isn't really possible, as the number of "retrials" is very limited (the case goes to a higher level court each time).
Missed? Please don't spread the FUD Nvidia produced further. .ini file, you'll lose something like 0.9% performance (btw nvidia loses slightly more if you change the LOD backs, some sites have measured it) and everything will look as it should. It's probably a bug in ATI's driver, but not even close to a cheat.
Fact is, pretty much every review site was at this Nvidia Editors Event where Nvidia accused ATI of cheating. Yet nobody except tom's hardware published it, why do you think they didn't?
Maybe because they checked the facts first?
Ok, I'll address it point for point: 1. The UT2k3 issue: Yes, it's true that detailed textures are missing. To say it's a cheat is greatly exaggerated - it is caused by the (non-standard) default LOD bias (0.8) UT2k3 uses which causes the highest detail level never to be used. This is known since at least december 2002. You can change the LOD back to default (it's a bit unsure why EPIC chose a higher LOD anyway) in the
2. Aquamark: It's true the image rendered isn't entirely correct (neither is Nvidia's, btw), some areas are too dark. However, Tom's states "It seems that ATi's driver doesn't continue to fade out the textures until the blending ends, instead simply cutting out certain textures when a certain degree of fade-out is reached. This obviously saves memory bandwidth, leading to a higher framerate" - which is complete BS.
3. Halo: People tried to look for some discrepancies in the rendering output of ATI's graphic cars, but didn't found anything. Without ANY evidence, this makes this accusation plain FUD.
It's a really sad (maybe desperate) move from nvidia - they more or less openly continue to uhm, "optimize" for certain benchmarks (despite their optimization guidelines which aren't worth the paper they are printed on) and accuse competitors of cheating without any proof (in fact, I'm sure they KNEW those were no cheats, but simple bugs), though they didn't actually accuse ATI of cheating directly (simply saying there are "issues" with ATI's drivers), and let toms hardware do it instead.
You might also want to read ATI's response on these accusations (and some discussion about it) at beyond3d.
Or do you mean scaling with clockspeed? In that case, the bigger the cache and the faster the system bus and ram, the better will it scale, but the cpu architecture itself is hardly a factor. Unfortunately I haven't seen any transistor numbers of a Itanium2 core. But I think it's not true. The Itanium saves some logic on instruction decoder, but has more execution units in parallel (which should lead to better performance, but ONLY IF it's actually possible to build a well optimizing compiler which manages to keep the execution units busy, and it's completely feasible that this is just not possible in the general case). I really don't think this is true. Scaling is independant from the cpu core architecture.
I will agree that EPIC (which, btw, isn't quite intels invention, it shares most of the ideas with VLIW) is a nice concept, but for some reason it just doesn't work in practice as well as it should.
I've personally fried a board by reattaching the PS2 mouse while the system was running - neither mouse nor keyboard worked afterwards.
That said, "fried a board" is not entirely accurate - all (?) boards have a fuse for the PS2 ports, which I just replaced (typically these are soldered microfuses, hard to spot and need soldering to replace, but certainly doable).
And I'll have to add it was an old board (the legendary asus p55t2p4, the ps2 mouse port was only optional), I've reattached ps2 mice to newer boards without incident.
1. He uses completely different systems (in favor of the IDE system). Though, if he's picked a task which is really I/O dependant, it shouldn't matter much - but without further analysis, you can't know that.
2. MUCH more important: What about file system types? Both the same or not? Couldn't find that information. This alone could probably account for a VERY large difference between the tested systems.
3. Similar to 2, partition size. Depending on the file system used, could have a very large performance impact - e.g. a smaller partition might have fewer inodes (or in case of FAT based systems, might use 32KB instead of 4KB blocks)!
That said, I have no trouble to believe that, if the test setup would be properly configured, the SCSI drive would still be faster. But, I'd say that's because of the harddisk itself, and has not much to do with the interface. SCSI drives rock in access times (doesn't have anything to do with SCSI, just with the market the drives are built for), which is very important for accessing lots of small files - transfer rate is just no factor. The difference in cache size could also make a bit of a difference.
(SCSI has of course other advantages too, it's possible to have 15 devices on one bus, it has that nice disconnect feature, it still causes slightly less cpu load (though I'm not sure that's SCSI inherent or just because of better / more expensive controllers), but these don't matter in the context of this "comparison".)
The article has some more funny things: Don't think so. PCI-64 will help if running multiple drives together with Gigabit NICs or something similar - but the drive alone can push only 66MB/s so there won't be any performance increase by using a faster controller.
Just because some reviewers have a P4EE doesn't mean it's available... Should be available in November afaik, with a price tag of 925 USD.
And, in fact, that's not the whole story either. Today, current leakage is a very serious issue (I haven't seen concrete numbers for 90nm process technology, but the leakage gets larger the smaller process technology you use, and the power dissipation due to leakage gets comparable to the power dissipation due to the transistor switching), and the current leakage is completely independant of clock speed. So, part of the whole power dissipation is independant of clockspeed, and the other part scales linearly with clockspeed.
It looks like the stock market didn't follow sco's logic neither - down 9% today (could of course be because of other things going on, but this is the only sco story today I've seen so far...)
You must confuse that with KT333. KT133A was really not that good, at least not the southbridge that came with it, for instance non-existant pci performance, problems with the ide interface (eventually bios updates fixed the data corruption issues at the cost of even worse pci performance).
SSE is single-precision (32bit) floats only, so pretty useless for scientific calculations (usually require doubles).
However, I believe the intel compiler uses SSE2 (which can handle 64bit floats) exclusively for float code, since the P4 legacy fpu is just slow. Of course there are compiler switches for the compiler so the code also runs on good old Athlon, Athlon XP, PIII (which lack SSE2, the Athlon also lacks SSE) - and those aren't exactly slow doing float calculations neither.
Pretty much all cards with dvi connectors can do 1600x1200 per connector nowadays, though it should be mentioned that all consumer ati radeon cards only have one dvi connector. However, all newer Matrox cards (Parhelia, P650, P750) as well as some nvidia consumer cards, including dirt cheap GeForce4MX (not all of them have two dvi ports of course, but some do) can easily do 1600x1200 with both dvi connectors.
However, the FX2000 (and FX3000, but no older nvidia workstation graphic cards) indeed have an advantage in that area - all other cards have dvi ports which can do a maximum of 1600x1200 (at 60Hz), because they all use so-called single-link TMDS transmitters. The FX2000 and FX3000 however have one single-link and one dual-link port (thus 1600x1200 on one monitor but 2048x1536 on the second monitor).
No, you can't disable RPC in w2k (well you can but almost nothing will run afterwards, not even the service manager which you need to get RPC working again, thank god regedit still runs...). Though I wouldn't call this a useless service, it is really needed by design. You can, however, easily disable DCOM (with w2k only sp3 or later) on your non-networked box, which should fix that RPC hole too if I read that advisory correctly (same workaround as with the last rpc vulnerability, the two bugs seem to be really almost exactly the same).
Must have been a very old monitor. This "too high frequencies can destroy monitors" is more urban myth than anything else nowadays. You can destroy your 20 year old 12" vga monitor, perhaps even very early multisync monitors, but I'm confident it won't work on any monitor built in the last 10 years or so - they'll just switch off, giving you that "hsync out of range" (or similar) message.
However, I'm not aware of ANY lawsuits concerning any of those software patents. IMHO nobody is crazy enough to sue someone else, because chances are the courts would just invalidate the patent (because it contains just non-patentable stuff according to the law). Remember, the patent office GRANTS the patent, but the COURT decides if it is VALID.
That's certainly not to say the drivers are perfect, however they do get better.
MS removed both JNI and RMI. They also altered some core classes, though iirc they just added some features to them (which would of course cause programs to fail on the true java version if you used those features).