Agreed, the hope is that the combination of Rust + a rewrite, you'd be in a MUCH better place than where we are now.
I think an interesting question is, why are there so many contributors to the Linux Kernel in comparison to something like glibc? Both, I'd argue, are equally foundational.
You're the first one in this thread to bring up the idea of rewriting the linux kernel in rust... the rest of us are just having a productive discussion on the degree to which a language solves a problem.
So are you personally volunteering to rewrite all of Linux and glibc in Rust? Are you or your employer volunteering to fund such efforts? There is a reason it hasn't happened yet - because doing so would be exceptionally time consuming and expensive.
Would the world be a better place if Linux, the BSD kernel behind OS X, and the Windows kernel were all rewritten in Rust? (I don't think it would be dramatically better overnight.)
I have to say, I feel a bit “dirty” carrying so much unused and legacy code around with Linux, so I like people trying to reinvent the wheel just for the pleasure of a fresh start. For the aesthetics. Even if it’s merely a fantasy and not replacing anything soon, realistically. They are also keeping OS development accessible to new generations of geeks. The unfriendliness of C, the gigantic codebase and seemingly distinct culture make the Linux kernel quite off putting, filtering possible engagement by unfortunate parameters IMO. Novel OS development in Rust takes away at least some of those barriers and some of the gained knowledge may be applicable with the Linux kernel later.
Writing an operating system is hard and laborious. There are many bugs beyond memory and there are already many tools the Linux team uses to make it safer. That you can make a better, more stable version of the Linux kernel with rust is still to be proven. Not arguing that the language is not better than C or that, if Linux was being started today, it wouldn't be a more sensible pick. But the language is just one component among many others that make such a projects successful.
I would actually be very surprised if there was anything nearly as good as Linux written in rust already. I'm not sure why a company would invest the huge amount of resources to get it done by now and, unless the language had some really unprecedented productivity, I don't think a community led protect would've had it finished by now.
The point of this LPC session was how to incrementally introduce Rust in the existing Linux kernel, with all its existing drivers and syscalls and similar. A rewrite would indeed be a daunting and problematic proposition.
There are kernels written in Rust, such as Redox, but those are separate projects, and that's not what this conference session or article are talking about.
Standing reminder: the Rust project is not a fan of rabid Rust over-evangelism (e.g. "Rewrite It In Rust", "Rust Evangelism Strike Force"), and sees it as damaging and unhelpful. We discourage that kind of thing wherever we see it. We're much more in favor of a measured, cautious approach.
God, I hope not. Ground-up rewrites (when they even succeed) typically lose features, performance, and security, since they don't have the benefit of 20+ years of correcting mistakes. Plus you lose all your contributors.
However, Rust is linker compatible with C, and can be runtimeless, so rewriting the kernel piecemeal over time instead could be great. ;-)
I can't help but feel most of these bugs and vulnerabilities in the Linux kernel could be avoided with a more robust foundation than C. It's nice to see that Rust is starting to be tolerated in the Linux kernel for modules.
It would be nice to see an effort to migrate some of the kernel core, but I can't see Rust gaining widespread acceptance in the kernel development community any time soon.
I believe Rust will benefit from the reality check that kernel development represents.
Kernel development is hard, and bullshit doesn't go very far in that context. Success for Rust in that environment (with some changes along the way) will be a proof of value.
I wish they would start creating a new kernel from scratch
in Rust.
It is needed and will be more cohesive and take more advantage of
the new language than stuffing it into Linux.
There will be a lot to learn from it though.
It will test the interop and cohabitation of Rust and C.
Lessons learned will be unbelievably valuable for other efforts to
mix and match them.
There are mainstream efforts to do the legwork to allow Linux kernel modules to be written in Rust and a fair few core system libraries (the most obvious example being librsvg) and applications have undergone Rust rewrites. And of course there's Redox OS which a full OS entirely written in Rust, and it only contains a few hundred lines of unsafe code (which, given how Rust works is the only really key code that needs to be audited for memory safety).
The reason that more things aren't yet written in Rust is because these things take time, and there is lots of inertia to switching languages for established projects (one big roadblock to such rewrites is that maintainers need to be familiar enough with Rust).
OTOH, it may cause companies to invest in creating a well maintained Rust frontend for gcc. People have already done much of the grunt work for this, so it seems like it's just a matter of manpower, and something that acceptance into the edges of the kernel might cause more investment in.
It's a fun idea and many people have had it first thing when they heard of Rust... So why did no one do it?
Quite simply: No one is going to rewrite the Linux Kernel in Rust. It is far too big and also you are not solving any real issues either. Rust only protects you from a small fraction of errors and while for an application like a browser, this can be a big gain, I would argue that it is negligible for a kernel in general. Reasons being that all the device IO, component interaction, privilege escalations, logical errors, hardware errors, firmware errors/bugs all can NOT be addressed by rust. Even for a browser, Rust is only a band-aid. The amount of logical errors and security holes in something as complex as a modern web-browser is more than enough of an attack surface. No need for a rouge pointer to weird memory.
What is MUCH more viable though is a project to compartmentalize the Linux Kernel into HVMs. I forgot the name but there are efforts to put nearly everything into its own HVM. Which means if the printer driver goes nuts, it can't really do anything to your system except not print anymore. If your graphics driver goes nuts, well then you won't see anything... And so on.
This means, almost no code rewrites and still MUCH higher protection than RUST. Rust does not compartmentalize. If any of your system components is fucked, your whole system is still fucked. That is why it's pointless to rewrite a kernel because of a language. You need to compartmentalize it...
Look at QubesOS for an early user-space effort. Would be nice to have a Qubes-Kernel too.
I understand what the kernel devs are afraid of. Rust needs to demonstrate beyond a shadow of a doubt that it's a good replacement for C in the kernel, or they risk alienating people who don't want to learn another language, and losing those developers to FreeBSD or something.
I love the idea of more rust into linux because I think it will make the code more secure and easier to contribute/modify. I am scared of any potential problems an immature ecosystem (relative to C ofcourse, don't jump the gun) can cause to this life-depending tool called the linux kernel. I am glad linus is open to it but careful. Balanced approach
Edit: I am also a proponent of careful re-writes of very old userspace utilities (eg: ping) accompanied by very rigorous tests to ensure there aren't any behavour changes
I think an interesting question is, why are there so many contributors to the Linux Kernel in comparison to something like glibc? Both, I'd argue, are equally foundational.
reply