> How secure were these devices? How much work was put onto application developers to maintain isolation? I mean it wasn't feasible back then since we didn't have MMUs (ifaik)

I'm almost willing to bet money VM has been used in production for longer than you've been alive. And of course machines had MMUs back then: They built a special one for the IBM System/360 model 40, to support the CP-40 research project, and the IBM System/360 model 67, which supported CP-67, came with one standard. IBM, being IBM, called them DAT boxes, because heaven and all the freaking angels forfend that IBM should ever use the same terminology as anyone else...

> This argument is pretty poor, since we've done a lot of things - cooperative multitasking, windows versions which had little to no isolation between the root user and other users, etc. etc. it doesn't mean they are the best approach now, or were even a good idea at the time. Yes we got them to work. Microsoft Bob and Windows ME worked too.

The difference between this and Windows Me is that we knew Windows Me was a bodge from day one. Windows 2000 was supposed to kill the Windows 95 lineage. (What's a "Windows 2000"? Exactly.)

Anyway, the hypervisor design concept came from people who'd seen what we'd now call a modern OS; in this case, CTSS, the Compatible Time-Sharing System (Compatible with a FORTRAN batch system which ran in the background...). They weren't coming from ignorance, but from the idea that CTSS didn't go far enough: CTSS was a pun, in that it mixed the ideas of providing abstractions and the idea of providing isolation and security into the same binary. The hypervisor concept is conceptually cleaner, and the article gives evidence it's more efficient as well.

> I don't think the javascript PC emulator runs that acceptably fast either. That was more of a toy example, I don't think you'll find many people using that for anything real.

You missed my point. My point was that it works acceptably fast (yes, it does, I've used it, and you won't convince me my perceptions are wrong) even though it's operating in the worst possible context: In a userspace process on an OS kernel, where everything it does involves multiple layers of function call indirection and probably a few context switches. Compared to that, getting a stripped-down unikernel written in OCaml to be performant has got to be relatively easy.

> At the kernel level performance/resource usage really does matter. I don't know enough about OCaml to comment on how it performs but especially when you make your argument about how (allegedly) terribly linux performs in certain circumstances, and that's a lot of what the selling point of unikernels are, it doesn't really follow to talk about how 'acceptable' performance is possible from higher level languages.

First: Only the unikernel would be written in OCaml. The hypervisor would have to be written in C and assembly.

Second: I never said Linux performs terribly. Linux performs quite well for what it is. It's just that what it is imposes inherent performance penalties.

Third: Although the article focused on performance, the main reason I support hypervisors is security. Security means simplicity. Security means invisibility. Security means comprehensibility, which means separation of concerns. Hypervisors provide all of those to a greater extent than modern OSes do.