The summary made me laugh. 'scientists says it has verified that quantum effects are indeed at work in the D-Wave processor'. Exactly the same claim could be made about pretty much any vaguely computer: how do they think transistors work?

With the exception of a very few fairly simple algorithms, anything that you can do in the cloud using homomorphic encryption, you can also do on your laptop without it...

Pretty much all of it. I don't know what a good business model for a FOSS game would be. Probably the same one that the TV studios use: provide a partial implementation (a pilot) for free and charge people for you to finish it. Once you've got enough funding, finish the game and release it. TV studios use channels as middle men in this situation, but there's no reason that it wouldn't work without the middle men.

The vast majority of software companies sell Free Software. Free Software just means that the person receiving the code has a set of rights to use, modify, and redistribute it, which is the case for most bespoke software, which is what most software companies (and, indeed, most software developers) sell.

It is difficult trying to combine selling commodity off the shelf (COTS) software with Free Software, but fortunately for 'FOSS Shills' COTS software has never been more than about 10% of the total software market.

Forking does that, because the GPL doesn't require that you contribute your changes back only forwards: you must give the code to the people you give binaries to, nothing more. It's easy to fork a project, make some structural changes, and then release your version that has all of the code that isn't necessary for your use removed and other things that are annoying for anyone who doesn't have access to the rest of your system added. The code is still available, but the cost of merging changes back upstream is often greater than the cost of rewriting them from scratch.

This is fine according to RMS, because the GPL is not meant to protect the authors of the original code, it's meant to protect the users who receive products based on it.

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...

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.

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.