To paraphrase an old joke: How do you know if someone is a Rust developer? Don’t worry, they’ll tell you. There is a move to put Rust everywhere, even in the Linux kernel. Not going fast enough for you? Then check out Asterinas — an effort to create a Linux-compatible kernel totally in Rust.
The goal is to improve memory safety and, to that end, the project describes what they call a “framekernel.” Historically kernels have been either monolithic, all in one piece, or employ a microkernel architecture where only bits and pieces load.
A framekernel is similar to a microkernel, but some services are not allowed to use “unsafe” Rust. This minimizes the amount of code that — in theory — could crash memory safety. If you want to know more, there is impressive documentation. You can find the code on GitHub.
Will it work? It is certainly possible. Is it worth it? Time will tell. Our experience is that no matter how many safeguards you put on code, there’s no cure-all that prevents bad programming. Of course, to take the contrary argument, seat belts don’t stop all traffic fatalities, but you could just choose not to have accidents. So we do have seat belts. If Rust can prevent some mistakes or malicious intent, maybe it’s worth it even if it isn’t perfect.
Want to understand Rust? Got ten minutes?
This is what Rust programmers should have done from the beginning. Rewrite it in Rust!
Why? Linux has thousands of man-years put into the development and a massive user base. Anything written from scratch will have a much smaller user base and a tiny fraction of the functionality.
Bringing rust into Linux a bit at a time is a much more sensible approach
Thousands of AAA developers (both hobbyists and corporate) would love to, but as long as Adolf Torvalds is in charge, there’s a zero chance of this happening. For Linux to move on we need to ditch the BDFL model of development and implement direct democratic process. Features could be discussed on a Reddit-like webpage and implemented (or rejected) based on amount of upvotes, instead of arbitrary “my way or the highway” mindset. I suppose some kind of blockchain voting should be used to prevent abuse and clone accounts.
What are you even talking about. Rust is already in the kernel, vetted by adolf torvalds himself.
Yes a lot of drama is going on, sometimes valud, sometimes not…
Reddit driven development for the core operating system used for the most things today…. You think that’s a good idea?
He must be attending communist rallies too…
No matter if written in C, Java or Rust, the fact remains that Linux is not UNIX, it’s something much worse.
Not gonna engage with that directly… But if someone really has the commitment to rewrite Linux from scratch, it does seem like a wasted opportunity not to treat it as a new OS. I’m sure even senior Linux devs have a list of things they’d do differently if they were starting over.
There are plenty of reasons, starting with the fact that there is no ecosystem and no immediate benefits for the majority of potential users.
Meanwhile a compatible kernel is not just an interesting research project, but a potential branch to test the viability of the idea. It’s not like the possible changes you mention can’t happen at all either.
But rust devs want to rewite the ecosystem too hahaha
Linux is in fact not UNIX/POSIX because Linux is a kernel while UNIX/POSIX defines a userspace environment. Linux can host a UNIX/POSIX compliant environment but does not do so in almost all cases. Adelie Linux is a distribution that is working toward full compliance.
Why would anyone want to take zero lessons from the last 46 years?
45* (since the 80’s when unix work, and most OS work, generally stopped)
≥ there’s no cure-all that prevents bad programming
which these days seems to include AI generated code being used without full understanding of what it does or needs to do. Every protection possible in the OS needed more than ever.
That sounds more like fear of new tools than a measured critique. AI-generated code can be risky if misused—just like human-written code. The key is understanding and testing, not assuming humans do it better by default.
Your comment leans on appeal to fear, a hasty generalization, and an implied slippery slope—none of which make for a strong argument.
and you should learn to read :)
Vibe coding skips debugging. If a human codes they test and debug the code, for example sending every possible value to an integer variable and seeing what breaks a function. In C/C++ syntax hides thijgs which Rust makes sure you declare upfront.
Humans do the full work, whereas using AI code skips several key steps of development. Shortcutting vs full investment in the process. AI use cant be a function of development if it is inhetently a dysfunction. AI is for research, and is less reliable than wikipedia.
Bad example, Wikipedia is much more reliable, and history, comments, and references are available.
Generative systems are fact auto completion that require a hand on the reigns at all times.
Wikipedia is the worst source of knowledge. Most universities forbid its use.
To CCO18: then just use Wikipedia as an aggregation of other sources. Most articles have citations which can be used and verified as primary sources
You think human software developers test every possible value of every variable? You are terribly mistaken; software development needs to happen within the lifetime of THIS universe.
I keep hearing this argument – that slop code is fine as long as you understand every detail of what it’s doing – and, yeah, obviously, but isn’t that wilfully missing the point? Because understanding the details is precisely what you’re using an LLM to avoid.
If you tell me a piece of code was generated by an LLM, I don’t know whether that code is good, but I am confident the person who generated it doesn’t understand it as well as a human author would. Because there would be no reason for them to use an LLM in the first place if they were willing to do that work.
There are plenty of parts of most programs that are simple but repetitive and time consuming.
i have some anxiety about the way the world is going, rust in particular, so i wanted to take a look at this.
the first question on my mind was how they could have done enough work to consider that they have built their own kernel, when in my mind that would require an enormous amount of device driver labor. and the answer is that it only runs under qemu, which means they use the handy qemu ‘virtio’ class devices. which definitely is, as they say, a convenient way to prototype OS ideas without the real struggle of making a kernel that talks to hardware.
the next question is whether the rust object model always makes a bunch of repetitive boilerplate code and this does seem to be another project that has that attribute. Linux itself, of course, has a lot of wrappers…but this has a lot of wrappers too. it didn’t seem to reduce that. and the wrappers each seem to have a lot of verbosity, like i found pro forma accessor functions, and also wrappers that copy the same 4 variables from one struct definition to another. i was really hoping it might improve the code readability but it seems to have slightly done the opposite.
and my biggest rust fear is cargo, and this uses cargo a bunch. it pulls in a bunch of 3rd-party crates. it has a bunch of repetitive filenames: 59 directories named “src/”, 55 files named “lib.rs”, and 185 files named “mod.rs”. all of these things make me unhappy but maybe i’m being unfair. surely the fantastic set of problems i ran into the first time i used cargo years ago have mostly been cleaned up. but i really hope if linux uses rust that it doesn’t use cargo, and certainly not 3rd-party crates.
so those observations really are more about my anxieties than they are necessarily problems in this project.
but i do have one straight up criticism…if i understand correctly, the ‘framekernel’ idea’s only concrete manifestation is that they’ve scattered deny(unsafe_code) around their codebase. that’s just the regular rust practice of only using unsafe when you need to. kind of no duh, and i don’t think it means this is fundamentally a different kind of kernel. it seems to be monolithic with the separation between services only guaranteed by the language…all rust kernels would presumably be like this.
Umm, RedoxOS seems to be coming along…