Wonder who could have done that?
The readme hints at the prompt:
> It keeps the original system's semantics — what it does — while rethinking how it's expressed: stronger types, clearer module boundaries, idiomatic abstractions everywhere.
"idiomatic abstractions" would certainly bloat the line count.
* https://github.com/yuan-xy/Linux-0.11/blob/master/kernel/for...
* https://github.com/Poseidon-fan/linux-0.11-rs/blob/420152fdf...
The Rust is slightly shorter, though it also isn't organized in exactly the same way. The code isn't that different overall, creating and copying some data structures around, as you'd expect for a fork implementation of this vintage.
Maybe I got lucky, but I would expect that it's more of what other people said: this repository includes far more than the kernel.
The majority of Rust the code in the repo is not for the Linux kernel.
It's about 15k lines of code for the kernel and the rest is various utilities, libraries and programs that can run on the kernel.
Sounds like a fun project....
Only in extra syntax constructs.
But Rust can absolutely do the same thing as C in fewer lines, especially when comparing each's standard features like string support.
A couple of times it was cute... but they took it too far in my opinion. And sadly the company was bought out, and now they too have decides to "stop trying to make Fetch happen" (yes, officially it was bought out, but not for the actual robots part).
Rust may be verbose, but at least you can read it without turning into a cynical greybeard subject matter expert first.
That movie is so old it's entirely possible that it's just named "fetch" because that's a reasonable thing to call this feature and so it's a coincidence, but I do like to think that at least some people at WHATWG were quoting Mean Girls...
And the terseness is good when you’re familiar with the code.
Tangential note: there is already a community effort[1] to rewrite GNU commandline tools into Rust and Canonical shipped the rust version of the /bin/utils in Ubuntu 26.04 Resolute Raccoon by default[2] in their "oxidizing" initiative.[3]
PS: Linus Torvalds has confirmed that the existing Linux kernel will never be fully rewritten in Rust.[4] Let's see how well that statement age.
[1]: https://github.com/uutils/coreutils
[2]: https://canonical.com/blog/canonical-releases-ubuntu-26-04-l...
[3]: https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...
A modern Rust rewrite of the Linux 0.11 kernel — boots on
i386in QEMU, runs a self-hosted Unix-style userland.
$ cd kernel && make run
…
Welcome to linux-0.11-rs.
https://github.com/Poseidon-fan/linux-0.11-rs
(login: 0 @ linux-rs :: Wed May 27 09:35:43 UTC 2026)
[root@linux-rs /root]# ls /bin | wc -l
69
linux-0.11-rs rebuilds the 1991 Linux 0.11 kernel from scratch in modern
Rust. It keeps the original system's semantics — what it does — while
rethinking how it's expressed: stronger types, clearer module boundaries,
idiomatic abstractions everywhere. The kernel boots on emulated i386
hardware, runs a full init → shell → coreutils stack, and ships with the
tooling to build your own bootable image in one command.
user_lib mirrors the public shape of
std::{fs, io, path, env, process, time} so user programs read like
ordinary Rust, not like syscall plumbing.sh) with pipelines, control flow, functions, glob, command and
arithmetic substitution, and an interactive line editor with Tab
completion and history.tools/build-disk.sh compiles every user
program, lays them out into a Unix-style filesystem, and packs the
result into a bootable disk image.mbrkit and
miniximg are standalone crates, useful on their own for
any project that touches MBR or Minix v1 images.make run.# Build every user program, lay out /etc /dev /bin, pack into disk.img.
tools/build-disk.sh
# Build the kernel and boot it in QEMU.
cd kernel && make run # VGA console
cd kernel && make run-console # serial console (-nographic)
You'll land at a shell prompt in /root. Try:
ls /bin # browse what's installed
echo $((1 + 2 * 3)) # arithmetic expansion
for f in /etc/*; do echo $f; done # for loop + glob
fact() { if [ $1 -le 1 ]; then echo 1; else echo $(($1 * $(fact $(($1-1))))); fi; }
fact 7 # → 5040
ec<TAB> # completes to `echo `
↑ # walks command history
Outside a devcontainer you'll also need a recent Rust nightly (pinned in
rust-toolchain.toml), qemu-system-i386, the x86_64-linux-gnu-*
cross-binutils, and the local image/test tools:
tools/install-tools.sh # installs mbrkit, miniximg, ktest onto PATH
End-to-end tests boot the kernel under QEMU and drive the serial console
from short .ktest scripts under ktest/suites/.
tools/run-tests.sh # run everything
tools/run-tests.sh --suite=shell # one suite
tools/run-tests.sh --test-set=shell.basic # one test
tools/run-tests.sh --disable-reboot # share one QEMU across tests
kernel/ The kernel itself
user_lib/ std-style user-space library
user_lib_macros/ proc-macro: #[user_lib::main]
user_program/ ~80 coreutils + the `sh` shell
ktest/ end-to-end test runner driving QEMU over serial
mbrkit/ MBR disk-image CLI (also on crates.io)
miniximg/ Minix-fs image CLI and library
rootfs/ disk-image content template (/etc, /root, …)
tools/ developer scripts (build-disk.sh, run-tests.sh, …)
tutorial/ mdbook walkthrough (work in progress)
.devcontainer/ ready-to-use dev environment
cargo install mdbook
cd tutorial && mdbook serve --open
See LICENSE.
Someone is having fun with a side experiment that has no practical real-world implications.
This stuff is supposed to be fun and we should celebrate when other people are doing fun, pointless things like this. If you're interested then ignore it and move on. There's no need to get involved or comment if a project of no consequence is uninteresting to you personally
Atleast people aren't AI rewriting things into PHP.
The reasons to not have a full-Rust Linux kernel are over more important, real engineering things. (Platform support being the big one.)
Because I don't think this. A rewrite is cheaper to me.
Kinda like jackass, fascinating to watch but damn I do not want to do it
In that sense, rewriting some code in Rust _may_ be cheaper than fixing the existing code. It may also be more welcoming to newer devs, since Rust can be easier to reason about, which is a long-term investment.
The borrow checker also helps with AI (as long as you don't let the AI use `unsafe`, or completely control what primitives in your codebase are allowed to use unsafe and never vibe-code any of it) — at least, the agent can't stop until `cargo build` passes.
I've also had better experience locally building applications in Rust than in C/C++. `cd ripgrep; cargo install --path .` or `cargo install ripgrep` usually just work, while `make` is usually painful.
And between rustc_codegen_gcc, projects like https://github.com/FractalFir/crustc, the ongoing addition of backends to LLVM and Rust, and the eventual removal of obsolete targets as hardware goes away, that's less and less of a problem.
I expect Rust to eventually get used in the core kernel, or in drivers that everyone wants to use (e.g. some new bus or device on most new hardware), but I expect that by the time that happens the set of targets supported by the kernel and the set of targets supported by Rust (including through things like crustc and codegen_gcc) will have converged sufficiently.