Intel tried a server chip about 5 years ago with an integrated memory controller, and they finally ditched it. Why? Because the upgrade path for memory technologies changed too damn much.
Maybe intel didn't succeed (though I don't know what project you're talking about), but the sun UltrasparcIII also has an on-chip memory controller. And as you should know those chips might not be the fastest, but they scale pretty damn well to a bazillion of cpus!
And, you don't need that many versions of the same chip since memory _technologies_ don't change that often (EDO, sdram, rdram, ddr and ddr2 cover about 10 years). So one chip for DDR200-DDR400, one for DDRII. Though if higher speed memory of the same type is introduced, the chip might need revalidation and a new stepping might be needed - but new steppings are done anyway (the P4 Northwood already has 3 steppings). And guess what? DDRII533 won't magically work on your existing P4 board either. And how much people upgrade the board so they can use the fastest ram but don't upgrade the cpu?
Move to a high speed packetized serial FSB
You could call AMD's I/O links (hypertransport) exactly that, except that they are not used for ram access.
Wrong. ATI's (binary only) drivers support 8500 and newer cards (though they don't have an official XFree86 4.3 driver yet, and the unofficial one will just lock up on the 8500/9000 with nwn).
The open-source dri driver (also included in xfree 4.3) supports cards up to 8500/9000/9100/9200 (including all older cards, but not newer ones). Though there are some issues currently with nwn, you have to switch TCL off to get correct lighting and to avoid texture flickering (not all people seem to be affected by the latter problem though).
I've personally analyzed the data from the driver (since I'm writing one), and they totally favor ATI with the heavy use of PS 1.4 shaders. In fact, the data changes completely if PS 1.4 support isn't claimed. (3x more geometry is sent)
You don't need to "analyze the data" to figure this out. futuremark themself stated how much PS 1.4/2.0 shaders are used. And that 3x times more geometry figure if you don't support PS1.4 is correct - guess why? If you do a fallback to PS1.1 (which 3dmark03 does if your hardware doesn't support 1.4) you need multiple passes, so the geometry data needs to be sent 3 times...
Also, PS 1.4 shaders don't always translate 'up' to PS 2.0 hardware very well
bull****. PS1.4 and PS2.0 shaders are actually very similar, PS2.0 shaders can be much longer and support some things PS1.4 shaders don't.
The only vendor that natively supports PS 1.4 is ATI.
Well, PS1.4 is a feature of DX8.1. And the GeForceFX supports PS 1.4 just as natively as the Radeon 9500 and up - both of them don't have dedicated hardware for PS1.4. The only cards which benefit from that are the Radeon 8500/9000/9100/9200, and regardless of that, the GeForce4Ti which do not support PS1.4 (nvidia's decision - why blame futuremark?) are still faster than those.
They should have created PS 1.1 shaders for the masses, and then if 2.0 hardware is detected, had 2.0 shaders for everything.
They DO have PS1.1 for the masses (the fallback from the PS1.4), you just can't do the effects in a single pass with PS1.1, which is why there are PS1.4 shaders. And converting the PS1.4 shaders to PS2.0 wouldn't change the speed they'd run on the FX (or the Radeon 9500 and up) anyway, but would just make it unable to run the them on older hardware.
It's sad the OEMs put alot of stock in 3Dmark, they don't seem to realize that gamers play games all day, not benchmarks.
A valid argument, but unfortunately no game today is even close to really depend (performance-wise) on the DX9 features of the newest graphic cards available. Not even the upcoming DoomIII will really depend on those features (all it requires is PS1.4 equivalent (remember, it's OpenGL) to do everything in a single pass).
Re:Hopefully Mozilla Mail POP3 bug is fixed
on
Mozilla 1.4 RC1
·
· Score: 1
Works here fine with user@domain too, so this is a no-problem - at least if the user can figure out he has to put the domain name in the user name.
I'll probably having a hard time to argue against JC, but here it goes: assumed shader precision is NOT 32 bit, both DX9 and ARB_fragment_program require 24bit floats as a mininum.
mczak
Yes the GF FX supports PS 1.4 since PS2.0 supersets PS1.4. But it doesn't have _native_ support (separate hardware for PS1.4).
the radeon 9500/9600/9700/9800 (r3x0 chips) don't have native support for PS1.4 neither. And in contrast to nvidia, they don't even have native PS 1.1-1.3 support - all code runs through the same execution units.
Any card which can run PS1.3 shaders can run PS1.4 shaders with performance hit.
Not true. There is only downward compatibility, not upward. The reason the 3dmark game tests still run is because they have alternate shaders, only using PS 1.1 (which is almost the same as PS 1.3, the difference being some quite exotic functions were added). But running 1.1 shaders has a performance hit in this case, as you need to do now multiple passes (because the maximum shader length for instance is shorter).
Sure, but if PS1.4 can do the trick then it's DX8.1 demo and not DX9 demo. The problem is that Futuremark claims that 3DMark03 is all about DirectX9.
Just as much as 3dmark01se is a DX8 benchmark (only 1 of 4 game demos really used DX8 technology). Plus, if you've run 3dmark03 on a DX8 card, you know that you probably only want to run it on a DX9 card...
oh nice, an ac insulting me (i know i shouldn't respond but I just can't resist). May I suggest you read some reviews (for instance at www.beyond3d.com, though the technical information there is probably slightly above what you're able to understand) instead of just citing nvidia PR?
- extended Pixel and Vertex shaders 2.0 (supported only by GeForceFX)
The extended Pixel and Vertex shaders which are supported only by the FX are nice, but pretty much the only advantage they have is the shaders can be longer. How useful is that if the FX can't even execute the standard shaders at a reasonable speed? (This feature is interesting for developers though, and probably non-gaming apps, but no game in the useful lifetime of the current FX chips will ever use it).
- Game 2: vertex shader 1.1 and pixel shader 1.4 (which isn't natively supported by NVIDIA cards)
So you blame futuremark that NVIDIAs cards don't have native 1.4 capability? And, btw, if a card has support for a specific shader version it is required to support all shader versions below. If nvidia can't do it fast, well that's their fault.
You just seem to restate Nvidias criticism of the benchmark, it's almost word-identical. Even though Nvidia are actually very lucky that 3dmark03 does not use _more_ 2.0 pixel shaders, as they are only about HALF as fast as ATI in that case (look at the non-cheated Game Test 4 results, the other game tests are quite close but Nvidia gets slaughtered at this).
If you _really_ want to blame someone else than Nvidia, then don't blame futuremark, but MS instead (for requiring FP24 precision instead of only FP16 in DX9, as the FX chips can only do FP16 and FP32 and are quite a bit slower with FP32 than FP16).
You got that wrong. ATI (R3x0)_always_ does FP24 (internally), the FX can do FX12, FP16, FP32. FP32 has quite a large performance hit (not because the calculations themselves are actually slower, but because double the amount of registers are needed). Unfortunately for Nvidia, DX9 requires FP24, so the GFFX would need to do FP32 all the time, even though performance wise the FX hardly competes even if it only uses FP16.
no, ATI also cheated, though on a MUCH smaller scale than nvidia. They also exchanged the complete shader (recognizing it by name or something like that), even though the exchanged shader delivered the same result (unlike nvidia, their shaders deliver different results, plus they have those really evil clip plane / buffer clear cheats).
You could argue that replacing complete shaders is optimizing (as long as the shader delivers the same output)and you could be right if this would be a game. However, the 3dmark03 licence clearly says that this is a cheat.
So, no, IMHO ATI shouldn't leave this optimization in there (they have already stated it will be gone in the next driver). If you mean with "broaden the scope of the optimization" that they put in an optimizer which could reorder instructions in a generic way then yes, that would be nice (AFAIK they already have such an on-the-fly optimizer, but it's probably not going to achieve as good results as manual tuning).
I don't doubt privoxy has more powerful capabilities than mozilla for those things, but you've picked an example which even mozilla 1.0 can do.
user_pref("browser.block.target_new_window", true) does the trick (though last time I checked that option still wasn't in the gui, at least in mozilla 1.3 you can now edit it directly in about:config).
you're forgetting this is not a 900Mhz bus. It's a quad-pumped 225Mhz bus. You could say this is equivalent, but of course the multipliers are different (this is similar to the P4 quad-pumped PSB400 which is a 100Mhz bus). So, a 2Ghz chip will get a multiplier of 9, 2.5Ghz will get 11 (though the math is slightly wrong).
And there wouldn't be much advantage of an even faster bus anyways, since it's already very fast (for a desktop bus system at least, slightly faster than the soon-to-be-announced PSB800 P4, and more than double the speed of the not-yet-confirmed FSB400 (200x2) Athlon XP.
So, if you're going to claim unbreakable encryption, you'd better hand me a proof that P!=NP.
Well, today's encryption are ALL breakable (except the OTP), from a theoretical viewpoint. If you prove P!=NP, that doesn't make them unbreakable - it just means you can stop searching for an algorithm which breaks them in polynomial time. So, from a theoretical viewpoint, it doesn't matter if P=NP or P!=NP, if you can break an encryption under one assumption you can also break it under the other (but, of course, probably with different time requirements).
The cpu isn't really a new design. There is some evidence this is the evolution of the PIII, at least the benchmark numbers support this theory perfectly well. The weakest point of the PIII was its limited front side bus bandwidth, so the Pentium-M gets a new bus interface (looks similar to the bus interface of the P4). In addition, the Pentium-M also has the SSE2 instructions, and some power saving features were added.
mczak
Another example is Compaq's upcoming EV7 (Alpha 21364), which also uses 8 channels to support massive bandwidth requirements and to keep latencies down
true, but you could also do this with ddr (though it might be harder). The AMD Opteron will do this (albeit only 2 channels per cpu, so a 4-way system would have 8 channels of ddr ram, is the 8 channels figure above per cpu?)
Besides, DDR SDRAM can't sustain its peak bandwidth even close to as well as RDRAM. Bursting isn't sustained bandwidth.(Remember, to transfer a byte, you have to transfer a QWORD. To transfer the next byte, you have to wait an entire clock cycle). Therefore, it only really allows 1/4 the peak bandwidth in this case
this is clearly wrong. The sustained data rate of ddr ram is very close to the theoretical peak throughput (the famous STREAM benchmark shows it, you can also use SiSoft Sandra which uses a variant of stream). In fact, it's closer to the theoretical maximum than rdram.
Generally RDRAM comes with two channels, while DDR generally comes with one.
True. But you can easily get a E7205 (aka Granite Bay) board with dual channel ddr (and it can only run them at ddr 266 speeds, so it gets a lot cheaper). Benchmark shows this dual channel ddr 266 board is around as fast as the i850e with dual channel 1066 rdram (which makes sense - same bandwidth).
Definitely second this. It can't play *anything* (well maybe it can but I couldn't find something it likes - really). Won't even play divx movies!
However, I didn't compile it myself, just looked around and somebody provided suse 8.1 binaries (rpm didn't like it - but you know --nodeps always helps).
mczak
and, additionally, UT2003 doesn't even qualify as a "true" DX8 game either. UT2003 doesn't use pixel shaders at all, and vertex shaders only to speed some things up (you can switch them off - looks exactly the same, and performance is still almost the same).
This is quite a different situation. As others have mentioned, since there won't be any PC games that really take advantage of DirectX 9 level features for months yet, ATI's "lead" is purely imaginary at this point
and exactly how is this different?
The GeForce didn't really have features that were used by games at that time neither. Sure it had hardware TnL, but this could easily emulated by software (and the games of that timeframe didn't even suffer a performance hit because they were typically fillrate limited and didn't have that many polygons).
GeForce also could do 32bit rendering, the Voodoo not - again, this didn't cause any games to fail (btw even now I think all games still can run at 16bit color). I won't argue that games look better if the rendering is done in 32bit instead of 16bit - a similar situation to today, you can crank up FSAA and AF levels on the R9700, but not on the GeForce4 (without massive slowdowns).
Also keep in mind that Nvidia has been making the (painful) switch to 0.13 Micron for the GeForce FX. In a few months, ATI is going to be stuck in a situation where it needs to make this switch as well to stay competitive, and then we'll see how good each company's timing is.
Both ATI and Nvidia don't make their chips themselves, instead TSMC (and UMC)does it for them. So, if the problems Nvidia had are really with the 0.13um process of TSMC, then ATI won't face them - simply because TSMC has fixed the problems. If the problems Nvidia had are not really directly manufacturing related, but instead design-related, ATI might also suffer from them in the future - but honestly I don't think designing a chip for 0.13um is really that much different than designing a chip for a 0.15um process. If rumors are true, the tape-out of the next-gen vaule/mobile chip of ATI (the RV350) built on a 0.13um process is already completed, so I don't expect problems there.
I'd still agree with you that the situation really is different and not directly comparable to the 3dfx fiasco. 3dfx basically failed to innovate for 3 chip generations, not only one. The voodoo2 basically was the same as voodoo1 at higher clock speeds and with a second (seperate chip!) texture unit, the voodoo3 was still the same 3d-wise, just integrated the 3 chips of the voodoo2 into one and included a 2d-core, at even higher clock speeds (not to say it wasn't a good card, it just added nothing new). Then came the Voodoo4/5 - it was late, 3dfx was already in trouble and guess what? Still mostly the same 3d core (except it could do 32bit color, but you couldn't call that revolutionary at that time). The supposed next-gen chip of 3dfx (rampage?) probably would have been really revolutionary if all rumors are true...
There were other problems at 3dfx, not related to their 3d-chips at all too.
No, the submitter is probably right. There are several cards with the Rage Pro name, the rage fury pro uses a compeletely different chip (r128) than the original rage pro (mach64). It should beat the TNT-based cards, but probably loses to TNT2-based cards (haven't checked it but from what I can remember it sounds reasonable). The mach64 based rage pro OTOH is right on the level of the voodoo1 or so.
This is quite obvious - how much faster is a GeForce4 ti4200 than a GeForce 2mx? 4-5 times? But, I'd bet a reasonably tweaked system with a GeForce4 ti4200 beats a wrongly configured system (e.g. no VIA drivers installed etc.) with a GeForce4 ti4600 (all other components identical) any day.
There are also other advantages to tweaking than pure performance. For instance, if you don't switch on dma mode for your dvd-drive (AFAIK, WXP is the first Windows to do it automatically), chances are dvds will stutter when you play them, no matter what hardware you have.
Be careful with the media type names. Your HP DVD i100 does neither write DVD-R nor DVD-RW. Instead, it writes DVD+RW (and was advertised as being DVD+R capable, but it isn't, so if you "update" it, you'll get a new drive). Compatibility with normal DVD drives isn't that good with DVD+RW media, but neither it is with DVD-RW media - however I'd expect newer DVD drives to be able to read them both (DVD+R compatibility should be better, just as DVD-R compatibility with DVD drives is better than DVD-RW).
mczak
It's not that AMD is crippled here (intel isn't faster either), it's just the G4 is way faster than everything else in that particular benchmark.
The reason the G4 is faster hasn't much to do with cpu architecture, it's really because of "altivec meager tweaks to rc5". The G3, a very similar architecture than the G4 but lacking altivec, is only _one third_ as fast as the G4.
RC5/64 scores (taken from www.distributed.net, comparable clockspeeds if available):
PPC 7400 G4/650: 5,6 million keys/s
PPC 7450 G4/667: 6.6 million keys/s
PPC 750 G3/600: 2 million keys/s
IBM Power III-2/375: 1.3 million keys/s, so in league with the G3 if they had the same clock speed
alpha 21264/667: 1.3 million keys/s (granted, probably a non-optimized rc5 client)
ultrasparc III/750: 1.5 million keys/s
athlon t'bird 650: 2.3 million keys/s
PIII 650: 1.8 million keys/s
(P4 2Ghz: 3.6 million keys/s)
So, it just happens the altivec unit boosts the G4 score beyond anything else by a large margin. This is the cpu you want for rc5. Unfortunately, you won't see these performance gains in general - actually, I'm wondering why apple doesn't use rc5 as their benchmark instead of the boring old photoshop comparison;-).
mczak
You certainly can install gcc 3.2 on older suse distros (not so easy as other apps, because suse will not provide gcc rpms). But this is guaranteed to give problems because of the new C++ ABI. Sure, you can also recompile all libraries (so you all have them installed 2 times...), but then it's definitely an upgrade outside the capabilities of joe user.
mczak
There will obviously always be an update you "really need" to some program in the distro - now it's KDE 3.1, then probably XFree 4.3...
IMHO a lot more important is that they include gcc 3.2, since this is something you cannot upgrade later. KDE 3.1 OTOH can be very easily upgraded (of course, modem users won't like it), suse packages of kde are usually available almost immediately.
mczak
Slashdot Mirror
And, you don't need that many versions of the same chip since memory _technologies_ don't change that often (EDO, sdram, rdram, ddr and ddr2 cover about 10 years). So one chip for DDR200-DDR400, one for DDRII. Though if higher speed memory of the same type is introduced, the chip might need revalidation and a new stepping might be needed - but new steppings are done anyway (the P4 Northwood already has 3 steppings). And guess what? DDRII533 won't magically work on your existing P4 board either. And how much people upgrade the board so they can use the fastest ram but don't upgrade the cpu?
You could call AMD's I/O links (hypertransport) exactly that, except that they are not used for ram access.
Wrong. ATI's (binary only) drivers support 8500 and newer cards (though they don't have an official XFree86 4.3 driver yet, and the unofficial one will just lock up on the 8500/9000 with nwn).
The open-source dri driver (also included in xfree 4.3) supports cards up to 8500/9000/9100/9200 (including all older cards, but not newer ones). Though there are some issues currently with nwn, you have to switch TCL off to get correct lighting and to avoid texture flickering (not all people seem to be affected by the latter problem though).
Works here fine with user@domain too, so this is a no-problem - at least if the user can figure out he has to put the domain name in the user name.
I'll probably having a hard time to argue against JC, but here it goes: assumed shader precision is NOT 32 bit, both DX9 and ARB_fragment_program require 24bit floats as a mininum. mczak
oh nice, an ac insulting me (i know i shouldn't respond but I just can't resist).
May I suggest you read some reviews (for instance at www.beyond3d.com, though the technical information there is probably slightly above what you're able to understand) instead of just citing nvidia PR?
The extended Pixel and Vertex shaders which are supported only by the FX are nice, but pretty much the only advantage they have is the shaders can be longer. How useful is that if the FX can't even execute the standard shaders at a reasonable speed? (This feature is interesting for developers though, and probably non-gaming apps, but no game in the useful lifetime of the current FX chips will ever use it). So you blame futuremark that NVIDIAs cards don't have native 1.4 capability? And, btw, if a card has support for a specific shader version it is required to support all shader versions below. If nvidia can't do it fast, well that's their fault.
You just seem to restate Nvidias criticism of the benchmark, it's almost word-identical. Even though Nvidia are actually very lucky that 3dmark03 does not use _more_ 2.0 pixel shaders, as they are only about HALF as fast as ATI in that case (look at the non-cheated Game Test 4 results, the other game tests are quite close but Nvidia gets slaughtered at this).
If you _really_ want to blame someone else than Nvidia, then don't blame futuremark, but MS instead (for requiring FP24 precision instead of only FP16 in DX9, as the FX chips can only do FP16 and FP32 and are quite a bit slower with FP32 than FP16).
You got that wrong. ATI (R3x0)_always_ does FP24 (internally), the FX can do FX12, FP16, FP32. FP32 has quite a large performance hit (not because the calculations themselves are actually slower, but because double the amount of registers are needed). Unfortunately for Nvidia, DX9 requires FP24, so the GFFX would need to do FP32 all the time, even though performance wise the FX hardly competes even if it only uses FP16.
no, ATI also cheated, though on a MUCH smaller scale than nvidia. They also exchanged the complete shader (recognizing it by name or something like that), even though the exchanged shader delivered the same result (unlike nvidia, their shaders deliver different results, plus they have those really evil clip plane / buffer clear cheats).
You could argue that replacing complete shaders is optimizing (as long as the shader delivers the same output)and you could be right if this would be a game. However, the 3dmark03 licence clearly says that this is a cheat.
So, no, IMHO ATI shouldn't leave this optimization in there (they have already stated it will be gone in the next driver). If you mean with "broaden the scope of the optimization" that they put in an optimizer which could reorder instructions in a generic way then yes, that would be nice (AFAIK they already have such an on-the-fly optimizer, but it's probably not going to achieve as good results as manual tuning).
I don't doubt privoxy has more powerful capabilities than mozilla for those things, but you've picked an example which even mozilla 1.0 can do. user_pref("browser.block.target_new_window", true) does the trick (though last time I checked that option still wasn't in the gui, at least in mozilla 1.3 you can now edit it directly in about:config).
you're forgetting this is not a 900Mhz bus. It's a quad-pumped 225Mhz bus. You could say this is equivalent, but of course the multipliers are different (this is similar to the P4 quad-pumped PSB400 which is a 100Mhz bus). So, a 2Ghz chip will get a multiplier of 9, 2.5Ghz will get 11 (though the math is slightly wrong).
And there wouldn't be much advantage of an even faster bus anyways, since it's already very fast (for a desktop bus system at least, slightly faster than the soon-to-be-announced PSB800 P4, and more than double the speed of the not-yet-confirmed FSB400 (200x2) Athlon XP.
The cpu isn't really a new design. There is some evidence this is the evolution of the PIII, at least the benchmark numbers support this theory perfectly well. The weakest point of the PIII was its limited front side bus bandwidth, so the Pentium-M gets a new bus interface (looks similar to the bus interface of the P4). In addition, the Pentium-M also has the SSE2 instructions, and some power saving features were added.
mczak
mczak
Definitely second this. It can't play *anything* (well maybe it can but I couldn't find something it likes - really). Won't even play divx movies!
However, I didn't compile it myself, just looked around and somebody provided suse 8.1 binaries (rpm didn't like it - but you know --nodeps always helps).
mczak
and, additionally, UT2003 doesn't even qualify as a "true" DX8 game either. UT2003 doesn't use pixel shaders at all, and vertex shaders only to speed some things up (you can switch them off - looks exactly the same, and performance is still almost the same).
mczak
The GeForce didn't really have features that were used by games at that time neither. Sure it had hardware TnL, but this could easily emulated by software (and the games of that timeframe didn't even suffer a performance hit because they were typically fillrate limited and didn't have that many polygons).
GeForce also could do 32bit rendering, the Voodoo not - again, this didn't cause any games to fail (btw even now I think all games still can run at 16bit color). I won't argue that games look better if the rendering is done in 32bit instead of 16bit - a similar situation to today, you can crank up FSAA and AF levels on the R9700, but not on the GeForce4 (without massive slowdowns). Both ATI and Nvidia don't make their chips themselves, instead TSMC (and UMC)does it for them. So, if the problems Nvidia had are really with the 0.13um process of TSMC, then ATI won't face them - simply because TSMC has fixed the problems. If the problems Nvidia had are not really directly manufacturing related, but instead design-related, ATI might also suffer from them in the future - but honestly I don't think designing a chip for 0.13um is really that much different than designing a chip for a 0.15um process. If rumors are true, the tape-out of the next-gen vaule/mobile chip of ATI (the RV350) built on a 0.13um process is already completed, so I don't expect problems there.
I'd still agree with you that the situation really is different and not directly comparable to the 3dfx fiasco. 3dfx basically failed to innovate for 3 chip generations, not only one. The voodoo2 basically was the same as voodoo1 at higher clock speeds and with a second (seperate chip!) texture unit, the voodoo3 was still the same 3d-wise, just integrated the 3 chips of the voodoo2 into one and included a 2d-core, at even higher clock speeds (not to say it wasn't a good card, it just added nothing new). Then came the Voodoo4/5 - it was late, 3dfx was already in trouble and guess what? Still mostly the same 3d core (except it could do 32bit color, but you couldn't call that revolutionary at that time). The supposed next-gen chip of 3dfx (rampage?) probably would have been really revolutionary if all rumors are true...
There were other problems at 3dfx, not related to their 3d-chips at all too.
mczak
No, the submitter is probably right. There are several cards with the Rage Pro name, the rage fury pro uses a compeletely different chip (r128) than the original rage pro (mach64). It should beat the TNT-based cards, but probably loses to TNT2-based cards (haven't checked it but from what I can remember it sounds reasonable). The mach64 based rage pro OTOH is right on the level of the voodoo1 or so.
mczak
This is quite obvious - how much faster is a GeForce4 ti4200 than a GeForce 2mx? 4-5 times? But, I'd bet a reasonably tweaked system with a GeForce4 ti4200 beats a wrongly configured system (e.g. no VIA drivers installed etc.) with a GeForce4 ti4600 (all other components identical) any day.
There are also other advantages to tweaking than pure performance. For instance, if you don't switch on dma mode for your dvd-drive (AFAIK, WXP is the first Windows to do it automatically), chances are dvds will stutter when you play them, no matter what hardware you have.
mczak
Be careful with the media type names. Your HP DVD i100 does neither write DVD-R nor DVD-RW. Instead, it writes DVD+RW (and was advertised as being DVD+R capable, but it isn't, so if you "update" it, you'll get a new drive). Compatibility with normal DVD drives isn't that good with DVD+RW media, but neither it is with DVD-RW media - however I'd expect newer DVD drives to be able to read them both (DVD+R compatibility should be better, just as DVD-R compatibility with DVD drives is better than DVD-RW).
mczak
It's not that AMD is crippled here (intel isn't faster either), it's just the G4 is way faster than everything else in that particular benchmark.
;-).
The reason the G4 is faster hasn't much to do with cpu architecture, it's really because of "altivec meager tweaks to rc5". The G3, a very similar architecture than the G4 but lacking altivec, is only _one third_ as fast as the G4.
RC5/64 scores (taken from www.distributed.net, comparable clockspeeds if available):
PPC 7400 G4/650: 5,6 million keys/s
PPC 7450 G4/667: 6.6 million keys/s
PPC 750 G3/600: 2 million keys/s
IBM Power III-2/375: 1.3 million keys/s, so in league with the G3 if they had the same clock speed
alpha 21264/667: 1.3 million keys/s (granted, probably a non-optimized rc5 client)
ultrasparc III/750: 1.5 million keys/s
athlon t'bird 650: 2.3 million keys/s
PIII 650: 1.8 million keys/s
(P4 2Ghz: 3.6 million keys/s)
So, it just happens the altivec unit boosts the G4 score beyond anything else by a large margin. This is the cpu you want for rc5. Unfortunately, you won't see these performance gains in general - actually, I'm wondering why apple doesn't use rc5 as their benchmark instead of the boring old photoshop comparison
mczak
You certainly can install gcc 3.2 on older suse distros (not so easy as other apps, because suse will not provide gcc rpms). But this is guaranteed to give problems because of the new C++ ABI. Sure, you can also recompile all libraries (so you all have them installed 2 times...), but then it's definitely an upgrade outside the capabilities of joe user.
mczak
There will obviously always be an update you "really need" to some program in the distro - now it's KDE 3.1, then probably XFree 4.3...
IMHO a lot more important is that they include gcc 3.2, since this is something you cannot upgrade later. KDE 3.1 OTOH can be very easily upgraded (of course, modem users won't like it), suse packages of kde are usually available almost immediately.
mczak