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

81–90 of 125 posts

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

#81

Post by bluejekyll »

pjmlp wrote: post #63
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/

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.

Yes, there might be some significant gaps that make kernel development much more difficult. Off the top of my head, the current state of async traits is still being fleshed out, but it’s coming. The async_trait macros rely on boxing, so I could see that as a big downside in the kernel space. And I know that we don’t yet have an async streaming interface stabilized in the std lib.

I’m not sure if these are blocking issues or not, thus my question.

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

#82

Post by btreecat »

jmull wrote: 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.?

My first thought was "can this run my containers?"

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

#84

Post by miki123211 »

dylukes wrote: post #54
haarts wrote: 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.

> 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?

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

#85

Post by surajrmal »

bluejekyll wrote: post #81
pjmlp wrote: post #63

Earlier quoted context omitted.

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.

Yes, there might be some significant gaps that make kernel development much more difficult. Off the top of my head, the current state of async traits is still being fleshed out, but it’s coming. The async_trait macros rely on boxing, so I could see that as a big downside in the kernel space. And I know that we don’t yet have an async streaming interface stabilized in the std lib. I’m not sure if these are blocking is…

async trait macros are no longer needed for the majority of use cases as of 1.75. additionally, I doubt a hobby OS will hit bottlenecks where boxing like this is a problem. Async streaming not being standardized as an interface would only matter if the kernel wanted to use libraries, and I would assume most kernels will be light on external dependencies so it shouldn't matter.

If you are targeting a posix syscall interface, a lot of that doesn't really require async to pull off. You need to switch threads whenever an operation is blocked rather than run unrelated work on that thread. I suppose you can still model that with async, but it certainly doesn't feel as helpful.

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

#86

Post by toyg »

rrr_oh_man wrote: post #2

[flagged]

Yeah, I read that and thought "woah, shots fired". But I'm old enough to know the definition of "secure system" varies so widely from person to person, it's just pointless to bicker about it. Some people won't be happy until programs have to ask whether they can flip a bit in memory by presenting the user's blood for analysis.

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

#87

Post by prmoustache »

pjmlp wrote: post #64
dylukes wrote: 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.

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.

It is probably for another product but there is at least one Sony email address, and a number email addresses from different corporate entities, on the FreeBSD contributors list. All 3 majors BSD OSes also list donators (can be financially or hardware).

So saying corps that use BSD code never give anything back because of license is not true. And an awful lot don't do any more or even hide their use of gpl licensed code anyway.

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

#88

Post by prmoustache »

gamache wrote: post #66
haarts wrote: 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.

macOS and iOS are BSDs. Pretty good niche!

This is pretty much a myth. Both run a different kernel. macOS used be known to have a network stack (and maybe some stuff like a virtual file system) from freebsd but I am pretty sure most of the code has been replaced by now.

Having some BSD userland binaries doesn't make your OS a BSD. Otherwise Windows is just a fork of curl.

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

#89

Post by ahepp »

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?

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

#90

Post by empath-nirvana »

tourmalinetaco wrote: post #19
omeid2 wrote: post #10

Earlier quoted context omitted.

It is fascinating how despite the thousands and thousands of high profile memory related RCE vulnerabilities, how this community doesn't seem to like pointing the fact that C is an unsafe language.

Rust is only “safe” because by default you’re not allowed to do certain things. If you applied those same limitations to C it would be just as if not more safe. And the things you’re not allowed to do in “safe” Rust is required in various applications that C excels at, meaning that for Rust to do the same it has to be “unsafe”.

> If you applied those same limitations to C it would be just as if not more safe.

If frogs had wings, they wouldn't bump their butts when they hop.

If you add all the security guarantees of Rust to C you would have something substantially similar to rust.

As to your last point, it's very easy in rust to isolate those operations so you can just go over those with a fine tooth comb and not have to worry about unsafe stuff appearing everywhere in your code.

Post reply on HN