Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Why has no one put microkernels and Erlang into a blender? I know there's QNX, but it's still UNIX, not Erlang.

That's a very good question. There are some even lesser known dialects out there that do this but you are going to find it hard to get to the same level of feature completeness that Erlang offers out of the box.

QNX and Erlang embody quite a few of the same principles, but QNX really tried hard to do this at the OS process level in a way that destroyed a lot of the advantages that doing the same under Erlang would have. I think the main obstacle is the fact that the CPU does not support reductions natively. Maybe you could take it a step further and design an FPGA CPU that implements the core features of Erlang at the hardware level?

That would be an absolutely awesome project. Usually when you can think of it someone has already done it so a bit of googling would be a good way to start with that.



You nerd sniped me a little and I'll admit I'm not 100% sure what a reduction is but I've understood it to be a measurement of work for scheduling purposes.

A bit of googling indicates that actually you can use performance monitoring instur to generate an interrupt every n instructions. https://community.intel.com/t5/Software-Tuning-Performance/H...

Which is part of the solution. Presumably the remainder of the solution is then deciding what to schedule next in a way that matches erlang.

Disclaimer: this is based off some googling that makes it seem like hardware support the desired feature exists, not any actual working code.


Oh that's a really neat find. I'm not sure how 'instructions' map to 'reductions' in the sense that if you stop when a reduction is completed the system is in a fairly well defined state so you can switch context quickly, but when you stop in mid reduction you may have to save a lot more state. The neat thing about the BEAM is that it is effectively a perfect match for Erlang and any tricks like that will almost certainly come with some kind of price tag attached. An interrupt is super expensive compared to a BEAM context switch to another thread of execution, you don't see the kernel at all, it is the perfect balance between cooperative and preemptive multitasking. You can pretend it is the second but under the hood it is the first, the end result is lightning fast context switches.

But: great find, I wasn't aware of this at all and it is definitely an intriguing possibility.


> That would be an absolutely awesome project. Usually when you can think of it someone has already done it so a bit of googling

I've done a bit of googling and research, nothing viable has surfaces, and I still haven't found the time to create a prototype myself, just some doodling around here and there. I do agree that it's an awesome idea, and it's been stewing in my head for a couple years now!

There are a lot of moving parts (scheduler design, probably needs its own high level language and bytecode, mapping capabilities onto actor semantics, etc.) that are outside what current OS-research seems to be focused on.

EDIT: I've just seen the mention of your QNX-like OS in your profile. Lovely! Any reason you haven't posted it on Github/Codeberg?


I've got a hobby OS you may want to check out. Crazierl is a just enough kernel that can run the FreeBSD build of BEAM as a single OS process.

Features include: x86-32 only, bios boot only, SMP capable, drivers in Erlang (there's nifs for managing memory with devices or i/o; and the kernel manages the interrupt controller(s) and has console output before userspace takes over), a kind of working IPv4 stack, dist!

It doesn't run on all my machines, but it does on some (it does some VGA things that I guess aren't well supported and also non uefi is iffy these days too. I typically run it in qemu and v86, but I think it will work in VMWare as well.

https://crazierl.org/ https://github.com/russor/crazierl/

There's a hosted v86 demo as well (works better on a desktop than a phone):

https://crazierl.org/demo.html

It's also in the weird OS section at https://copy.sh/v86/


Very neat! I have my own OS to work with that I know like my back pocket, so if I ever go this route I'll probably just carve that up.


Did you get your serial ports working? :)

If it doesn't take much time, it's worth trying to get it to run in v86; it's so much easier to send people a link to a web page to poke at your OS than to send them an image and tell them to run qemu against it.

Edit: I misinterpretted --- you'll carve your OS up, not mine, that makes more sense!

Old comment: Feel free to carve away, just be aware that just because it's committed doesn't mean it works... I wouldn't take my memory management code, for example. There's some fiddly issues I haven't tracked down because it doesn't break consistently.


I got distracted (story of my life) by something very interesting that takes precedence but I'll return to it at some point, I've made up my mind about that.


That last link deserves its own HN post!


v86 has been posted a few times [1], I'm pretty sure that's how I became aware of it to use as a target platform. It's a nice project, and they've taken three PRs from me (so far) that make it easier for me to run my weird OS :) Lots of other contributions here and there from others which is great, because I thought I was going to have to build a virtio-net device in v86 or write a ne2k driver in crazierl, and other people built and debugged the virtio-net so I can just use it.

[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...


> Any reason you haven't posted it on Github/Codeberg?

Yes, I don't want Microsoft to be able to pretend claim I gave it to them for some particular purpose which I didn't. They'll have to come and take it.

Feel free to use that code and do anything you want with it, and if there are no more seeds for the code let me know and I'll serve up the torrent.


I hear you. These days all my projects are on private SSH repositories on my servers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: