Live data from Hacker News

MotorOS: a Rust-first operating system for x64 VMs

github.com

91–100 of 125 posts

Re: MotorOS: a Rust-first operating system for x64 VMs

#91

The author wrote this on reddit: > What does "Rust-first" mean here? It means not only that both the (micro) kernel and the drivers are implemented in Rust, but also that Rust is the first (and only, at the moment) language that userspace programs can be written in. > Although technically one can reverse-engineer the Rust-based ABI and the provided Rust toolchain to write apps for Motor OS in e.g. C, that is some wor…

I thought the Rust ABI wasn't even stable?

Re: MotorOS: a Rust-first operating system for x64 VMs

#92
post #69

I think the most close to production ready "mostly" Rust OS is Fuchsia.

I've seen this stated in a couple places, but IIRC the kernel is C++ and the UI is Dart. I assume lots of things in between could be in rust, but do you know which? daemons, services, drivers, window server?

Re: MotorOS: a Rust-first operating system for x64 VMs

#95
post #79

> ...Docker, Nix OS, "serverless", etc. all exist because of Linux's complexity Yeah, this seems like it's more directly competing with those than Linux. I'd want to see those addressed in the "Why?" -- that is, why MotorOs instead of Docker, etc.?

> why MotorOs instead of Docker, etc.?

It basically says it already:

> Motūrus OS is a microkernel-based operating system

By and large, microkernel and containers solve the same problem. Except, I wouldn't call containers a "solution", more like a workaround. Not in the sense that containers by themselves are a workaround, but the way they are used is a workaround for the same problem.

The way containers are used today, especially in the context of Kubernetes, is to finely slice the available physical resources. The orchestration allows to manage which part of the application gets what slice of the resource, thus attempting to cut down on waste that's typically generated in the world where resources are managed through VMs. Where the typical problem is that a single VM will require too many resources because of the bloated OS it needs to run and because it's hard to create VMs with very limited resources, since OSes usually come as a package deal.

So, containers "solve" the problem by giving up VM optimization -- instead it's usually beneficial to create very beefy VMs, on top of which then a new virtualization layer is created with containers. This minimized the VM waste, but doesn't get rid of it entirely, and, of course, creates a lot of complications with all the indirection resulting from two-tiered virtualization.

Microkernel is the opposite of this "solution" -- it's the attempt to make OSes more modular, and as such less demanding of resources. Ideally, in the world if microkernels you don't need containers (at least not for the thing they are usually used today): your VMs can slice the resources in the way at least as efficient as containers do (or, hopefully, even better).

So... to predict the next possible question: why containers are so popular and micorkernels aren't: it's because the later is harder on the applications (even when applications don't actually need something, they often use it because it's available in a full-blown OS, applications aren't usually written with resource scarcity in mind). Secondly, containers, essentially, exist on top of somewhat uniform, somewhat stable interface of Linux kernel. Micorkernel VMs would expose users to the zoo of ideas hardware vendors put into their products, making portability difficult. Finally, for all its flaws, Kubernetes is a big system with many (even if not so great) solutions for many problems. So, programmers who fear technology feel like it gives them a safety net and will allow them to program from a more comfortable position of modifying YAML files, copying the most upvoted answers from StackOverflow. There won't be such an easy cake in microkernel world.

Re: MotorOS: a Rust-first operating system for x64 VMs

#96
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).

Re: MotorOS: a Rust-first operating system for x64 VMs

#97
post #54

Earlier quoted context omitted.

What do you think is running on your favorite game consoles (that aren't Xbox)? I'll give you a hint, it isn't Linux. Nintendo is using a custom OS but with a huge chunk of user space borrowed from FreeBSD. Sony on the other hand just went and forked FreeBSD outright. You might also want to look into what OS are being used for server environments. A lot more BSD there than you might have initially guessed.

> but with a huge chunk of user space borrowed from FreeBSD Any sources on this, and on what parts were borrowed specifically? I was under the impression that Nintendo did away with most of the Unix layers we know and love and went all-in on custom code and APIs, is that not the case?

The network stack is taken from BSD, but then again so was the network stack on Windows 2000/XP.

Re: MotorOS: a Rust-first operating system for x64 VMs

#98

Sounds interesting, but it also reminds me of what Linus once said when asked about fearing competition. From my memory his answer was something like: I really like writing device drivers. Few people like that and until someone young and hungry comes along who likes that I'm not afraid of competition.

So Linux will essentially just become a HAL / "bios"

I don't think so. There is no stable interface to the drivers which makes their reuse in other projects a huge effort. With Linux you either get the whole kernel or nothing and the whole thing is more than a HAL or BIOS.

Re: MotorOS: a Rust-first operating system for x64 VMs

#99

Out of curiousity, why would a small kernel take a whole 200ms to start on a modern computer? Wouldn't it need to initialize some metadata for the memory pages, mount the filesystem, and try to launch an init process? I suppose there might be an ethernet driver and possibly something to pipe logs to ("stdout" for the VM) to initialize. Shouldn't that all take a few microseconds? Or is all the slowness in the host pre…

Because of the debug mode

Yes! And because of sandbagging :)

Re: MotorOS: a Rust-first operating system for x64 VMs

#100

One thing I keep hoping to see in all of these kernels in Rust is an async first kernel. Is there something that makes this particularly difficult or do folks not see the value in it? I know from following along with Phil Oppermann’s OS in Rust series that is definitely possible, but these last few OS’ in Rust seem to not be attempting this, https://os.phil-opp.com/async-await/

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).

Post reply on HN