Hacker News Reader

Comment by haberman | Hacker News Reader

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)

View on HN

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?

> You could imagine an OS with no threads. E.g. dataflow, or message-processors working queues, or something else.

Sort of like Erlang? Which can run on POSIX.

> Perhaps instead of processes we'd use just virtual machines.

Sort of like the JVM, or Docker, or VirtualBox, or any number of VM technologies that run on POSIX?

> There are strong reasons to want safety and security guarantees around the lifetimes of those things.

Why do any of these things need to live in the kernel to give safety/security guarantees? If anything, code that runs in the kernel is more vulnerable, not less.

btw. I don't think POSIX is the be-all end-all or anything. But if I imagine something better than POSIX, its abstractions are even less opinionated than POSIX, not more.

Putting things in a kernel control failure modes, security, performance at the cost of rigid APIs. So I understand wanting to avoid committing to a kernel. But its harder to make strong guarantees without.

Getting rid of POSIX is the only way of achieving safer OSes. POSIX is nothing more than the C runtime vs what other languages with richer runtimes offer. They standards body just decided to split the runtime between ANSI and Open Group.

I only care about OS POSIX support every time I have to go down to C or C++. Otherwise the OS can have whatever abstraction model it feels like.

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.

Reply on news.ycombinator.com