Hacker News Reader

Comment by amelius | Hacker News Reader

> Most system components run in user-space on a microkernel system. Because of this, bugs in most system components won’t crash the system/kernel.

It's funny because I want this when I write applications. Each library should run in its own sandbox, and by default they shouldn't be able to touch each other's data.

View on HN

This is something the CHERI architecture[0] (an extension to ARM and RISC-V that implements a capability memory model) can allow this performantly with compiled code (without needing to context switch). This PhD dissertation from Cambridge[1] implements this for C/C++ under CheriBSD (their fork of FreeBSD that supports CHERI).

[0]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

[1]: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-949.pdf

illumos on RISC-V with CHERI would be the ultimate. There is another variant of RISC-V that is spectre immune. I have also recently heard of approaches at compile-time, such as RESPECTRE, that remove the spectre problem.

Something stupid I always wanted to do was to make an object-oriented language where literally every single object was a separate UNIX process. The naive implementation would have horrendous context switching overhead from the IPC, but maybe there's a clever and elegant way to use shared memory...

Practically Erlang

The original idea of Smalltalk was very much that :) Sadly, hardware limitations of the time did not allow Smalltalk to be implemented this way. Erlang was likely the first generally available implementation if the idea. (Now you write in Elixir for the same VM.)

It seems like the reduced overhead of cooperative multitasking (vs OS threads or even greenthreads) is so important that people are writing code entirely differently because of it. Like all those promise/future frameworks in Java etc, or NodeJS which works this way natively.

  https://learning-0mq-with-pyzmq.readthedocs.io/en/latest/pyzmq/patterns/pair.html

You're describing Elixir/Erlang?

Sorta, but while Erlang/Elixir isolates actors in normal APIs, a erlang process can access most anything using “system calls”. Same for RPCs to other nodes. You can do almost anything a local process can for better or worse.

Some of us are "spoiled" by Rust. About ten years ago the Erlang argument may have been somewhat compelling. Now we use software libraries that don't crash in the first place. Not every Rust library meets that metric, but using Rust as a baseline and a small handful of other patterns/practices it's not hard to meet these days.

Reply on news.ycombinator.com