Running the figures through Google math, starting with a 60"x42" panel generating 55W at peak, I calculate a 116 mile x 2 meter strip of solar panels would generate ~12MW. That's an order of magnitude short... I don't know what kind of duty cycle the 110MW is required at, but if that's continuous to run the train line, it's only going to be able to operate for an hour a day.

It's enough to make one suspicious about feasibility, anyway.

What's your point? Processors can pipeline across branches just fine, and the main effect of cache is to give a performance boost to smaller code -- code that separates and reuses functions rather than inlining them willy-nilly.

Inlining can still be a win sometimes, but compilers will do that for you automatically anyway...

Actually the idea makes sense. When they say VM, they mean like Java VM, or .NET runtime VM. The quote you pasted has the goods: "this VM has no means to convert integer to pointer". So you can't make a pointer into your neighbour process' data unless that neighbour process gives you such a pointer, because the only way to get pointers in the first place is from malloc().

This is the basis of security in sandboxed Java applications, it's not controversial or new. IIRC MS Research is working on a similar operating system that uses the .NET runtime -- ah yes, Singularity OS.

The state save on shutdown, far from being the best thing about this OS, as far as I'm concerned is the worst thing. Even if the software written for this thing is bug-free and never corrupts its own state, hardware is not 100% reliable -- memory gets corrupted, disks get corrupted, drivers end up wedged in unexpected states due to flaky hardware.

Imagine if a BSOD-equivalent occurs due to something that got corrupted 30 seconds ago, and that state got persisted to disk. From now on, every time you turn the machine on, you have less than 30 seconds before that exact same BSOD happens. Congratulations, your computer is now useless until you reinstall your OS! Brilliant.

The obvious workaround is, of course, to save program state out regularly as files in a constrained, standard format, which is independent of your program's implementation. Other reasons you might want to do this include upgrading software and interoperation between different applications.

But of course, as soon as you admit that, you admit that the new paradigm is not actually going to be a programming revolution at all, from an application perspective. You have to be able to save your state to a file and restore it: the only difference is that now that code will get executed less. As a programmer, though, it makes no difference to me whether the code is executed once or a million times, it's exactly the same effort to write it.

The filesystem is an ugly anachronism in a lot of ways, but it's also really, really technically practical.

That said, I wouldn't be surprised either if we were using VM-based operating systems in 10 years or so. There are some really interesting things you can do with JIT compilation when the OS and application code are not divided by a giant wall. But I do think they'll have filesystems of some sort.

I would imagine they work pretty much the same way bans, embargoes, and tariffs work for all goods: exports and imports are declared by the sender and inspected at the border. The government bodies that deal with imports and exports have been doing it for a really long time.

That's not to say smuggling doesn't happen, but I think by now it's a pretty well-understood problem.

When the ban was put in place the people who put it in place surely knew roughly how many printers were likely to be smuggled in from the US anyway, how many would come from sources in other countries, etc. I can believe there wasn't a good reason for passing the law, but assuming they were completely ignorant of the possibility of smuggling is going a little far...