Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MotorOS: a Rust-first operating system for x64 VMs

github.com

Post reply on HN
Print view View original

101–110 of 125 posts

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

#101

Post by bluejekyll »

ahepp wrote: post #89
bluejekyll wrote: post #30

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/

Maybe I'm misunderstanding your proposal, but it seems to undermine process isolation. If you trust processes to yield under a co-operative multitasking system, why not trust them to leave each other's memory alone?

I was thinking of the internal Kernel tasks that might block, where it might be possible to have things happen in parallel, like bringing various hardware components online. See the sibling discussion on 200ms startup times.

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

#102

Post by bluejekyll »

lasiotus wrote: post #100
bluejekyll wrote: post #30

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

I think I missed this on my quick pass through the code, I see a lot async usage here as well, https://github.com/moturus/moto-runtime/blob/main/src/net_as...

Very cool. Thanks for pointing this out.

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

#105

Post by crabbone »

weinzierl wrote: post #33

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.

I don't think drivers are what warrants Linux its popularity / indispensability. I worked in a few places where people, well, at least moderately, liked to write drivers. Also, consider that it would've been definitely possible to write an OS with a mechanism for module loading compatible with Linux drivers.

My take on this question would be the ease of use for application developers. This ease of use consists of plenty of somewhat ready-to-use libraries that cover plenty of use-cases, huge community that both produces documentation and will answer questions should you have any, multiple hardware vendor support, and of course, licensing.

It's possible to compete with Linux in very special, very narrow use-cases, but trying to win against Linux on every front would require an insane amount of effort by a very large group of people.

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

#106

Post by lasiotus »

xyst wrote: post #103

Kind of cool as a hobby OS. But would be nice to backup your claims regarding performance with actual numbers.

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?

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

#107

Post by crabbone »

rrr_oh_man wrote: post #2

[flagged]

You probably need to interpret this as saying "the system is written in such a way that the application developer needs to take extra steps to secure their applications, compared to how it could've been written".

For example, privilege elevation in Linux is a very complex and complicated mechanism. The famed "sudo" command has a very long history of bugs. To the point that I remember RHEL peddling their own version ("ksudo" if memory serves... I cannot find any mentions of this, it was some 15 years ago). It's very hard to get things right. Especially, to prove that you've done things right, if you are after security.

The system interface is designed "for comfort" rather than "for security". Many things could've been a lot more secure, but very tedious on application programmer (imagine SeLinux, but in hyperactive mode... that's every sysadmin's nightmare).

In practice, with a lot of community effort, tools like "sudo" eventually reached a point where they are mostly reliable for what they are expected to do. So, to face practical threats, today, the system may be OK, but this isn't the testimony to its design, rather it is a consequence of how much effort was spent plugging the holes.

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

#108

Post by seanw444 »

rascul wrote: post #75
dylukes wrote: post #62

Earlier quoted context omitted.

If I'm in the mood for being a little glib... where do you think that Linux distribution that SteamOS is based on got its user-space (or more seriously, its drivers?) Also: the SteamDeck is by any reasonable standard a console. It just happens to run a windowed environment out of the box. Don't be that guy. If you want to pump Valve, focus instead on their contributions to the Wine project.

> where do you think that Linux distribution that SteamOS is based on got its user-space (or more seriously, its drivers?) Are you saying that Arch gets its userspace and drivers from FreeBSD?

I guess there is some BSD software that is common in Linux, like OpenSSH tools and dhcpcd. But that's not unique to Arch.

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

#109

Post by toast0 »

andyferris wrote: post #40

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…

Timer calibration is a big time suck.

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

#110

Post by toast0 »

wavemode wrote: post #38
weinzierl wrote: post #33

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.

You don't need very many device drivers to run in a VM. The real question is, how useful is a non-C-compatible, non-Linux-compatible, VM-only OS. Maybe a little bit, for microservices?

For work, I run a rust service on GCP. It could run on this instead of docker on Linux.

I'm going to assume without looking at this project that observability and operability would be worse than it already is though, so I'm not in a hurry to move. Anyway, GCP means cost of compute is a rounding error compared to cost of bandwidth, so I have no reason to find the edge of efficiency.

Post reply on HN