Jonathan Blow

every time you access a device. Note that even just this latter constraint would simplify current-day kernels massively.

Thanks Jon. Do you have a simple explanation for how competing programs would share a device safely? Something akin to locks in shared memory?

I think that depends on the device, because different tasks are different. It seems easy to figure out how each individual task would work for most devices. The hard one I don't know about is the file system, I feel like that still needs to be in kernel, but haven't thought

about it enough to be really sure. That said I feel like "the filesystem" is probably the problem. I am not sure why there should be a "the filesystem" as opposed to whatever filesystems applications maintain with user-level code (there is an overall disk space allocation

problem, but that is the kind of thing that would be in per-application permissions anyway -- how much disk is this program allowed to use?) This means programs are siloed off from each other's files and probably most system files, but this is what we want for security anyway.

(Well you also have to schedule, but I feel like by the time you get down to scheduling raw reads/writes, that is simple enough for the device to do without a kernel in the way).

And they already _do_ schedule them... all drives now have complicated controllers with caching on them, so it's not like the OS is doing the heavy lifting - the _drive_ is doing the heavy lifting.

Reinventing OS is one side of the story. But isn't the gaming targeted part like a small bootloader with an unikernel, with access to HDD, GPU and raw CPU (+threading & networking eventually). Like the Amiga OS in @cmuratori talk? Boot into a game