A compute rate that varies with temperature would seem to be a bug, rather than a feature.

Read again: The inability to re-clock the GPU frequencies and voltages dynamically based upon load has been... The reclocking (or lack thereof) affects temperature, not is caused by it.

(Though the other responses are technically accurate, I think they miss the main point of the complaint.)

Add to that: speed doesn't matter to commercial transports nearly as much as reliability. There are a lot more people who are willing to accept shipment in 3 weeks from today than in 2-4 weeks from today. 5 knots is probably a little bit too slow, but 10-15 knots is a very respectable speed for a large cargo ship. It doesn't seem like much, but you cover a lot of distance doing 10 knots 24 hours a day...

Most of the more distant islands were colonised during small ice ages, when it was possible to walk much of the distance and people had to move a lot because food was scarce. There was thought to be a land bridge from South-East Asia to South America well after homo sapiens came along, and getting from Europe to North America via Iceland and Greenland wasn't such a massive journey for a lost Viking ship aiming for the islands around the north of Scotland.

For a long time, the limiting factor was the amount of food and water that you could carry. The reason that Columbus couldn't get funding for so long was that intelligent people did the calculations of his journey time and worked out that he'd run out of food about half way to India. Fortunately for him, there was a convenient continent a bit less than half way there for him to stop and resupply...

Sailing ships can be becalmed for days or even weeks. This is more of a problem the bigger the ship, as the more wind you need to start it moving again. Even at the best of times, their speed is highly variable, depending on wind speed and direction - if it's a head wind then they need to tack, which can significantly reduce their maximum straight-line speed, if it's a run or a reach then they can go faster. This makes them tricky from an economic perspective, where you need to book dock time well in advance to get goods loaded and unloaded and where your customers typically require things delivered within a fairly narrow window. For low-priority goods, it might be fine, as long as you were willing to wait at the far end for a few days for a free slot in the unloading dock.

There have been some attempts to address this, by flying kits up in the jetstream and using their rotation to drive a screw. This has a lot of potential, but the last demo I saw was only generating 20% of the energy required to propel the craft - the rest came from burning oil.

Sure, that's why, in the past year, we've had a load of network stack improvements contributed back by NetFlix and Juniper, a new flash filesystem and NAND layer by a company building embedded systems, a load of storage stack improvements contributed by iX Systems and NetApp, HyperV support contributed by Microsoft, sandboxing support funded by Google...

What about detecting domains that have just expired, but haven't been removed yet? And not just for .com but for other TLDs (and second-level domains as appropriate, see http://publicsuffix.org/) as well.

Yes. This. Just trying to figure out "is this domain registered, or is it available?" is a complete pain in the ass, for any sort of automated system.

I don't, I'm afraid. My school had a book shelf full of books of fun projects involving the BBC, and this was one entry in one of them.

I read a different book, in the '80s about things that you could do with a BBC Micro. One of them was a sound recogniser, which worked in a similar way with a 1MHz 6502. Most of this kind of book seemed to disappear in the '90s though, and didn't really start to reappear until recently.

At least in my experience, Phillips heads are rather more common than flat heads, and screwdrivers are about equally common for both. Both are far, far more common than anything else.

(I'm not saying that it's hard to find others -- just that if you're at a friend's house or something and need to borrow a screwdriver, there's a decent chance they'll have several flat heads, several Phillips, and little or nothing else.)

No, if you don't distribute the binary then you still have no obligation to distribute the code under GPLv3. Similarly, if you only use a program via file descriptors then GPLv3 doesn't require you to do anything except point your customers at an upstream URL.

The OS X kernel includes a lot of code from FreeBSD, including most of the process management code, the MAC framework, much of the VM subsystem, and so on. The userland includes FreeBSD libc and mostly FreeBSD utilities (the NetBSD code was largely gone by Rhapsody DR2). Check the license files on opensource.apple.com sometime...

It's not that clear cut. Sony is actually distributing the binaries, but for a lot of potential contributors the GPL doesn't force anything: they use their derived work internally, never distribute it, so don't need to share any changes. One the other hand, they will often avoid GPL'd code because of the potential for it to affect their ability to turn something into a product later. In this case, they'll either develop their own or, more likely, license a proprietary version.

Without the legal constraint, there are still reasons to push changes upstream. Maintaining a fork is expensive. Bugs get fixed and new features introduced upstream and the more you've diverged, the harder it is to pull the changes. This is why Juniper has recently been pushing a lot of things to FreeBSD - they've realised how much it was costing them for JunOS to be significantly different to a modern FreeBSD.

Even with the GPL's constraint, there are lots of ways around it. Companies ship mobile phones with Linux kernels and binary display drivers, by only using the public kernel interfaces and loading the driver late in the boot process, with most of it running in userspace. At worst, they're required to release the code for their shim that exports the hardware registers directly to userspace. For other code, you can run it in a separate process and the GPL doesn't apply.

We've ported Dalvik to FreeBSD. The Binder IPC stuff also needs porting, however having done this the isolation between applications could be much better enforced using Capsicum. For real-world usage, you'd also need to port the GPU drivers, because Android has its own graphics stack.

Try again.