No double standard at all. Symantec et. al. exist only because of Microsoft's design/implimentation errors - they should not exist at all - there should be no market for microsoft to push them OUT of.
False. Anti-virus and anti-spyware applications protect against things OS-level security cannot.
If microsoft started addressing the problem and making the changes that rendered 3rd party virus programmes unnecessary, I would not only applaud them, but I might even change my mind about being willing to even DEVELOP windows applications.
How do you propose Microsoft address the problem of end users deliberately - or even accidentally - running malicious code ?
In 25 years as a programmer, I have never written a windows *anything* for a client, and never will. Because when the sucker crashes (and it will), will the client blame microsoft? No, they'll blame ME - and it will affect MY reputation.
Bullshit. Microsoft *always* get the blame - even from people who should know better - even though 99% of "Windows problems" are really "software developer problems". That's why they go to such ridiculous lengths to maintain backwards compatibility - despite it often getting in the way of a better/cleaner implementation - because they know they'll always wear the blame for (frequent, gratuitous) developer fuckups.
Exhibit A: The multitude of applications that "require" Administrator accounts to run.
Exhibit B: The backlash against them for SP2 "breaking" applications.
Exhibit C: The plethora of low-quality hardware drivers
I have no problems whatsoever accepting responsibility for my errors. But there is no f..king way in HELL that I am going to send a client a programme and have them call me once a week bitching about how it keeps crashing becase it's MY fault, when it's because the damned thing is running on an unreliable piece of shit.
If your application is crashing, it's almost always going to be your fault.
Your post reeks of someone who hasn't used Windows since 1992 and thinks they are incapable of making mistakes. Even if you did write Windows software, I have little doubt it would be unstable and break every convention and best practice known just because "you know best".
You make a differentiation without merit, except for pure academic theory maybe.
No, the differentiation is important, because the consequences and remedies are significantly different.
"Inadequate security" would mean it's impossible to safely run a Windows system. Since this is demonstrably false - and fairly trivial to enforce in a managed environment - then it's simply not a factor.
Software bugs, OTOH, the end user - even administrators - can do very little to fix.
Most security problems are software bugs.
Rubbish. The vast majority of security breaches come from end users, either deliberately (corporate espionage style) or inadvertently (running virus-laden files from email attachments or downloads).
Buggy software and users are what I am most worried about, in this order.
Then your priorities are backwards. The most common vector into the typical machine for malicious code is the end user deliberately executing it, either knowingly or unknowingly. Accidental code execution via software bugs follows a distant second. Remote code execution - automated or otherwise - is barely even on the scope. These first two vectors are *precisely* the holes that anti-spyware and anti-virus software tools attempt to plug and OS-level security is largely incapable of closing.
User error is a very important source of security problems, but your statement goes way too far.
No, it doesn't.
I repeat: anti-spyware and anti-virus software aren't there to protect you against "inadequate security". They *may* do this as a side effect, but it is not their purpose.
I suspect you have not extensively used Internet Explorer on a user with administrator rights (MS Windows default) to browse the Internet.
No. Nor would I ever consider doing it.
If you had, you would have collected spyware without agreeing to install anything.
Undoubtedly. But this would be due to software bugs (and, arguably, bad UI), not "inadequate security" - not to mention the foolishness of browsing the web with a high-privilege account.
With Windows XP (original release, no SP 1) just connecting to the Internet from a user with administrator rights, without a firewall, is enough to be infected by worms within a short time.
As is installing many Linux distros and commercial unixes from the same time period. Again, you are largely describing problems caused by software bugs, not "inadequate security". I will agree that the firewall should have been enabled by default from the first release of XP and that services shouldn't be binding to external network interfaces by default - but even without that, all those remote exploits are coming from *coding errors*.
OS-level security - which Windows NT has in spades - can protect you against some aspects of malicious code. However, it cannot protect you against all, or even the most common, aspects of malicious code. That is what anti-spyware and anti-virus software is for.
Microsoft releasing operating systems with inadequate security is not comparable to repair of products that deteriorate through wear and tear (the software equivalent for that is such tools as defragmenters or registry cleaners).
Except anti-spyware and anti-virrus software isn't protecting you against "inadequate security", it's protecting you against user error - the stuff OS-level "security" can't.
Linux and OSX, both more secure OSs than Windows, [...]
Quite arguable.
[...] allow users to change the time without root priviledges.
Linux certainly doesn't:
[CHI csmith@unix-prod01 ~]$ date Wed May 31 21:35:42 CDT 2006 [CHI csmith@unix-prod01 ~]$ date 05312145 date: cannot set date: Operation not permitted Wed May 31 21:45:00 CDT 2006 [CHI csmith@unix-prod01 ~]$ date Wed May 31 21:36:02 CDT 2006 [CHI csmith@unix-prod01 ~]$
Unless, of course, you're root:
[CHI csmith@unix-prod01 ~]$ sudo date 05312145 Password: Wed May 31 21:45:00 CDT 2006 [CHI csmith@unix-prod01 ~]$ date Wed May 31 21:45:01 CDT 2006 [CHI csmith@unix-prod01 ~]$
I don't have an OS X machine handy since I didn't bring my iBook to work today, but I would imagine - and certainly *hope* - that OS X requires an admin user authentication before allowing the time to be changed.
I'm sorry I don't understand your crazy Windows ways.
It's got nothing to do with "Windows ways". Allowing unprivileged users to change the system time is security hole.
Actually, as I understand the reason that *nix lets users change the time is because they're not changing system time, they're changing their individual user time.
I don't understand what you mean by "individual user time". In Linux (and UNIX) normal users cannot change the time. Even "user friendly" distros like Ubuntu require the user to authenticate via sudo before allowing them to change the time.
I think you are confused.
Which, as far as protecting the system from dumbass users goes, makes a hell of a lot more sense than the Windows way.
Right. So explain to me again how *pretending* to let users change the time rather than saying either "permission denied" or "authorise yourself to continue" does a better job of "protecting the system" ?
Editing config files is fine for the typical slashdot user, but an absolute stopping point for 99% of normal computer users.
I would argue that editing text files is an atrocious form of configuration modification - outside of disaster-recovery scenarios - for everyone, regardless of skill level.
So don't blame Linux, blame your graphics card makers.
No, blame Linux. If Linux had a stable kernel ABI (like, say, every other remotely mainstream OS), so 0.0.0.1 kernel revisions/patches didn't break every binary module, requiring a recompile, then video card manufacturers (not to mention everyone else who writes drivers) would be able to create a simple, consistent driver package that didn't require intimate knowledge of your exact kernel version to install.
Vista doesn't have particularly high hardware requirements (I was surprised they weren't higher). Even a mid-range PC from ~3 years ago is only likely to require a memory upgrade - (and even that's unlikely, in the case of an enthusiast) - and a "high end" PC ~5 years ago should be capable with a cheap video card upgrade.
That's assuming you want the fancy Aero interface, of course - if the "Classic" interface is good enough for you then anything back to about 7 years should be ok, maybe needing more RAM.
Any remotely serious gamer (ie: the context of this article) will have had a PC more than capable of running Vista for years already. Compared to the hardware requirements of current (and upcoming) games, Vista is a lightweight.
[...] and even needs a GPU upgrade for DX10.
So did DX9 and various other fancy new technologies like Pixelshader 3.0. Again, if you're a serious gamer, you'll already be planning (or have committed to) a video card upgrade, just to play games, that will be more than sufficient for Vista.,
I've seen Unix binaries for HPUX run 7 major versions after the original compilation, and we didn't have source.
And XP running DOS programs dating from the mid 80s is not at all uncommon.
DOS games - as anyone dating from the era should know - *frequently* relied on direct access to hardware and undocumented bugs/quirks/features in both hardware and the different versions (and brands) of DOS. That they often don't work in a compatibility layer that doesn't allow direct hardware access and typically only reproduces documented functionality, is hardly surprising. They are a special case.
Shit, with many later DOS games (eg: just about anything from Origin) it was often a challenge getting it to run *in regular MS-DOS* - and you're expecting compatibility from a completely different OS ?
Ubuntu and Mac OSX do this as well, though from what I've heard Vista doesn't implement it as well, and asks for your password at for stupid things like adusting the time.
If you cannot understand why adjusting the system time needs elevated privileges, you're probably not qualified to be making any comments about security. At all.
DirectX 10, which evidently will *only* be Vista (though I've yet to see a technological reason why it can't go into XP other than "We need a reason for you to upgrade to Vista).
You don't think the completely new display subsystem and video driver model in Vista might have just a little bit to do with it ? Just maybe ?
I'm sure I'm not the only one to have found this to be anything but the case. They break games from one version of Direct X to another, more less the whole OS.
For example ?
Microsoft has never shown themselves to be worried about breaking backward compatibility.
Considering the ridiculous lengths Microsoft commonly go to so that backwards compatibility is preserved, that's pretty funny.
I always thought the OS and software were the easy part. What do folks like for hardware platforms? I don't care about 2 or 4 drive solutions - those are trivial. I'm talking 8-10 drives in the 320-500 gb range. Most turn-key solutions are Far too expensive when compared to the 'build a box' DIY alternative.
Personally I would argue that the hardware/OS support and ongoing maintenance hassles of DIY more than cover the additional cost of off-the-shelf hardware like Promise's vTrak chassis, but that's coming from a business-production-environment perspective. I can certainly see why use for home would consider $$$ saved up front far more important than ongoing "user time costs".
The biggest performance-related problem in building your own SAN/NAS is that most - if not all - consumer level motherboards have pitiful amounts of I/O bandwidth. Usually just a single ~130M/s PCI bus, which even a small four-disk array is more than capable of flooding. New machines have more I/O bandwith in the form of PCIe, but it's usually tied up amongst too few slots and PCIe disk controllers are still usually uncommon, expensive and poorly supported in terms of drivers.
I would suggest chasing up some old Xeon server motherboards (single or dual CPU) with multiple PCI-X slots and buses, then some four or eight slot SATA controllers. Ideally, you want SATA controllers that are either 66Mhz PCI (most Promise cards support this) or PCI-X (most 8-port and larger controllers support this). I suggest Xeon boards because very few P3 or Athlon "server" boards even have PCI-X and most that do only have one or two 64/66Mhz buses, shared among multiple slots. They also tend to be relatively expensive. "High end" (for their day) [dual] Xeon boards often have 4 - 5 PCI-X slots, often shared between two or three 64 bit, 133Mhz PCI-X buses.
The other big problems you will find are cooling and power.
* Cooling, because drives - particularly close packed - generate a lot of heat and overheated hard disks die very quickly. Ideally you want to keep your drives down around the 30 - 35 degrees C mark. I use 4-in-3 Coolermaster drive cages with integrated 12cm fans a a cheap solution, but there are also numerous 4-in3 and even 5-in-3 "hotswap" cages that are more expensive. Ignore people who tell you they are only for "CM Stacker" cases, they fit fine into any set of three 5.25" drive bays.
* Power, because while a dozen hard disks idling (or even in heavy use) don't use a lot of power, when they all spin up at once they do draw a lot of current - and most SATA drive/controller combos aren't capable of staggering drive spinups. New PSUs these days have ridiculously high capabilities, however, these days, so it's becoming much less of a problem.
CPU grunt is basically irrelevant. Even a few hundred Mhz worth of P2 is capable of doing RAID5 checksumming faster than any array you're likely to assemble with consumer-level parts and by the time you get a semi-decent motherboard, the slowest/cheapest CPU you can put into it is already ~10x faster than it needs to be.
Note that most cheap SATA controllers are cheap for a reason - they suck. Either their performance is atrocious, they don't play play well with multiple controllers in the same box, or they throw mysterious errors when used in software RAID arrays (ie: with all ports busy simultaneously). Somewhat ironically, however, many hardware RAID controllers (real hardware RAID controllers) give better performance overall when used as a dumb controller and Linux software RAID, than when configured to use hardware RAID.
What I want is an ethernet-based (iSCSI) consumer-grade SAN. I want to buy a box with five or six drive bays, pack it full of 500GB SATA disks, and then send it over the network to my desktop.
[Software RAID is documented. If it fails, you can plug the drives into another system that understands the RAID format and get at the data.]
I haven't dealt with software RAID enough to know how accurate that statement is.
Speaking as someone who has moved a single array between about 5 machines over its lifetime, including from kernel 2.4 machines to kernel 2.6 machines, I'd say that if you've got a Linux software RAID array, it'll probably work on any Linux machine you can find to plug it into (assuming that machine has appropriate drives for the disk controllers and RAID level).
How big of an array though. I have 4 250 gig drives in a RAID 5 config. It seriously took 36+ hours to rebuild on a Pentium 4 2.4 gigahertz with 1 gig of ram.
Firstly, make sure your rebuild isn't being throttled. cat/proc/sys/dev/raid/speed_limit_max will print out the maximum speed (in kb/sec) the array will rebuild at. Use something like echo 100000 >/proc/sys/dev/raid/speed_limit_max to set it suitably high so that the throttling won't occur.
Secondly, the limiting factor in your rebuild speed will be (in decreasing order of likelihood) bus bandwith, individual disk performance, disk controller or driver bugs/quirks/limitations, CPU speed. Although if you have PCIe or PCI-X disk controllers (unlikely) you may hit limits in individual disk performance before you run out of bus bandwidth. With a 2.4Ghz P4 I can pretty confidently say your bottleneck will never be the CPU.
In your case, your machine almost certainly has all the drives hanging off a single 33Mhz, 32 bit PCI bus. So the absolute upper limit on your array's performance is going to be around 120M/s, and that's assuming the machine isn't doing anything else except rebuilding the array. You're only ever likely to see this sort of performance off the array from long, sequential reads, however (dd if=/dev/md0 of=/dev/null type of thing).
(This is a rough overview). With 4 drives, you have roughly 30M/s per drive maximum, so your best-case RAID rebuild speed will be about 30M/s - this is assuming your drives can sustain 30M/s for both reads and writes across their entire surface. Rebuilding a RAID5 array involves reading data and parity from N-1 drives and writing it to the Nth drive - in other words you have to completely reconstruct a single disk. At 30M/s, it should take about 250000/30/60 ~= 138 minutes to copy the 250G necessary to reconstruct that disk.
(Tech-savvy readers should realise at this point why hardware RAID is theoretically faster than software RAID - particularly for average PCs and/or large numbers of drives - and why it has nothing to do with the "overhead" of calculating RAID5/6 parity.)
Note that 138 minutes is a best case scenario, so it taking 36 hours could be explained by you using the system at the same time, automated system maintenance occurring, less-than-stellar drivers, etc, etc. With such a massive difference between "should be" and "was", however, I'd be examining the individual components pretty closely to see where the bottleneck is. What's the maximum performance you can get from each individual drive (use hdparm and dd). How about from the entire array ?
I can't imagine how many days or weeks a software RAID 5 would take to rebuild........
Probably less - most hardware RAID cards throttle the rebuild process by default (which you can also do in software RAID - at least on Linux).
Added to that, the bottleneck in the rebuild process is the IO bandwidth, not the CPU power. Even something pitifully slow (by modern standards) like a 300Mhz P2 has a RAID5 checksumming speed well into the hundreds of megabytes a second.
On any remotely modern CPU, the overhead of software RAID is miniscule to the point of irrelevance.
Would a NAS device not require some pretty good processing power under a bit of a load?
Not really. It would, however, need quite a bit of I/O bandwidth - something the vast majority of PCs have very little of.
(This is assuming you want to serve up something over gig ethernet - at 100Mb ethernet speeds pretty much anything will be sufficient, although large array [re]build times will be long).
The keyword you missed is 'inherently'. Having a lot of independent eyeballs on the code is essential priciple for locating bugs and avoiding backdoors.
Only if the eyeballs are any good and are actually interested in looking at the code.
It's a bit like the draftees vs professional soldiers situation.
A small, well trained group of code auditors will be far more effective at finding coding errors than a large group of amateurs - and they'll do it even in code they have no personal interest in.
Slashdot Mirror
False. Anti-virus and anti-spyware applications protect against things OS-level security cannot.
If microsoft started addressing the problem and making the changes that rendered 3rd party virus programmes unnecessary, I would not only applaud them, but I might even change my mind about being willing to even DEVELOP windows applications.
How do you propose Microsoft address the problem of end users deliberately - or even accidentally - running malicious code ?
In 25 years as a programmer, I have never written a windows *anything* for a client, and never will. Because when the sucker crashes (and it will), will the client blame microsoft? No, they'll blame ME - and it will affect MY reputation.
Bullshit. Microsoft *always* get the blame - even from people who should know better - even though 99% of "Windows problems" are really "software developer problems". That's why they go to such ridiculous lengths to maintain backwards compatibility - despite it often getting in the way of a better/cleaner implementation - because they know they'll always wear the blame for (frequent, gratuitous) developer fuckups.
Exhibit A: The multitude of applications that "require" Administrator accounts to run.
Exhibit B: The backlash against them for SP2 "breaking" applications.
Exhibit C: The plethora of low-quality hardware drivers
I have no problems whatsoever accepting responsibility for my errors. But there is no f..king way in HELL that I am going to send a client a programme and have them call me once a week bitching about how it keeps crashing becase it's MY fault, when it's because the damned thing is running on an unreliable piece of shit.
If your application is crashing, it's almost always going to be your fault.
Your post reeks of someone who hasn't used Windows since 1992 and thinks they are incapable of making mistakes. Even if you did write Windows software, I have little doubt it would be unstable and break every convention and best practice known just because "you know best".
No, the differentiation is important, because the consequences and remedies are significantly different.
"Inadequate security" would mean it's impossible to safely run a Windows system. Since this is demonstrably false - and fairly trivial to enforce in a managed environment - then it's simply not a factor.
Software bugs, OTOH, the end user - even administrators - can do very little to fix.
Most security problems are software bugs.
Rubbish. The vast majority of security breaches come from end users, either deliberately (corporate espionage style) or inadvertently (running virus-laden files from email attachments or downloads).
Buggy software and users are what I am most worried about, in this order.
Then your priorities are backwards. The most common vector into the typical machine for malicious code is the end user deliberately executing it, either knowingly or unknowingly. Accidental code execution via software bugs follows a distant second. Remote code execution - automated or otherwise - is barely even on the scope. These first two vectors are *precisely* the holes that anti-spyware and anti-virus software tools attempt to plug and OS-level security is largely incapable of closing.
Then how can it be possible to run a problem-free Windows installation simply by following a handful of common-sense pointers ?
No, it doesn't.
I repeat: anti-spyware and anti-virus software aren't there to protect you against "inadequate security". They *may* do this as a side effect, but it is not their purpose.
I suspect you have not extensively used Internet Explorer on a user with administrator rights (MS Windows default) to browse the Internet.
No. Nor would I ever consider doing it.
If you had, you would have collected spyware without agreeing to install anything.
Undoubtedly. But this would be due to software bugs (and, arguably, bad UI), not "inadequate security" - not to mention the foolishness of browsing the web with a high-privilege account.
With Windows XP (original release, no SP 1) just connecting to the Internet from a user with administrator rights, without a firewall, is enough to be infected by worms within a short time.
As is installing many Linux distros and commercial unixes from the same time period. Again, you are largely describing problems caused by software bugs, not "inadequate security". I will agree that the firewall should have been enabled by default from the first release of XP and that services shouldn't be binding to external network interfaces by default - but even without that, all those remote exploits are coming from *coding errors*.
OS-level security - which Windows NT has in spades - can protect you against some aspects of malicious code. However, it cannot protect you against all, or even the most common, aspects of malicious code. That is what anti-spyware and anti-virus software is for.
Yes. Just like every other bit of non-Public Domain software you didn't write yourself.
Why should I pay to fix their software??
You shouldn't.
Which three ?
Except anti-spyware and anti-virrus software isn't protecting you against "inadequate security", it's protecting you against user error - the stuff OS-level "security" can't.
Unfortunately, users can't be patched.
Quite arguable.
[...] allow users to change the time without root priviledges.
Linux certainly doesn't:
Unless, of course, you're root:
I don't have an OS X machine handy since I didn't bring my iBook to work today, but I would imagine - and certainly *hope* - that OS X requires an admin user authentication before allowing the time to be changed.
I'm sorry I don't understand your crazy Windows ways.
It's got nothing to do with "Windows ways". Allowing unprivileged users to change the system time is security hole.
Actually, as I understand the reason that *nix lets users change the time is because they're not changing system time, they're changing their individual user time.
I don't understand what you mean by "individual user time". In Linux (and UNIX) normal users cannot change the time. Even "user friendly" distros like Ubuntu require the user to authenticate via sudo before allowing them to change the time.
I think you are confused.
Which, as far as protecting the system from dumbass users goes, makes a hell of a lot more sense than the Windows way.
Right. So explain to me again how *pretending* to let users change the time rather than saying either "permission denied" or "authorise yourself to continue" does a better job of "protecting the system" ?
I would argue that editing text files is an atrocious form of configuration modification - outside of disaster-recovery scenarios - for everyone, regardless of skill level.
No, blame Linux. If Linux had a stable kernel ABI (like, say, every other remotely mainstream OS), so 0.0.0.1 kernel revisions/patches didn't break every binary module, requiring a recompile, then video card manufacturers (not to mention everyone else who writes drivers) would be able to create a simple, consistent driver package that didn't require intimate knowledge of your exact kernel version to install.
Vista doesn't have particularly high hardware requirements (I was surprised they weren't higher). Even a mid-range PC from ~3 years ago is only likely to require a memory upgrade - (and even that's unlikely, in the case of an enthusiast) - and a "high end" PC ~5 years ago should be capable with a cheap video card upgrade.
That's assuming you want the fancy Aero interface, of course - if the "Classic" interface is good enough for you then anything back to about 7 years should be ok, maybe needing more RAM.
Any remotely serious gamer (ie: the context of this article) will have had a PC more than capable of running Vista for years already. Compared to the hardware requirements of current (and upcoming) games, Vista is a lightweight.
[...] and even needs a GPU upgrade for DX10.
So did DX9 and various other fancy new technologies like Pixelshader 3.0. Again, if you're a serious gamer, you'll already be planning (or have committed to) a video card upgrade, just to play games, that will be more than sufficient for Vista.,
Good advice. I'd never support a company whose business plan was so narrow as to only target ~95% - 99% of their potential market, either.
And XP running DOS programs dating from the mid 80s is not at all uncommon.
DOS games - as anyone dating from the era should know - *frequently* relied on direct access to hardware and undocumented bugs/quirks/features in both hardware and the different versions (and brands) of DOS. That they often don't work in a compatibility layer that doesn't allow direct hardware access and typically only reproduces documented functionality, is hardly surprising. They are a special case.
Shit, with many later DOS games (eg: just about anything from Origin) it was often a challenge getting it to run *in regular MS-DOS* - and you're expecting compatibility from a completely different OS ?
If you cannot understand why adjusting the system time needs elevated privileges, you're probably not qualified to be making any comments about security. At all.
You don't think the completely new display subsystem and video driver model in Vista might have just a little bit to do with it ? Just maybe ?
For example ?
Microsoft has never shown themselves to be worried about breaking backward compatibility.
Considering the ridiculous lengths Microsoft commonly go to so that backwards compatibility is preserved, that's pretty funny.
You were shooting for "+1, Funny" right ?
DRM - as a concept - is just a logical progression of copyright law. I think you'll find there's a lot of people who are pro-copyright.
Personally I would argue that the hardware/OS support and ongoing maintenance hassles of DIY more than cover the additional cost of off-the-shelf hardware like Promise's vTrak chassis, but that's coming from a business-production-environment perspective. I can certainly see why use for home would consider $$$ saved up front far more important than ongoing "user time costs".
The biggest performance-related problem in building your own SAN/NAS is that most - if not all - consumer level motherboards have pitiful amounts of I/O bandwidth. Usually just a single ~130M/s PCI bus, which even a small four-disk array is more than capable of flooding. New machines have more I/O bandwith in the form of PCIe, but it's usually tied up amongst too few slots and PCIe disk controllers are still usually uncommon, expensive and poorly supported in terms of drivers.
I would suggest chasing up some old Xeon server motherboards (single or dual CPU) with multiple PCI-X slots and buses, then some four or eight slot SATA controllers. Ideally, you want SATA controllers that are either 66Mhz PCI (most Promise cards support this) or PCI-X (most 8-port and larger controllers support this). I suggest Xeon boards because very few P3 or Athlon "server" boards even have PCI-X and most that do only have one or two 64/66Mhz buses, shared among multiple slots. They also tend to be relatively expensive. "High end" (for their day) [dual] Xeon boards often have 4 - 5 PCI-X slots, often shared between two or three 64 bit, 133Mhz PCI-X buses.
The other big problems you will find are cooling and power.
* Cooling, because drives - particularly close packed - generate a lot of heat and overheated hard disks die very quickly. Ideally you want to keep your drives down around the 30 - 35 degrees C mark. I use 4-in-3 Coolermaster drive cages with integrated 12cm fans a a cheap solution, but there are also numerous 4-in3 and even 5-in-3 "hotswap" cages that are more expensive. Ignore people who tell you they are only for "CM Stacker" cases, they fit fine into any set of three 5.25" drive bays.
* Power, because while a dozen hard disks idling (or even in heavy use) don't use a lot of power, when they all spin up at once they do draw a lot of current - and most SATA drive/controller combos aren't capable of staggering drive spinups. New PSUs these days have ridiculously high capabilities, however, these days, so it's becoming much less of a problem.
CPU grunt is basically irrelevant. Even a few hundred Mhz worth of P2 is capable of doing RAID5 checksumming faster than any array you're likely to assemble with consumer-level parts and by the time you get a semi-decent motherboard, the slowest/cheapest CPU you can put into it is already ~10x faster than it needs to be.
Note that most cheap SATA controllers are cheap for a reason - they suck. Either their performance is atrocious, they don't play play well with multiple controllers in the same box, or they throw mysterious errors when used in software RAID arrays (ie: with all ports busy simultaneously). Somewhat ironically, however, many hardware RAID controllers (real hardware RAID controllers) give better performance overall when used as a dumb controller and Linux software RAID, than when configured to use hardware RAID.
Something like this ?
I haven't dealt with software RAID enough to know how accurate that statement is.
Speaking as someone who has moved a single array between about 5 machines over its lifetime, including from kernel 2.4 machines to kernel 2.6 machines, I'd say that if you've got a Linux software RAID array, it'll probably work on any Linux machine you can find to plug it into (assuming that machine has appropriate drives for the disk controllers and RAID level).
Firstly, make sure your rebuild isn't being throttled. cat /proc/sys/dev/raid/speed_limit_max will print out the maximum speed (in kb/sec) the array will rebuild at. Use something like echo 100000 > /proc/sys/dev/raid/speed_limit_max to set it suitably high so that the throttling won't occur.
Secondly, the limiting factor in your rebuild speed will be (in decreasing order of likelihood) bus bandwith, individual disk performance, disk controller or driver bugs/quirks/limitations, CPU speed. Although if you have PCIe or PCI-X disk controllers (unlikely) you may hit limits in individual disk performance before you run out of bus bandwidth. With a 2.4Ghz P4 I can pretty confidently say your bottleneck will never be the CPU.
In your case, your machine almost certainly has all the drives hanging off a single 33Mhz, 32 bit PCI bus. So the absolute upper limit on your array's performance is going to be around 120M/s, and that's assuming the machine isn't doing anything else except rebuilding the array. You're only ever likely to see this sort of performance off the array from long, sequential reads, however (dd if=/dev/md0 of=/dev/null type of thing).
(This is a rough overview). With 4 drives, you have roughly 30M/s per drive maximum, so your best-case RAID rebuild speed will be about 30M/s - this is assuming your drives can sustain 30M/s for both reads and writes across their entire surface. Rebuilding a RAID5 array involves reading data and parity from N-1 drives and writing it to the Nth drive - in other words you have to completely reconstruct a single disk. At 30M/s, it should take about 250000/30/60 ~= 138 minutes to copy the 250G necessary to reconstruct that disk.
(Tech-savvy readers should realise at this point why hardware RAID is theoretically faster than software RAID - particularly for average PCs and/or large numbers of drives - and why it has nothing to do with the "overhead" of calculating RAID5/6 parity.)
Note that 138 minutes is a best case scenario, so it taking 36 hours could be explained by you using the system at the same time, automated system maintenance occurring, less-than-stellar drivers, etc, etc. With such a massive difference between "should be" and "was", however, I'd be examining the individual components pretty closely to see where the bottleneck is. What's the maximum performance you can get from each individual drive (use hdparm and dd). How about from the entire array ?
Probably less - most hardware RAID cards throttle the rebuild process by default (which you can also do in software RAID - at least on Linux).
Added to that, the bottleneck in the rebuild process is the IO bandwidth, not the CPU power. Even something pitifully slow (by modern standards) like a 300Mhz P2 has a RAID5 checksumming speed well into the hundreds of megabytes a second.
On any remotely modern CPU, the overhead of software RAID is miniscule to the point of irrelevance.
Not really. It would, however, need quite a bit of I/O bandwidth - something the vast majority of PCs have very little of.
(This is assuming you want to serve up something over gig ethernet - at 100Mb ethernet speeds pretty much anything will be sufficient, although large array [re]build times will be long).
Only if the eyeballs are any good and are actually interested in looking at the code.
It's a bit like the draftees vs professional soldiers situation.
A small, well trained group of code auditors will be far more effective at finding coding errors than a large group of amateurs - and they'll do it even in code they have no personal interest in.