The obvious distinction is whether they invest a engineering effort in developing things. Most patent trolls just buy up patents and then try to turn them into money. Companies like ARM also don't make things, but the stuff that they license has obvious value: creating it independently from scratch would require a lot of time and money. Typically, these companies don't just license patents, they also provide detailed designs, engineering support, and so on.

It's much easier to sell an unlocked phone than a locked one, so that's still valuable.

I only spent a few minutes looking last time I was in the US, but I found lots of mobile phone shops that were willing to give cheaper SIM-only deals and even more such deals were available online. Eventually I decided that since my phone had OSMAnd for offline maps and I had WiFi in the hotel (and a lot of coffee shops and so on), I didn't need to bother with mobile coverage.

When people say GSM, they mean the ETSI standards, including UMTS, HSPA and LTE. Most vaguely recent 'GSM' phones speak at least GSM and UMTS, many also do HSPA and the latest ones do LTE as well. All of the newer standards are also patented, but they're RAND licensed and so there's lots of competition among device makers.

One of my undergrads just started his PhD and drew my attention to the fact that he was born after the Web was created. I stopped using dial-up when he was 9, so it's entirely possible that he has never used a modem...

That's not what I mean. The defragmentation should happen as part of the normal read / write process. It should not be a separate task, because there is no gain at all (and a significant penalty) from defragmenting files that you (almost) never access.

The main advantage of VMs over processes is that they have a much smaller amount of OS state. In a VM, almost all of the state is within the VM. There's a tiny amount for the PV devices, but that's it. In a POSIX OS, even the state associated with the file descriptor table is huge and then there are things like locks that are blocking in the kernel and all of the state that is associated with the scheduler and so on. If you want to move a process from one host to another, it's decidedly nontrivial, especially if it has open files and sockets. Hypervisors, however, are designed to suspend, resume, clone, and migrate VMs.

No, what they've 'invented' is called a LibOS, and in combination with the hypervisor is called either a separation kernel or an exokernel, depending on which community you're in. And they aren't claiming to have invented it - academic literature is full of them - they're claiming to have implemented one that is BSD licensed, available now, and runs existing Linux binaries.

C++ has had a reliable standardised ABI for years. It's supported everywhere except Windows...

Take a look at the donors list to the FreeBSD Foundation and see how many of them are big companies (e.g. NetApp, Juniper) that ship proprietary products built on FreeBSD, yet still contribute back changes. And then look at companies like Google, which build their infrastructure on Linux but keep a lot of changes public. The GPL doesn't force them to give anything back unless they distribute the modified version, and they don't distribute the modified Linux that they run on their servers. It's only a legal risk if you are distributing the software, but given that 90% of all developers are working on in-house software that is never intended for distribution then that means that the GPL only ever forces the 10% of potential developers who are working on commodity off-the-shelf software to release code, and they are the ones who are least likely to touch the GPL in the first place.

Over the years, I've worked with companies that have maintained private forks of GPL'd projects, because they don't want the potential liability of distributing things under the GPL. When they take some of our BSDL code, however, they'll push back patches because there's no possible legal obligation arising from their doing so, and it's cheaper to have all of their changes upstream than maintain a private fork. I've also worked with companies that have done a clean-room reimplementation of a project rather than touch the GPL (in many cases, it's remained private, in some they've released it under a permissive license).

It's using a (heavily modified) FreeBSD kernel with the Linux compat layer, so it's not surprising. And the 1% speedup isn't the real win. The benefit is that you can make a very small VM image that can spool up new instances in about a second. It isn't that you can run a single instance 1% faster, it's that when you get load spikes you can start up 1000 new instances in between getting the SYN and sending the ACK...

You don't have 12 VMs. You have 12 kinds of VM. You have tens to thousands of instances of those VMs, depending on your load.

And in the deployment scenarios that this is intended for, each one of those would be running in a separate VM. If you have lots more incoming mail, you might spin up more spam filter instances dynamically. You'd probably only have a single persistent VM for the storage, but everything else would be scaled dynamically.

There really isn't on most cloud systems. You compromise the web server, and now you've got the credentials to access the db server. That's far more important than anything on the local filesystem. Sniffing all traffic going to the system? There isn't any traffic going to anything other than the (single) running app. And even with a compromised kernel, you can't put the interface in promiscuous mode because the paravirtualised device doesn't support it.

So the question is whether you'd rather have a slimmed-down FreeBSD kernel in your TCB or a full-featured Linux kernel and GNU userland. If you have an OS where you can spin up new instances in a second, that makes it possible to compartmentalise your system much more than if starting up a new VM takes a minute. It also makes scaling easier.

Nothing. This is the plan that was discussed at BSDCan this year. It's basically a more formal way for the people that were already collaborating to continue to collaborating, but in a way that encourages more people to join in.