What I've always wondered is why we don't build more datacenters in colder climates here in north america. Why put huge commercial datacenters in places like Dallas or San Diego (there are plenty in each) when you could place them in Canada or Alaska? In a cold enough climate, you could just about heatsink the racks to the outside ambient temperature and have little left to do for cooling. I suppose the downside is 20ms of extra latency to some places, and perhaps having to put more fiber and power infrastructure in a remote place. But surely in the long run the cooling savings would win no?
I am also in the "no PS/2, but please leave 1 serial port" camp. For a linux box (and what better use for ITX is there?), it's really nice to have serial console support so that you don't have to ever hook up a keyboard and monitor. It's even better if the BIOS supports serial console redirection, so that you can even edit bios settings over the serial interface.
Until the BIOS guys come up with a way to do serial console over USB (which wouldn't be too hard really), I'd like the serial port to stay.
I should add an example of the sort of thing they might have an interest in communicating: "Warning: don't use particle accelerators to exceed the 1kTeV barrier" (which probably ends up being a hugely long message when sent in some kind of universally-understandable form), because they want more civilizations to "make it", and it's common for them to wipe themselves out by this method because of some aspect of physics that usually isn't obvious when one reaches the level of sophistication to attempt it.
Of course that specific message is unlikely, and we could never guess what the message would be or it would be pointless, but you get the idea.
I think you're spot-on that SETI is a waste in "probability of success" terms, if you're defining success as "snooping random intergalactic communications that might randomly pass near us in space and time". However, I think at least some SETI promoters are hopeful about a (potentially) higher probability signal source: advanced alien races that are broadcasting legacy radio waves specifically at us, or at other low-tech civilizations in general. An advanced alien race might surmise that most fledgling civilizations will go through a phase of electromagnetic communication, and want to impart some kind of information to us.
Who gives a crap about karma anyways? I can't believe anyone (myself included) even bothers to commenting here anymore, although somehow it keeps happening.
Precisely. If the transaction IDs are secure, then you have to play "man in the middle" to sniff the request and fake a response. But if you can guess the transaction IDs, you can blindly send a spoofed response from elsewhere on the net and fake out the user's DNS resolver. The details of doing this in practice can be tricky, but it's doable. That's why the dnsext working group has been trying to improve this aspect of the protocol. While MS's implementation has flaws that make it more predictable than it otherwise should be, the fundamental problem is with the decades-old DNS protocol to begin with. The transaction IDs are 16-bit numbers, which is very limiting if you need to generate secure sequences of them that can't be guessed. It's not too hard to just spam responses with random response IDs and get some small success rate with only 16 bits to play with.
One of the current proposals (which I'm not a fan of because of other technical implications for DNS) is that since DNS query names are case-insensitive and copied by the server from the request packet to the response packet, to use the "uppercase bit" of each letter as more bits for the secure transaction ID. The fact that people are willing to consider hacks like these should tell you something about how badly we're backed into a corner on this issue with the DNS protocol. Hopefully soon someone will do something sensible like standardize an EDNS1 with extra transaction ID bits in the OPT RR, and then in like 10 years (if history is any guide) it might actually see wide deployment.
I agree on a software level, but one must not forget that hardware access is even better than root access. Anyone who has physical access to a machine while not under intense, close scrutiny will be able to take over the machine and do whatever they want to it. So if you slap some mid-tower cases into some little semi-cubicles in a library, someone's going to hack them, regardless of operating system choice. They can always wait for the right time and quickly pop the case and swap in a new boot device which (very quickly) scans the other boot device and modifies security settings on it.
The way to fix this is to physically secure the machines. Lock them up in ventilated boxes under the desks, so that the users only have access to the screen, keyboard, and mouse (and then make sure you've kiosk'd that interface, so that certain hotkeys are disabled, etc).
Either that, or get away from the PC-per-user thing entirely. Just install some cheap color X-terminals for the users, and have them use services off of a farm of centralized machines in separate secured area. You can fit a lot more users per hardware dollar with Xterms. Instead of 8 stations = 8 PCs, it's 8 stations = 1 slightly beefier PC + 8 Xterms. (or whatever you decide your ratio to be).
This is trivial to prevent with ulimits, which are configured with a simple file in/etc. I would hope any sane distribution would default to having ulimits for users. If not, that needs to be rolled into the config for a library-like system.
I remember when Microsoft had more fanboys than it does today, but I don't remember *ever* liking them myself. My first Microsoft experience was using MS-DOS 2.11 on a Tandy 1000HX, because it was my first real computer and I didn't know any better. Windows didn't even exist at the time (at least as far as I knew). From that point forward I went through a string of different x86 operating environments, and the only rule of thumb was "Avoid Microsoft if at all possible". It was always DR-DOS and/or QEMM-386 (and DesqView) instead of the MS equivalents, DesqView/X and/or OS/2 2.x over Windows 3.x/95/NT, and eventually Linux instead of all of that once I found Linux circa 1994.
Another example is programming tools. It's not just the Visual[C/Basic/Whatever] of today that sucks - MS tools sucked all the way back to MASM, when the better alternative that I preferred was Borland's TASM. Microsoft always sucked, and smart people always knew it.
Of course the probability of finding something to complain about in Apple or Google's behavior increases the larger and more diverse the companies get. They'll still never be in the MS category. Google may eventually be "that company that started out as my best friend, but eventually made some sad mistakes much further down the road that hurt their reputation", but they'll never seem to have been evil incarnate from the get-go. Apple may occasionally make anti-consumer moves, but at least they've got a kick-ass design team and they truly love their user community and try to turn out some high quality code (and are using a *nix baseline, that's such a huge plus). MS has been using underhanded evil tactics to shove crappy solutions down unwitting consumers' throats from inception. I won't feel any remorse when and if they finally die off for good.
Syncing to GPS alone could be an issue for wide adopting as a last-mile technology though. It would really suck if intermittent GPS failure (due to extreme weather, military blackout, etc) caused everyone's last-mile links to malfunction due to bad timing. The situation could be remedied by ensuring the APs also have a very stable monotonic clock source to run from between GPS syncs, but it has to be stable enough to support your wireless timing at sufficient precision for hours or more. That will add cost and complexity to the solution. Something like an OCXO might do the trick ( http://en.wikipedia.org/wiki/OCXO ) and still be reasonably ok on cost/complexity. But if the timing needed enough precision to require rubidium, that would probably be a show-stopper.
The difference is that the subunits are instructed on what to do via a single procedural stream of instructions from the compiler's point of view. The CPU does some work to reorder and parallelize the instruction stream to try to keep all the subunits busy if it can, but it doesn't always do a great job, and the compiler also knows the rules for how a given CPU does the re-ordering/parallelization and tries to optimize the stream to better the outcome. This scheduling is taking place at a very low level with very small chunks of (or even single) instructions. Algorithms for auto-parallelizing code quickly in hardware don't really scale up to bigger chunks of code (and as we've seen, even when they deal with smaller chunks, the stream needs to be pre-optimized by the compiler for effectiveness).
But certainly this must be an area of active research. An "obvious" (if currently impossible) solution is to build an 80 core CPU that looks like a 4-core CPU to the operating system, and dedicates a few cores to auto-parallelizing the 4 instruction streams from the OS onto the remaining bulk of the cores. However if we had algorithms that could do that job reasonably effectively in realtime, we could certainly put those same algorithms in compilers and make them do an even better job in non-realtime. So that makes that approach seem silly.
Both languages have lots of idiots writing bad code in them. Perl is an extremely flexible and well-designed language, upon which many good modern layers of language meta-enhancement (have you looked at Moose - http://search.cpan.org/dist/Moose ?) have been built. PHP is an atrociously-designed language that only someone who loves things like HTML and Visual Basic could love.
Perl is the duct tape of the internet that real working people hold big things together with on a daily basis, PHP is the elmer's glue some 12 year old is trying to sniff to get high (in vain, because it's the new kind that you can't get high off of anyways).
Of course PHP's popular, it's very easy to deploy it and start writing code in it with zero skills (and to their honest credit, packaged full-blown PHP applications are generally easier to deploy than the equivalent in Perl), but that doesn't mean it's a good language to architect things in.
This sounded great up until the MSSQL part. Don't repeat your mistake and lock your company into more years of fighting bullshit and eventually migrating away again (or dying). If PostgreSQL can meet your needs (and really, there are very few needs it can't meet), migrate to that instead. Or if you really need certain enterprisey things that Pg doesn't have, then consider Oracle or DB2. But don't make the mistake of locking yourself into MSSQL as a way to get out of MySQL. MSSQL is just as bad as MySQL in its own unique ways, and Microsoft is famous for finding ways to trap you into long-term vendor lockin.
I agree about PostgreSQL being a better option for so many reasons (and this new Sun thing is just yet another on the list). The only thing PostgreSQL really needs is some kind of asynch multimaster replication. That's one place where you can get "forced" to use MySQL because Pg can't do what you need. MySQL's implementation of asynch multimaster replication sucks anyways, I'm sure the Pg community can do it better eventually.
Back to the topic at hand though, one way around the libmysqlclient GPL thing is to insulate yourself in a dynamic language where your code doesn't explicitly "link" with libmysqlclient. If you're using Perl (or any other similar language I would assume), DBD::mysql links to libmysqlclient.a, but your own Perl application can be whatever license you like and just "use DBI" (and DBD::mysql indirectly), which is not linking.
say() is a fairly pragmatic addition to the language. Do you have any idea the percentage of "print" statements in existing perl code which end in "\n". And how often that "\n" is the sole reason to use interpolating quotes and/or an append operator in the print statements (eg:
Actually, Perl 5.10 has been in release candidate state for a little while now, and someone recently just happened to drop an email reminding p5p of the upcoming anniversary and how cool it would be to release on the anniversary date, so it became a target to get the final out on that date. Without the anniversary to shoot for, it probably would've been a few days later. The fact that the anniversary happened to fall somewhere in the right vicinity was pure luck.
I think the 18 cutoff is reasonable. It's arbitrary, but due to high school ending about there, and all the associated "adult" responsibilities one gains, there does tend to be a pretty dramatic shift in maturity level somewhere within a couple of years of there. State laws differ on how they handle the age of consent stuff, but a lot of the more reasonable states using a sliding window near the age border, as in something like "anyone screwing anyone age 14-17 who is more than 3 years older than them is illegal", which lets 17 years have relationships with 20 year olds at max, and 14 year olds have sex with 17 year olds at max. These kinds of laws are pretty reasonable when you think about it. If a 21 year old guy is screwing a 16 year old girl, you know he's taking advantage of her mentally and physically in the majority of cases, and most of society would frown on it. You have to draw some rough lines in the sand somewhere.
There's a wide open market of customers who don't insist you do stupid things. If you've got skills, you don't have to cater to idiots. It's that simple.
Your non-MRAM scenario (battery-backed fast DDR volatile ram caches with flash drives behind them) is exactly what Texas Memory Systems has been doing for a while. If you really want to throw hardware at certain performance problems, their solutions are quite useful.
I whole-heartedly agree with you. However, I think there's sometimes a bias among otherwise smart people to only realize this thinking process is going on in certain situations and not others. For most "controversial" ideas where something could in theory be settled by the proper application of logic and science (although perhaps fully convincing data doesn't yet exist), the argumentative "believer" partisans operate like this on both sides of the argument. The Global Warming thing is a perfect example. Somewhere in between Gore and Bush lies the scientific truth behind the cause of the warming, but it seems everyone has already decided to "believe" one way or the other to the extreme anyways. Same thing with all of the other touchy political subjects, like abortion, guns, the death penalty, euthanasia, social welfare programs, tax/debt/spending issues, just about everything to do with the current USMiddle East situation, etc...
I think education is at the root of it all. If we (a) guaranteed a good education through age 18-ish to everyone in the US (we don't, most of them get shitty educations) and (b) ensured that the core focus of that education was not memorizing facts to pass a test, but instead learning how to reason, apply logic, and learn new things independently, we might see some improvement after a few generations.
I do this in all of my active defense systems for production sites. I tend to make the firewall rules reasonably aggressive at detecting anything that looks remotely like attack traffic (connections on ports that neither us or customers are ever supposed to use but do see attack traffic (22, 139, etc...), tcp flag combos common in stealth scanners, certain known exploit string matches on port 80 traffic, etc), but the offending IPs are only blacklisted for a few minutes at first, ramping up to perhaps half a day if they're persistent within the blacked-out time window. This is more than enough to deter most automated (and even a few manual) attackers, assuming you're not protecting super valuable data. Still, there's no excuse not to be proactively checking up on your defenses and making sure things are behaving well.
I think your comment is a good example of why tinyurl-ish things are dangerous. You, like most tinyurl users, aren't really thinking through all of the layers involved here. If you use tinyurl for all of the links you publish, none of your links will work if tinyurl crashes (and they'll all be hijacked if tinyurl is cracked). If 80% of twitter links use tinyurl, same deal. It defeats the normal inherent robustness of the internet if a significant random subset of the traffic is being routed through a single service somewhere just to shorten the names.
Slashdot Mirror
What I've always wondered is why we don't build more datacenters in colder climates here in north america. Why put huge commercial datacenters in places like Dallas or San Diego (there are plenty in each) when you could place them in Canada or Alaska? In a cold enough climate, you could just about heatsink the racks to the outside ambient temperature and have little left to do for cooling. I suppose the downside is 20ms of extra latency to some places, and perhaps having to put more fiber and power infrastructure in a remote place. But surely in the long run the cooling savings would win no?
I am also in the "no PS/2, but please leave 1 serial port" camp. For a linux box (and what better use for ITX is there?), it's really nice to have serial console support so that you don't have to ever hook up a keyboard and monitor. It's even better if the BIOS supports serial console redirection, so that you can even edit bios settings over the serial interface.
Until the BIOS guys come up with a way to do serial console over USB (which wouldn't be too hard really), I'd like the serial port to stay.
I should add an example of the sort of thing they might have an interest in communicating: "Warning: don't use particle accelerators to exceed the 1kTeV barrier" (which probably ends up being a hugely long message when sent in some kind of universally-understandable form), because they want more civilizations to "make it", and it's common for them to wipe themselves out by this method because of some aspect of physics that usually isn't obvious when one reaches the level of sophistication to attempt it.
Of course that specific message is unlikely, and we could never guess what the message would be or it would be pointless, but you get the idea.
I think you're spot-on that SETI is a waste in "probability of success" terms, if you're defining success as "snooping random intergalactic communications that might randomly pass near us in space and time". However, I think at least some SETI promoters are hopeful about a (potentially) higher probability signal source: advanced alien races that are broadcasting legacy radio waves specifically at us, or at other low-tech civilizations in general. An advanced alien race might surmise that most fledgling civilizations will go through a phase of electromagnetic communication, and want to impart some kind of information to us.
The US has been preparing for this phase a little longer than China though
http://www.afspc.af.mil/units/
Who gives a crap about karma anyways? I can't believe anyone (myself included) even bothers to commenting here anymore, although somehow it keeps happening.
Precisely. If the transaction IDs are secure, then you have to play "man in the middle" to sniff the request and fake a response. But if you can guess the transaction IDs, you can blindly send a spoofed response from elsewhere on the net and fake out the user's DNS resolver. The details of doing this in practice can be tricky, but it's doable. That's why the dnsext working group has been trying to improve this aspect of the protocol. While MS's implementation has flaws that make it more predictable than it otherwise should be, the fundamental problem is with the decades-old DNS protocol to begin with. The transaction IDs are 16-bit numbers, which is very limiting if you need to generate secure sequences of them that can't be guessed. It's not too hard to just spam responses with random response IDs and get some small success rate with only 16 bits to play with.
One of the current proposals (which I'm not a fan of because of other technical implications for DNS) is that since DNS query names are case-insensitive and copied by the server from the request packet to the response packet, to use the "uppercase bit" of each letter as more bits for the secure transaction ID. The fact that people are willing to consider hacks like these should tell you something about how badly we're backed into a corner on this issue with the DNS protocol. Hopefully soon someone will do something sensible like standardize an EDNS1 with extra transaction ID bits in the OPT RR, and then in like 10 years (if history is any guide) it might actually see wide deployment.
I agree on a software level, but one must not forget that hardware access is even better than root access. Anyone who has physical access to a machine while not under intense, close scrutiny will be able to take over the machine and do whatever they want to it. So if you slap some mid-tower cases into some little semi-cubicles in a library, someone's going to hack them, regardless of operating system choice. They can always wait for the right time and quickly pop the case and swap in a new boot device which (very quickly) scans the other boot device and modifies security settings on it.
The way to fix this is to physically secure the machines. Lock them up in ventilated boxes under the desks, so that the users only have access to the screen, keyboard, and mouse (and then make sure you've kiosk'd that interface, so that certain hotkeys are disabled, etc).
Either that, or get away from the PC-per-user thing entirely. Just install some cheap color X-terminals for the users, and have them use services off of a farm of centralized machines in separate secured area. You can fit a lot more users per hardware dollar with Xterms. Instead of 8 stations = 8 PCs, it's 8 stations = 1 slightly beefier PC + 8 Xterms. (or whatever you decide your ratio to be).
This is trivial to prevent with ulimits, which are configured with a simple file in /etc. I would hope any sane distribution would default to having ulimits for users. If not, that needs to be rolled into the config for a library-like system.
I remember when Microsoft had more fanboys than it does today, but I don't remember *ever* liking them myself. My first Microsoft experience was using MS-DOS 2.11 on a Tandy 1000HX, because it was my first real computer and I didn't know any better. Windows didn't even exist at the time (at least as far as I knew). From that point forward I went through a string of different x86 operating environments, and the only rule of thumb was "Avoid Microsoft if at all possible". It was always DR-DOS and/or QEMM-386 (and DesqView) instead of the MS equivalents, DesqView/X and/or OS/2 2.x over Windows 3.x/95/NT, and eventually Linux instead of all of that once I found Linux circa 1994.
Another example is programming tools. It's not just the Visual[C/Basic/Whatever] of today that sucks - MS tools sucked all the way back to MASM, when the better alternative that I preferred was Borland's TASM. Microsoft always sucked, and smart people always knew it.
Of course the probability of finding something to complain about in Apple or Google's behavior increases the larger and more diverse the companies get. They'll still never be in the MS category. Google may eventually be "that company that started out as my best friend, but eventually made some sad mistakes much further down the road that hurt their reputation", but they'll never seem to have been evil incarnate from the get-go. Apple may occasionally make anti-consumer moves, but at least they've got a kick-ass design team and they truly love their user community and try to turn out some high quality code (and are using a *nix baseline, that's such a huge plus). MS has been using underhanded evil tactics to shove crappy solutions down unwitting consumers' throats from inception. I won't feel any remorse when and if they finally die off for good.
Syncing to GPS alone could be an issue for wide adopting as a last-mile technology though. It would really suck if intermittent GPS failure (due to extreme weather, military blackout, etc) caused everyone's last-mile links to malfunction due to bad timing. The situation could be remedied by ensuring the APs also have a very stable monotonic clock source to run from between GPS syncs, but it has to be stable enough to support your wireless timing at sufficient precision for hours or more. That will add cost and complexity to the solution. Something like an OCXO might do the trick ( http://en.wikipedia.org/wiki/OCXO ) and still be reasonably ok on cost/complexity. But if the timing needed enough precision to require rubidium, that would probably be a show-stopper.
The difference is that the subunits are instructed on what to do via a single procedural stream of instructions from the compiler's point of view. The CPU does some work to reorder and parallelize the instruction stream to try to keep all the subunits busy if it can, but it doesn't always do a great job, and the compiler also knows the rules for how a given CPU does the re-ordering/parallelization and tries to optimize the stream to better the outcome. This scheduling is taking place at a very low level with very small chunks of (or even single) instructions. Algorithms for auto-parallelizing code quickly in hardware don't really scale up to bigger chunks of code (and as we've seen, even when they deal with smaller chunks, the stream needs to be pre-optimized by the compiler for effectiveness).
But certainly this must be an area of active research. An "obvious" (if currently impossible) solution is to build an 80 core CPU that looks like a 4-core CPU to the operating system, and dedicates a few cores to auto-parallelizing the 4 instruction streams from the OS onto the remaining bulk of the cores. However if we had algorithms that could do that job reasonably effectively in realtime, we could certainly put those same algorithms in compilers and make them do an even better job in non-realtime. So that makes that approach seem silly.
Both languages have lots of idiots writing bad code in them. Perl is an extremely flexible and well-designed language, upon which many good modern layers of language meta-enhancement (have you looked at Moose - http://search.cpan.org/dist/Moose ?) have been built. PHP is an atrociously-designed language that only someone who loves things like HTML and Visual Basic could love.
Perl is the duct tape of the internet that real working people hold big things together with on a daily basis, PHP is the elmer's glue some 12 year old is trying to sniff to get high (in vain, because it's the new kind that you can't get high off of anyways).
Of course PHP's popular, it's very easy to deploy it and start writing code in it with zero skills (and to their honest credit, packaged full-blown PHP applications are generally easier to deploy than the equivalent in Perl), but that doesn't mean it's a good language to architect things in.
This sounded great up until the MSSQL part. Don't repeat your mistake and lock your company into more years of fighting bullshit and eventually migrating away again (or dying). If PostgreSQL can meet your needs (and really, there are very few needs it can't meet), migrate to that instead. Or if you really need certain enterprisey things that Pg doesn't have, then consider Oracle or DB2. But don't make the mistake of locking yourself into MSSQL as a way to get out of MySQL. MSSQL is just as bad as MySQL in its own unique ways, and Microsoft is famous for finding ways to trap you into long-term vendor lockin.
I agree about PostgreSQL being a better option for so many reasons (and this new Sun thing is just yet another on the list). The only thing PostgreSQL really needs is some kind of asynch multimaster replication. That's one place where you can get "forced" to use MySQL because Pg can't do what you need. MySQL's implementation of asynch multimaster replication sucks anyways, I'm sure the Pg community can do it better eventually.
Back to the topic at hand though, one way around the libmysqlclient GPL thing is to insulate yourself in a dynamic language where your code doesn't explicitly "link" with libmysqlclient. If you're using Perl (or any other similar language I would assume), DBD::mysql links to libmysqlclient.a, but your own Perl application can be whatever license you like and just "use DBI" (and DBD::mysql indirectly), which is not linking.
say() is a fairly pragmatic addition to the language. Do you have any idea the percentage of "print" statements in existing perl code which end in "\n". And how often that "\n" is the sole reason to use interpolating quotes and/or an append operator in the print statements (eg: )? It's a high percentage and a pain in the ass.
Actually, Perl 5.10 has been in release candidate state for a little while now, and someone recently just happened to drop an email reminding p5p of the upcoming anniversary and how cool it would be to release on the anniversary date, so it became a target to get the final out on that date. Without the anniversary to shoot for, it probably would've been a few days later. The fact that the anniversary happened to fall somewhere in the right vicinity was pure luck.
I think the 18 cutoff is reasonable. It's arbitrary, but due to high school ending about there, and all the associated "adult" responsibilities one gains, there does tend to be a pretty dramatic shift in maturity level somewhere within a couple of years of there. State laws differ on how they handle the age of consent stuff, but a lot of the more reasonable states using a sliding window near the age border, as in something like "anyone screwing anyone age 14-17 who is more than 3 years older than them is illegal", which lets 17 years have relationships with 20 year olds at max, and 14 year olds have sex with 17 year olds at max. These kinds of laws are pretty reasonable when you think about it. If a 21 year old guy is screwing a 16 year old girl, you know he's taking advantage of her mentally and physically in the majority of cases, and most of society would frown on it. You have to draw some rough lines in the sand somewhere.
There's a wide open market of customers who don't insist you do stupid things. If you've got skills, you don't have to cater to idiots. It's that simple.
Your non-MRAM scenario (battery-backed fast DDR volatile ram caches with flash drives behind them) is exactly what Texas Memory Systems has been doing for a while. If you really want to throw hardware at certain performance problems, their solutions are quite useful.
http://www.superssd.com/products/ramsan-500
I whole-heartedly agree with you. However, I think there's sometimes a bias among otherwise smart people to only realize this thinking process is going on in certain situations and not others. For most "controversial" ideas where something could in theory be settled by the proper application of logic and science (although perhaps fully convincing data doesn't yet exist), the argumentative "believer" partisans operate like this on both sides of the argument. The Global Warming thing is a perfect example. Somewhere in between Gore and Bush lies the scientific truth behind the cause of the warming, but it seems everyone has already decided to "believe" one way or the other to the extreme anyways. Same thing with all of the other touchy political subjects, like abortion, guns, the death penalty, euthanasia, social welfare programs, tax/debt/spending issues, just about everything to do with the current USMiddle East situation, etc...
I think education is at the root of it all. If we (a) guaranteed a good education through age 18-ish to everyone in the US (we don't, most of them get shitty educations) and (b) ensured that the core focus of that education was not memorizing facts to pass a test, but instead learning how to reason, apply logic, and learn new things independently, we might see some improvement after a few generations.
Your "freedom immigrants" sound like MySQL AB
Like everyone else said, if you want it cheap, DIY. If you want a packaged solution though, I'm liking Netgear (formerly Infrant)'s ReadyNAS NV+. http://www.netgear.com/Products/Storage/ReadyNASNVPlus.aspx
It even comes with a pre-installed version of slimserver inside the NAS (for serving up your music library from your NAS to Squeezebox players).
I do this in all of my active defense systems for production sites. I tend to make the firewall rules reasonably aggressive at detecting anything that looks remotely like attack traffic (connections on ports that neither us or customers are ever supposed to use but do see attack traffic (22, 139, etc...), tcp flag combos common in stealth scanners, certain known exploit string matches on port 80 traffic, etc), but the offending IPs are only blacklisted for a few minutes at first, ramping up to perhaps half a day if they're persistent within the blacked-out time window. This is more than enough to deter most automated (and even a few manual) attackers, assuming you're not protecting super valuable data. Still, there's no excuse not to be proactively checking up on your defenses and making sure things are behaving well.
I think your comment is a good example of why tinyurl-ish things are dangerous. You, like most tinyurl users, aren't really thinking through all of the layers involved here. If you use tinyurl for all of the links you publish, none of your links will work if tinyurl crashes (and they'll all be hijacked if tinyurl is cracked). If 80% of twitter links use tinyurl, same deal. It defeats the normal inherent robustness of the internet if a significant random subset of the traffic is being routed through a single service somewhere just to shorten the names.