1. 9

  2. 2

    Reminds me of Your computer is already a distributed system. Why isn’t your OS? from HotOS 2009:


    We argue that a new OS for a multicore machine should be designed ground-up as a distributed system, using concepts from that field. Modern hardware resembles a networked system even more than past large multiprocessors: in addition to familiar latency effects, it exhibits node heterogeneity and dynamic membership changes

    And now that I look at the author list, I see Roscoe, who gives the 2021 keynote that Cantrill recommends:


    (copy of HN comment)

    1. 2

      Looks like the first link was truncated; the full URL is https://www.usenix.org/legacy/events/hotos09/tech/full_papers/baumann/baumann.pdf.

    2. 2

      First I’ve heard that Oxide is developing their own operating system - amusingly named Hubris!

      1. 1

        I don’t write Rust nor any low level coding, but Bryan Cantrill always makes for an interesting watch.

        1. 1

          and the binaries are tight!

          He’s talking here about no-std. But I wonder, in light of this, why the std-based (i.e. non-embedded) Rust world has a reputation for bloat while the no-std ecosystem apparently does not. Maybe the embedded developers are just aware enough of their constraints that they don’t pile on abstractions?

          1. 3

            Making an analogy to C++, I think maps and vectors are incredibly convenient data structures, but they have 2 issues for embedded: 1) they allocate on the heap (in order to grow) and 2) they bloat your code because you will have vector<T> and map<K,V> for dozens of T, K, V in a given program.

            So if you make a rule of not using heap allocation, then you can’t use standard containers, and a consequence of that may be less code bloat. You have to do everything the “long way” – C-style – which is way more code to write, but compiles to less code.

            I don’t actually have any experience with Rust no_std but I think there are pretty clear parallels… interested in any opinions to the contrary.

            1. 1

              That’s one thing I like about Zig: I can use standard containers without heap allocation. No no_std needed, just pass in an appropriate allocator.

            2. 1

              different targets, no-std has to be slim, with std you can use the NPM approach: everything and the kitchensink, also it’ll work without any problems to do that. And of course a static compiled runtime (that isn’t stripped?) doesn’t help reducing the size.