The posited advantage of an hereditary monarchy is not so much that the new is the son of the old ruler, it's that he is raised from birth to rule adn the responsibilities that this entails. This can be a better idea than having someone with a sufficiently big ego to decide that they ought to be in power. The first problem is that you don't have a good fallback - if the next in line to the throne is a poor choice then ideally you'd have a dozen other candidates to pick from. The second is that monarchies traditionally don't provide a good way of deselecting the ruler. Perhaps the biggest selling point of democracy is that you get to have a revolution and overthrow the government every few years, without anyone having to die.

And the problem here is awarding academic funding to people because they're good at non-academic activities. How about decoupling them entirely? Seems to work everywhere else...

There are a very small number of truly exceptional C?Os and most of those know a single industry very well and do badly when translated to other markets. According to a study that was on Slashdot a couple of years ago, the vast majority make decisions that are no better for the company that a random selection. You can replace most Fortune 500 CEOs with a magic 8 ball and get about the same performance. That's not true of most of the other employees, including the janitors, so why are they paid several orders of magnitude more? Because most of the CEOs are on the boards of other companies and approve large salaries in exchange for the same favour being paid to them.

With a ground-pointing camera and an estimation of altitude you can use feature detection to get a moderately accurate estimate of speed. This won't work if you're above the clouds, but if you are then doing the same thing with the clouds will give you a rough estimate of air speed, as clouds are approximately stationary relative to the air that contains them.

BeOS 5 is not easy to compromise remotely because the network stack crashes under load, or after a few minutes of low load. Does Haiku have the same feature?

The grid losses are about 7%, but that's because the distances are kept quite small. Most consumers are in the same state as their power stations, and often a lot closer. There's a reason power stations are built quiet close to cities. Try powering the coasts from a solar array in the middle of the USA and you'll see much bigger losses. And the middle of the USA is exactly where you want to have large-scale solar collectors: where you have lots of empty space with lots of sunshine.

Solar is not great for powering the grid, where the supply and demand must be balanced and where you want to put the supply and demand close together to minimise transmission losses. It's much better for workloads that are effectively charging batteries. If you stick big solar collectors in the middle of the desert, connecting that up to the grid for the rest of the USA is pretty difficult and you'll still have the problem that there are big demand spikes just as the solar sun starts to set. In contrast, if it's all producing hydrogen (or charging batteries), then you can build up a small surplus to cover times when demand spikes above production temporarily and you just need pipes to ship the water in and trains to ship the power out.

There's a difference, which is that most crappy corporate software isn't attempting to define standards and a platform for everyone else to build on top of. OpenStack claims to be developing a vendor-agnostic standard and reference implementation for interoperable systems.

Why would a filesystem need to know? On FreeBSD, the filesystem just spits a BIO_DELETE command into the GEOM layer, and it is up to GEOM to schedule when to dispatch it - it's free to reorder it, as long as it doesn't move it after a BIO_WRITE with an overlapping range. If the filesystem needs to know about the status of other filesystems then that's a serious layering problem. The FS should not be making the decision about whether to send the BIO_DELETE, because it's the responsibility of something lower down the stack to decide what to do with it. For example, a RAM disk can use it to free the underlying memory. You don't want every filesystem to have to know about every possible kind of device.

And TRIM is enabled by default on OS X if you use the stock drives. If you use an after-market replacement then you do need to explicitly enable it (which sucks). With FreeBSD, it's enabled for UFS by default since 9.0 and ZFS by default since 9.2. It is also enabled in software raid configurations by default in 10.0. I'm very surprised Linux doesn't enable it by default.

Because that would require the flash to do deduplication and know that the blocks were full of FF and so could be copy-on-write (and, in your scheme, block-level compression). You're thinking of an SSD as if it were a big RAM chip, full of blocks of flash with a simple addressing scheme. It isn't. It's a load of flash cells, which wear out over time, and a very complicated controller that maps blocks to cells. The point of TRIM is not to erase the block, it is to remove the block from the remapping tables so that that the wear levelling knows it has an unused block that can be erased whenever it makes sense to do so. The erasure happens on a cell granularity, and cells are some multiple of the block size (not sure what they are these days, probably 64-128KB). Knowing that all blocks in a cell are free is great, because the controller can then erase the entire cell. Knowing that only one block is in use and it hasn't been modified for a while means that it can defragment by erasing one cell, moving the individual infrequently modified blocks to that cell, and then add their old cells to the free list for erasure.

It's also worth noting that there are two modes for TRIM. One enforces the invariant that two reads of the same block will give the same value if there are no writes between them, the other only requires this invariant for blocks that have not been marked as erased. There's often a performance difference between them, because the latter lets the drive just leave the block as spare and overwrite it during a GC and then reallocate it on write (a good implementation would mark it as zero'd and always return zeros until there is a write, but this requires slightly more space in the remapping tables and so isn't always done). It sounds like Linux is still using the former version, which can be very slow on some drives.

Bitcoins have experienced drops in value over the course of a single day that are greater than the drop in value of the US dollar over the entire great depression, or its total deflation over the last 100 years. It's not cratering because it's value is effectively a random number and it will keep going up for as long as people are making money from the wild fluctuations in value of an unregulated instrument. When the big speculators cash out and the rest realise that they just own a magic number that no one with significant assets has ever promised to accept in payment, you'll see what cratering really means.

So you're saying that being a politician is just considered a misdemeanour?

And yet SELinux went in. And if you look at the last decade of CVEs for the Linux kernel, see how many come with the note 'Does not affect users not using SELinux'. A great many of them were in the null pointer dereference checker, and were an entire category of exploit that was unknown until the NSA contributed SELinux. But, sure, go on believing that Linus keeps you safe from the NSA if that makes you happy.