Comment by haberman
11 years ago
> 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.
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.
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.