[gibbonsrcool]

I’m asking this question as someone with zero experience in writing an OS, but who has done limited services development. Would it be an interesting research project to write an OS with the following traits: 1. The purpose of the OS would be to run microservices only 2. The OS would provide the minimum functionality to provide a platform for services to run on the web assembly system interface 3. Some interim solution for providing sockets would have to be built until wasi spec supports it 4. No file system, no writing to disc, OS gets booted from USB, services pulled and initialized from network

Apologize ahead of time if this is a naive question and I need to jump into more traditional OS dev to get my bearing. I’m a mobile/services taking a break and I just happen to currently be intrigued by Rust and WASM.

[im_down_w_otp]

When we add WASM support to https://github.com/auxoncorp/ferros it'll sorta be like what you're angling at there in your description.

[gibbonsrcool]

Thank you

[pjc50]

> 1. The purpose of the OS would be to run microservices only

Ah, a microkernel approach! It's not a bad idea but tends to lose out in performance terms.

> Some interim solution for providing sockets would have to be built until wasi spec supports it

With a little ambition, and an inter-process communication framework, you could have a "network card microservice" that's got access to the PCIe registers and takes packets in and out. You could then either do "user-mode networking" in the application or run a normal IP stack to hand out packets to more normal looking sockets.

> No file system, no writing to disc

No reason why you can't write a NVMe driver in WASM...

[andrewchambers]

You could start your search looking for 'unikernel' tools, a few already exist.

[pjc50]

Unikernel is kind of the opposite of microkernel, though; a unikernel merges the application "upwards" into the kernel, while a microkernel system tries to split responsibility into lots of not-especially-trusted pieces.

[masklinn]

At the same time, a unikernel will usually rely on a unified upstream virtual machine, which a hypervisor will provide, because you're rarely going to run unikernel applications on exclusive bare metal.

In that context you can think of the hypervisor as your microkernel which provides a unified but very low level API to the unikernel-based microservices.

[pjc50]

Yes. Whereas in a traditional setup you'd have an "OS" running an "executable", the hypervisor-unikernel setup the unikernel plays the role of the executable. This indicates that something is very wrong with the OS APIs that this is considered the best way to arrange the desired isolation level!

[gibbonsrcool]

I hadn’t heard this term before so that will help my search.

[girvo]

MirageOS is not Rust, but in the ballpark!

https://mirage.io/

[rascul]

I have also found OSv to be interesting.

https://osv.io/

[gibbonsrcool]

I am also interested in OCaml, so thanks for sharing this. I’ve heard it’s higher level than Rust and has GC. I’ve spent most of my career using Java and after a few weeks of Rust I love many things about it but feel managing lifecycles and ownership might be too much for me.

[speed_spread]

Hang in there. Lifecycles manage themselves, mostly. You can write large, complete applications without handling a single explicit lifetime. The borrow checker becomes second nature once you get the hang of it. Don't feel bad for using Rc/Refcell/Clone everywhere. Your code will still be faster than it would have been in most other languages.

[KMag]

The thing about GC is that it doesn't free you from having to think about lifecycle management, it just frees you from having to write it down. I've seen a few memory leaks in Java programs due to people not putting enough thought into when a piece of data is no longer needed.

Granted, most programs don't run long enough/process enough data for poor lifecycle hygiene to become noticeable in GC'd languages.