5 ms·

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

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)

sehugg 11y ago
A GPU driver is a pretty grand abstraction.
- haberman 11y ago
  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.
  - monocasa 11y ago
    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.
JoeAltmaier 11y ago
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.
- haberman 11y 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.
  - david-given 11y ago
    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.
  - JoeAltmaier 11y ago
    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?
    - haberman 11y ago
      > 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.
      - JoeAltmaier 11y ago
        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.
      - 11y ago
pjmlp 11y ago
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.

sehugg 11y ago

A GPU driver is a pretty grand abstraction.

haberman 11y ago
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.
- monocasa 11y ago
  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.

JoeAltmaier 11y ago

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.

haberman 11y 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.
- david-given 11y ago
  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.
- JoeAltmaier 11y ago
  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?
  - haberman 11y ago
    > 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.
    - JoeAltmaier 11y ago
      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.
    - 11y ago

pjmlp 11y ago

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.