lasiotus

I've been working on Motor OS for almost five years now. In May during the short Fable window it helped me find and fix a race that I've been debugging for about three months. Since July (when Fable, and later Astra) became available, most items on the roadmap have been fixed. What it would take me ~ 3 months doing myself (evenings and weekends), LLMs complete in about a week (with supervision; even Fable MAX and Astra MAX need supervision when doing critical low-level stuff).

It says

"Open source, native macOS and Linux packages, boots in under 10 seconds.

curl -fsSL https://capsem.org/install.sh | sh ",

but also

"What platforms are supported?

Capsem requires macOS on Apple Silicon (M1 or later). It uses Apple's Virtualization.framework which is only available on macOS. The guest VM runs aarch64 Linux."

So ... what is it? Also, there are a lot of "schreenshot placeholder" on the home page...

gVisor is... less secure than VMs; but the front page price-compares against VMs, so not apples-to-apples

Unikernels are on the smaller side of the spectrum; Linux on the larger side, with a lot of room in the middle...

Is there anything like this but in TUI?

Motor OS is now a Tier-3 target in Rust.

> If anything does present a concrete issue we are eager to address it.

That's great to hear! I think it is a bit too early to spend extra effort on porting Wasmtime to Motor OS at the moment, as there are a couple of more pressing issues to sort out (e.g. FS performance is not yet where it should be), but in a couple of months I may reach out!

> Not sure how to help with this [...]

I guess not much can be done at the moment: dependencies are often the primary obstacle in porting crates to new targets, and just comparing the list of dependencies of wasmtime vs wasmi gives a pretty good indication of which crate is a bit more careful in this regard:

https://crates.io/crates/wasmtime/33.0.0/dependencies https://crates.io/crates/wasmi/0.47.0/dependencies

I'm not the OP, but I have a similar experience with Motor OS: wasmi compiles and works "out of the box", while wasmtime has a bunch of dependencies (e.g. target-lexicon) that won't compile on custom targets even if all features are turned off in wasmtime.

Motor OS

Motor OS (https://motor-os.org) attempts to do exactly that, by focusing on a rather narrow, from a "mainstream OS", point of view, niche. Kind of "do this one thing better" approach.

Motūrus OS (https://github.com/moturus/motor-os) has a newer microkernel.

Some extra context for comparison: Talc is faster than Frusa when there is no contention, but slower when there are concurrent allocations. Both are much slower than Rust's system allocator. Benchmark here: https://crates.io/crates/frusa.

SEEKING VOLUNTEERS: Motūrus OS

Motūrus OS is a new operating system for VMs written in Rust. A lot of interesting things to do for someone interested in systems-level Rust projects, from a simple Elf loader to a crash-resistant filesystem.

Or just porting C stuff like vim.

https://github.com/moturus/motor-os

The lainding page at https://github.com/moturus/motor-os explicitly says that both networking and file I/O are slow and have to be improved. The only claim is about fast bootup, and the number is there, and can easily be verified.

Where do you see any unsupported claims re: performance?

I tried with async in the kernel first, but the cruft that was needed two years ago was not worth it in the kernel itself. The net I/O is actually async-first, see here: https://github.com/moturus/moto-runtime/blob/main/src/net.rs

File I/O will move to this model later (the current file I/O code is quite old and mostly a placeholder).

Yes! And because of sandbagging :)

I'm the project author/dev. Thanks a lot for posting this, and for comments/discussions!

I see two main concerns raised here:

(a) long-term viability and support (b) compilers, binary compatibility, etc.

While the first concern is definitely valid, and without a community this project will not succeed, I do believe that potential benefits of Motor OS (or a similarly focused/structured project) will eventually result in a widely used new operating system. There are major problems with Linux inside VMs (and sometimes outside), and the Linux devs are not focused on this enough to clean things up anytime soon. I work on Linux Kernel at my day job, I know.

Re: compiler instability, binary compatibility, etc.: I'm sorry, I don't understand what is the issue here. The latest Linux kernel can be compiled with different GCC or LLVM toolchains on x86_64, and the result will happily run old binaries compiled years ago with who knows what. repr(C) structs in rust are stable... So why so many concerns here?

Again, thank you all for your comments and questions - I'm happy to answer more (at least until my day job kicks in).