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.

If you make a web site and it happens to crash IE6, then you're not at fault. If you make a web site that intentionally crashes IE6 and encourage IE6 users to visit it, then I don't see why it would be treated any differently from any other DoS attack. If I find a bug that crashes Apache from a malformed URL and then stick a link to someone's Apache server with such a URL on my web page, I don't think there's any doubt that it's malicious.

In the case of Google, they intentionally exploited a security hole in Safari to collect information about the user. This seems like something that is a pretty clear cut case of violating whatever the US equivalent of the Computer Misuse Act is. $17m seems like a very low fine considering the number of people who were affected. It's under $1 per incident, which doesn't seem enough to discourage a company like Google.

If they install them for the purpose of making your phone vulnerable, yes. If they exploit the holes introduced by the crapware for profit (or for other purposes), then yes.

They identified a vulnerability in a piece of software, and instead of reporting it they decided to exploit it.

More specifically, Apple does not and never has allowed GPLv3 code into the building. They're not stripping out GPLv3 code, they're staying with old versions of projects that switched to GPLv3 until a permissively licensed replacement is finished. This is not a strategy exclusive to Apple - a lot of companies were unhappy with GPLv2 and now find GPLv3 quite scary. We've had quite a few companies start to contribute to FreeBSD and related projects as a result of GPLv3.

Most of those companies don't donate large amounts to the Foundation, but they do employ people to work on code that can be upstreamed. This benefits the system a lot, but the advantage of Foundation donations is that they can be used to work on things that are not directly commercially relevant now - for more strategic projects, or for cleaning up bits of the infrastructure.