Hmm. Given we got here by talking about people who can't (rather than won't) run heavyweight GUI clients, a Rust rewrite seems like it misses the point.
That is, I'm sure it makes sense for them, and for most of their actual users, because Rust is nice, but if I have an m68k machine, too bad, there is no Rust for m68k (unless I'm reading the platform support chart wrong) and so this rewrite likely orphans me.
Now, if for a Debian channel, even a Debian channel about an attempt to port Debian to m68k, then I have no doubt your users all have something less stupid, maybe ARM or x86-64 or even PowerPC. They prefer a non-GUI for their own reasons but ultimately Matrix is an option.
But if you're a channel for actual m68k "classic" Amiga you might actually have a non-trivial number of users for whom "it doesn't run on m68k" is a showstopper. They have an IRC client today.
Rust doesn't target barely-capable archaic platforms like Motorola 68xxx or 80286 and I don't think it should start. But that means we have to accept that a Rust client won't support those platforms.
Go ahead and rewrite 30+ million lines of C code in Rust, LMAO.
It's not going to happen, Rust support is being added for new code, not specifically to rewrite the kernel.
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.
The entire point of the presentation is to discuss these issues, and recommend rust for more ancillary tasks (modules/drivers, firmware, utilities) than the kernel itself.
> Kernel programmers would be using something else if that's what they wanted to use.
The vast majority of the languages having arisen in the last 40 or so years are completely unsuitable for kernel development, so not necessarily.
I don't think it makes sense to rewrite the Linux kernel in Rust. As long as we're dreaming, let's talk about a new OS without all the legacy cruft. Be sure to make it hard to lock the user out, so userbinator is happy too, but (again) as long as we're dreaming that's on the agenda too.
Telling QEMU to move from C to Rust is bad idea imo. QEMU Devs are probably well versed in Source code of QEMU and C. Telling them to learn new language and rewrite QEMU would be a joke. It would give lot of new problems than solving the current issues.
Probably, RUST Devs who are well versed in emulation can start another project in RUST which has same goals of QEMU but telling existing software to rewrite is a big JOKE to be laughed at.
This has nothing to do with RUST but "Rewrite in New language" syndrome.
There's too much friction for Rust to be the solution, unless there are drastic changes in the near future. None of Vulkan, Metal, GTK, Qt, Cocoa, Android, iOS, or Wayland have official Rust support, and maintaining the boundary is a non-trivial task.
My gut feeling is that a different language with less friction will gain more traction.
Ah, I didn't catch the part of the article that pointed out not relying on existing compilers was an explicit goal (Which probably should have been obvious in hindsight). To each his own, it's still a fun project if not particularly practical. But that makes sense then that this probably isn't the only way to bootstrap Rust onto a new architecture.
Your argument reads like: you shouldn't need to run Rust programs unless _the entire operating system_ is first rewritten in Rust. I doubt you really mean that, though...
"Talk is cheap, show me the code" - Linus Torvalds
The author applies the same standard reasons for moving from C to Rust for the QEMU project which are valid reasons. However, I would take the author more seriously if they have done a proof of concept first and then later made their case for this.
Otherwise, it is another "rewrite it in rust" post which is yet to materialise into a real project.
i can understand the argument for new code, but what do you want people to do, recode the entirety of the linux kernel in rust? the kernel is allowing rust for new drivers
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.
> Of course, rewriting and existing kernel stepwise would be interesting, if possible.
Perhaps it's possible to write a new kernel in Rust, and have it be backwards compatible with Linux, by "wrapping" the Linux kernel and drivers in sandboxes?
So a Rust kernel with some kind of built-in environment isolation, in which it can run the real Linux kernel. The running Linux kernel would then access physical hardware through a wrapper in the Rust kernel, while the Rust kernel would access hardware directly.
That's really the only way I see this project gaining widespread adoption: by leveraging Linux. Linux simply has too much momentum to be replaced with something non-compatible.
Of course, a Rust kernel could be useful for all kinds of things other than replacing Linux. Like a Mirage OS-type kernel that uses Rust to write drivers in Rust (instead of OCaml).
That is, I'm sure it makes sense for them, and for most of their actual users, because Rust is nice, but if I have an m68k machine, too bad, there is no Rust for m68k (unless I'm reading the platform support chart wrong) and so this rewrite likely orphans me.
Now, if for a Debian channel, even a Debian channel about an attempt to port Debian to m68k, then I have no doubt your users all have something less stupid, maybe ARM or x86-64 or even PowerPC. They prefer a non-GUI for their own reasons but ultimately Matrix is an option.
But if you're a channel for actual m68k "classic" Amiga you might actually have a non-trivial number of users for whom "it doesn't run on m68k" is a showstopper. They have an IRC client today.
Rust doesn't target barely-capable archaic platforms like Motorola 68xxx or 80286 and I don't think it should start. But that means we have to accept that a Rust client won't support those platforms.
reply