sea levels to rise almost a meter more than present over the next century ... hardly a doomsday scenario

I believe you don't realise quite how many people live within a vertical metre of sea level.

I have some of his science fiction novels. They are truly, truly awful. Highly recommended.

Most operating systems these days don't run device driver interrupt handling code directly in the interrupt handler --- it's considered bad practice, as not only do you not know what state the OS is in (because it's just been interrupted!), which means you have an incredibly limited set of functionality available to you, but also while the interrupt handler's running some, if not all, of your interrupts are disabled.

So instead what happens is that you get out of the interrupt handler as quickly as possible and delegate the actual work to a lightweight thread of some description. This will usually run in user mode, although it's part of the kernel and still not considered a user process. This thread is then allowed to do things like wait on mutexes, allocate memory, etc. The exact details all vary according to operating system, of course.

This means that you nearly always have an extra couple of context switches anyway. The extra overhead in a well designed microkernel is negligible. Note that most microkernels are not well designed.

L4 is well designed. It is frigging awesome. One of its key design goals was to reduce context switch time --- we're talking 1/30th the speed of Linux here. I've seen reports that Linux running on top of L4 is actually faster than Linux running on bare metal! L4 is a totally different beast to microkernels like Mach or Minix, and a lot of microkernel folklore simply doesn't apply to L4.

L4 is ubiquitous on the mobile phone world; most featurephones have it, and at least some smartphones have it (e.g. the radio processor on the G1 runs an L4-based operating system). But they're mostly using it because it's small (the kernel is ~32kB), and because it provides excellent task and memory management abstraction. A common setup for featurephones is to run the UI stack in one task, the real-time radio stack in another task, with the UI stack's code dynamically paged from a cheap compressed NAND flash setup --- L4 can do this pretty much trivially.

This is particularly exciting because it looks like the first genuinely practical L4-based desktop operating system around. There have been research OSes using this kind of security architecture for decades, but this is the first one I've seen that actually looks useful. If you haven't watched the LiveCD demo video, do so --- and bear in mind that this is from a couple of years ago. It looks like they're approaching the holy grail of desktop operating systems which, is to be able to run any arbitrary untrusted machine code safely. (And bear in mind that Genode can be run on top of Linux as well as on bare metal. I don't know if you still get the security features without L4 in the background, though.)

This is, basically, the most interesting operating system development I have seen in years.

I'd wait until there's more information about the protocols involved. It's almost certain that the video being displayed on the tablet is being broadcast via radio from the console --- which means it's entirely feasible that the tablet is dumb as rocks and isn't programmable; and that all the logic is actually happening on the console.

If that were the case, the only way you'd be able to repurpose the tablet would be to clone the no-doubt proprietary radio link that the console used, which is probably going to be hard.

In any event I expect the first reverse-engineering reports to come out approximately thirty seconds after this thing ships in the US, so it's not as if we'd have to wait very long.

Anyone can compile C into Javascript. Only I can compile C into... Perl.

See cluecc.

(Clue allows C to be compiled, badly, into a variety of scripting languages including Lua, Javascript and Perl as well as Java. Some nutter even contributed a Common Lisp backend. It was an experiment to see whether exploiting certain vaguenesses in the ANSI C spec concerning pointer representation was useful. Unlike Enscripten, Clue doesn't have a big array of bytes representing the C memory; instead pointers are represented as object-offset tuples. It worked really well, but unfortunately nearly all existing code out there doesn't work right on a system where sizeof(int)==sizeof(double)==sizeof(char)==1 and sizeof(void*)==2. Plus, the compiler frontend I was using had a number of major issues. But it works well enough to run benchmarks.)

(And before you ask, yes, compiling C into Perl 5 is a total, utter, complete waste of time.)

You're underestimating the amount of innuendo a skilled operator can extract from a slide rule. They are, after all, far more phallic than your average calculator.

Just don't try it with one of those newfangled circular slide rules.