BeamOS - Let's Imagine an Operating System Written in Elixir

Warning: Half-baked shower-thought follows. High probability of ridiculousness.

Suppose you wanted to write an operating system on top of the BEAM in Elixir. How would you design it and what do you think would be the biggest challenges?

What kind of unique features could it enable?

Let’s call it BeamOS.

I imagine each application within the operating system running as supervised processes, with some unique possibilities of running across several machines in a cluster. Perhaps even some kind of peer-to-peer-ish networking features, where one could share one’s hardware with friends and family.

Maybe I could run my word processor on your hardware.

I also imagine the possibilities for distributing applications through some kind of built-in app store/package manager thingy. Sort of like APT or Homebrew, but OS-native.

I suppose one of the biggest challenges of implementing an operating system in a language with immutable data would be running out of memory due to copying of data. Drivers, compute-heavy operations and GUI code would also need to be implemented as NIFs in C, I guess.

This is probably a silly idea, but I think it’s fun to think about.

Feel free to contribute to my fantasy, if you find it entertaining :slight_smile:

4 Likes

Definitely a fun idea and you aren’t the first to think of it. Check out these slides on the HydrOS project: http://www.erlang-factory.com/static/upload/media/1498583896660864samwilliamshowtobuildanoswitherlang_awhistlestoptourofhydros.pdf

Here is their official site, that i’ve visited before, but appears to be down right now :confused: http://hydros-project.org/

3 Likes

That’s really cool, @sneako —Thanks for sharing those links!

2 Likes

One limitation is that in an Erlang/Elixir node you can only have one version of module. This makes it difficult to run multiple applications if they happen to both use the same name for different modules. The confusion would be truly wonderful. :wink:

When we were designing Erlang and the basic ideas of how to use the language features we were thinking more along the lines of operating systems rather than of applications. I tend to think of it not so much as a language with concurrency but more of an operating system with a languages.

Have a peak at the GRiSP.

14 Likes

Thank you for your input, @rvirding! It’s very interesting to hear some thoughts and point of view about this topic from one of the originators and designers of Erlang.

That looks interesting!

I think it makes sense to use Erlang and the BEAM for embedded, where you’d want to distribute new versions of your code to a large number of devices without inconvenient downtime. Devices could get notified of new software versions and pull updates at convenient times, etc.

It’s one of the areas where hot code swapping might be a good solution.

I haven’t done any embedded programming yet and I’m looking forward to checking out Nerves at some point. Now that I know about GRiSP, I’ll check that out as well.

2 Likes

I really wish there was a BeEmacs.

3 Likes

It’s worth creating if only for that awesome name :smile:

3 Likes

@rvirding - Is it OK with you if I snag that as a quite for a presentation I’m putting together? :slight_smile:

2 Likes

Not quite the same but it made me remember the Midori, Microsoft’s take on how a message passing OS could look like

http://joeduffyblog.com/2015/11/03/blogging-about-midori/

1 Like

No worries, go ahead. :smile:

4 Likes

Awesome, thanks!

2 Likes

It’s more than entertaining, it’s enticing!
Having written OS-s for standalone embedded systems many years ago I think “BEAMOS” sounds awesome. My initial thoughts would be things like writing an ETS term-store to manage EEPROM for example . The BIOS events could post to system processes that manage a piece of hardware; keyboard!{} sort of thing. Where would be draw the line between Elixir and underlying driver code that would just have to be written in C/Assembly as well??

Given the nature of supervision trees and OTP this could be a very very resilient OS indeed!

:slight_smile:

4 Likes

Cool! Yeah, I also imagine it could be a great OS for IoT devices and heterogeneous nodes in the context of edge computing. I don’t have sufficient skills to make it a reality, though (yet).

1 Like

Well…there’s enough of us out there…I guess the first thing would be to create a bootable image, I’ve seen a few articles on how to do this but they all ended with “Don’t!” as it’s utterly pointless! LOL

But… I was a big fan fan of Squeak Smalltalk many years ago and they had SqueakOS, a similar idea.

I mean, taking it one step at a time, what would we need? A position independent build of elixir and libraries bundled into a bootable disk image…just enough to boot to the iex console ??

Stop there I think…I can feel an oppressive amount of thought queuing up…

It would be fun though…

2 Likes

Sounds like a challenge to me! :laughing:

[…] taking it one step at a time, what would we need?

I would’t even know where to begin.

I guess I’d have to read a book on operating system design first.

1 Like

It’s all about onions. That and mapping what you want onto what you have. Thinking back to my 8085 project (yes, that long ago) we designed “the ideal machine” for what we wanted to do (real time telemetry gathering, mass reading of digital I/O, analog cards etc) and then we looked at what the 8085 could do along with the supporting stuff 8255-s. 8259, etc (programmable I/O and interrupt controller respectively) and gradually wrote software that supported co-operative multitasking, provided an “API” for all bespoke software to use etc etc it was dead interesting as it was my first real job and I still remember like it was yesterday!

So, I guess we’d first have to figure out an initial set of goals; maybe keyboard I/O and basic tty style I/O and go for it. There’d have to be a “BIOS Layer” where Elixir code (via NIF code) can make calls to the BIOS and then process the return data to do something.

I’d start some processes in memory and then have an ISR (interrupt service routine) post the raw keyboard event to an Elixir process and what happens from there is anybodies guess! Likewise for terminal I/O, a buffer can be populated with outbound data (like an asynchronous UART queue or something) and an Elixir process can “receive” character data and then make the relevant BIOS call to output some text.

I still think the Squeak Smalltalk is a good one; that runs on more platforms than the JVM and that is still the case last time I looked.

It would come down to isolating those places where I/O is required and start simple. Once you could do basic keyboard and screen work then you could turn your attentions to the persistent storage model…hell I’d be so bold as to map DEFSTRUCT-s onto physical disk structures and leave it at that. Imagine treating the hard drive as a relational database and that’s all you needed to know…I mean it works like that anyway but it goes via a backend database driver…so all you’d need is a “raw disk” abstraction layer instead and that should be enough.

I am sure I could spend a lot of time thinking about this but…

- is it worth it other than for pedagogical reasons?
- who would use it?
- how would you maintain it?
- is it worth it? and
- is it worth it ??

Moving on…for now :wink:

3 Likes

I just came here to say it can’t be done!!

(hopefully now someone will make it)

1 Like

LOL! Yeah, that’s how the story goes. It’s like how the police officer in an action movie cannot solve the case until after he or she gets taken off the case and/or gets fired.

1 Like

That’s what the Nerves project does more or less.

2 Likes

@emacstheviking - It definitely seems like you’ve got way more hard-core/low-level programming experience under your belt than I have, based on that story. It sounds… deliciously complicated.

1 Like