12 ms·

For someone who is completley not into OS programming but has heard a lot about safety and rust etc. etc. Assuming the rust safety lives up to the type. Is th

For someone who is completley not into OS programming but has heard a lot about safety and rust etc. etc. Assuming the rust safety lives up to the type. Is this (or any other project) likely to ever become a "real" useful os. What about including rust modules in the linux kernel? What are the barriers?

jerf 8y ago
Is someone likely to build a Rust OS that is real and useful? Yes. Projects are already in progress, and even if they all shut down, I'm sure more will exist in the future. Is that Rust OS going to experience "success" by traditional metrics, such as taking a significant chunk of Linux's marketshare away, and becoming a viable thing you can run on some real piece of hardware for some real purpose? I won't say "no" but it will be at least a decade before that will happen. Not because Rust is bad, or the resulting OS will be bad, but all the entrenched advantages existing OSes have are just staggeringly huge. If a perfect OS jewel of perfection appeared today, but with no other support for it (no software, drivers, applications that can only run on it, etc.) it would be a long, long time for it to get any traction.
- AnIdiotOnTheNet 8y ago
  The key to getting there (aside from the driver issue), I think, would be creating an environment that is simple, easy to work with, and friendly to creating new tools. The faster you can spin up new tooling, and the more you want to, the more willing people will be to move to the new system. Then you provide VMs, emulators, and/or compatibility environments for running software from "legacy" systems. Do not attempt to make a new posix system, because we already have giant, entrenched, mature posix OSs and you'll bring nothing new or interesting enough to the table to warrant switching while being held back by the creaking old standard. I'd be willing to make a lot of sacrifices to move to an OS that met my personal list of wants.
  - pjc50 8y ago
    Maybe, but if you dont't have a POSIX API you'll cut yourself off from a lot of applications. Even Windows is gradually admitting defeat with WSL. You can only get adoption of a non-POSIX OS if it offers something really unique to the user, or is in a very different market space.
    - AnIdiotOnTheNet 8y ago
      You can do it in a VM or compatibility layer. Your OS can support "personalities" like Windows uses to implement WSL, but with containers. So now you can have multiple POSIX containers on your non-POSIX system. You should encourage people to make native software using the new paradigms and abstractions of the OS, built from the ground up with decades of hindsight, rather than encouraging crappy ports. > You can only get adoption of a non-POSIX OS if it offers something really unique to the user At this point, just not being built on 50 year old crappy standards would be pretty unique. I have my own personal wish-list of features that would lure me in even if the only hardware supported was an RPi.
      - glhaynes 8y ago
        You still end up in the OS/2 situation - even if non-native apps didn't always run great, had much worse memory usage, didn't feel native, etc... they were still good enough that nearly nobody (comparatively) wrote native OS/2 apps. It's not impossible to imagine an alternate past where OS/2 had worse DOS/Windows compatibility and ended up more successful! (In actuality, I think it'd probably have done even worse — showing that the strategic options to replace the foundation of an entrenched ecosystem are "bad" vs. "worse".) I'd like to see other paradigms explored, too, but it seems unfortunately hard to get there from here.
        AnIdiotOnTheNet 8y ago
        Yeah, it is hard. So what? So is just about everything worth doing. One thing is for certain: you will not replace the current players by cloning them.
  - rixrax 8y ago
    Most of the action on desktop takes place in a browser though. So I think you could go a long way by getting to the point where you can run Firefox or Chrome (or some other webkit etc. based browser). Isn't this sort of what ChromeOS does already.
    - AnIdiotOnTheNet 8y ago
      > Most of the action on desktop takes place in a browser though. Then who cares about the OS? Why even bother. Just use ChromeOS.
      - notriddle 8y ago
        The obvious answer is "because ChromeOS is spyware." But the really fun possibility is having an OS where "Web" and "Posix" are equally-placed personalities that the OS ran, not only preventing rogue web pages from touching the posix system, but also preventing rogue posix processes from touching the browser (except where the end-user intentionally joins them through the system-provided Open File dialog or by opening the case and removing the debug pin to unlock cross-VM debugging). ChromeOS sort of implements that today, by running custom Linux environments in containers, but I'd rather trust Xen than Docker as the underlying isolation layer.
        AnIdiotOnTheNet 8y ago
        This is about the most boring thing I've ever heard. This is trivial to accomplish today, hell, QubesOS does the whole concept much better.
    - sandov 8y ago
      The whole point of a desktop PC is that you can produce, not only consume. Otherwise you might as well buy an iPad and browse the web/watch YouTube.
- Verdex 8y ago
  Fully agree. I think that now is the time for not only new system level programming languages, but now is also the time for new OS implementations using said programming languages. That being said, "now" actually refers to a period of time that will be anywhere from 5 to 25 years long (and you might want to weight that towards the long end).
- bogomipz 8y ago
  >"Yes. Projects are already in progress, and even if they all shut down," Might you have any recommendations of specific ones worth paying attention to right now?
  - ethelward 8y ago
    The most advanced one is Redox https://www.redox-os.org/ https://www.redox-os.org/
    - bogomipz 8y ago
      Thanks for the link. Interesting it looks like Redox is writing their own filesystem or at least reimplementing ZFS: https://github.com/redox-os/tfs https://github.com/redox-os/tfs I wonder how that effects the time horizon for maturity. I've always just assumed that a filesystem takes a good 10 years to be really stable. Maybe my assumptions are way off? Or the facts that its a reimplementation makes that matter much less? Didn't it take BTRFS around this length of be considered production stable?
      - est31 8y ago
        TFS is very cool. Too sad that ticki has stopped working on it: http://ticki.github.io/blog/why_im_leaving_open_source/ http://ticki.github.io/blog/why_im_leaving_open_source/ Due to this, I don't know whether it will be ready at all.
- andrewflnr 8y ago
  > a perfect OS jewel of perfection appeared today, but with no other support for it... Sounds like seL4 to be honest, and yeah, it's taking a while to see adoption.
jononor 8y ago
As far as I understand, the goal of the original post is to be an educational resource. Redox OS on the other hand is a real OS in Rust, already at a basic useful level: https://www.redox-os.org/ https://www.redox-os.org/ As for Rust modules in the Linux kernel, I expect the barriers there to be primarily political. Other proposals for non-C modules in the main tree have not been very welcomed.
swebs 8y ago
There is a demand for a FOSS, realtime, safety critical OS for embedded systems. Linux and QNX are the main options right now, but they both have their downsides (QNX being proprietary and Linux being monolithic).
- seren 8y ago
  FreeRTOS maybe ? But I am not quite sure what is the exact license, or if there are restrictions in terms of features for the free version.
- pjmlp 8y ago
  I doubt Linux faires that well against something like INTEGRITY OS.
sushibowl 8y ago
Redox OS is the most mature rust-based operating system that I know of. Exactly at which point you can call a project such as this useful or real is of course debatable, but redox is advanced enough to run a GUI. The linux kernel is very unlikely to accept anything other than C. It would further complicate their build system, and raise the (already high) barrier to entry for developers. Rust also does not have the breadth of architecture support that the Linux kernel needs.
- std_throwawayay 8y ago
  I think none of your points are really set in stone. * The kernel already contains some C++ which (if you ask C programmers) is not C. And many C programmers are more likely to accept Rust than having to deal with C++. * AFAIK there is not gcc front-end for Rust yet but LLVM tools can compile the kernel, too. When Rust stabilizes gcc support may come, too. * The barrier for entry could be lowered by using Rust for Rust programmers if it is employed in some specific modules. The resulting code could be more clear. Not everything in the kernel is pointer pointing and bit shuffling. * The number of architectures that Rust supports are growing daily.
  - jononor 8y ago
    Where in the (mainline) kernel is there C++ code?
    - std_throwawayay 8y ago
      I could swear that I read that they start allowing some C++ contributions. But with a search in the kernel source I could not come up with any evidence. If there is any C++ code in the kernel they hid it well.
      - scoopr 8y ago
        You may be thinking of GCC
  - milkey_mouse 8y ago
ChrisSD 8y ago
I think it would take a lot of persuasion for Linux to be written in anything but C (and assembly). All their tooling and expertise is geared towards GNU C. Rust is a young language and LLVM based too so I doubt it'll be accepted any time soon.
yoshuaw 8y ago
The MesaLock Linux project aims to structurally replace parts of Linux with safer equivalents. For example OpenSSL: https://github.com/mesalock-linux/mesalink https://github.com/mesalock-linux/mesalink I think projects such as MesaLock are interesting because they don't try and start from scratch[1], but instead incrementally improve the status quo. [1]: Though I love Redox & pals. I'm definitely rooting for their success.
gardaani 8y ago
steveklabnik: "Not even Rust people think that the kernel should adopt Rust." https://news.ycombinator.com/item?id=16547450 https://news.ycombinator.com/item?id=16547450
- steveklabnik 8y ago
  The Linux kernel, yes.
jcranmer 8y ago
In OS programming, there is a strong bias towards favoring C as the only serious programming language. Rust is one of the few programming languages that has the potential to break through this barrier, especially because the ability to support bare-metal programming is one of its design goals. But the key word there is "potential"--Rust, as it stands right now, is not ready to be used in production OSes. Features such as inline assembly or other developments for #[no_std] support need to be worked on and supported in non-nightly modes for any production OS to take notice, for example.
- mehrdadn 8y ago
  I feel like if C++ didn't break through this barrier then I wouldn't hold my breath for Rust.
  - Someone1234 8y ago
    I don't follow that argument. C++ didn't break through because the benefits didn't outweigh the drawbacks compared to straight C (meaning you can implement C++ like concepts in straight C, and not have to deal with a lot of baggage C++ brings). Rust is a whole other kettle of fish. It has more or less been proven by this point that people cannot write memory safe C, even experts in the language are still introducing memory-unsafe bugs in 2018. Therefore Rust is bringing features the C language cannot offer. Which isn't to say I know that Rust will be "successful." I don't know that. But I do know it is worth TRYING to see if it can be successful, and C++'s lack of success isn't really a counter-argument. I'm still sad that Microsoft's Singularity OS[0] never got further developed, interesting concept. [0] https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)
    - pjmlp 8y ago
      Bias is everything, Joe Duffy briefly mentioned at his RustConf keynote that many at WinDev did not believe Midori was possible, even when shown running in front of them.
TheCondor 8y ago
Rust modules in Linux? Anyone could start to do it now, but it won’t be mainlined, probably not ever. A real useful OS in rust? I think this is a complicated question. I don’t see a rust based posix kernel ever taking off in an interesting way, the C based kernels are stable and fairly safe, the community quickly fixes issues when they come up. A new kernel won’t have the architecture and driver support so it will have those downsides with the upside being maybe more safety which is harder to measure. It’s just that compelling. Now a new hypervisor? Maybe some sort of unikernel core? Maybe some sort of container hosting microkernel or some new thing I’m not dreaming up right now? I could see that taking off. I think it would have to be a new thing.
- rurounijones 8y ago
  Hypervisor / container hosting was what I had in mind yes. Seems that would be the place where a from-scratch OS, safe, would immediately gain usefulness.
  - archgoon 8y ago
    So something like Firecracker? https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/
    - monocasa 8y ago
      The other way around. Firecracker is like a stripped down qemu-kvm.
vectorEQ 8y ago
>>> Assuming the rust safety lives up to the type ^ this... :-)
steveklabnik 8y ago
Fuchsia isn’t pure Rust, but has a lot and it’s only increasing.
zaarn 8y ago
Atm the barriers are all the unstable features you need to rely on as well as rust and LLVM bugs. The LLVM bug I've encountered makes it impossible to properly handle interrupts with error codes unless you use [naked], which is unreliable in my experience. The Rust bugs are on one hand a None variable being initialized to a Some() value and a bug where rust injects a few instructions between inline assembly that corrupt the stack. These problems can usually be worked around in some ways, it's annoying and means the rust compiler is not quite there yet. However, with rust it's easier to reason about why an error occured than in C, atleast in my experience, although some things can only be found out by trial and error (corrupted stack or hitting undefined instructions), as a result I would predict that Rust could result in a lot more fun designs and architectures than simply writing a Microkernel (Redox).
- steveklabnik 8y ago
  > a None variable being initialized to a Some() value Did you file a bug about this? this seems extremely bad.
  - zaarn 8y ago
    No, I'm waiting on a fix for the other bugs first since I've monkey patched this one so far by using some unsafe.
- pcwalton 8y ago
  > The Rust bugs are on one hand a None variable being initialized to a Some() value Wait. There has to be more going on there than just that—perhaps it's some interaction with naked functions?—or else we'd be seeing crashes everywhere from this.
  - zaarn 8y ago
    Well, there is only a single place were this happens reproducable. All other None values are fine in the same binary. The variable is not touched by any code I haven't verified over this. I don't have any naked functions in the relevant binary either.
agumonkey 8y ago
Well well well.. as a special kind of user, I often wish for a tinier even limited OS that would part from C type system. For rust modules.. BSD added lua support for kernel modules.. surely linux can tolerate gc-less rust.
Thaxll 8y ago
Probably not, at least on the desktop, good luck getting drivers working when you see the state of Linux / BSD after 20 years and thousands of engineers that worked on them. It's 2019 and we still have issues on Linux that were fixed in Windows XP era. Also I think people are blinded by that "rust safety" thing for an OS, it doesn't really matter, Redox that is written in Rust had a challenge a year ago about breaking it, it took a few minutes for someone to kernel panic with bad arguments in a user space CLI, so how long do you think it's going to take to have something as secure / stable as Linux for Redox, 10 / 15 years and at the same time you need all the features / drivers to have a usable OS, just forget about it. The only way you can have a "successful" OS nowdays is to target a very specific niche / usecase.
- tracker1 8y ago
  Given the amount of software that runs on servers with a limited footprint need, or orchestrating virtual machines or containers running similar/other software I wouldn't count out the potential. It won't be a desktop application anytime soon, but there is room for the OS is the Service type of OS.
buildbot 8y ago
AWS Firecracker, there VM behind Fargate and Lambda is written in Rust, if that counts as an "OS". https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...
shmerl 8y ago
One of the areas still in development in Rust now is handling memory allocation failures. That's important for kernel development.
- steveklabnik 8y ago
  This is both kinda true and kinda not; the allocator work will help with using the standard library data structures on a kernel heap, but many kernels write their own specialized structures anyway, so you’d make the kernel allocator fallible and it all works out.
  - shmerl 8y ago
    Yeah, the above will just make such development more accessible.
- Gajurgensen 8y ago
  Why wouldn't it be a good solution to write something like Box, but with a new function that returns `Option<Box<T>>`? I'm not sure what Rust is lacking here.
timClicks 8y ago
The barriers are mostly cultural, but even the technical ones are huge. Including non-C code into the Linux kernel would require a lot of internal momentum, because of inertia. On the technical side, it would require everyone downstream of the kernel to update their build process. That said, there is little stopping you from experimenting with writing your own kernel modules in Rust that wouldn't need to make their way into mainline.

jerf 8y ago

Is someone likely to build a Rust OS that is real and useful? Yes. Projects are already in progress, and even if they all shut down, I'm sure more will exist in the future. Is that Rust OS going to experience "success" by traditional metrics, such as taking a significant chunk of Linux's marketshare away, and becoming a viable thing you can run on some real piece of hardware for some real purpose? I won't say "no" but it will be at least a decade before that will happen. Not because Rust is bad, or the resulting OS will be bad, but all the entrenched advantages existing OSes have are just staggeringly huge. If a perfect OS jewel of perfection appeared today, but with no other support for it (no software, drivers, applications that can only run on it, etc.) it would be a long, long time for it to get any traction.

AnIdiotOnTheNet 8y ago
The key to getting there (aside from the driver issue), I think, would be creating an environment that is simple, easy to work with, and friendly to creating new tools. The faster you can spin up new tooling, and the more you want to, the more willing people will be to move to the new system. Then you provide VMs, emulators, and/or compatibility environments for running software from "legacy" systems. Do not attempt to make a new posix system, because we already have giant, entrenched, mature posix OSs and you'll bring nothing new or interesting enough to the table to warrant switching while being held back by the creaking old standard. I'd be willing to make a lot of sacrifices to move to an OS that met my personal list of wants.
- pjc50 8y ago
  Maybe, but if you dont't have a POSIX API you'll cut yourself off from a lot of applications. Even Windows is gradually admitting defeat with WSL. You can only get adoption of a non-POSIX OS if it offers something really unique to the user, or is in a very different market space.
  - AnIdiotOnTheNet 8y ago
    You can do it in a VM or compatibility layer. Your OS can support "personalities" like Windows uses to implement WSL, but with containers. So now you can have multiple POSIX containers on your non-POSIX system. You should encourage people to make native software using the new paradigms and abstractions of the OS, built from the ground up with decades of hindsight, rather than encouraging crappy ports. > You can only get adoption of a non-POSIX OS if it offers something really unique to the user At this point, just not being built on 50 year old crappy standards would be pretty unique. I have my own personal wish-list of features that would lure me in even if the only hardware supported was an RPi.
    - glhaynes 8y ago
      You still end up in the OS/2 situation - even if non-native apps didn't always run great, had much worse memory usage, didn't feel native, etc... they were still good enough that nearly nobody (comparatively) wrote native OS/2 apps. It's not impossible to imagine an alternate past where OS/2 had worse DOS/Windows compatibility and ended up more successful! (In actuality, I think it'd probably have done even worse — showing that the strategic options to replace the foundation of an entrenched ecosystem are "bad" vs. "worse".) I'd like to see other paradigms explored, too, but it seems unfortunately hard to get there from here.
      - AnIdiotOnTheNet 8y ago
        Yeah, it is hard. So what? So is just about everything worth doing. One thing is for certain: you will not replace the current players by cloning them.
- rixrax 8y ago
  Most of the action on desktop takes place in a browser though. So I think you could go a long way by getting to the point where you can run Firefox or Chrome (or some other webkit etc. based browser). Isn't this sort of what ChromeOS does already.
  - AnIdiotOnTheNet 8y ago
    > Most of the action on desktop takes place in a browser though. Then who cares about the OS? Why even bother. Just use ChromeOS.
    - notriddle 8y ago
      The obvious answer is "because ChromeOS is spyware." But the really fun possibility is having an OS where "Web" and "Posix" are equally-placed personalities that the OS ran, not only preventing rogue web pages from touching the posix system, but also preventing rogue posix processes from touching the browser (except where the end-user intentionally joins them through the system-provided Open File dialog or by opening the case and removing the debug pin to unlock cross-VM debugging). ChromeOS sort of implements that today, by running custom Linux environments in containers, but I'd rather trust Xen than Docker as the underlying isolation layer.
      - AnIdiotOnTheNet 8y ago
        This is about the most boring thing I've ever heard. This is trivial to accomplish today, hell, QubesOS does the whole concept much better.
  - sandov 8y ago
    The whole point of a desktop PC is that you can produce, not only consume. Otherwise you might as well buy an iPad and browse the web/watch YouTube.
Verdex 8y ago
Fully agree. I think that now is the time for not only new system level programming languages, but now is also the time for new OS implementations using said programming languages. That being said, "now" actually refers to a period of time that will be anywhere from 5 to 25 years long (and you might want to weight that towards the long end).
bogomipz 8y ago
>"Yes. Projects are already in progress, and even if they all shut down," Might you have any recommendations of specific ones worth paying attention to right now?
- ethelward 8y ago
  The most advanced one is Redox https://www.redox-os.org/ https://www.redox-os.org/
  - bogomipz 8y ago
    Thanks for the link. Interesting it looks like Redox is writing their own filesystem or at least reimplementing ZFS: https://github.com/redox-os/tfs https://github.com/redox-os/tfs I wonder how that effects the time horizon for maturity. I've always just assumed that a filesystem takes a good 10 years to be really stable. Maybe my assumptions are way off? Or the facts that its a reimplementation makes that matter much less? Didn't it take BTRFS around this length of be considered production stable?
    - est31 8y ago
      TFS is very cool. Too sad that ticki has stopped working on it: http://ticki.github.io/blog/why_im_leaving_open_source/ http://ticki.github.io/blog/why_im_leaving_open_source/ Due to this, I don't know whether it will be ready at all.
andrewflnr 8y ago
> a perfect OS jewel of perfection appeared today, but with no other support for it... Sounds like seL4 to be honest, and yeah, it's taking a while to see adoption.

jononor 8y ago

As far as I understand, the goal of the original post is to be an educational resource. Redox OS on the other hand is a real OS in Rust, already at a basic useful level: https://www.redox-os.org/ https://www.redox-os.org/ As for Rust modules in the Linux kernel, I expect the barriers there to be primarily political. Other proposals for non-C modules in the main tree have not been very welcomed.

swebs 8y ago

There is a demand for a FOSS, realtime, safety critical OS for embedded systems. Linux and QNX are the main options right now, but they both have their downsides (QNX being proprietary and Linux being monolithic).

seren 8y ago
FreeRTOS maybe ? But I am not quite sure what is the exact license, or if there are restrictions in terms of features for the free version.
pjmlp 8y ago
I doubt Linux faires that well against something like INTEGRITY OS.

sushibowl 8y ago

Redox OS is the most mature rust-based operating system that I know of. Exactly at which point you can call a project such as this useful or real is of course debatable, but redox is advanced enough to run a GUI. The linux kernel is very unlikely to accept anything other than C. It would further complicate their build system, and raise the (already high) barrier to entry for developers. Rust also does not have the breadth of architecture support that the Linux kernel needs.

std_throwawayay 8y ago
I think none of your points are really set in stone. * The kernel already contains some C++ which (if you ask C programmers) is not C. And many C programmers are more likely to accept Rust than having to deal with C++. * AFAIK there is not gcc front-end for Rust yet but LLVM tools can compile the kernel, too. When Rust stabilizes gcc support may come, too. * The barrier for entry could be lowered by using Rust for Rust programmers if it is employed in some specific modules. The resulting code could be more clear. Not everything in the kernel is pointer pointing and bit shuffling. * The number of architectures that Rust supports are growing daily.
- jononor 8y ago
  Where in the (mainline) kernel is there C++ code?
  - std_throwawayay 8y ago
    I could swear that I read that they start allowing some C++ contributions. But with a search in the kernel source I could not come up with any evidence. If there is any C++ code in the kernel they hid it well.
    - scoopr 8y ago
      You may be thinking of GCC
- milkey_mouse 8y ago

ChrisSD 8y ago

I think it would take a lot of persuasion for Linux to be written in anything but C (and assembly). All their tooling and expertise is geared towards GNU C. Rust is a young language and LLVM based too so I doubt it'll be accepted any time soon.

yoshuaw 8y ago

The MesaLock Linux project aims to structurally replace parts of Linux with safer equivalents. For example OpenSSL: https://github.com/mesalock-linux/mesalink https://github.com/mesalock-linux/mesalink I think projects such as MesaLock are interesting because they don't try and start from scratch[1], but instead incrementally improve the status quo. [1]: Though I love Redox & pals. I'm definitely rooting for their success.

gardaani 8y ago

steveklabnik: "Not even Rust people think that the kernel should adopt Rust." https://news.ycombinator.com/item?id=16547450 https://news.ycombinator.com/item?id=16547450

steveklabnik 8y ago
The Linux kernel, yes.

jcranmer 8y ago

In OS programming, there is a strong bias towards favoring C as the only serious programming language. Rust is one of the few programming languages that has the potential to break through this barrier, especially because the ability to support bare-metal programming is one of its design goals. But the key word there is "potential"--Rust, as it stands right now, is not ready to be used in production OSes. Features such as inline assembly or other developments for #[no_std] support need to be worked on and supported in non-nightly modes for any production OS to take notice, for example.

mehrdadn 8y ago
I feel like if C++ didn't break through this barrier then I wouldn't hold my breath for Rust.
- Someone1234 8y ago
  I don't follow that argument. C++ didn't break through because the benefits didn't outweigh the drawbacks compared to straight C (meaning you can implement C++ like concepts in straight C, and not have to deal with a lot of baggage C++ brings). Rust is a whole other kettle of fish. It has more or less been proven by this point that people cannot write memory safe C, even experts in the language are still introducing memory-unsafe bugs in 2018. Therefore Rust is bringing features the C language cannot offer. Which isn't to say I know that Rust will be "successful." I don't know that. But I do know it is worth TRYING to see if it can be successful, and C++'s lack of success isn't really a counter-argument. I'm still sad that Microsoft's Singularity OS[0] never got further developed, interesting concept. [0] https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)
  - pjmlp 8y ago
    Bias is everything, Joe Duffy briefly mentioned at his RustConf keynote that many at WinDev did not believe Midori was possible, even when shown running in front of them.

TheCondor 8y ago

Rust modules in Linux? Anyone could start to do it now, but it won’t be mainlined, probably not ever. A real useful OS in rust? I think this is a complicated question. I don’t see a rust based posix kernel ever taking off in an interesting way, the C based kernels are stable and fairly safe, the community quickly fixes issues when they come up. A new kernel won’t have the architecture and driver support so it will have those downsides with the upside being maybe more safety which is harder to measure. It’s just that compelling. Now a new hypervisor? Maybe some sort of unikernel core? Maybe some sort of container hosting microkernel or some new thing I’m not dreaming up right now? I could see that taking off. I think it would have to be a new thing.

rurounijones 8y ago
Hypervisor / container hosting was what I had in mind yes. Seems that would be the place where a from-scratch OS, safe, would immediately gain usefulness.
- archgoon 8y ago
  So something like Firecracker? https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/
  - monocasa 8y ago
    The other way around. Firecracker is like a stripped down qemu-kvm.

vectorEQ 8y ago

>>> Assuming the rust safety lives up to the type ^ this... :-)

steveklabnik 8y ago

Fuchsia isn’t pure Rust, but has a lot and it’s only increasing.

zaarn 8y ago

Atm the barriers are all the unstable features you need to rely on as well as rust and LLVM bugs. The LLVM bug I've encountered makes it impossible to properly handle interrupts with error codes unless you use [naked], which is unreliable in my experience. The Rust bugs are on one hand a None variable being initialized to a Some() value and a bug where rust injects a few instructions between inline assembly that corrupt the stack. These problems can usually be worked around in some ways, it's annoying and means the rust compiler is not quite there yet. However, with rust it's easier to reason about why an error occured than in C, atleast in my experience, although some things can only be found out by trial and error (corrupted stack or hitting undefined instructions), as a result I would predict that Rust could result in a lot more fun designs and architectures than simply writing a Microkernel (Redox).

steveklabnik 8y ago
> a None variable being initialized to a Some() value Did you file a bug about this? this seems extremely bad.
- zaarn 8y ago
  No, I'm waiting on a fix for the other bugs first since I've monkey patched this one so far by using some unsafe.
pcwalton 8y ago
> The Rust bugs are on one hand a None variable being initialized to a Some() value Wait. There has to be more going on there than just that—perhaps it's some interaction with naked functions?—or else we'd be seeing crashes everywhere from this.
- zaarn 8y ago
  Well, there is only a single place were this happens reproducable. All other None values are fine in the same binary. The variable is not touched by any code I haven't verified over this. I don't have any naked functions in the relevant binary either.

agumonkey 8y ago

Well well well.. as a special kind of user, I often wish for a tinier even limited OS that would part from C type system. For rust modules.. BSD added lua support for kernel modules.. surely linux can tolerate gc-less rust.

Thaxll 8y ago

Probably not, at least on the desktop, good luck getting drivers working when you see the state of Linux / BSD after 20 years and thousands of engineers that worked on them. It's 2019 and we still have issues on Linux that were fixed in Windows XP era. Also I think people are blinded by that "rust safety" thing for an OS, it doesn't really matter, Redox that is written in Rust had a challenge a year ago about breaking it, it took a few minutes for someone to kernel panic with bad arguments in a user space CLI, so how long do you think it's going to take to have something as secure / stable as Linux for Redox, 10 / 15 years and at the same time you need all the features / drivers to have a usable OS, just forget about it. The only way you can have a "successful" OS nowdays is to target a very specific niche / usecase.

tracker1 8y ago
Given the amount of software that runs on servers with a limited footprint need, or orchestrating virtual machines or containers running similar/other software I wouldn't count out the potential. It won't be a desktop application anytime soon, but there is room for the OS is the Service type of OS.

buildbot 8y ago

AWS Firecracker, there VM behind Fargate and Lambda is written in Rust, if that counts as an "OS". https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...

shmerl 8y ago

One of the areas still in development in Rust now is handling memory allocation failures. That's important for kernel development.

steveklabnik 8y ago
This is both kinda true and kinda not; the allocator work will help with using the standard library data structures on a kernel heap, but many kernels write their own specialized structures anyway, so you’d make the kernel allocator fallible and it all works out.
- shmerl 8y ago
  Yeah, the above will just make such development more accessible.
Gajurgensen 8y ago
Why wouldn't it be a good solution to write something like Box, but with a new function that returns `Option<Box<T>>`? I'm not sure what Rust is lacking here.

timClicks 8y ago

The barriers are mostly cultural, but even the technical ones are huge. Including non-C code into the Linux kernel would require a lot of internal momentum, because of inertia. On the technical side, it would require everyone downstream of the kernel to update their build process. That said, there is little stopping you from experimenting with writing your own kernel modules in Rust that wouldn't need to make their way into mainline.