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.

Yes, but they're going to have to do this anyway. The DDoS won't affect just one customer, it'll affect lots of people at Rackspace, and will cost Rackspace money. Whether this one customer pays Rackspace or not won't make any difference to Rackspace's costs.

That's what makes Rackspace's behaviour here so dubious. Your example of it being like car insurance after the accident is invalid. It's more like a car accident that blocks the road. (Yes, yes, a car analogy on Slashdot, just deal with it, okay?) Whether you pay emergency services to move your car is irrelevant, because they either way they're still going to move it... because otherwise the road is blocked.

What makes you think they're going to keep their word? You're not signing a contract here, these are criminals! All you're doing is showing you're a soft touch. They'll be back, and they'll demand more money. They'll probably tell their friends, too. Not to mention the moral aspect that by giving in to these people you are directly funding crime.

No, you ignore them entirely. Don't even reply to the emails (but keep them safe). If they DDoS you, live with it. Remember that these guys rent their botnet from other criminals, so every second they're DDoSing you is costing them money. As soon as they realise that they're not going to get anything out of you they'll give up and move on to the next target. Yes, you'll probably be knocked offline for a while but (a) with a bit of marketing nous you can make this work for you, by issuing thundering press releases going on about not giving in the terrorist demands, issuing 'apologies' to your customers and giving them discounts to make up for it so driving sales, etc --- basically, free PR, make the most of it; and (b) your internet-facing servers should be coping anyway. Of course, given that they aren't, that last doesn't help right now. But beef them up because it'll help next time.

Rackspace's behaviour is contemptible, though. I'd suggest looking for a different provider.

After looking at those pictures, all I can say is: eeeeee. 128kB RAM maximum and a 16-bit processor? And they were trying to do real work on it? In 1998? What were they thinking? Even in those days, you trivially could do an indistinguishable emulation in software on a low-end PC...

A while back I was working on site with a customer... a major featurephone manufacturer, who will remain nameless so as to protect the incompetent. We discovered that the phone would crash if our software ran the CPU flat-out, even if it was at a lower priority thread than anything else.

It turns out that the sorry excuse for an operating system this thing ran was doing system-critical tasks in the idle thread, so if the CPU didn't idle some message queues would overflow and the OS would reboot. When I asked if there was a way around this, the response was that it was deliberate because the hardware would overheat if the CPU ran continuously for more than about thirty seconds at a time.

(This OS, BTW, was such an epic failure that when it was cancelled the entire staff went with it... and so did the building.)