Seagate don't fine you if you put Hitachi disks in some of your machines. If they do, or ever did, the analogy is fair and I stand corrected.
I would imagine if you've signed an exclusive supplier contract with Seagate and received a tidy discount for doing so, then Seagate find out you're putting Hitachi drives in their laptops, they'd be inclined to "fine" you (and quite justified in doing so).
After ~20 years in the industry, through thousands (probably tens of thousands) of PCs - everything from no-name dsektops to high-end IBM blade servers, I think I've witnessed (or received direct reports of) 3 or 4 PSU failures ever.
Heck, if someone asked me to rank the components most likely to fail in a computer, the PSU would probably be sitting just above screw holes and mounting posts.
WTF are you people doing to your computers ? Is the power supply in Australia really that much better than the rest of the world ?
Sure, but a good SAN has to worry about not losing that cache in case of a power failure, which adds a series of costs and design trade-offs that drive the cost up beyond just the RAM.
Battery-backed cache and cache destaging are hardly a groundbreaking ideas, nor is scaling the battery or "UPS" capacity to allow for the cache size.
That's one reason why it's not really fair to compare a chunk of RAM to an enterprise grade write caching solution.
It most certainly *is* fair. Larger amounts of cache available on higher-end systems (that are otherwise using the same theory - eg: EMC AX150 vs CX3-80) demonstrate the technical aspect(s) of the problem is/are already solved. At which point the issue *is* just the marginal cost of more RAM (and possibly more battery capacity).
Not if you've got 14 satellite sites of 2 or 3 people. Am I meant to setup and maintain 15 BDC's (includes 1 BDC at the main office)?
That depends entirely on what you're trying to achieve. Is there a fileserver at each office ?
I'd love to set up a WSUS server but unfortunately I haven't found out hoe to tell the laptops to go to the internet for updates when they cant get to the WSUS server..
That's because it would defeat the main reason for using WSUS, which is so *you* control that updates that the machines have rolled out to them.
If all you want to do is update the machines, then you push out a.reg to all of them setting the necessary Registry Keys to automate the updates.
That only leaves the problem of my 125KB/s versus 400 students all wanting updates.
Right. So your problem isn't with WSUS, or even Windows, at all - it would be the same regardless of the platform.
If it were a simple matter of setting up WSUS, I'd make the policy changes here before sending out the machines. It's also a matter of my budget not allowing a monster net connection.
Then why aren't you setting the policy for them to automatically update from Microsoft's servers ?
Incidentally, going back to your original post:
[...] which is a problem with the way they've hyper-integrated the kernel, the IE engine, and the shell. If things weren't tied together so tightly, a lot less reboots would be needed, and I'd imagine fewer people would be clicking 'later, go away' on WUAU notifications.
There is nothing "hyper-integrated" about the kernel, IE and the shell in Windows. They have exactly the same relationship as, say, GNOME or KDE on Linux, or Safari (more accurately, WebKit) and OS X. The reason updates "require" reboots is because that's the only way you can be sure with a typically ignorant end user at the helm, everything that needs to be replaced and/or restarted has been.
You might find this hard to believe, but the Navy actually employs engineers on their ships to run their computer systems, and expects them to be able to do more than treat those systems like your cable box at home.
I don't find it hard to believe at all.
I do find it hard to believe they would have been allowed - by either technology or protocol - to just plug in a keyboard to a handy port and restart a service to get everything up and running again.
All the wikipedia page says is that the error "brought down all the machines on the network". How are you marshaling that in support of your interpretation of events?
The part that says "[...] a crew member entered a zero into a database field causing a divide by zero error in the ship's Remote Data Base Manager [...]".
Anyway, I was on the internet when this actually happened and read the news articles about it, both Navy and MS statements.
So was I, and I remember the same hysterical "OMGWTF! Micro$oft was involved, clearly everything that happened must have been their fault" bigots crawling out of the woodwork then, blithely ignoring all the other more likely explanations (which would have been perfectly acceptable if, say, Linux was involved) in favour of the one that pandered to their bias.
Most of those aren't around any more, but if you'd be so bold as to read the Wired article that is cited as the source of the incident, you'd see that it was a divide-by-zero that then resulted in a buffer overrun. That buffer overrun would have been in the exception handler, which was probably (not necessarily, but if the designers weren't thinking of divide-by-zero errors, then probably) the default Windows handler. A buffer overflow in the kernel could crash the system and require a hard reboot very easily, though the conditions leading to that overflow could be specific and/or rare.
The application was running in user space (and if it wasn't, then it still wouldn't be the fault of Windows).
The reality of the situation is that there at least half a dozen quite reasonable, rational, and likely explanations that could apply before the spectre of an error in a user space program bringing down Windows NT. Which can be quite seen easily by considering the summarisation of the event without mentioning the OS.
"On 21 September 1997 while on maneuvers off the coast of Cape Charles, Virginia, a crew member entered a zero into a database field causing a divide by zero error in the ship's Remote Data Base Manager which brought down all the machines on the network, causing the ship's propulsion system to fail."
Confronted with the above, what would be the reasonable conclusions (bear in mind we're talking about a software package that was rushed and didn't even bother to perform basic user input validation or exception catching) ? A system that can't be easily restarted ? Corrupted database stopping the application from restarting ? Lack of people with low-level knowledge of the system on board ? A mission protocol that says certain types of failures are an automatic return to port ?
Or that a user space application crashed a multiuser, memory-protected OS ?
What does Occam's Razor suggest the most likely answer is ?
According to whom ? How do you know what they actually meant when they said "reboot" ? A typically ignorant end user would probably calling killing X with Ctrl+Alt+Backspace 'rebooting', but that wouldn't mean the computer was actually rebooted.
If only the application had crashed, and Windows had recovered correctly, only the application would have had to be restarted.
Right. Just like when the menu system in my cable box crashes, but it keeps merrily recording in the background, all I need to do is restart the "menu application".
Oh, wait. I can't just "restart the menu application" because there is no way to do that on an appliance that has no generic interface. I have to softboot or power-cycle it.
When a computer doing something like that "crashes", end users don't fuck around trying to "restart the application" (assuming they even knew how). It's not their job to troubleshoot the problem, and they almost certainly have no idea how to even begin doing so. They reboot, because that's what they've been told to do.
The Navy also said that Windows had crashed, and when Microsoft tried to defend themselves by blaming the application for dividing by zero, they did not contradict the Navy's claim that Windows failed to handle it properly.
Really ? That's not what the Wikipedia page says. Perhaps you have a more credible source ?
So that's evidence. Proof may be impossible to come by, but oh well this is the internet and that's better evidence than Windows not crashing due to a divide-by-zero exception when running an application that does not generate divide-by-zero exceptions.
So we have two choices:
1. Windows can't handle a divide-by-zero exception in user space, but apparently the only time it has ever been recorded is on the USS Yorktown (or there is a huge conspiracy trying to cover up this basic bug).
2. The completely reasonable, rational, and plausible explanations of both the failure and the response to it that have been already given are right.
I know the suggestions are a healthy mix of 'how I'd do it' and 'UR DOIN IT RONG', but I'm really one of those cases where the MS Way simply will not work, no matter how much or little I'd like it to.
So push out.reg files to the machines and make them use your updates server. You don't _have_ to use GPOs to configure WSUS on the client side.
MS has a reputation of being easy to use, but I can't figure out where that rep came from. Every time I get a new version of Windows or Office at work my productivy goes through the floor because I have to learn to use the damned thing all over again, as it's more different from its earlier counterpart than from its competetion.
Bullshit.
There are two examples of having to "learn to use the damned thing all over again" for Windows and Office in the last 20 years: Windows 95 and Office 2007.
Another weakness (in both WU and FF) is that neither will ask the user to log in as admin and install updates. WU will just do it and reboot the computer in the middle of whatever you were doing (such as giving a presentation to potential clients using a laptop that had been off for a couple of weeks. No, the "Rebooting in 5 minutes" bar does not have a cancel button if you're not an administrator) unless there's a EULA to click, in which case it does jack shit (in the case of my mother's computer, which I have to remind her to log in as admin every once in a while to install any updates requiring her to click I Agree, then log back in as her unprivileged user before Teh Nasties take over her computer.
This is your IT support's fault, not Windows Update's.
Not having input validation on a userland application should NEVER be the reason a whole OS goes belly-up.
Indeed.
Your suggestion could be interpreted that Microsoft was not to blame on the Yorktown debacle, which is wrong.
They weren't. The application crashed, not the OS. It is trivial to demonstrate that Windows NT can handle a userspace application dividing-by-zero, you just use Calculator.
Source for obvious reasons. I know the Brits and Americans are friends, but still, running an OS that is doing Bill-knows-what doesn't sound very secure in many ways (Would you want the US military running a closed source Red Hat Linux sight unseen?). Even if there is no backdoors/spying, the ability to compile the source and see what it is doing at every step will have benefits in the future, to look for holes previously unknown, to see what it is doing every step of the way, or to graft new abilities into it.
What makes you think they haven't got a contract with Microsoft for access to the source code ?
That's through a switch, on a reasonably active network, without even the slightest attempt at tuning. I have little doubt I could push that up to 80+MB/sec without much effort (albeit probably not with SCP, which has other performance limitations) and I've gotten 150MB/sec with bonded NICs and iSCSI.
Actually the network CAN be the bottleneck even at low throughput. We had an Oracle server that saw an ~20% decrease in CPU load and significant reduction in latency by going with a TOE card, a $50K server (running several times that in software) sped up significantly with the addition of an $800 card, the best bang for the buck I have seen in over a decade in IT.
How did you manage to get a $50k server that didn't already have a TOE card in it in the first place !? Heck, even bottom of the barrel 1U servers have had TOE NICs in them for years.
"switch" by their definition in the user manual simply means hub, except it can amplify the signal. No actual switching involved, other than the fact that it can "switch" between 10Mb/s, 100Mb/s and 1000Mb/s. {sigh}
Wow. I didn't think it was even possible to buy a gigabit hub.
I was having a discussion with someone who does SAN work. He was all happy about his piece of equipment. I found out the specs of the components, and then priced it out with better PC based stuff running Linux.
[...]
I'm slowly prepping a friends place to have a Linux machine be the SAN. Decent parts, standard protocols (SMB, NFS, and iSCSI). The only "slowly" part is that there is no rush right now, so when I see something that'll do it well, we buy the parts. Once we have all the parts, it'll be a running machine.
Do your Linux-based "SANs" provide dual (ideally active/active) controllers with battery-backed, mirrored cache ? Because even low-end $10-$20k devices like the Dell MD3000i or EMC AX4-5 do that these days.
Instead of arguing from the "theory" side though, I'd rather say this - evolution is a theory, but the scientific community holds to it as if it WERE a law.
That's because it's so well understood and supported by the observed evidence.
In other words, they have decided that no other explanation should be allowed.
On the contrary, a genuine alternative to Evolution would be almost incomprehensively big news.
That's why there is a theory of gravity. But there's a law of gravity also. The law of gravity has been observed since the beginning of time, correct? What exactly causes gravity is still a mystery.
So it's basically the same as Evolution, then (other than more being known about how Evolution actually works) ?
A custom-built box, as many commenters suggested, seemed a tad inappropriate to me as he asked for an NAS device, not a server. Installing Ubuntu or whatever on it seems like more of a performance hit than a properly optimized "off the shelf" NAS box, since they most likely don't run Dbus, GNOME, Hald, bluetooth or any other desktop software atop the basic kernel and networking services.
While this is true, for noticably less than you'll pay for a NAS appliance, you can build a PC with vastly more CPU power and RAM (in particular, storage vendors - even with high-end, full-blown SAN solutions - are offensively stingy with cache), which will more than make up for any extra stuff that might be running.
You need to spend a LOT on an "appliance" type storage system to get something that has higher performance and/or better features than a "server". Particularly with cache, storage vendors across the board are offensively stingy (16 gigs of high-quality ECC RAM costs maybe $800, but you'll be lucky if your $100k SAN comes with half that amount).
Personally I would recommend the OP looks at Server/NAS-style "appliances" like Dell's NF500. They're the only sort of "cheap" turnkey devices he'll find that will deliver the performance he seems to want, and will probably only cost a grand or two more than DIY.
Well it looks like SMB is your best bet for compatibility. For a budget, just go with a small Linksys or Cisco device, as you can specify the hard drive and the network around it governs the speed.
This isn't really true. For *lots* of low-end NAS devices, the performance limitation is their puny CPUs, that can barely shift bits fast enough to saturate a 100M link.
Slashdot Mirror
Seagate don't fine you if you put Hitachi disks in some of your machines. If they do, or ever did, the analogy is fair and I stand corrected.
I would imagine if you've signed an exclusive supplier contract with Seagate and received a tidy discount for doing so, then Seagate find out you're putting Hitachi drives in their laptops, they'd be inclined to "fine" you (and quite justified in doing so).
After ~20 years in the industry, through thousands (probably tens of thousands) of PCs - everything from no-name dsektops to high-end IBM blade servers, I think I've witnessed (or received direct reports of) 3 or 4 PSU failures ever.
Heck, if someone asked me to rank the components most likely to fail in a computer, the PSU would probably be sitting just above screw holes and mounting posts.
WTF are you people doing to your computers ? Is the power supply in Australia really that much better than the rest of the world ?
Sure, but a good SAN has to worry about not losing that cache in case of a power failure, which adds a series of costs and design trade-offs that drive the cost up beyond just the RAM.
Battery-backed cache and cache destaging are hardly a groundbreaking ideas, nor is scaling the battery or "UPS" capacity to allow for the cache size.
That's one reason why it's not really fair to compare a chunk of RAM to an enterprise grade write caching solution.
It most certainly *is* fair. Larger amounts of cache available on higher-end systems (that are otherwise using the same theory - eg: EMC AX150 vs CX3-80) demonstrate the technical aspect(s) of the problem is/are already solved. At which point the issue *is* just the marginal cost of more RAM (and possibly more battery capacity).
Not if you've got 14 satellite sites of 2 or 3 people. Am I meant to setup and maintain 15 BDC's (includes 1 BDC at the main office)?
That depends entirely on what you're trying to achieve. Is there a fileserver at each office ?
I'd love to set up a WSUS server but unfortunately I haven't found out hoe to tell the laptops to go to the internet for updates when they cant get to the WSUS server..
That's because it would defeat the main reason for using WSUS, which is so *you* control that updates that the machines have rolled out to them.
If all you want to do is update the machines, then you push out a .reg to all of them setting the necessary Registry Keys to automate the updates.
Even if they do, unless they compile the source code themselves with a compiler they know they can trust there's no certainty over what is running.
So exactly the same problem they'd face with Open Source, then ?
That only leaves the problem of my 125KB/s versus 400 students all wanting updates.
Right. So your problem isn't with WSUS, or even Windows, at all - it would be the same regardless of the platform.
If it were a simple matter of setting up WSUS, I'd make the policy changes here before sending out the machines. It's also a matter of my budget not allowing a monster net connection.
Then why aren't you setting the policy for them to automatically update from Microsoft's servers ?
Incidentally, going back to your original post:
[...] which is a problem with the way they've hyper-integrated the kernel, the IE engine, and the shell. If things weren't tied together so tightly, a lot less reboots would be needed, and I'd imagine fewer people would be clicking 'later, go away' on WUAU notifications.
There is nothing "hyper-integrated" about the kernel, IE and the shell in Windows. They have exactly the same relationship as, say, GNOME or KDE on Linux, or Safari (more accurately, WebKit) and OS X. The reason updates "require" reboots is because that's the only way you can be sure with a typically ignorant end user at the helm, everything that needs to be replaced and/or restarted has been.
You might find this hard to believe, but the Navy actually employs engineers on their ships to run their computer systems, and expects them to be able to do more than treat those systems like your cable box at home.
I don't find it hard to believe at all.
I do find it hard to believe they would have been allowed - by either technology or protocol - to just plug in a keyboard to a handy port and restart a service to get everything up and running again.
All the wikipedia page says is that the error "brought down all the machines on the network". How are you marshaling that in support of your interpretation of events?
The part that says "[...] a crew member entered a zero into a database field causing a divide by zero error in the ship's Remote Data Base Manager [...]".
Anyway, I was on the internet when this actually happened and read the news articles about it, both Navy and MS statements.
So was I, and I remember the same hysterical "OMGWTF! Micro$oft was involved, clearly everything that happened must have been their fault" bigots crawling out of the woodwork then, blithely ignoring all the other more likely explanations (which would have been perfectly acceptable if, say, Linux was involved) in favour of the one that pandered to their bias.
Most of those aren't around any more, but if you'd be so bold as to read the Wired article that is cited as the source of the incident, you'd see that it was a divide-by-zero that then resulted in a buffer overrun. That buffer overrun would have been in the exception handler, which was probably (not necessarily, but if the designers weren't thinking of divide-by-zero errors, then probably) the default Windows handler. A buffer overflow in the kernel could crash the system and require a hard reboot very easily, though the conditions leading to that overflow could be specific and/or rare.
The application was running in user space (and if it wasn't, then it still wouldn't be the fault of Windows).
The reality of the situation is that there at least half a dozen quite reasonable, rational, and likely explanations that could apply before the spectre of an error in a user space program bringing down Windows NT. Which can be quite seen easily by considering the summarisation of the event without mentioning the OS.
"On 21 September 1997 while on maneuvers off the coast of Cape Charles, Virginia, a crew member entered a zero into a database field causing a divide by zero error in the ship's Remote Data Base Manager which brought down all the machines on the network, causing the ship's propulsion system to fail."
Confronted with the above, what would be the reasonable conclusions (bear in mind we're talking about a software package that was rushed and didn't even bother to perform basic user input validation or exception catching) ? A system that can't be easily restarted ? Corrupted database stopping the application from restarting ? Lack of people with low-level knowledge of the system on board ? A mission protocol that says certain types of failures are an automatic return to port ?
Or that a user space application crashed a multiuser, memory-protected OS ?
What does Occam's Razor suggest the most likely answer is ?
That the systems had to be rebooted.
According to whom ? How do you know what they actually meant when they said "reboot" ? A typically ignorant end user would probably calling killing X with Ctrl+Alt+Backspace 'rebooting', but that wouldn't mean the computer was actually rebooted.
If only the application had crashed, and Windows had recovered correctly, only the application would have had to be restarted.
Right. Just like when the menu system in my cable box crashes, but it keeps merrily recording in the background, all I need to do is restart the "menu application".
Oh, wait. I can't just "restart the menu application" because there is no way to do that on an appliance that has no generic interface. I have to softboot or power-cycle it.
When a computer doing something like that "crashes", end users don't fuck around trying to "restart the application" (assuming they even knew how). It's not their job to troubleshoot the problem, and they almost certainly have no idea how to even begin doing so. They reboot, because that's what they've been told to do.
The Navy also said that Windows had crashed, and when Microsoft tried to defend themselves by blaming the application for dividing by zero, they did not contradict the Navy's claim that Windows failed to handle it properly.
Really ? That's not what the Wikipedia page says. Perhaps you have a more credible source ?
So that's evidence. Proof may be impossible to come by, but oh well this is the internet and that's better evidence than Windows not crashing due to a divide-by-zero exception when running an application that does not generate divide-by-zero exceptions.
So we have two choices:
1. Windows can't handle a divide-by-zero exception in user space, but apparently the only time it has ever been recorded is on the USS Yorktown (or there is a huge conspiracy trying to cover up this basic bug).
2. The completely reasonable, rational, and plausible explanations of both the failure and the response to it that have been already given are right.
No, the OS crashed too, because it failed to handle the exception properly.
Evidence ? Perhaps some examples of other applications that can crash Windows when they divide by zero ?
I know the suggestions are a healthy mix of 'how I'd do it' and 'UR DOIN IT RONG', but I'm really one of those cases where the MS Way simply will not work, no matter how much or little I'd like it to.
So push out .reg files to the machines and make them use your updates server. You don't _have_ to use GPOs to configure WSUS on the client side.
MS has a reputation of being easy to use, but I can't figure out where that rep came from. Every time I get a new version of Windows or Office at work my productivy goes through the floor because I have to learn to use the damned thing all over again, as it's more different from its earlier counterpart than from its competetion.
Bullshit.
There are two examples of having to "learn to use the damned thing all over again" for Windows and Office in the last 20 years: Windows 95 and Office 2007.
Yeah, cause Active Directory scales great over the internet, and EVERYONE has a 100Mb connection or better at their place of business.
AD scales fine over a WAN if you have a DC at your satellite sites.
Another weakness (in both WU and FF) is that neither will ask the user to log in as admin and install updates. WU will just do it and reboot the computer in the middle of whatever you were doing (such as giving a presentation to potential clients using a laptop that had been off for a couple of weeks. No, the "Rebooting in 5 minutes" bar does not have a cancel button if you're not an administrator) unless there's a EULA to click, in which case it does jack shit (in the case of my mother's computer, which I have to remind her to log in as admin every once in a while to install any updates requiring her to click I Agree, then log back in as her unprivileged user before Teh Nasties take over her computer.
This is your IT support's fault, not Windows Update's.
That would imply that there was 1 application running the whole ship. Is that true?
No, it would imply there was one application running the propulsion system, which failed, as per the Wikipedia article linked above.
Alternatively, it could mean there was one central application which all the other applications relied on that crashed. Like, say, a database.
It would be known in advance to be error prone, hard to test and hard to maintain.
We're talking about developers who neglected to perform basic sanity checks on user-inputted data.
Not having input validation on a userland application should NEVER be the reason a whole OS goes belly-up.
Indeed.
Your suggestion could be interpreted that Microsoft was not to blame on the Yorktown debacle, which is wrong.
They weren't. The application crashed, not the OS. It is trivial to demonstrate that Windows NT can handle a userspace application dividing-by-zero, you just use Calculator.
Didn't the Brits hear about what happened to the USS Yorktown [wikipedia.org] when they tried Windows as a naval solution. God save the Queen, please.
Perhaps the Brits are smart enough to put user input validation into their applications ?
Source for obvious reasons. I know the Brits and Americans are friends, but still, running an OS that is doing Bill-knows-what doesn't sound very secure in many ways (Would you want the US military running a closed source Red Hat Linux sight unseen?). Even if there is no backdoors/spying, the ability to compile the source and see what it is doing at every step will have benefits in the future, to look for holes previously unknown, to see what it is doing every step of the way, or to graft new abilities into it.
What makes you think they haven't got a contract with Microsoft for access to the source code ?
[ZUR (UTC+0100) csmith@dr01
scp dr02:/tmp/1000.testfile
1000.testfile
100% 1000MB 47.6MB/s 00:21
[ZUR (UTC+0100) csmith@dr01
That's through a switch, on a reasonably active network, without even the slightest attempt at tuning. I have little doubt I could push that up to 80+MB/sec without much effort (albeit probably not with SCP, which has other performance limitations) and I've gotten 150MB/sec with bonded NICs and iSCSI.
Actually the network CAN be the bottleneck even at low throughput. We had an Oracle server that saw an ~20% decrease in CPU load and significant reduction in latency by going with a TOE card, a $50K server (running several times that in software) sped up significantly with the addition of an $800 card, the best bang for the buck I have seen in over a decade in IT.
How did you manage to get a $50k server that didn't already have a TOE card in it in the first place !? Heck, even bottom of the barrel 1U servers have had TOE NICs in them for years.
"switch" by their definition in the user manual simply means hub, except it can amplify the signal. No actual switching involved, other than the fact that it can "switch" between 10Mb/s, 100Mb/s and 1000Mb/s. {sigh}
Wow. I didn't think it was even possible to buy a gigabit hub.
I was having a discussion with someone who does SAN work. He was all happy about his piece of equipment. I found out the specs of the components, and then priced it out with better PC based stuff running Linux.
[...]
I'm slowly prepping a friends place to have a Linux machine be the SAN. Decent parts, standard protocols (SMB, NFS, and iSCSI). The only "slowly" part is that there is no rush right now, so when I see something that'll do it well, we buy the parts. Once we have all the parts, it'll be a running machine.
Do your Linux-based "SANs" provide dual (ideally active/active) controllers with battery-backed, mirrored cache ? Because even low-end $10-$20k devices like the Dell MD3000i or EMC AX4-5 do that these days.
Instead of arguing from the "theory" side though, I'd rather say this - evolution is a theory, but the scientific community holds to it as if it WERE a law.
That's because it's so well understood and supported by the observed evidence.
In other words, they have decided that no other explanation should be allowed.
On the contrary, a genuine alternative to Evolution would be almost incomprehensively big news.
That's why there is a theory of gravity. But there's a law of gravity also. The law of gravity has been observed since the beginning of time, correct? What exactly causes gravity is still a mystery.
So it's basically the same as Evolution, then (other than more being known about how Evolution actually works) ?
OS X doesn't support NFS? Linux doesn't support AFP?
Not as well as they (respectively) support SMB.
A custom-built box, as many commenters suggested, seemed a tad inappropriate to me as he asked for an NAS device, not a server. Installing Ubuntu or whatever on it seems like more of a performance hit than a properly optimized "off the shelf" NAS box, since they most likely don't run Dbus, GNOME, Hald, bluetooth or any other desktop software atop the basic kernel and networking services.
While this is true, for noticably less than you'll pay for a NAS appliance, you can build a PC with vastly more CPU power and RAM (in particular, storage vendors - even with high-end, full-blown SAN solutions - are offensively stingy with cache), which will more than make up for any extra stuff that might be running.
You need to spend a LOT on an "appliance" type storage system to get something that has higher performance and/or better features than a "server". Particularly with cache, storage vendors across the board are offensively stingy (16 gigs of high-quality ECC RAM costs maybe $800, but you'll be lucky if your $100k SAN comes with half that amount).
Personally I would recommend the OP looks at Server/NAS-style "appliances" like Dell's NF500. They're the only sort of "cheap" turnkey devices he'll find that will deliver the performance he seems to want, and will probably only cost a grand or two more than DIY.
Well it looks like SMB is your best bet for compatibility. For a budget, just go with a small Linksys or Cisco device, as you can specify the hard drive and the network around it governs the speed.
This isn't really true. For *lots* of low-end NAS devices, the performance limitation is their puny CPUs, that can barely shift bits fast enough to saturate a 100M link.