I went one step more serious for the bundled cable runs in the basement (each run will be up to 16 Cat5 cables--carrying LAN, USB extenders, security video, and maybe even voice telephone if I get bored).
Same idea with the stick-to-itself Velcro ties; I'm using the Monoprice ones, but the Panduit ones are much nicer (and priced accordingly).
But instead of screwing the tie to the joist, I put in a nylon 3/4" flat cable staple. That way, I can take the tie away completely, replace it, whatever without grabbing the screwdriver. And I can use ties that are too long and still keep them semi-tidy.
Definitely needs to be recloseable, though; my cable runs always start neat. It's when I have to change something that things get messy; with the Velcro wraps, I'm pretty good at taking the time. With zip-ties, a couple of cable changes and the rats start complaining I'm making their nest look bad.
It's not too hard to find a router with a gigabit switch on it for the LAN side. The GigE switch is its own thing, doesn't have to go through the router's CPU; it's a switch-on-a-chip device. They almost all have port-tagging VLANs, but unless you're fiddling with the firmware that part doesn't matter.
Why you'd want a switch in your modem, though, that I don't understand. Am I the only one who has had modems burn out? (Surprisingly, NOT the one that got hit by lightning.)
Disk speed is definitely something to consider: I've got a number of disks, laptop and desktop size, that do about 110MB/s at the outer rim, and drop off to around 60MB/s at the hub.
It's one thing to know, intellectually, that's how disks work (more bytes/revolution, fixed revolution/second at the rim); it's another to actually see it in the RAID1 rebuild statistics.
Anyway, why are we excited about a single device? Don't we multiplex multiple data streams onto the same network link?
To be fair, on UNIX there is special kernel support for this. Though it's not support for ISO files, it's the loopback device. (Not all UNIXes have one, so not all UNIXes can mount a filesystem from a file.)
Filesystems must be on block devices. Files are character sequence. The loopback driver makes a block device out of a character sequence.
But then you can do ANYTHING. You can put an MD RAID device in it. You can make it a physical volume for the LVM. You can LUKS encrypt it. You can do ALL of the above by cascading block device to block device. (You can make an MD of an MD of an MD if you really want.) You can mount ANY filesystem, not just an ISO. Those filesystems can be read/write.
OS X can do much of that, too: I use an encrypted sparsebundle to store client-specific files. Each client is its own sparsebundle. So when I'm with Client A, none of Client B's files are accessible. (Sparsebundle is basically a de-luxe loopback device; it aggregates multiple files to make the loopback, and enables sparse allocation on filesystems which don't support sparse files.)
It truly is the power of abstraction. It's just one reason I can't stand Windows; it treats everything as a special case.
You can never be sure; policies are only worth the people standing behind them. When the people go away (for whatever reason, these examples are corporate acquisitions), there's no more policy.
Say you liked SoundJam MP. Cassidy & Greene had a nice upgrade policy. They got bought by Apple and the "upgrade policy" became, "use iTunes."
Symantec loved to buy (back in the pre-OS X days) utility suites for the Mac and discontinue them.
Note that C++ only guarantees destructors are not run before something goes out of scope; exactly when after is Implementation Defined. So if a file MUST be closed (say, because you just wrote it and want to pass it to another program), you still need to invoke the close method explicitly.
Perl does much the same thing when a reference to an IO::File class or a filehandle gets garbage-collected. This Java feature just makes it part of the language syntax, rather than having to glom on yet another library.
If the count isn't known, it shouldn't use a progress bar. What's the Windows version of the "barber pole" unknown-limits-but-not-crashed progress indicator?
Why not? All of the Red Hat kernel source is available. They stopped doing the 1000s of patches in the SRPM thing, but it's still source. (Oh the horror of that old patch structure... maybe it was handy if you were trying to undo Red Hat's changes, or just "lift" their changes into a different kernel version. But if all you wanted was to work around the bug in your stupid TSSTCorp DVD burner....)
Or Red Hat's competitors could put the same effort into maintaining their kernel snapshot... but at some point, wouldn't you just get Red Hat if you want something done the Red Hat way?
Or they could band together with other groups and propose a more stable-than-stable kernel branch... oh wait.
The great thing about the Check Engine Light is, you know the one thing you don't need to look at is the engine itself.
First check the gas filler cap is on tightly. Then drive for a day or two and see if it goes out on its own. If it still doesn't go out, then you can bother with an OBDII readout.
I do remember that "ENGINE" light on a 1978 Mercury Grand Marquis (Brougham!). The manual had pages and pages explaining what to do; things like, "If you speed up and it goes out, check the coolant. If you slow down and it flickers, check the oil levels." And so on. However much they saved by combining "TEMP", "CHARGE" and "OIL PRESSURE" into a single lamp they spent on extra pages in the manual.
The keychain has to keep recoverable plaintexts for passwords: it works by supplying the password to an arbitrary authentication mechanism.
If it stored hashes instead, those would simply become equivalent to plaintext; you'd need only that hash to authenticate. You couldn't, for example, store a hash from a challenge-response system--you have to compute the response for each challenge.
If you really need that kind of protection, Kerberos 5 very quickly seems to be the "done already" answer. (And yes, I know what it takes to run a krb5 server group; though only enough to get OpenAFS happy.)
This is just one of the many ways the cheap devices run out of RAM. It's almost as if they're designed to be used inside a Faraday cage with a single Wi-Fi client, upon which only the Web is ever browsed.
As a result, a crusty old Linksys WRT54GS (with dd-wrt or Tomato or OpenWRT) does much, much better than a brand-new 802.11n Linksys unit. I've seen lots of failure modes; my favourite was the unit that would overheat and reset under heavy traffic--and wipe the NVRAM settings on its way down, resulting in the LAN being fully open via the "linksys" access point.
I've also seen a Linksys 802.11n unit that would hop channels whenever there was any wi-fi traffic from another network on that same channel. This is really good if there's 3 of those units in the same area. They all start hopping around to different channels, and every hop the clients lose their connection and start scanning for known access points. (That was with "channel hopping" disabled in the menus, of course; a Wi-Fi monitor showed it was still doing it.)
Chucked the former out and put a WRT54G, one of the newer ones with really low RAM but could still take dd-wrt. The LAN and WLAN suddenly stayed up all the time, as long as there weren't torrents. (Not enough RAM for the NAT tables. And, to be honest, existing connections would run just fine, there just wasn't room for new connections.)
The other one got replaced with an ASUS RT-N16, my current favourite 'cause it's got gobs of RAM and spacious, relaxing flash.
There actually was one a few years back, "Thief Tastes Judo Justice", from Western Canada. I can't find a link to it; one of the guys at my dojo had brought in the actual newspaper. (It's entirely possible the paper in question wasn't on-line at the time.)
Mostly, though, people who are able to deal with those situations seldom get in to them: just being aware of what's around you does a lot.
And, as another reply says, most of us are in it for sport and exercise, just like boxers and wrestlers.
(BTW, what percentage is that? Where I'm from, there's far more joggers than martial artists... and we're not too far behind the U.S. in obesity stats.)
...and if that Blue Line device doesn't do it for you (mine failed due to weather ingress in the bit that goes on the meter), you can just go outside and look.
At least, if you've got an LCD readout meter. All the models I've seen cycle between at least "total kWh usage" and "current kW load". (For the old spinning-disk-of-aluminum inductive units, grab a stopwatch and see how long it takes for the black mark to come 'round again.)
This is why you should never ask what someone wants. Ask what they want _to do_.
In that case, Mr. Ford might hear the answer, "Get from New York to Philadelphia in less than 3 days."
And for some of us, the "desktop environment" is "so we can have a bunch of xterms open and check Slashdot in a browser at the same time! Try that with screen! hahahaha!"
I've still got the OpenMotif source around somewhere, I can opt out of this mess....
We should have got the one that ran the Linux kernel and dealt with JTAG programming and all that. We spent person-months discovering just how badly.NET ME actually worked (like, unidirectional communication--from the board only). Supposedly, the newer.NET ME has that fixed... but the board in question can't be upgraded. It's.NET ME 2.5 or Linux.
We could, however, re-flash it to Linux with the debug adapter (which we didn't buy) and a JTAG programmer (which we can fake on a parallel port).
Or, we could buy some microcontrollers for 1/60th the price and do whatever we feel like for [nearly] free--no need for a Visual Studio or Windows license for starters. All you need is one (1) Arduino USB board and you can hook off the USB chip to program any other ATmega MCU--even ones just on a breadboard. (We actually went with a different MCU family 'cause we had access to a universal in-circuit programmer; but Arduino makes bootstrapping ATmega circuits really easy. Well, if you get the Solarbotics one it is--they've put pin headers to break out the necessary lines from the USB chip....).NET ME was like using a GUI: If you wanted to do things they thought of, it worked more-or-less OK. If you wanted to do something else, you had the wrong product.
You're probably better off with a good software stack for that. You'd want to program it to always WRITE both, but READ from the SSD unless it gets an I/O error.
I have to support customers on RHEL 5 (and 4...) so I haven't kept up with all the latest in the Linux kernel MD driver. But I think the stuff is there in the kernel proper for it to do this, I'm not sure about a user interface to control it. If not, well, what's a few local patches among friends?
Less heat means you can also pack 'em in closer together: you don't need as much air circulating to keep things cool.
OTOH, I've used SSDs which ran pretty hot; they used more power than a 7200 RPM 3.5" disk, let alone a 7200 RPM 2.5" disk. If you're replacing 15k RPM drives, sure, that's a big power savings. But I remain unconvinced that 15k RPM is the right tool for many jobs--7.2k and striping works really well for me. (My group has no budget, so I have to do the best I can. The group with a budget--and the 15k RPM SAN--has I/O problems all the time.)
Back in my days as a software tester, that's basically what I would do when I suspected something was looping. Wedge a debugger into the running process, see how far the program counter was going, and see what registers were changing, and a quick look at the autos in the current stack frame. (Most autos would be in registers: this was not an x86-based system.)
I made no attempt to get the program to continue, though; once I was pretty sure it was in a loop, I'd then work out the minimum necessary circumstances to trigger it and log a bug report.
SAS does have better enclosure services support, and the SAS port expanders technology seems to be a lot more robust than SATA. (Part of the problem with SATA is, you're allowed "dumb" and "smart" port multipliers. And it's really hard to find out what is what from the label; you basically have to hope there's a photo on NewEgg where you can read the numbers off the chips.)
SAS isn't guaranteed expensive. If you can find a non-RAID SAS controller, they're comparable to an equivalent SATA controller, but of course can drive SAS expanders, SAS and SATA drives.
It's just very hard to find non-RAID SAS controllers. I've got the Supermicro AOC-SASLP-MV8 one on a bunch of machines; that sucker will let me push 700 MB/s to bog-standard Seagate SATA drives in a stripe-set. (That works out to the maximum sustained write speed on all 6 drives in the set; you can see performance drop off as you get closer to the disk hubs.) Yours for a measly $120CDN or so; fanout cables extra.
That aside, the Backblaze pod approach--right down to the SiL chipset on the SATA controllers--is exactly how I've got my home media fileserver set up. Only, being a cheap bastard, I got a bunch of port-multiplying eSATA boxes on sale and didn't have to get the custom chassis. I can playback multiple Blu-Ray.mt2s files at once, what more do I need?
Just because it's a hard drive, doesn't mean you have to put a filing system on it. (Other commenters have covered the future-life of filesystems.)
Heck, just because it's optical doesn't mean you have to use ISO9660 or UDF.
I still have a script that hooks into the user-exits in GNU TAR to bridge a TAR across multiple optical discs. You can read it back on any OS which lets you get block access to the drive, which is at least Solaris, AIX, Linux, BSD and Mac OS X. (I've read back the burns on all of them. Burning means you need cdrecord, which, hey, works on all of those as well.)
You can do the same thing with HDDs. Sure, filesystems are convenient, but they're not necessary--neither is partitioning. A hard drive is a random-access block storage device; an optical drive is a sequential-access block storage drive with fast seeks; and a tape drive is a sequential-access block storage device with slow seeks.
Which means, if it works on tape, it will work on optical. If it will work on optical, it will work on hard disk.
Pick the combination you think suits your future needs and STORE THE DOCUMENTATION WITH YOUR ARCHIVES.
There were certainly early DVD-Rs that had bad dyes.
Fortunately, those are easy to spot: the ones I had all became visibly "blotchy" on the data side of the disc. That, and all the ROM drives I had started saying, "No medium present" when I loaded them. That was back when $3/disc was too good to be true... and it was.
Hmmm, I had CD-RWs go visibly bad like that, too: it looked like the dye "leaked" out of the grooves and made puddles inside the polycarbonate.
Heck, I've still got 3.5" floppies from the 80s that people say shouldn't work any more, and even some C64-era 5.25" stuff (prerecorded floppies from the early 80s) that still works.
Last time I was in a Borders--near the Walden Galleria outside Buffalo--they were unable to sell me the product I wanted. It was a DVD or CD or something, and it was in one of those "all our customers are shoplifters" plastic cases they have to remove at the register.
They couldn't find who had the gadget to remove the case.
After 5 minutes, I got tired of waiting, made them give me my money back, and left with my friends. There was important lunch to be eaten, Niagara Falls to be looked at, and other more valuable uses of time.
Costco in Canada had the same thing for like $5 more (after exchange), but was actually able to sell it to me. That counts for a whole lot in retail.
Bah, in the 90s, using technologies like AFS and DFS, we could serve 10,000s of users from crappy low-end RS/6000s. Any one server only had a small part of the filesystem storage; and only the location broker needed to know how to translate a path to a server address--it didn't have any file data itself, and was replicated at least 3 times. (And, once cached, the client didn't need to check with the location broker again until an error or it was told to.)
If you're doing that many users with NFS or SMB from a single server, you've already failed--no matter how big your box is, you're going to have massive I/O contention on its LAN interfaces and its disk interfaces. Solving that means spreading out the I/O so the network switches can do their things.
Or your load is so small that yes, you can serve it from a beige box you built from NewEgg parts.
No-one has told the U.S. border guards in economically depressed areas of New York State; you know, the parts that aren't New York City.
Those guys seem to be out to actively prevent tourism; which is all that some of those towns have left. One idiot north of the Adirondaks and Lake Champlain said he'd never even heard someone say "sightseeing" before, and we couldn't possibly be tourists as a result.
Presumably, he's never read those brochures at the New York Welcome Centre....
Slashdot Mirror
I went one step more serious for the bundled cable runs in the basement (each run will be up to 16 Cat5 cables--carrying LAN, USB extenders, security video, and maybe even voice telephone if I get bored).
Same idea with the stick-to-itself Velcro ties; I'm using the Monoprice ones, but the Panduit ones are much nicer (and priced accordingly).
But instead of screwing the tie to the joist, I put in a nylon 3/4" flat cable staple. That way, I can take the tie away completely, replace it, whatever without grabbing the screwdriver. And I can use ties that are too long and still keep them semi-tidy.
Definitely needs to be recloseable, though; my cable runs always start neat. It's when I have to change something that things get messy; with the Velcro wraps, I'm pretty good at taking the time. With zip-ties, a couple of cable changes and the rats start complaining I'm making their nest look bad.
It's not too hard to find a router with a gigabit switch on it for the LAN side. The GigE switch is its own thing, doesn't have to go through the router's CPU; it's a switch-on-a-chip device. They almost all have port-tagging VLANs, but unless you're fiddling with the firmware that part doesn't matter.
Why you'd want a switch in your modem, though, that I don't understand. Am I the only one who has had modems burn out? (Surprisingly, NOT the one that got hit by lightning.)
Worse than that: They're copying OS/2, which they helped write. (OS/2 could boot to a non-GUI text console for servers and ATMs.)
Heck, they're copying one of their own SAFE MODE boots.
Or maybe, They're copying DOS.
Disk speed is definitely something to consider: I've got a number of disks, laptop and desktop size, that do about 110MB/s at the outer rim, and drop off to around 60MB/s at the hub.
It's one thing to know, intellectually, that's how disks work (more bytes/revolution, fixed revolution/second at the rim); it's another to actually see it in the RAID1 rebuild statistics.
Anyway, why are we excited about a single device? Don't we multiplex multiple data streams onto the same network link?
To be fair, on UNIX there is special kernel support for this. Though it's not support for ISO files, it's the loopback device. (Not all UNIXes have one, so not all UNIXes can mount a filesystem from a file.)
Filesystems must be on block devices. Files are character sequence. The loopback driver makes a block device out of a character sequence.
But then you can do ANYTHING. You can put an MD RAID device in it. You can make it a physical volume for the LVM. You can LUKS encrypt it. You can do ALL of the above by cascading block device to block device. (You can make an MD of an MD of an MD if you really want.) You can mount ANY filesystem, not just an ISO. Those filesystems can be read/write.
OS X can do much of that, too: I use an encrypted sparsebundle to store client-specific files. Each client is its own sparsebundle. So when I'm with Client A, none of Client B's files are accessible. (Sparsebundle is basically a de-luxe loopback device; it aggregates multiple files to make the loopback, and enables sparse allocation on filesystems which don't support sparse files.)
It truly is the power of abstraction. It's just one reason I can't stand Windows; it treats everything as a special case.
You can never be sure; policies are only worth the people standing behind them. When the people go away (for whatever reason, these examples are corporate acquisitions), there's no more policy.
Say you liked SoundJam MP. Cassidy & Greene had a nice upgrade policy. They got bought by Apple and the "upgrade policy" became, "use iTunes."
Symantec loved to buy (back in the pre-OS X days) utility suites for the Mac and discontinue them.
It's just scoping, really. You can do it in C++ if you like, here's one way to DIY (without the error checking):
Note that C++ only guarantees destructors are not run before something goes out of scope; exactly when after is Implementation Defined. So if a file MUST be closed (say, because you just wrote it and want to pass it to another program), you still need to invoke the close method explicitly.
Perl does much the same thing when a reference to an IO::File class or a filehandle gets garbage-collected. This Java feature just makes it part of the language syntax, rather than having to glom on yet another library.
If the count isn't known, it shouldn't use a progress bar. What's the Windows version of the "barber pole" unknown-limits-but-not-crashed progress indicator?
Why not? All of the Red Hat kernel source is available. They stopped doing the 1000s of patches in the SRPM thing, but it's still source. (Oh the horror of that old patch structure... maybe it was handy if you were trying to undo Red Hat's changes, or just "lift" their changes into a different kernel version. But if all you wanted was to work around the bug in your stupid TSSTCorp DVD burner....)
Or Red Hat's competitors could put the same effort into maintaining their kernel snapshot... but at some point, wouldn't you just get Red Hat if you want something done the Red Hat way?
Or they could band together with other groups and propose a more stable-than-stable kernel branch... oh wait.
The great thing about the Check Engine Light is, you know the one thing you don't need to look at is the engine itself.
First check the gas filler cap is on tightly. Then drive for a day or two and see if it goes out on its own. If it still doesn't go out, then you can bother with an OBDII readout.
I do remember that "ENGINE" light on a 1978 Mercury Grand Marquis (Brougham!). The manual had pages and pages explaining what to do; things like, "If you speed up and it goes out, check the coolant. If you slow down and it flickers, check the oil levels." And so on. However much they saved by combining "TEMP", "CHARGE" and "OIL PRESSURE" into a single lamp they spent on extra pages in the manual.
The keychain has to keep recoverable plaintexts for passwords: it works by supplying the password to an arbitrary authentication mechanism.
If it stored hashes instead, those would simply become equivalent to plaintext; you'd need only that hash to authenticate. You couldn't, for example, store a hash from a challenge-response system--you have to compute the response for each challenge.
If you really need that kind of protection, Kerberos 5 very quickly seems to be the "done already" answer. (And yes, I know what it takes to run a krb5 server group; though only enough to get OpenAFS happy.)
This is just one of the many ways the cheap devices run out of RAM. It's almost as if they're designed to be used inside a Faraday cage with a single Wi-Fi client, upon which only the Web is ever browsed.
As a result, a crusty old Linksys WRT54GS (with dd-wrt or Tomato or OpenWRT) does much, much better than a brand-new 802.11n Linksys unit. I've seen lots of failure modes; my favourite was the unit that would overheat and reset under heavy traffic--and wipe the NVRAM settings on its way down, resulting in the LAN being fully open via the "linksys" access point.
I've also seen a Linksys 802.11n unit that would hop channels whenever there was any wi-fi traffic from another network on that same channel. This is really good if there's 3 of those units in the same area. They all start hopping around to different channels, and every hop the clients lose their connection and start scanning for known access points. (That was with "channel hopping" disabled in the menus, of course; a Wi-Fi monitor showed it was still doing it.)
Chucked the former out and put a WRT54G, one of the newer ones with really low RAM but could still take dd-wrt. The LAN and WLAN suddenly stayed up all the time, as long as there weren't torrents. (Not enough RAM for the NAT tables. And, to be honest, existing connections would run just fine, there just wasn't room for new connections.)
The other one got replaced with an ASUS RT-N16, my current favourite 'cause it's got gobs of RAM and spacious, relaxing flash.
There actually was one a few years back, "Thief Tastes Judo Justice", from Western Canada. I can't find a link to it; one of the guys at my dojo had brought in the actual newspaper. (It's entirely possible the paper in question wasn't on-line at the time.)
Mostly, though, people who are able to deal with those situations seldom get in to them: just being aware of what's around you does a lot.
And, as another reply says, most of us are in it for sport and exercise, just like boxers and wrestlers.
(BTW, what percentage is that? Where I'm from, there's far more joggers than martial artists... and we're not too far behind the U.S. in obesity stats.)
...and if that Blue Line device doesn't do it for you (mine failed due to weather ingress in the bit that goes on the meter), you can just go outside and look.
At least, if you've got an LCD readout meter. All the models I've seen cycle between at least "total kWh usage" and "current kW load". (For the old spinning-disk-of-aluminum inductive units, grab a stopwatch and see how long it takes for the black mark to come 'round again.)
This is why you should never ask what someone wants. Ask what they want _to do_.
In that case, Mr. Ford might hear the answer, "Get from New York to Philadelphia in less than 3 days."
And for some of us, the "desktop environment" is "so we can have a bunch of xterms open and check Slashdot in a browser at the same time! Try that with screen! hahahaha!"
I've still got the OpenMotif source around somewhere, I can opt out of this mess....
I've dealt with .NET Micro Edition.
We should have got the one that ran the Linux kernel and dealt with JTAG programming and all that. We spent person-months discovering just how badly .NET ME actually worked (like, unidirectional communication--from the board only). Supposedly, the newer .NET ME has that fixed... but the board in question can't be upgraded. It's .NET ME 2.5 or Linux.
We could, however, re-flash it to Linux with the debug adapter (which we didn't buy) and a JTAG programmer (which we can fake on a parallel port).
Or, we could buy some microcontrollers for 1/60th the price and do whatever we feel like for [nearly] free--no need for a Visual Studio or Windows license for starters. All you need is one (1) Arduino USB board and you can hook off the USB chip to program any other ATmega MCU--even ones just on a breadboard. (We actually went with a different MCU family 'cause we had access to a universal in-circuit programmer; but Arduino makes bootstrapping ATmega circuits really easy. Well, if you get the Solarbotics one it is--they've put pin headers to break out the necessary lines from the USB chip....) .NET ME was like using a GUI: If you wanted to do things they thought of, it worked more-or-less OK. If you wanted to do something else, you had the wrong product.
You're probably better off with a good software stack for that. You'd want to program it to always WRITE both, but READ from the SSD unless it gets an I/O error.
I have to support customers on RHEL 5 (and 4...) so I haven't kept up with all the latest in the Linux kernel MD driver. But I think the stuff is there in the kernel proper for it to do this, I'm not sure about a user interface to control it. If not, well, what's a few local patches among friends?
Less heat means you can also pack 'em in closer together: you don't need as much air circulating to keep things cool.
OTOH, I've used SSDs which ran pretty hot; they used more power than a 7200 RPM 3.5" disk, let alone a 7200 RPM 2.5" disk. If you're replacing 15k RPM drives, sure, that's a big power savings. But I remain unconvinced that 15k RPM is the right tool for many jobs--7.2k and striping works really well for me. (My group has no budget, so I have to do the best I can. The group with a budget--and the 15k RPM SAN--has I/O problems all the time.)
Back in my days as a software tester, that's basically what I would do when I suspected something was looping. Wedge a debugger into the running process, see how far the program counter was going, and see what registers were changing, and a quick look at the autos in the current stack frame. (Most autos would be in registers: this was not an x86-based system.)
I made no attempt to get the program to continue, though; once I was pretty sure it was in a loop, I'd then work out the minimum necessary circumstances to trigger it and log a bug report.
SAS does have better enclosure services support, and the SAS port expanders technology seems to be a lot more robust than SATA. (Part of the problem with SATA is, you're allowed "dumb" and "smart" port multipliers. And it's really hard to find out what is what from the label; you basically have to hope there's a photo on NewEgg where you can read the numbers off the chips.)
SAS isn't guaranteed expensive. If you can find a non-RAID SAS controller, they're comparable to an equivalent SATA controller, but of course can drive SAS expanders, SAS and SATA drives.
It's just very hard to find non-RAID SAS controllers. I've got the Supermicro AOC-SASLP-MV8 one on a bunch of machines; that sucker will let me push 700 MB/s to bog-standard Seagate SATA drives in a stripe-set. (That works out to the maximum sustained write speed on all 6 drives in the set; you can see performance drop off as you get closer to the disk hubs.) Yours for a measly $120CDN or so; fanout cables extra.
That aside, the Backblaze pod approach--right down to the SiL chipset on the SATA controllers--is exactly how I've got my home media fileserver set up. Only, being a cheap bastard, I got a bunch of port-multiplying eSATA boxes on sale and didn't have to get the custom chassis. I can playback multiple Blu-Ray .mt2s files at once, what more do I need?
Just because it's a hard drive, doesn't mean you have to put a filing system on it. (Other commenters have covered the future-life of filesystems.)
Heck, just because it's optical doesn't mean you have to use ISO9660 or UDF.
I still have a script that hooks into the user-exits in GNU TAR to bridge a TAR across multiple optical discs. You can read it back on any OS which lets you get block access to the drive, which is at least Solaris, AIX, Linux, BSD and Mac OS X. (I've read back the burns on all of them. Burning means you need cdrecord, which, hey, works on all of those as well.)
You can do the same thing with HDDs. Sure, filesystems are convenient, but they're not necessary--neither is partitioning. A hard drive is a random-access block storage device; an optical drive is a sequential-access block storage drive with fast seeks; and a tape drive is a sequential-access block storage device with slow seeks.
Which means, if it works on tape, it will work on optical. If it will work on optical, it will work on hard disk.
Pick the combination you think suits your future needs and STORE THE DOCUMENTATION WITH YOUR ARCHIVES.
There were certainly early DVD-Rs that had bad dyes.
Fortunately, those are easy to spot: the ones I had all became visibly "blotchy" on the data side of the disc. That, and all the ROM drives I had started saying, "No medium present" when I loaded them. That was back when $3/disc was too good to be true... and it was.
Hmmm, I had CD-RWs go visibly bad like that, too: it looked like the dye "leaked" out of the grooves and made puddles inside the polycarbonate.
Heck, I've still got 3.5" floppies from the 80s that people say shouldn't work any more, and even some C64-era 5.25" stuff (prerecorded floppies from the early 80s) that still works.
Last time I was in a Borders--near the Walden Galleria outside Buffalo--they were unable to sell me the product I wanted. It was a DVD or CD or something, and it was in one of those "all our customers are shoplifters" plastic cases they have to remove at the register.
They couldn't find who had the gadget to remove the case.
After 5 minutes, I got tired of waiting, made them give me my money back, and left with my friends. There was important lunch to be eaten, Niagara Falls to be looked at, and other more valuable uses of time.
Costco in Canada had the same thing for like $5 more (after exchange), but was actually able to sell it to me. That counts for a whole lot in retail.
Bah, in the 90s, using technologies like AFS and DFS, we could serve 10,000s of users from crappy low-end RS/6000s. Any one server only had a small part of the filesystem storage; and only the location broker needed to know how to translate a path to a server address--it didn't have any file data itself, and was replicated at least 3 times. (And, once cached, the client didn't need to check with the location broker again until an error or it was told to.)
If you're doing that many users with NFS or SMB from a single server, you've already failed--no matter how big your box is, you're going to have massive I/O contention on its LAN interfaces and its disk interfaces. Solving that means spreading out the I/O so the network switches can do their things.
Or your load is so small that yes, you can serve it from a beige box you built from NewEgg parts.
No-one has told the U.S. border guards in economically depressed areas of New York State; you know, the parts that aren't New York City.
Those guys seem to be out to actively prevent tourism; which is all that some of those towns have left. One idiot north of the Adirondaks and Lake Champlain said he'd never even heard someone say "sightseeing" before, and we couldn't possibly be tourists as a result.
Presumably, he's never read those brochures at the New York Welcome Centre....