Hi there, I work on Fuchsia, specifically on our Software Delivery system [1].
You hit on exactly the right point: it's _possible_ to download and run software on demand, but it's also possible (and recommended) for products to turn off that capability if it's not useful or valuable for their use case. We pin packages for the base system itself, as well as lots of configurations of products.
The ability to run code on demand is really valuable for our development flows and quick prototyping: built a new test or experiment? No need to update your device, just try to run it, and it runs!
There are some ways to do this on paper ballots! They aren't foolproof, but provide optional verification of votes without relying on electronic voting.
A number of end-to-end verifiable voting systems have been proposed and fielded! See [0].
The key issue they try to solve is how to let you check your vote was counted without being able to prove who you voted for to anyone else, thus preventing coercion attacks.
Most of them rely on paper, but some [1], provide reasonable guarantees about online voting.
Backpressure between threads and utilization could be hard here. Balance between the speed of the accept, request, and worker threads is something I'm curious about. In theory, you could create pools of each if you find that one set bottlenecks the other. Also, workload isolation is important--I'm curious how the author deals with (or avoids) transferring ownership of large amounts of memory and cache between cores without incurring significant transfer overhead.
The real problem is the entrenched legacy software that uses BSD sockets. I don't want to even imagine the cost of rewriting all of that to use a different networking paradigm. POSIX certainly isn't the best way to do things, especially with the move to the cloud, but much of today's high-performance software today does fine with sockets. There are absolutely some hacks that are used to get around some inadequacies, but BSD sockets work, by and large.
It happens all the time, actually. Michael Bloomberg has attributed the rise in New York's crime rate recently to a rise in the snatch-and-grab thefts of Apple products. [1]
It looks like the GPU on the RasPi is still more powerful, so the cheaper board might still be better for things like a media center application. I'm very curious though about what appears to be a SATA port on the Cubieboard.
Also, the RasPi has a huge initial advantage in that it was in the space first. They have a leg-up in publicity, marketing, and simply an initial user-base. If the Cubieboard benchmarks don't absolutely trounce the Raspberry Pi for almost every type of computation, I don't see the Cubieboard overtaking the Pi anytime soon.
I'm going to go ahead and guess that the people behind Qubes were worrying less about the fact that the desktop paradigm may be fundamentally flawed in terms of usability (not going to argue on that one), but more about security, which is the stated goal of the project. Desktops may be on the way out, but that doesn't mean that we can't do some very basic security work on the heart of the OS. Looking at some of the documentation, it appears that their VM-per-application-group idea could scale very well to touch- and app-based interfaces with some work.
Security has a vital place in every OS, regardless of the skin you put over the top of it.