While you cannot add new drives to a vdev, you can expand a vdev by incrementally replacing all of its drives with larger versions. Replace a drive, resilver, replace a drive, resilver... and when you're all done, just export the pool, import it back, and you have the full capacity of the new drives available.

It appears to use a lot of memory because it replaces the standard kernel disk cache with its own ARC, and as unused memory is wasted memory, the ARC will eat up every last bit of memory you allow it.

It's performing a checksum of your entire system. That's going to be a CPU hog. BTRFS will be no different in this regard. Still, the default algorithm is fairly lightweight, and on a modern multi-core multi-GHz system, you should be bottlenecked on disk long before you "thrash" your CPU. If you're trying to run ZFS on an old low end Atom, well... don't do that!

Of course it does. It just has some limitations. You cannot remove devices from a pool, and you cannot reshape a Z/2/3 vdev. You can add a new disk to a mirror vdev. You can replace all the disks in a Z vdev with larger ones, and then expand the vdev to use the new space. You can add a new disk to a pool. You can add a new mirror or Z vdev to a pool.

If you intend to send the snapshots over the network, as is often the case with rsync, you need to pair it with some independent communication tool, and since the output of "zfs send" tends to be very bursty, you need a sizable memory buffer.

Do you hide them behind the finished carpentry projects?

More accurately, the "exciting" choice is the inexpensive choice, and inexpensive means more launches, or more money available for other programs.

This isn't the turn of the century with your new fangled AGP 4x graphics card. PCI Express is symmetric. You can pull data in from peripherals just as fast as you can push it out. If there is a bottleneck in pulling computed physics data from modern graphics cards, it's entirely the fault of the internal design of those modern graphics cards.

Did the satellite get delivered to its intended orbit? Then it's a successful launch. That makes twelve successful launches, one partial success (primary delivered, secondary failed), and three failures.

You're not trying to find submarines hiding on the other side of a thermocline. You're just trying to track any obstructions within a couple dozen feet.

So give the thing a low power sonar system and automatic collision avoidance system. Give it instructions that if the battery gets below a certain point, it shuts down the engines, auto-surfaces, and starts up a rescue beacon.

Won't happen, barring a software bug, and a software bug IS an unavoidable liability of writing software. Google allows their autonomous vehicles to maintain pace with the flow of traffic, up to ten miles per hour above the posted speed limit. If the average flow of traffic exceeds the posted speed limit, it indicates the posted speed limit is much too low for the conditions of the road. Further, it would require everyone on the road to be similarly breaking the speed limit, which would mean those other hundreds of vehicles would all have to be simultaneously pulled over and ticketed, which is a logistical impossibility.

Come now. What percentage of people on the road actually have any situational awareness? They're not looking around to track voids in traffic should they need to change lanes in an emergency. They're not looking downstream to see that accident half a mile away and traffic backing up. They're watching no further than the brake lights in front of them. Even if they are trying to pay attention, it takes a hell of a lot of concentration and practice to constantly track a dozen cars around you in all directions, and a hell of a lot more to anticipate movements when those cars leave line of sight. This sort of thing is trivial for a computer.

As for "self", are you referring to the current state of the car? Surely autonomous control tied into your vehicle's data bus with direct access to engine sensors, accelerometers, gyroscopes, suspension deflectometers, and all manner of other equipment would have a much better chance of assessing the current state of the vehicle than the driver.

The US has no hard limit. If you're breaking the speed limit, you're breaking the speed limit, and it's the discretion of the office how bored/lazy/behind_on_quota they are as to whether you get pulled over and ticketed. The fact that the UK has actually codified this is absurd. Why not just bump the signage by that much, and make the signs themselves the hard limit?

The implication is that as a student, they moved her around to many different projects in many different areas to get a wider breadth of experience, but only a couple of them were ever likely to come to fruition.

If it's not structural, it's cosmetic. As long as you adhere to weight and attachment limitations, the facade can be changed on a whim.

It's still nothing more than a cluster. The only difference is your high availability and dynamic allocation is now performed at the (virtual) machine level, rather than the application level.