3 ms·

Show HN: Crazierl – An Erlang Operating System

72 points by toast0 7mo ago

Crazierl is an experimental/hobby operating system based around BEAM. I've linked the browser based demo; I don’t recommend using a phone; it does work, slowly, on the phones I tested, but it’s very awkward to use. You can share a link with a hashtag with your friends and click the consent checkbox, and it (should) link up into dist and I’ve also included a chat application you can start with chat:start(). (quit chat with /quit, or use the shell menu with ctrl-g to switch between shells etc). The browser demo relies on the v86 javascript x86 virtual machine. You can also run Crazierl on a real x86 system, but I’ve had mixed luck on modern systems, it uses some esoteric legacy VGA features and support for that isn’t getting better. Crazierl is fairly limited: 32-bit x86, BIOS boot, only two NIC drivers virtio-net and realtek 8168. But it's got enough to become part of an Erlang dist cluster. It also supports SMP, but it’s crashy with high core counts in qemu; there’s almost certainly several concurrency bugs in the kernel. There's also a lot of excess tcp debug spew (sorry). Source code is available (Apache) https://github.com/russor/crazierl/ https://github.com/russor/crazierl/

zephyrwhimsy 7mo ago
[flagged]
mixedbit 7mo ago
Is the OS implemented from scratch, or is it a stripped down version of some existing OS?
- toast0 7mo ago
  The kernel is pretty much from scratch. It provides a FreeBSD compatible syscall interface for the syscalls that BEAM calls, as well as the FreeBSD runtime loader. I do make healthy use of FreeBSD libraries to provide the OS, you can get an idea of what I pull from the file names in the Makefile [1]. Building an OS is a lot, so I tried to stick to the parts I find fun and interesting. Things like a NIC driver in Erlang [2] (with NIFs to copy to/from device memory). But process / thread creation is original, memory management is original (not necessarily good), time keeping is original, etc. I used existing code and interfaces so I didn't have to write a bootloader, memcpy, and lots of other stuff. [1] https://github.com/russor/crazierl/blob/main/Makefile#L23 https://github.com/russor/crazierl/blob/main/Makefile#L23 [2] https://github.com/russor/crazierl/blob/main/src/rtl_8168.erl https://github.com/russor/crazierl/blob/main/src/rtl_8168.er...
  - asenchi 7mo ago
    DragonFlyBSD would be really interesting here as well since its kernel has Light Weight Kernel Threads that use message passing. Similar in shape to Erlang/BEAM. Though I guess you've built the kernel in Erlang... so wrong abstraction.
    - toast0 7mo ago
      My kernel is in C. BEAM is in userspace. Most of the drivers are in userspace too. Turns out, if you let userspace mmap whatever address it wants to, and have access to all the i/o ports, plus have a way to hook interrupts, you can write drivers in userspace. You could run beam as init with an existing kernel, but I wanted to explore something with less kernel.
tombert 7mo ago
I've thought about doing something like this but I am only very recently getting into low-level OS stuff. I can't remember who said this, but they called "Erlang an operating system for your code", and I think that's fairly accurate. When I build an Erlang app, I don't build it the same way as I would with Rust; I have a lot of independent gen_servers that do operate independent from each other. The Erlang VM is (roughly) preemptive multitasking, and even each process has its own GC, so it does feel like it could be a natural fit for its own operating system without having to live on top of Linux.
- calvinmorrison 7mo ago
  There's some definite prior art here where they worked on that a LOT. https://www.erlang-factory.com/static/upload/media/1498583896660864samwilliamshowtobuildanoswitherlang_awhistlestoptourofhydros.pdf https://www.erlang-factory.com/static/upload/media/149858389...
  - tombert 7mo ago
    You know, I read those slides when they were new, and I apparently just completely forgot about it. Not that it's not interesting, just that my brain is dumb sometimes.
  - toast0 7mo ago
    Unfortunately, the hydros project website is gone. I'm not sure if it moved somewhere.
    - calvinmorrison 7mo ago
      here's what I dug up https://github.com/attah/hydros https://github.com/attah/hydros https://github.com/samcamwilliams/hydros-site https://github.com/samcamwilliams/hydros-site
      - toast0 7mo ago
        Thanks! There's some really interesting things here. I chose to interface with some basic hardware only from my kernel, but hydros uses Erlang to interface with the IO-APIC and a bunch of other stuff. They've even got NIFs to do sti/cli from Erlang.
lightandlight 7mo ago
> browser-based demo Wait, so is the browser running a JavaScript build of Qemu? /
- alhazrod 7mo ago
  It seems to be using 'v86' by copy. [0]: https://github.com/copy/v86 https://github.com/copy/v86
- toast0 7mo ago
  I don't think v86 [1] is based on qemu, but it's a javascript (well javascript + rust->wasm) virtual PC. Not my project, it's super lovely for hobby os demos though. (And they've taken a couple of my PRs!) [1] https://copy.sh/v86/ https://copy.sh/v86/ https://github.com/copy/v86 https://github.com/copy/v86
zephyrwhimsy 7mo ago
[flagged]
zephyrwhimsy 7mo ago
[flagged]
kajogo 7mo ago
super interesting!

72 points by toast0 7mo ago

zephyrwhimsy 7mo ago

[flagged]

mixedbit 7mo ago

Is the OS implemented from scratch, or is it a stripped down version of some existing OS?

toast0 7mo ago
The kernel is pretty much from scratch. It provides a FreeBSD compatible syscall interface for the syscalls that BEAM calls, as well as the FreeBSD runtime loader. I do make healthy use of FreeBSD libraries to provide the OS, you can get an idea of what I pull from the file names in the Makefile [1]. Building an OS is a lot, so I tried to stick to the parts I find fun and interesting. Things like a NIC driver in Erlang [2] (with NIFs to copy to/from device memory). But process / thread creation is original, memory management is original (not necessarily good), time keeping is original, etc. I used existing code and interfaces so I didn't have to write a bootloader, memcpy, and lots of other stuff. [1] https://github.com/russor/crazierl/blob/main/Makefile#L23 https://github.com/russor/crazierl/blob/main/Makefile#L23 [2] https://github.com/russor/crazierl/blob/main/src/rtl_8168.erl https://github.com/russor/crazierl/blob/main/src/rtl_8168.er...
- asenchi 7mo ago
  DragonFlyBSD would be really interesting here as well since its kernel has Light Weight Kernel Threads that use message passing. Similar in shape to Erlang/BEAM. Though I guess you've built the kernel in Erlang... so wrong abstraction.
  - toast0 7mo ago
    My kernel is in C. BEAM is in userspace. Most of the drivers are in userspace too. Turns out, if you let userspace mmap whatever address it wants to, and have access to all the i/o ports, plus have a way to hook interrupts, you can write drivers in userspace. You could run beam as init with an existing kernel, but I wanted to explore something with less kernel.

tombert 7mo ago

I've thought about doing something like this but I am only very recently getting into low-level OS stuff. I can't remember who said this, but they called "Erlang an operating system for your code", and I think that's fairly accurate. When I build an Erlang app, I don't build it the same way as I would with Rust; I have a lot of independent gen_servers that do operate independent from each other. The Erlang VM is (roughly) preemptive multitasking, and even each process has its own GC, so it does feel like it could be a natural fit for its own operating system without having to live on top of Linux.

calvinmorrison 7mo ago
There's some definite prior art here where they worked on that a LOT. https://www.erlang-factory.com/static/upload/media/1498583896660864samwilliamshowtobuildanoswitherlang_awhistlestoptourofhydros.pdf https://www.erlang-factory.com/static/upload/media/149858389...
- tombert 7mo ago
  You know, I read those slides when they were new, and I apparently just completely forgot about it. Not that it's not interesting, just that my brain is dumb sometimes.
- toast0 7mo ago
  Unfortunately, the hydros project website is gone. I'm not sure if it moved somewhere.
  - calvinmorrison 7mo ago
    here's what I dug up https://github.com/attah/hydros https://github.com/attah/hydros https://github.com/samcamwilliams/hydros-site https://github.com/samcamwilliams/hydros-site
    - toast0 7mo ago
      Thanks! There's some really interesting things here. I chose to interface with some basic hardware only from my kernel, but hydros uses Erlang to interface with the IO-APIC and a bunch of other stuff. They've even got NIFs to do sti/cli from Erlang.

lightandlight 7mo ago

> browser-based demo Wait, so is the browser running a JavaScript build of Qemu? /

alhazrod 7mo ago
It seems to be using 'v86' by copy. [0]: https://github.com/copy/v86 https://github.com/copy/v86
toast0 7mo ago
I don't think v86 [1] is based on qemu, but it's a javascript (well javascript + rust->wasm) virtual PC. Not my project, it's super lovely for hobby os demos though. (And they've taken a couple of my PRs!) [1] https://copy.sh/v86/ https://copy.sh/v86/ https://github.com/copy/v86 https://github.com/copy/v86

zephyrwhimsy 7mo ago

[flagged]

zephyrwhimsy 7mo ago

[flagged]

kajogo 7mo ago

super interesting!