It works if and only if the target system is also using LSI RAID controllers.
In the business world where you don't change the underlying OS on a critical system just because you feel like it, it's pretty easy to make sure the target hardware meets the spec.
If ZFS finds a checksum error, it thinks it's running on two big drives in a stripe with no redundancy, and it will be unable to recover the lost data.
There will be yet another level of redundancy through the cluster, as each file will be available on at least two different nodes. ZFS will help in finding discrepancies that are found at the cluster level.
Why would I prefer ZFS over DIF on FC and now SAS2 which does the checksumming in a far more comprehensive manner for me and is agnositic to the file system it is on?
ZFS checksums the data in situ and will prevent bit rot, while the methods you reference are for verifying the data hasn't changed during the transfer across a wire.
3. RAID controllers are pretty much all unique and their volumes are non portable. They are also not documented well. Your drives are useless without the controller, and even recovering with a new controller of the same type is a crapshoot.
Modern LSI RAID controllers use a completely portable format. You can move the array to any other controller that supports that same level of RAID and it can be imported into the config. I have done this successfully even when the controller chip was a completely different model.
RAID controllers are limited by their on-board chips which are typically sub-GHz RISC (ARM, Intel, MIPS) processors - an external SAS RAID controller will cost you about $2-5000 extra and have a throughput of a few 100MBps and a few 100's of IOPS.
There are sub-$1000 LSI RAID controllers that have no problem providing 500MB/sec even with 10x 5400rpm drives in RAID-6. Faster drives and more spindles plus SSD cache (handled by that same LSI controller, so it's OS-agnostic) can give apparent throughput of around 150MB/sec per spindle. For your 36 spindle scenario, that would be around 5GB/sec, which is nearly double your throughput.
Right now, I'm in the process of building a cluster where each node will use two groups of hardware RAID-6 over 10 drives, and then use a zpool to combine the storage and give me all the other ZFS features (snapshots, scrub, etc.). The whole cluster will be combined using Lustre to give around 350TB of usable storage. Based on similar build-outs that our software vendor has seen, our biggest issue will be that we only have 20Gbps total network capacity per node, and under heavy load will likely be saturated.
This is the same thing people have seen with bluetooth ear pieces. They are really nice for a small percentage of the time, but not enough to capitalize for the majority of the market.
But bluetooth headsets do what they are intended for very well...they have long battery life (days at a minimum, weeks for many models) and allow you to perform any audio interaction with your phone that you might need without having to remove your phone from its storage.
A smart watch can't do audio interactions any better than the phone, and the display doesn't provide enough extra utility (texts can be listened to via text-to-speech over a bluetooth headset) until some "killer app" is written for it. In addition, most bluetooth headsets require little to no extra software on the phone, but apps that utilize a smart watch will have to have code that specifically handles the smart watch interface.
My watch is a Tissot PRC200 Automatic. Not a very expensive watch
At US$600, it's also not "cheap".
But, you do make a good point in that people who already wear watches tend to like the style they have, and won't trade that for smart watch functionality. And, that people who wouldn't mind spending $350 on a smart watch likely already have a watch at least that expensive that they won't give up.
You'd look pretty silly trying to contort yourself in order to read the time or do a google search on an ankle monitor.
I don't think I need to remind you that there are people who—as I type this—are downloading video of somebody else contorting themselves into just such a position, silly-looking or not.
So, such a device would aid in creation of "plot" for these videos.
If you're like a lot of people, you carry a backpack/computer case with you on a regular basis. Keeping your phone safely inside that bag for most circumstances would be a benefit, freeing your pockets of the burden. You could still receive/triage incoming communications while the phone was tucked away. "Nearby" for a well designed bluetooth transceiver is 30-45 feet which is enough to keep you from having to unsheathe your phone in most circumstances.
The correct solution is to put all the "phone" functionality (antenna, transmitter, etc.) in the "watch", and use the "phone" as nothing more than a remote display and computing platform. It would be tricky to create the right split (since the watch has to have some computing power), but not impossible. The second trick would be to get the battery life of the watch high enough with the added power requirements.
The current split of "watch is a peripheral" won't appeal to enough people to make true sales inroads. Sure, Apple is going to sell a lot of these just because of the Apple name, but it's still going to be just a small percentage of iPhone owners, much less smart phone owners.
The law is typically written to specifically exempt law enforcement and emergency responders.
Most of those exemptions are only truly valid while on an "emergency" response, even though most cops treat them like full-time exemptions.
Because of the emergency requirement, and because the police car has a radio and most have computers, I can't think of any reason to allow cops to use hand-held cell phones for any reason while driving. If they are responding to an emergency, they should be using official communications methods, and if they aren't, they shouldn't get an exemption from laws.
Why? Really why should I wait? I have an app on my phone that reads my text message if I am in my car. I never respond and it is no more distracting than the radio.
Similarly, my car provides this same feature, and also allows me to send "canned" texts (similar to one-button taunts in online games) with a couple of clicks on the car's touch screen. I also can't edit "regular" texts while the car is in motion, but I can edit either the canned texts to meet my needs or edit a normal text while the car is stopped but still hit "send" while the car is in motion.
I already go to get water, hit the head, or get lunch, several times a day
Damn, how many lunch breaks do you need?
He's a hobbit, so he starts with second breakfast, and it just continues from there.
And if you want to put a 1TB RAM drive into a server?
Buy hardware that supports 2-4TB on the motherboard.
Regardless of the physical size of the server, the price for such a motherboard plus RAM is going to be less than the add-in card plus RAM. It might be a lot more for the add-in solution, as you might not get warranty support unless you buy RAM from the same company that sells the card. You might also have to decide how much RAM disk you want at time of purchase, while system RAM can be upgraded (to the limit of the motherboard) and you can easily decide the size of RAM disk via software.
Also, for Linux, add-in cards might not have drivers, while system RAM does.
Or how about someone starts making RAM drives (for a decent price!) again?
It's easier to just buy more system RAM than to have specialized "RAM drive" hardware.
Then, if caching doesn't give you good enough performance, you can just use software to create a RAM disk.
Your absolutely right. A lot of iPhone users only want an iPhone due to the traditionally tiny form factor. It is somewhat surprising to see Apple alienate this crowd.
There is no reason the iPhone 6 needs to be larger than the iPhone 5, even with a larger screen.
It's just Apple sticking to the exact same space-wasting layout of previous iPhones that makes it so. My phone has a 5.2" 1920x1080 screen, giving it a bigger screen and more resolution than the iPhone 6, yet the iPhone 6 is only 0.25" less wide (and the same height).
Apple design fail.
The optimum committee has no members. -- Norman Augustine
