I guess that's a US phone number? I'm in the UK so I'll probably have to call elsewhere (at least if I don't want it to cost a bomb!). But thanks anyhow for digging it out for me. I activated it once when I installed it; I assume that since it's an OEM version they make the assumption that hardware will never change:-(
I missed that you said it was an OEM version but I'm still pretty confident that Microsoft Support could provide you with the activation code or tell you who to contact to get one. In the end, the activation code should be free (according to Microsoft's own policies).
If I could, that would be wonderful. I did try to find a contact number for them, but when I looked into support, WinXP's activation dialogue / the MS website told me I wasn't eligible for any free support and that no reactivations weren't available for my license (this was the point they offered to let me purchase a new one). Maybe there's a different place I should have been looking for support details - I just followed the trail that seemed obvious from the information given. If I was just unlucky and didn't look in the right places, then maybe I'll be able to get this system running again soon.
Or you could just call their support number and explain your issue and they'll give you an Activation Code at no cost... but that wouldn't fit the Slashdot hatred of MS:)
Well, I could but...
1) having paid for Windows I think I can still be upset when it locks me out and prevents access to data I need. It seems like I'd get a better user experience by downloading a copy with broken security, which makes me wonder where my money is going;-)
2) Since it's an OEM release, I actually can't just call MS unless I want to pay through the nose (i.e. not at no cost) - and even then I'm not sure if they'll do anything. Windows tells me that it's not eligible for re-activation, but that I might like to buy a brand new copy of Windows instead. I might still get something out of Dell, who sold me the box, but I've already wasted more time on it that I wanted. For the time being I've given up using Windows for a bit.
I guess what I'm saying is that I'm not hatin' on MS because it's Slashdot and that's what people do here. I'm hatin' on MS because the legally obtained software disabled itself like a piece of shareware and then suggested I buy a new license in order to get to my data:-) It's just a bad customer experience, plain and simple - and partially by design, rather than just a random bug.
Well... IIRC, updates for MS Office are only allowed if you're running on a genuine Windows OS. Let me run that by again in case it sounded too crazy to be true: you can only get product updates for Office if you [i]also[/i] buy Windows. [i]And[/i] use it;-) The updater explicitly checks if you're running Office under Wine and fails to auto-update if you are... To me this seems to be blatantly anti-competitive: "buy our other product, or we won't support this one properly".
If being able to validate successfully under Ubuntu would give me the ability to get updates for a product I've paid for then yes, this is worth it.
Side note: I also have a legitimate copy of Windows I run in a virtual machine. An upgrade of the virtual machine software made the virtual hardware look different, so Windows decided I was a pirate, refused to reactivate and is currently holding my data to ransom. If I'd got a pirate cracked Windows and bypassed such checks entirely, I assume I'd still be able to access my data. Since I've already paid for the license, I'd feel justified in dropping a cracked install onto that disk to get back the functionality I paid for in the first place.
2 gig is just fine. It'll store a lot of photos after all. But imagine a different way of using this kind of system: carrying around your laptop / PDA (or even an iPod / Zune with wifi) whilst taking lots of pictures. It stays in a low power state and just wakes up every so often to stream pictures off your camera. You'd never get the "out of memory" errors at a critical point, because your memory card is continually being emptied. Does that make the 2Gig sound worth it? If you could get the device to hook up to any nearby wifi and securely transfer the pictures back home for storage, that would be cool too.
And that's not to mention that as soon as you come home your camera can start syncing your photos before you've even taken it out of the bag. And this shouldn't really even stop you from plugging the camera / SD card into your computer if you're too impatient to wait for the wireless sync!
Side note: my guess from the article is that this device has some kind of "built in" file transfer mechanism and doesn't export itself as a wireless interface to the device it's plugged into. But if it did, it could make the GP2X a whole new level of awesome!
I don't know exactly how this gadget is intended to work, but I would suggest people should consider all the things it *could* do before they get too upset over the prices.
Qemu could run an x86 OS inside a PPC OS. Actually, Qemu can provide a user-level binary translation layer to apps, including translating syscalls appropriately - you don't have to emulate a whole system, the app has its own sandbox that looks like the foreign architecture.
Well, the Intel IXP network processor had on chip memory controllers and integrated multiple different types of core onto the chip (specifically an ARM CPU for general purpose processing, and dedicated accelerator cores for network packet processing) and used fine grained multithreading within the network microengines. It's had this kind of set up for years (I remember reading about second generation IXP parts back in 2003). I doubt any of these concepts were genuinely new then either, but it's not strictly true to say that they've stolen them from recent AMD and Sun innovations; the IXP predates both Niagara and AMD's purchase of a GPU company, for instance. Intel has also been making GPUs for longer than AMD.
I'm not saying that Intel comes up with all it's own ideas; I agree that it would be entirely unsurprising for Intel to borrow ideas from its competitors. Moreover it's possible that they were motivated by their competitors to develop these features into their mainstream x86 chips. But, to be fair to them, they're more-or-less obliged to implement some features of their competitors when either it's required by the marketplace or it's the most sensible-looking direction to continue development successfully.
Worth noting that this strategy may well have at least occurred to Intel already.
It's not a new idea to mix lots of kinds of cores on one die: Intel's IXP network processors have been available a number of years now. These combine an Xscale (StrongARM) core with a number of specialised network processing-oriented microengines. The Xscale can run Linux and acts as a supervisor to the microengines, which do the fast path work of actually processing the data. The microengines are streamlined to be able to do this job quickly, meanwhile the Xscale is able to run control plane and management code efficiently - because that's what it's designed to do.
It'll be interesting to see if Intel also use this strategy in their future desktop and server CPUs - it certainly makes good sense, and it's an approach they've already productised in other areas.
Sure thing... but there will be other processes also trying to use the filesystem server that may have a higher priority than our first client. My point is that to handle this correctly there needs to be an implementation of pre-emption *inside* server processes. Sure you can pre-empt the filesystem server itself, but the microkernel can pre-empt operations occuring inside the server, on behalf of other threads.
The solution to this could be to multithread the server (in which case you still have the problem of transferring the client's priority onto that thread) or use some other kind of mechanism for scheduling client requests within the server.
In a monolithic kernel, you don't have "servers" - OS-level work on behalf of a thread is (not always admittedly, but often) carried out in the context of that process. This in turn means that the kernel's process context is automatically a container for processing related to that process, that the kernel scheduler is able to pre-empt syscall operations performed by that process, etc. It's not necessary for each subsystem to have a local implementation of scheduling in order to implement global policy.
The exceptions to this are where work is tasked of to another kernel thread, or where *incoming* network IO for a process is handled. But syscalls, at least, can generally be handled in process context, whereas in a microkernel they're typically carried out in server context.
Sooooo, it's easy to have someone else handle the multi-process bits in a monolithic design. But when it comes to writing services for microkernels suddenly everyone is an idiot?
I don't think that was what was meant.
Thing is, with a monolithic kernel every process can run in userspace or in kernel space. (OK, I'm assuming a 1:1 kernel threads to user threads, but lets ignore that issue for now) Because all the processes have a kernel context, it's quite simple to manage multiple processes making use of the kernel at once. Run kernel code to service the filesystem request in the kernel-mode context of the process that made the request. At this point, if the kernel supports pre-emption then it's possible to pre-empt that process during kernel-mode execution and resume it later.
In a microkernel you don't get that. The filesystem server doesn't implicitly get its multithreading from each process being represented by a kernel thread - because it can't access the kernel. If it wants an implementation of multithreading it has to implement its own (nb. could use a library to simplify this). But lots of tasks now require explicit extra code: the FS server might need to handle scheduling priorities itself, because the internals of the server aren't under direct control of the kernel; threading in the FS server must be made explicit because it doesn't come "for free" when processes are created. This is a problem for every server that needs to serve multiple clients simultaneously.
A lot of this should be solvable with library code, I have thought. But the basic argument here (AFAIK) is that you have to code up somewhere in userspace extra implementations to take care of things that are implicitly provided for in a monolithic design.
> I'm not sure what you mean by "storing" there, but if you're talking > about standard C and C++, you're almost certainly wrong in any case. > The sort of hackery you're talking about, assuming size equivalence > between unrelated types
I was under the impression it was permitted by the standards but looking more closely at the C99 spec draft (http://dev.unicals.com/papers/c99-draft.html) suggests instead that the uintptr_t type is provided for storing a pointer in an integer type. (It's an optional type, though, so for some platforms you may need to provide your own.)
Assigning pointers to a unsigned long is AFAIK a supported part of the GNU C standards though; it's necessary for kernel code. (assigning to an ordinary int is naughty though - kernel developers will chase you with pitchforks)
>and doing pointer arithmetic on a void*,
Now that *is* evil, I wouldn't advocate that:-)
> might work in some predictable >way on a particular platform. However, it's neither standard (the >standards give very few guarantees about sizeof whatever_type, >particularly where pointers are concerned), nor portable, nor a smart >way to write your code.
Assigning pointers to longs is useful for interfaces between subsystems (particularly in kernel-type code when you're using C and have no encapsulation). It's not something you'd do *within* a subsystem but it provides a useful storage for opaque data that may or may not be a pointer, depending on implementation.
I'm pretty sure that storing void * pointers in (unsigned) longs is OK according to the spec (Kernel code does it all the time). Doing arithmetic on them is portable *if you're careful*.
Things get thornier if you do pointer arithmetic with a void * directly (on gcc, AFAIK it'll *probably* do what you meant and treat it like a char *). If you're storing void *'s in an int that's also a problem: it'll work on 32-bit x86 but not on other platforms which have ints narrower than pointers.
I think you're referring to Sparc's "register windows" that (I believe) are rather like IA64's "register stack". IA64 additionally has the ability to rename the registers on each iteration of a loop - that's the rotating register files. This helps you do software pipelining (e.g. when iterating in an inner loop, hide load latencies by preloading future data into a register before doing operations on the current data.) without needing to bloat the code by "unrolling" the loop.
Re:Writing has been on the wall
on
Dell Dumping Itanium
·
· Score: 2, Interesting
Would a 9Meg cache really help an SpecFP benchmark that much? I'd have guessed an Opteron's FP pipes would be permanently saturated with well less than the full 9MB on many benchmarks.
> So please... enlighten me on how the Itanium > architecture improves computing on any metric.
Personally I like the predicate registers, conditional execution and rotating register files - a neat way to pipeline loops without unrolling. I like the concept of VLIW-style without huge amounts of nop padding (although it can't eliminate it). It also has pretty neat support for doing explicit cache prefetches in software.
Some of these have obviously been done before to varying degrees (but I've not heard of rotating register files in a general purpose chip). Whether or not the chip as a whole was worthwhile, I think the nice bits have technical merit and I'd expect some of them to pop up in other places.
Intel went through an interesting trend throughout the company of trying to push huge amounts of complexity out of the chip and into the compiler. This wasn't just Itanium: the IXP network processors have a *really* weird programming model (c.f. the much more conventional IBM designs). I occasionally wonder what caused *all* the architects at Intel HQ to go down this road on completely unrelated products (something in the water supply?). I must admit I *really* like the idea of pushing cleverness up the stack but if you're going to do it, you should provide *real* benefits.
Yup, *that* is worrying. My ISP is a university and thus generally quite permissive, with a load of totally random restrictions that they sometimes enforce in heavy-handed ways.
This kind of technology might be useful to ISPs (from their point of view) but it's something I'd pay extra to avoid - I'd been very happy to vote with my wallet by going to another ISP, as long as the competition is available (not in my case:-( )
OTOH, will the availability of this technology *really* make the situation much worse in clueless ISPs than it already is?
Despite Linux's increasing share of the server room, can anyone remember the "Year of the Linux server"? People keep looking for the "Year of the Linux Desktop" and to a certain extent they're right: each year, events occur that could help increase desktop share. There's just no decisive flip to Linux.
Linux is already desktop ready for large segments of users - for others it's nowhere close. Growing marketshare takes time and is self-reinforcing - the process is just going to take a while.
Before anyone gets too upset at the idea of their computers getting cut off from the internet for running P2P:
This kind of technology is not interesting to home users, or even for developer workstations: nobody is going to want to use a technology that cuts off their personal computer. The place it looks (IMHO) to be aimed at is ordinary user desktops in large corporations. These are (supposed to be) highly locked-down environment and controlled tightly by the sysadmins. In this environment, the IT manager is going to prefer inconveniencing a few users by cutting their 'net connection than managing a widescale worm outbreak that'll likely take the rest of the network down for everyone.
Horses for courses: home users and developers will still be best served by taking precautions (virus scanners and social countermeasures) and being vigilant for signs of an outbreak.
Actually, RAID 1 (mirroring) still potentially doubles your read bandwidth so it can in principle provide speedups here. RAID 0 can speed up writes as well but is not redundant.
The easiest way to get everyone else to use the changes is to get them in the next release - lots of people aren't quite happy with the current feel, so that may be possible.
I have high hopes for Nexuiz but it has a few rough edges that need smoothing off before it's really polished (I think the menu system needs some improvement, for instance).
Slashdot Mirror
Hey! No recursing!
I guess that's a US phone number? I'm in the UK so I'll probably have to call elsewhere (at least if I don't want it to cost a bomb!). But thanks anyhow for digging it out for me. I activated it once when I installed it; I assume that since it's an OEM version they make the assumption that hardware will never change :-(
If I could, that would be wonderful. I did try to find a contact number for them, but when I looked into support, WinXP's activation dialogue / the MS website told me I wasn't eligible for any free support and that no reactivations weren't available for my license (this was the point they offered to let me purchase a new one). Maybe there's a different place I should have been looking for support details - I just followed the trail that seemed obvious from the information given. If I was just unlucky and didn't look in the right places, then maybe I'll be able to get this system running again soon.
Well, I could but...
1) having paid for Windows I think I can still be upset when it locks me out and prevents access to data I need. It seems like I'd get a better user experience by downloading a copy with broken security, which makes me wonder where my money is going ;-)
2) Since it's an OEM release, I actually can't just call MS unless I want to pay through the nose (i.e. not at no cost) - and even then I'm not sure if they'll do anything. Windows tells me that it's not eligible for re-activation, but that I might like to buy a brand new copy of Windows instead. I might still get something out of Dell, who sold me the box, but I've already wasted more time on it that I wanted. For the time being I've given up using Windows for a bit.
I guess what I'm saying is that I'm not hatin' on MS because it's Slashdot and that's what people do here. I'm hatin' on MS because the legally obtained software disabled itself like a piece of shareware and then suggested I buy a new license in order to get to my data :-) It's just a bad customer experience, plain and simple - and partially by design, rather than just a random bug.
Well... IIRC, updates for MS Office are only allowed if you're running on a genuine Windows OS. Let me run that by again in case it sounded too crazy to be true: you can only get product updates for Office if you [i]also[/i] buy Windows. [i]And[/i] use it ;-) The updater explicitly checks if you're running Office under Wine and fails to auto-update if you are... To me this seems to be blatantly anti-competitive: "buy our other product, or we won't support this one properly".
If being able to validate successfully under Ubuntu would give me the ability to get updates for a product I've paid for then yes, this is worth it.
Side note: I also have a legitimate copy of Windows I run in a virtual machine. An upgrade of the virtual machine software made the virtual hardware look different, so Windows decided I was a pirate, refused to reactivate and is currently holding my data to ransom. If I'd got a pirate cracked Windows and bypassed such checks entirely, I assume I'd still be able to access my data. Since I've already paid for the license, I'd feel justified in dropping a cracked install onto that disk to get back the functionality I paid for in the first place.
2 gig is just fine. It'll store a lot of photos after all. But imagine a different way of using this kind of system: carrying around your laptop / PDA (or even an iPod / Zune with wifi) whilst taking lots of pictures. It stays in a low power state and just wakes up every so often to stream pictures off your camera. You'd never get the "out of memory" errors at a critical point, because your memory card is continually being emptied. Does that make the 2Gig sound worth it? If you could get the device to hook up to any nearby wifi and securely transfer the pictures back home for storage, that would be cool too.
And that's not to mention that as soon as you come home your camera can start syncing your photos before you've even taken it out of the bag. And this shouldn't really even stop you from plugging the camera / SD card into your computer if you're too impatient to wait for the wireless sync!
Side note: my guess from the article is that this device has some kind of "built in" file transfer mechanism and doesn't export itself as a wireless interface to the device it's plugged into. But if it did, it could make the GP2X a whole new level of awesome!
I don't know exactly how this gadget is intended to work, but I would suggest people should consider all the things it *could* do before they get too upset over the prices.
Qemu could run an x86 OS inside a PPC OS. Actually, Qemu can provide a user-level binary translation layer to apps, including translating syscalls appropriately - you don't have to emulate a whole system, the app has its own sandbox that looks like the foreign architecture.
Well, the Intel IXP network processor had on chip memory controllers and integrated multiple different types of core onto the chip (specifically an ARM CPU for general purpose processing, and dedicated accelerator cores for network packet processing) and used fine grained multithreading within the network microengines. It's had this kind of set up for years (I remember reading about second generation IXP parts back in 2003). I doubt any of these concepts were genuinely new then either, but it's not strictly true to say that they've stolen them from recent AMD and Sun innovations; the IXP predates both Niagara and AMD's purchase of a GPU company, for instance. Intel has also been making GPUs for longer than AMD.
I'm not saying that Intel comes up with all it's own ideas; I agree that it would be entirely unsurprising for Intel to borrow ideas from its competitors. Moreover it's possible that they were motivated by their competitors to develop these features into their mainstream x86 chips. But, to be fair to them, they're more-or-less obliged to implement some features of their competitors when either it's required by the marketplace or it's the most sensible-looking direction to continue development successfully.
...hear my prayer!
Worth noting that this strategy may well have at least occurred to Intel already.
It's not a new idea to mix lots of kinds of cores on one die: Intel's IXP network processors have been available a number of years now. These combine an Xscale (StrongARM) core with a number of specialised network processing-oriented microengines. The Xscale can run Linux and acts as a supervisor to the microengines, which do the fast path work of actually processing the data. The microengines are streamlined to be able to do this job quickly, meanwhile the Xscale is able to run control plane and management code efficiently - because that's what it's designed to do.
It'll be interesting to see if Intel also use this strategy in their future desktop and server CPUs - it certainly makes good sense, and it's an approach they've already productised in other areas.
And they call those tunes the Al-Gore-Rythms?
a me=al_gore
http://www.badpuns.com/jokes.php?section=shaggy&n
Sure thing... but there will be other processes also trying to use the filesystem server that may have a higher priority than our first client. My point is that to handle this correctly there needs to be an implementation of pre-emption *inside* server processes. Sure you can pre-empt the filesystem server itself, but the microkernel can pre-empt operations occuring inside the server, on behalf of other threads. The solution to this could be to multithread the server (in which case you still have the problem of transferring the client's priority onto that thread) or use some other kind of mechanism for scheduling client requests within the server. In a monolithic kernel, you don't have "servers" - OS-level work on behalf of a thread is (not always admittedly, but often) carried out in the context of that process. This in turn means that the kernel's process context is automatically a container for processing related to that process, that the kernel scheduler is able to pre-empt syscall operations performed by that process, etc. It's not necessary for each subsystem to have a local implementation of scheduling in order to implement global policy. The exceptions to this are where work is tasked of to another kernel thread, or where *incoming* network IO for a process is handled. But syscalls, at least, can generally be handled in process context, whereas in a microkernel they're typically carried out in server context.
Incidentally, my post would have been less monolithic if I'd remembered
tags. Ah well.
Sooooo, it's easy to have someone else handle the multi-process bits in a monolithic design. But when it comes to writing services for microkernels suddenly everyone is an idiot? I don't think that was what was meant. Thing is, with a monolithic kernel every process can run in userspace or in kernel space. (OK, I'm assuming a 1:1 kernel threads to user threads, but lets ignore that issue for now) Because all the processes have a kernel context, it's quite simple to manage multiple processes making use of the kernel at once. Run kernel code to service the filesystem request in the kernel-mode context of the process that made the request. At this point, if the kernel supports pre-emption then it's possible to pre-empt that process during kernel-mode execution and resume it later. In a microkernel you don't get that. The filesystem server doesn't implicitly get its multithreading from each process being represented by a kernel thread - because it can't access the kernel. If it wants an implementation of multithreading it has to implement its own (nb. could use a library to simplify this). But lots of tasks now require explicit extra code: the FS server might need to handle scheduling priorities itself, because the internals of the server aren't under direct control of the kernel; threading in the FS server must be made explicit because it doesn't come "for free" when processes are created. This is a problem for every server that needs to serve multiple clients simultaneously. A lot of this should be solvable with library code, I have thought. But the basic argument here (AFAIK) is that you have to code up somewhere in userspace extra implementations to take care of things that are implicitly provided for in a monolithic design.
Presumably that "He was not in the least bit scared to be killed in nasty ways" and that he would fetch the Law Lords "A Shrubbery".
Like the user name btw ;-)
:-)
> I'm not sure what you mean by "storing" there, but if you're talking
> about standard C and C++, you're almost certainly wrong in any case.
> The sort of hackery you're talking about, assuming size equivalence
> between unrelated types
I was under the impression it was permitted by the standards but looking more closely at the C99 spec draft (http://dev.unicals.com/papers/c99-draft.html) suggests instead that the uintptr_t type is provided for storing a pointer in an integer type. (It's an optional type, though, so for some platforms you may need to provide your own.)
Assigning pointers to a unsigned long is AFAIK a supported part of the GNU C standards though; it's necessary for kernel code. (assigning to an ordinary int is naughty though - kernel developers will chase you with pitchforks)
>and doing pointer arithmetic on a void*,
Now that *is* evil, I wouldn't advocate that
> might work in some predictable
>way on a particular platform. However, it's neither standard (the
>standards give very few guarantees about sizeof whatever_type,
>particularly where pointers are concerned), nor portable, nor a smart
>way to write your code.
Assigning pointers to longs is useful for interfaces between subsystems (particularly in kernel-type code when you're using C and have no encapsulation). It's not something you'd do *within* a subsystem but it provides a useful storage for opaque data that may or may not be a pointer, depending on implementation.
I'm pretty sure that storing void * pointers in (unsigned) longs is OK according to the spec (Kernel code does it all the time). Doing arithmetic on them is portable *if you're careful*.
Things get thornier if you do pointer arithmetic with a void * directly (on gcc, AFAIK it'll *probably* do what you meant and treat it like a char *). If you're storing void *'s in an int that's also a problem: it'll work on 32-bit x86 but not on other platforms which have ints narrower than pointers.
I think you're referring to Sparc's "register windows" that (I believe) are rather like IA64's "register stack". IA64 additionally has the ability to rename the registers on each iteration of a loop - that's the rotating register files. This helps you do software pipelining (e.g. when iterating in an inner loop, hide load latencies by preloading future data into a register before doing operations on the current data.) without needing to bloat the code by "unrolling" the loop.
Would a 9Meg cache really help an SpecFP benchmark that much? I'd have guessed an Opteron's FP pipes would be permanently saturated with well less than the full 9MB on many benchmarks.
> So please... enlighten me on how the Itanium
> architecture improves computing on any metric.
Personally I like the predicate registers, conditional execution and rotating register files - a neat way to pipeline loops without unrolling. I like the concept of VLIW-style without huge amounts of nop padding (although it can't eliminate it). It also has pretty neat support for doing explicit cache prefetches in software.
Some of these have obviously been done before to varying degrees (but I've not heard of rotating register files in a general purpose chip). Whether or not the chip as a whole was worthwhile, I think the nice bits have technical merit and I'd expect some of them to pop up in other places.
Intel went through an interesting trend throughout the company of trying to push huge amounts of complexity out of the chip and into the compiler. This wasn't just Itanium: the IXP network processors have a *really* weird programming model (c.f. the much more conventional IBM designs). I occasionally wonder what caused *all* the architects at Intel HQ to go down this road on completely unrelated products (something in the water supply?). I must admit I *really* like the idea of pushing cleverness up the stack but if you're going to do it, you should provide *real* benefits.
Let me guess, every third article is a dupe of something published elsewhere in the paper, right? ;-)
Yup, *that* is worrying. My ISP is a university and thus generally quite permissive, with a load of totally random restrictions that they sometimes enforce in heavy-handed ways.
:-( )
This kind of technology might be useful to ISPs (from their point of view) but it's something I'd pay extra to avoid - I'd been very happy to vote with my wallet by going to another ISP, as long as the competition is available (not in my case
OTOH, will the availability of this technology *really* make the situation much worse in clueless ISPs than it already is?
Despite Linux's increasing share of the server room, can anyone remember the "Year of the Linux server"? People keep looking for the "Year of the Linux Desktop" and to a certain extent they're right: each year, events occur that could help increase desktop share. There's just no decisive flip to Linux.
Linux is already desktop ready for large segments of users - for others it's nowhere close. Growing marketshare takes time and is self-reinforcing - the process is just going to take a while.
Before anyone gets too upset at the idea of their computers getting cut off from the internet for running P2P:
This kind of technology is not interesting to home users, or even for developer workstations: nobody is going to want to use a technology that cuts off their personal computer. The place it looks (IMHO) to be aimed at is ordinary user desktops in large corporations. These are (supposed to be) highly locked-down environment and controlled tightly by the sysadmins. In this environment, the IT manager is going to prefer inconveniencing a few users by cutting their 'net connection than managing a widescale worm outbreak that'll likely take the rest of the network down for everyone.
Horses for courses: home users and developers will still be best served by taking precautions (virus scanners and social countermeasures) and being vigilant for signs of an outbreak.
Actually, RAID 1 (mirroring) still potentially doubles your read bandwidth so it can in principle provide speedups here. RAID 0 can speed up writes as well but is not redundant.
The easiest way to get everyone else to use the changes is to get them in the next release - lots of people aren't quite happy with the current feel, so that may be possible.
I have high hopes for Nexuiz but it has a few rough edges that need smoothing off before it's really polished (I think the menu system needs some improvement, for instance).