Comment by haberman
11 years ago
I think we've discovered over time that OS Kernels aren't the place for Grand Abstractions.
Grand Abstractions are cool and powerful when you are happy to live within their universe. But they tend to be incompatible with other Grand Abstractions.
That's why modern kernels tend to focus on Boring Abstractions (threads, processes, locks, memory maps, files, cgroups, etc.) Then the interesting and more opinionated stuff can happen in user-space (Docker, JIT-comiling VMs, web browsers, mobile apps, etc)
Disagree. Those things are already GAs, just ones more familiar with programmers today. So we call them boring.
Change the way you think about code, and change the world. And it starts with the application environment, often called the OS.
> Those things are already GAs, just ones more familiar with programmers today.
Ask yourself this: could you efficiently implement Taos abstractions on top of POSIX? (probably yes) Could you efficiently implement POSIX abstractions on top of Taos? (probably no) That is the difference between a Grand Abstraction and a Boring Abstraction.
> Change the way you think about code, and change the world.
I agree that Grand Abstractions can be powerful.
> And it starts with the application environment, often called the OS.
Sure, just leave the GAs out of the kernel. It doesn't mean you can't have them. Just put them in user-space. Then GAs can operate in a competitive market where you use them because you want to, not because you have to.
intent was actually largely Posix compliant, towards the end. As it ran in a flat address space, we never managed to implement fork(), but I believe someone was working on exploiting the Java garbage collector to search for all pointers belonging to the process and rewriting them so as to allow copying the process somewhere else in memory... or something. Possibly the company folding was a mercy.
You could imagine an OS with no threads. E.g. dataflow, or message-processors working queues, or something else. Perhaps instead of processes we'd use just virtual machines. Maybe instead of managing memory, we manage only data abstractions e.g. capabilities. There are strong reasons to want safety and security guarantees around the lifetimes of those things.
All of those should properly be managed by a kernel, yes?
3 replies →
Actually I think library OS like Oberon, Singularity, MirageOS, Drawbridge are the way to go.
We are currently stuck with VMS influenced OS and UNIX clones everywhere.
This is why I follow the MacOS X, Android and WinRT changes as their stacks could completely replace the old idioms if they didn't care about backwards compatibility.
A GPU driver is a pretty grand abstraction.
How so? Yes it provides complex abstractions, but these are not inventions of the software, it is just exporting the abstractions supported by the hardware.
And in fact the kernel space interface doesn't abstract much at all. All of this Vulkan/Metal/DX12 stuff really looks like someone decided to simply export the kernel level interface in a cleaner way.