Live data from Hacker News

MotorOS: a Rust-first operating system for x64 VMs

github.com

61–70 of 125 posts

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

#61
post #54
post #53

Earlier quoted context omitted.

You think BSDs are next-in-line? Why is that? I have the distinct impression BSDs will remain niche. Something radical (like MotorOS?) seems more likely.

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.

> your favorite game consoles

unless it's a steamDeck, ofc. No love for consoles, though.

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

#62
post #61
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.

> your favorite game consoles unless it's a steamDeck, ofc. No love for consoles, though.

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.

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

#63

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/

It would help if async Rust was actually a fully done feature, instead of half way there.

As Niko Matsakis puts it, async/await is Rust in hard mode, you don't need that when having to also worry about everything writing an OS from scratch entails.

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

#64
post #54
post #53

Earlier quoted context omitted.

You think BSDs are next-in-line? Why is that? I have the distinct impression BSDs will remain niche. Something radical (like MotorOS?) seems more likely.

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.

And thanks to the BSD license, the project is getting zero back from Sony, while those Playstation profits get a big higher thanks to less R&D costs spent on OS code.

Same applies to clang/LLVM port to the Playstation, regarding everything that would expose console implementation details without an NDA.

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

#65

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…

Unstable, undocumented, compiler-(version-)dependent ABIs are the reason Haiku for x86-32 still has to use GCC 2.95.

I’m never not going to welcome a hobby OS, especially in an interesting language (still have fond memories of House). By all means, go for it. Just... it’s important to be aware of the prior art here.

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

#66
post #53

Earlier quoted context omitted.

Replacing Linux is hard even for the BSDs, and those are very well established and considered basically next-in-line for similar tasks.

You think BSDs are next-in-line? Why is that? I have the distinct impression BSDs will remain niche. Something radical (like MotorOS?) seems more likely.

macOS and iOS are BSDs. Pretty good niche!

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

#68
post #55

Earlier quoted context omitted.

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?

It's relatively trivial to have a `FROM scratch` dockerised microservice in Rust. I'm not convinced having an entire OS brings that much to the table.

From the description, this aims to recreate that but forgo the entirety of the linux+docker stack needed to actually be able to do FROM scratch in the first place

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

#70

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…

Unstable, undocumented, compiler-(version-)dependent ABIs are the reason Haiku for x86-32 still has to use GCC 2.95. I’m never not going to welcome a hobby OS, especially in an interesting language (still have fond memories of House). By all means, go for it. Just... it’s important to be aware of the prior art here.

Haiku was stuck on old GCC only because they wanted to support old BeOS binaries? But binary backwards/forwards compatibility is not requirement for many use-cases.
Post reply on HN