> Nix OS all exist because of Linux's complexity
That said, I would be thrilled to build this and other alt OSes and their userlands with Nix / Nixpkgs :).
MotorOS: a Rust-first operating system for x64 VMs
31–40 of 125 posts
Re: MotorOS: a Rust-first operating system for x64 VMs
#32The 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…
> Rust is the first (and only, at the moment) language that userspace programs can be written in.
Shouldn't be much effort to make it compatible with Crablang, no?
/s
Re: MotorOS: a Rust-first operating system for x64 VMs
#33Sounds 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.
Re: MotorOS: a Rust-first operating system for x64 VMs
#34It sounds like a cool project and I hope it continues development, but there is such a huge graveyard of such projects that have never gone anywhere that I struggle to get excited about them anymore. Replacing Linux is really hard, even for specific uses like cloud.
Replacing Linux is hard even for the BSDs, and those are very well established and considered basically next-in-line for similar tasks.
Re: MotorOS: a Rust-first operating system for x64 VMs
#35One 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/
There are so many posts about how async Rust isn't the right abstraction it would surprise me if someone doubled-down on it right now.
Re: MotorOS: a Rust-first operating system for x64 VMs
#36> a simple multi-processor round robin (SMP)
> the kernel is very small and does not block, so does not need to be preemptible
I don't believe you and I don't even need to look at the code to know this is false.
Re: MotorOS: a Rust-first operating system for x64 VMs
#37> a simple multi-processor round robin (SMP) > the kernel is very small and does not block, so does not need to be preemptible I don't believe you and I don't even need to look at the code to know this is false.
Care to elaborate?
Re: MotorOS: a Rust-first operating system for x64 VMs
#38Sounds 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?
Re: MotorOS: a Rust-first operating system for x64 VMs
#39[flagged]
Everything is relative of course but it's a consensus view in OS literature that the Unix family of operating systems doesn't have strong security. There's a huge TCB in which bugs lead to vulnerabilities with high probability, as we see all the time. This is why eg cloud providers don't rely on the OS to isolate customers from each other. Since the reneissance of virtualization, many security focused systems have bu…
Idk if it's "the Unix family". Clouds are running with SmartOS for example with containers running on bare metal and I've not heard of security issues with this model.
Re: MotorOS: a Rust-first operating system for x64 VMs
#40Out 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 preparing the resources? (as in QEMU and KVM?)