alt.hn

7/13/2026 at 8:11:29 PM

Linux 0.11 rewritten in idiomatic Rust, boots in QEMU

 https://github.com/Poseidon-fan/linux-0.11-rs

by arto

7/13/2026 at 9:54:07 PM

I just compared this Rust implementation against the original C sources. Some ~50k SLOC (Rust) compared to maybe ~8-12k SLOC of C (depending on if you count headers). Why is the Rust implementation so much more complex and onerous?

by prologic

7/13/2026 at 10:07:37 PM

If the readme is anything to go by, this doesn't look like it was written by hand. Codex if I were to guess. I wonder the coding agent "improved" the code.

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.

by josephg

7/14/2026 at 6:54:35 AM

If that's the case, I don't really get the purpose of this. It's presumably not a useful system for day to day computing. The main reason I could see someone wanting to build this would be as an educational exercise, and using an LLM to do it completely fails at that.

by kelnos

7/14/2026 at 10:11:19 AM

Figuring out how to prompt and test is educational, and it's potentially a useful test of a model/harness.

by kadoban

7/14/2026 at 1:18:02 PM

I would presume Linux 0.11 itself wouldn’t be considered very useful for day to day computing this century. This seems a proof of concept on a very early, simpler version of the kernel. As a PoC I find it useful as exactly that.

by cestith

7/15/2026 at 10:13:25 AM

Well maybe they just did it for fun

by paddim8

7/14/2026 at 10:50:54 AM

The purpose of this project is probably to create something that can be pointed to while saying "This is evidence that the entire Linux kernel could be rewritten in Rust! So now you have to agree to rewrite the modern kernel!"

by oalae5niMiel7qu

7/15/2026 at 5:55:22 AM

The linux kernel is already bloated. We don't need more bloat.

by hulitu

7/13/2026 at 11:13:04 PM

kinda sad cuz 10klines you really get into "well I can just sit there and bang at the problem by hand" territory.

Sounds like a fun project....

by rtpg

7/13/2026 at 11:20:07 PM

Linux at that point’s whole purpose was to bang at it by hand and learn something. There’s a ton of irony in having an LLM do it.

by goalieca

7/14/2026 at 6:12:10 AM

RedHat used to have a poster of the linux source code. Because some early version did fit a large sheet of paper.

Not sure if that's still available but it was a fun poster that I can highly recommend.

by treffer

7/14/2026 at 10:48:53 AM

That's odd. Abstractions in other programming languages reduce the line count.

by oalae5niMiel7qu

7/13/2026 at 11:48:08 PM

so, slop

by pydry

7/13/2026 at 10:32:25 PM

For fun, I decided to take a look at a random syscall: fork.

* 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.

by steveklabnik

7/13/2026 at 10:05:22 PM

According to this breakdown: https://ghloc.vercel.app/Poseidon-fan/linux-0.11-rs?branch=m...

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.

by dminik

7/13/2026 at 10:13:20 PM

Also, after a quick look at a few files, the rust version appears to be much more commented. Not sure if that makes up the extra several thousand lines, but surely counts accounts for some of that.

by dminik

7/13/2026 at 10:20:01 PM

SLOC should omit comments no?

by cozzyd

7/14/2026 at 11:46:23 AM

Onerous is a great word for this. I just checked the linked fork implementation, and basically all the lines of C code there is to the point, and does something useful. Most lines of Rust actually are there to satisfy some constraint of the language, do error handling or call into some other abstraction.

The post title describes this as 'idiomatic', but I have a feeling that actual Rust programmers might not agree on that.

This adds a ton of noise, and breaks up the flow of the 'happy path'.

I can reasonably expect what the C code will do, however with Rust, most code runs in 3 layers of nested lambdas, so I have no idea what's going without inspecting the definiton.

This also means that while Linux 0.11 could be compiled with optimizations disabled, and get decent performance, Rust relies on complex compiler transforms to generate OK code.

To be fair, these issues are not unique to Rust, as (for example) C++ isn't exactly better in this regard, but imo Rust could be a lot more pleasant to read or write for reason that have nothing to do with memory safety or borrow checking.

One of my opinions, is that 'smart' compilers often create long and implicit chains of reasoning that must be followed, making the code very hard to navigate without either an IDE, or having to run it straight up.

Complex type inference, and permissive import systems often lead to this, and these issues are not unique to Rust (and tbf, Rust dispatch is almost always static, so you don't have to deal with DI container BS)

by torginus

7/14/2026 at 1:14:44 AM

Longer isn’t always worse.

C code probably has no problem mixing and perverting int vs enum. Bitfields, structs, etc…

A rust program would define an enum and also implement handling of unexpected values (or consider them errors). Structs and bitfields would be more intentionally used.

Sure, Rust macros can avoid the boilerplate code, but overall line count may still increase a bit.

That said, I’d blame auto-generated code here as other commenters do.

by BobbyTables2

7/13/2026 at 10:56:37 PM

This repo contains a lot of extra tools and userspace programs.

The majority of Rust the code in the repo is not for the Linux kernel.

by Aurornis

7/13/2026 at 10:30:04 PM

I like how everyone has a different theory as to why

by ls-a

7/13/2026 at 9:58:19 PM

I don't think it's rust

by binsquare

7/13/2026 at 10:27:43 PM

because of AI

by icemanx

7/13/2026 at 9:58:31 PM

More LoC means easier to quantify the impact when telling a story. The actual code quality may be lower but that’s the schmuck’s problem that comes after once promo is acquired.

by broknbottle

7/13/2026 at 10:09:36 PM

Or, as others have already noted, it's only about 15k and the repo includes tools and test programs.

by 3836293648

7/13/2026 at 10:05:44 PM

I’ve never worked with Silicon Valley people before now, and now I get why so many projects are abandoned and rewritten when they could just use open source. The whole culture is promo driven.

by newtonianrules

7/14/2026 at 10:13:49 AM

Coders like to code. It's in our nature. Even those who will get no benefit from it still _very_ often code their own version of things for various reasons, often bad reasons.

by kadoban

7/13/2026 at 9:58:41 PM

One of the tradeoffs of Rust is its verbosity I think (in return for which Rustaceans would say you gain explicitness).

by sudb

7/13/2026 at 10:16:38 PM

Verbosity compared to C?

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.

by coldtea

7/13/2026 at 10:28:38 PM

I absolutely despise that C convention if abbreviating absolutely every single thing as much as possible. Yeah yeah, that was necessary back in the day when memory was scarce and editors were awful, but come on those days were almost half a century ago by now.

Rust may be verbose, but at least you can read it without turning into a cynical greybeard subject matter expert first.

by 9dev

7/13/2026 at 10:35:43 PM

I've found that the less real estate my eyes need to scan, the faster I understand the code, even if its more tersely expressed and requires a little decoding. Relatedly, I've come to appreciate a line of code that does the thing rather than one that calls a function whose name might express what the function does, but I might need to go find it and and read its code. That works well if your language supports a terse expression. So I prefer you tersely multiply/reduce a list rather than call a function, but some languages just aren't friendly to that and demand verbosity.

by hughw

7/13/2026 at 10:52:05 PM

This is why kotlin is so amazing, unusually concise and unusually clear in meaning.

by doginasuit

7/13/2026 at 11:13:53 PM

Rust does so a lot of abbreviation, though. fn, ptr, mut, etc.

by rcxdude

7/14/2026 at 8:17:53 AM

It's ok to abbreviate things that are a) standardised, and b) used extremely frequently. Keywords are the best case here. Standard library functions are often ok (e.g. I wouldn't say renaming `memcpy` to `memory_copy` gains you much).

The problem with many C programmers is they tend to abbreviate identifiers in code that they write, which have neither of those properties. It really slows down reading code.

It's actually even worse for hardware (SystemVerilog) developers. For some reason they have to abbreviate everything as much as humanly possible. In some cases it is acceptable (clk/rst for clock/reset) again because it's standard and common. But often you'll end up with nonsense like `dma_ctn_tlul_rsp_intg_err`. Good luck figuring that out if you don't know all the acronyms (it's DMA ConTrol Network ReSPonse INTeGrity ERRor). Obviously you don't need `dma_control_network_response_integrity_error` but there's a middle ground (probably e.g. `dma_control_resp_integrity_err`). (And sorry to pick on OpenTitan; their code isn't actually as bad for this as some of the closed source stuff I've seen.)

by IshKebab

7/15/2026 at 5:25:31 AM

What is the `tlul` part? Just a typo? I don't see it in your expansions.

by atiedebee

7/15/2026 at 6:27:11 AM

Yeah I forgot about that actually. It's TileLink-UltraLight, a SoC bus (basically an open version of AXI). It's probably an acceptable acronym in this context because it's used all over the chip. But also I dunno if it adds much to the name to include the bus that it's connected to.

by IshKebab

7/13/2026 at 10:59:29 PM

I kinda love it, because verbosity means you have to rely on completion and that has a negative impact on retention.

And the terseness is good when you’re familiar with the code.

by skydhash

7/14/2026 at 12:20:10 AM

>"Rust may be verbose, but at least you can read it without turning into a cynical greybeard subject matter expert first."

Actually stuff like fn, mut etc. feels like mutilation to me. I guess it is highly individual.

by FpUser

7/14/2026 at 8:03:57 AM

Rust is not a very verbose language. I translated (without AI) a medium sized program I'd written from Python to Rust and it was 10% longer. Hardly worth mentioning.

by IshKebab

7/13/2026 at 10:20:42 PM

I used to like rust, but I feel like I’m being Pavlovian-conditioned to recoil at its mention now.

by mjhay

7/13/2026 at 11:00:34 PM

This is Linux 0.11 from 1991.

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

by Aurornis

7/14/2026 at 11:30:30 AM

Someone recently had a fun side experiment [1] that ended up killing a product.

[1] https://bun.sh/blog/bun-in-rust

by egorfine

7/14/2026 at 4:43:07 PM

How did it kill the product? It's still cranking along pretty good.

by jmcqk6

7/14/2026 at 12:05:24 PM

Well you have our attention, could you explain the backstory?

by Attummm

7/14/2026 at 2:48:15 PM

Bun was originally written in Zig. It was one of the Zig language’s flagship projects that was brought up everywhere as an example of a successful Zig project, alongside Tiger Beetle and Ghostty.

The Bun team did an experiment to have an LLM transliterate the codebase to Rust and then iterate on turning it into idiomatic Rust. They were losing a lot of time dealing with memory management problems and wanted to move to a language with more memory safety built in rather than Zig’s very manual cleanup, which is challenging in a project like Bun that is dealing with running another language.

The Bun team posted a small blog post about the migration with technical details about how they’re doing it, along with some thanks to the Zig team and positive notes about Zig. The Zig language creator posted a blog post where he ranted about the Bun creator writing “slop before LLMs” and being a “stinky manager” according to “juicy grapes” he heard through the grapevine and numerous other attacks. It was an emotionally charged response to one of the language’s flagship projects leaving for another language.

This split the community, or at least became divisive for a lot of people who have no interest in Bun but view the fight as a proxy for some other battle like hating LLMs or Rust.

It didn’t actually kill the project. The team was acquired by Anthropic and it (the Rust version) is being used in their products, so it’s actually running everywhere and doing more than ever. There was a poll on some subreddit that showed only 30% of people were going to keep using it after the rewrite and people keep holding this up as evidence that the project is dead.

by Aurornis

7/14/2026 at 4:44:48 PM

I find his comment interesting. It's just mundane feedback, but still a feedback.

Likewise, you could ignore his comment but decided to engage.

by kreco

7/13/2026 at 10:32:20 PM

I have the opposite feeling; I am liking Rust more and more and thinking most of the world's C code should be rewritten. It seems like a sweet spot of enforced memory safety, performance, and human/agent readability.

by block_dagger

7/14/2026 at 3:47:30 AM

I think Rust is annoyingly complex and badly designed (although it has good parts) and this would be the same mistake as past pushs to move projects to C++ because "object orientation is clearly better", and as such also step towards more complexity that is difficult to undo again and therefor actively harmful. The better and more powerful approach to safety is proving correctness, which is already possible today but we lack good opensource tooling. Proofs can be added to existing code without introducing complexity.

by uecker

7/14/2026 at 11:31:48 AM

Be careful. People are known to be lost once they start allowing poisonous thoughts like "most of the world's C code should be rewritten".

by egorfine

7/13/2026 at 10:43:26 PM

why rewrite if you can check for and fix bugs? If you are thinking of AI fixing bugs is less expensive

by skor

7/13/2026 at 10:55:51 PM

Memory bugs are unknown unknowns that AI may or may not catch. There's net-present-value in switching to a language where certain types of memory bugs are impossible.

by minimaxir

7/14/2026 at 12:59:54 PM

On the contrary, AI agents are doing an outstanding job of catching and fixing them. The jury's still out on the cost-to-value ratio of improving existing code vs. rewriting it.

by otterley

7/14/2026 at 5:39:36 PM

Those memory bugs tend to be known unknowns. It's the unknown unknowns that are really scary.

by minimaxir

7/14/2026 at 12:33:15 AM

I think Rust (the compiler / borrow checker) kinda finds bugs for you, some of which C/C++ does not.

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.

by tarokun-io

7/13/2026 at 10:54:56 PM

I guess ask the bun people why they translated from zig to rust. I think it was essentially because rust guarantees a set of bugs can't exist so over medium to long term timeframes you end up with less technical debt.

by ImaCake

7/14/2026 at 12:52:30 AM

I know the answer, because they get their money from AI bros and it's a really good headline.

by krater23

7/15/2026 at 5:21:56 AM

This isn't a helpful reply, I come here for thoughtful discussion, not knee-jerk reactions.

by ImaCake

7/14/2026 at 2:49:44 PM

Because making segfaults impossible is simply a better solution to playing a game of whack a mole of "crash, root cause, fix and add test for that very specific bug"?

by eddd-ddde

7/14/2026 at 12:01:11 AM

> If you are thinking of AI fixing bugs is less expensive

Because I don't think this. A rewrite is cheaper to me.

by insanitybit

7/14/2026 at 9:32:53 AM

Rust and C++'s overcomplex syntax are a nightmare to maintain and set.

Go should have been the C succesor long ago, at least for 64 bit machines. In the end It's from the same people of Unix/C/Plan9, so they know their flaws and reasons.

For C++ like performance, sadly there's nothing close to Rust, but Zig and Nim can be close and good enough. Inb4 "mah objects", just use Java or C# and forget C++ forever for OOP programming. The sooner, the better. If you like using C++ just as an improved C and hate templates and objects, just use it for QT5/6 and some performing games and applications. Go can handle the rest just fine.

What I'd love is to see projects like Cataclysm DDA:Bright Nights rewritten in Go, they could save tons of issues on compiling (Clang 11 here, a nightmware to compile) and running, because for an open world game using the GC would free tons of waste on references and objects ingame. Also it will compile much faster and it could be ported to most platforms with no efforts at all.

And I say this as an ScummVM user and sometimes I like debugging some old adventure and RPG games under it...

by anthk

7/14/2026 at 4:45:56 PM

Golang is not a replacement for C. It is a much higher level language, which doesn't play well with systems programming/embedded development etc.

by bergkvist

7/15/2026 at 5:19:36 PM

Tell that to the C creators.

by anthk

7/14/2026 at 11:31:12 AM

Problem with C++ is that it allows an overcomplicated code.

by egorfine

7/14/2026 at 9:41:39 PM

Go doesn't help with memory safety in concurrent settings, and a kernel is very much that.

by yencabulator

7/13/2026 at 10:22:47 PM

I still like it. People are having fun playing with their toy and tool. I have no problem with that.

by Krutonium

7/13/2026 at 10:27:15 PM

I shouldn’t have been so negative. I still very much like Rust, but hearing about these AI rewrites constantly is tiresome.

by mjhay

7/13/2026 at 11:12:19 PM

I'd prefer reading about a rust rewrite then a saas paas CMS integration web thing on the latest framework It'll probably go nowhere, but it's cool to see people test the limits of what they can do and I can't watch without spending a penny

Kinda like jackass, fascinating to watch but damn I do not want to do it

by willx86

7/14/2026 at 5:29:36 AM

That's fair but you don't get that across very well with a comment that mentions Rust and doesn't mention AI.

by Dylan16807

7/13/2026 at 10:26:46 PM

People are having fun with AI coding, and I have no problem with that, but I am sick of hearing about it.

by fsckboy

7/13/2026 at 10:28:38 PM

Of all the tools in software engineering to be overpopular and overused, Rust is an instance where that is a very good thing.

Atleast people aren't AI rewriting things into PHP.

by minimaxir

7/13/2026 at 10:32:24 PM

Be careful, that sounds almost like a dare...

by vlod

7/13/2026 at 11:23:00 PM

Can you elaborate on what causes that reaction specifically?

by treyd

7/14/2026 at 11:32:17 AM

The cult mentality of rust rewrites. Religion above all reason.

by egorfine

7/14/2026 at 8:20:57 AM

It's pretty much the standard target for slop now, so now "in Rust" kind of implies "I just pointed Claude at it and have no idea if the result is any good, also it's an abandoned project."

Tbh I think Rust is popular and mainstream enough that it doesn't matter too much. There are still plenty of great Rust projects out there.

by IshKebab

7/14/2026 at 10:32:32 AM

Truly, is that Rust's fault that sloppers are targeting it?

Personally I'm becoming increasingly disillusioned with current LLMs' capabilities. All those recent high profile "rewrites" turned out to be transliterations to unsafe Rust.

I could rewrite anything in unsafe Rust like right now, despite being a novice in the language.

by Tade0

7/14/2026 at 8:20:04 PM

> Truly, is that Rust's fault that sloppers are targeting it?

The "Rewrite it in Rust!", all gas, no brakes zealotry predates LLM coding agents. When you dismiss the trade-offs with no consideration, and abide no questions about the possible cost of the "one true $X", you're practicing religion, not engineering. What has changed is the zealots no longer restricted to demanding that other people adapt their preferred language, but can now automate forking projects into their ideal language. I'm hoping the next shoe to drop is the realization that the language is a small part of a projects success, when it's time to maintain their forks.

by overfeed

7/15/2026 at 6:12:45 AM

Rewrite it in Rust isn't zealotry with no consideration of the trade-offs. It's simply that Rust is so much better than C that it's pretty much a no-brainer to rewrite C in Rust, or at least to attempt it.

Sorry you can't see a good thing for what it is.

> the language is a small part of a projects success

Perhaps, but it is still a part of a project's success. Many projects written in PHP or Ruby or something other sub-par language have succeeded in spite of that, of course. But plenty have failed that might otherwise have succeeded because of that too. For example Mercurial.

by IshKebab

7/15/2026 at 6:32:53 AM

Rust is not a lot better than C. In many aspect, it is worse. It is better if you focus on a specific point (memory safety) and exaggerate its importance beyond all other considerations and ignoring all other options to make progress in this area. This is the zealotry part.

For my personal IT security, people pushing Rust made things worse not better as I do not get security updates for parts of my OS (Debian) anymore. Also the supply chain risks in the Rust ecosystem are worrying. So even if you go the overall topic security rather than just memory safety, the situation is not all that clear anymore.

It is, of course, in the best interest of Google and co., who are in the business of putting spyware and locked-down content-distribution systems in everybody's pocket, to fully focus on memory safety. Not so much for the free software community where supply chain, long-term maintenance, and the health of existing projects and communities are more important.

And just to preempt the argument "but the superior type system will make everything better". I also was super excited about type system in my youth. I get why people are exited about this. But with experience I realized this also fairly easy to overestimate the impact of this (as I did myself). I also think that Rust is somewhat poorly designed in this regard compared to what is possible here, and adopting it makes it harder to adopt truly better techniques.

by uecker

7/15/2026 at 8:18:41 AM

> [...]it's pretty much a no-brainer to rewrite C in Rust, or at least to attempt it.

Thank you for proving my point. To be clear: there are a lot of legitimate reasons to not rewrite a C projects in Rust, memory safety isn't a universal trump card that supercedes all other considerations in all projects; one has to be zealot to believe that.

I suspect the majority of Rust users are rational about when Rust is appropriate (or not), but they are not going around in random bug threads demanding rewrites of multi-decade projects.

by overfeed

7/14/2026 at 11:52:02 AM

That's not quite true. I had a look into the Bun port and it's not like c2rust where it literally will convert every pointer access into `unsafe` and 50% of your code will be `unsafe`. It's a lot safer than that. They claim only 4% of lines are unsafe, and 78% of those are from C/C++ interop. That's more than a typical Rust project but it's still a lot less than C/C++ or Zig.

> I could rewrite anything in unsafe Rust like right now, despite being a novice in the language.

I really doubt that. Unsafe Rust is actually significantly more difficult to get right than C or C++. See e.g. https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ or https://lucumr.pocoo.org/2022/1/30/unsafe-rust/

It's not too big of a deal because in idiomatic Rust you pretty much never write unsafe code (except for FFI), but it would be nice if it was not quite so hard (or poorly defined).

by IshKebab

7/13/2026 at 10:34:27 PM

I hate that 5 years ago I'd see a headline like this and think it was awesome, and now it's just "look at what someone's spent tokens on today"

by broodbucket

7/13/2026 at 11:01:41 PM

Written by AI and not nearly as impressive at all. Such a shame because I thought someone had spent real time and effort producing this. The output is commoditised and now neither important nor precious. Damn near anyone could repeat it.

by encyclopedism

7/13/2026 at 11:17:32 PM

To paraphrase another comment (https://news.ycombinator.com/item?id=48900086), this project is fun and fun should be encouraged, as experimentation is what leads to more innovative things. The existence of this project doesn't take away from anything.

by minimaxir

7/14/2026 at 10:40:10 AM

I have many times chastised commenters about shitting on other peoples toy/hobby/side projects, but like many others I'm a bit lost on the fun of iterating on "get the Linux 0.whatever source code and rewrite it in rust..." and then crowing "LOOK WHAT I DID!" on HN. If the OP had documented "this is how I prompted the code generating LLM du jour to produce an equivalent to this early Linux kernel, this is the AI workflow I used, and this is how I overcame the problems along the way..." or some such, I'd be all in on this being interesting. As it is, it's Yet Another LLM generated bit of self promotion avoiding saying 'AI did this' and disguised as 'innovation', just like the other ten thousand 'I took something people did all the hard work on and had AI gen up a clone in rust/go/python/whatever in an afternoon...aren't I clever'.

by kjs3

7/14/2026 at 5:21:51 PM

just putting "rewritten by AI" in the headline would prevent the missed expectation feeling I got from clicking into it. but it would also sound less cool and probably get fewer upvotes, so...

by 0x262d

7/14/2026 at 3:41:15 PM

I feel like we are past the point where using an AI tool to translate some code, to write some code, to copy some code, is considered interesting or novel.

by wang_li

7/13/2026 at 11:42:41 PM

I don't think it's wrong to do this and I'm glad it's fun for some, it's just not the same as seeing a project like this that was human authored

by broodbucket

7/14/2026 at 9:04:32 AM

except it’s not really fun.

by dijksterhuis

7/14/2026 at 11:31:14 AM

addendum because that was admittedly a bit of a low effort reply.

throwing a token generator at an idea is not really fun. there’s a reason show hm rules say something about not posting quick one offs (pretty sure this was originally posted as a show hn?). the fun for someone like me is in the appreciation of the effort, not the result.

quirky idea? sure. but not fun

by dijksterhuis

7/14/2026 at 10:03:30 AM

I wish people who do this stuff could at least write their own docs.

by trollbridge

7/14/2026 at 10:55:07 AM

I can't help but glaze over any AI written documentation. If it wasn't worth the time to write then it's surely not going to be worth the time to read

by broodbucket

7/14/2026 at 8:09:19 PM

In our internal repos, I carefully mark out AI generated stuff versus human generated stuff. Of course, the AI generated stuff is often excellent, but its main purpose is to be there to prompt some AI in the future of what to do.

by trollbridge

7/14/2026 at 2:04:23 PM

"look at what someone's spent tokens on today"

Water, drinking water. Fsck these tokens.

by HackerThemAll

7/14/2026 at 5:12:49 AM

I hate LLMs so, so much. They are destroying everything that used to be cool about programming. Or maybe the problem is that a bunch of people who don't actually like programming joined the industry, and now they have a tool that lets them phone it in even harder.

by bigstrat2003

7/13/2026 at 11:10:20 PM

The ultimate boss of Rust rewrites. Very happy that LLM assisted coding unlocks these kind of projects

by bijowo1676

7/13/2026 at 9:56:55 PM

Slopware?

by xqb64

7/13/2026 at 10:09:57 PM

Presumably, but exactly the sort of project where slopware is appropriate. Nobody is expected to use it.

by bryanlarsen

7/14/2026 at 1:59:54 PM

> Nobody is expected to use it.

There's a certain ironic circularity to this comment given Torvalds' original email, describing his little project as:

> just a hobby, won't be big

(of course, I agree with you, no one is going to use a vibe-coded port of 0.11. A port of the latest kernel however....)

by Octoth0rpe

7/13/2026 at 10:37:00 PM

Haha, well, maybe a couple dozen grad students creating some unusual extension to the os:)

by computerdork

7/14/2026 at 9:27:18 AM

No, it's exactly the sort of projects slop is not appropriate. If you're going to use this in production, at least using LLMs (maybe) allows you to deliver faster.

by afdbcreid

7/14/2026 at 1:23:06 PM

What if 0.11 and some userland for it is just a PoC on the way to doing the same with 7? Is it worthwhile then?

by cestith

7/14/2026 at 10:22:20 AM

The Redox operating system is a complete rewrite of operating system concepts in Rust.

Disclaimer, I worked on the Mac OS port.

by singularity2001

7/14/2026 at 10:37:05 AM

What does it mean to work on a port of redox on macos? The ability to compile it / build a disk image on macOs?

by Octoth0rpe

7/14/2026 at 6:44:22 AM

I'm wondering if anyone's attempting to revitalise the old Minix. Minix started out an educational software, from which, Torvalds admitted, he drew inspiration. Since then, they had higher ambitions. And now, from the last I heard, it has evolved into neither here nor there.

by penguin_booze

7/14/2026 at 11:05:17 AM

Beginning with ME (Management Engine) firmware version 11 (found on Skylake CPUs and newer), Intel utilizes a customized version of the MINIX 3 microkernel operating system.

by nineteen999

7/14/2026 at 3:02:52 AM

I wonder how long until we have an entire distro in Rust? I worked on this from the other end making drop in clones of bash, git, make, nftables, pf, iptables, and others, build on the Rust uutils.

fwiw, I never liked the ergonomics of Rust when coding by hand, but it is head and shoulders my favorite vibe coding language.

by jsLavaGoat

7/13/2026 at 10:22:55 PM

Docs full of emojis, this is another AI slop?!

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...

[4]: https://news.ycombinator.com/item?id=41355731

by devy

7/13/2026 at 10:53:42 PM

As soon as Linus retires, there will be an initiative to rewrite the Linux kernel in Rust assisted by LLMs. Either that, or some company will fund a fork before that. Imagine, man pages full of emojis!

by lioeters

7/13/2026 at 10:55:50 PM

Linus is supportive of Rust and uses LLMs.

The reasons to not have a full-Rust Linux kernel are over more important, real engineering things. (Platform support being the big one.)

by steveklabnik

7/13/2026 at 11:17:53 PM

> Platform support being the big one.

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.

by JoshTriplett

7/13/2026 at 11:22:01 PM

I certainly don't think it'll be a barrier forever, for sure.

by steveklabnik

7/13/2026 at 11:15:46 PM

Since the Rust support in the kernel is not optional, it already has an impact on platform support, no? Or maybe they are using the gnu toolchain to avoid that?

by xedrac

7/13/2026 at 11:20:26 PM

Rust support in the kernel is still optional; it's currently only allowed in drivers, and drivers only use Rust if they can accept running only on current Rust targets (which is not a substantive limitation).

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.

by JoshTriplett

7/13/2026 at 10:59:37 PM

[dead]

by lioeters

7/13/2026 at 10:53:30 PM

How do the binary sizes compare? An original Linux 0.11 kernel vs. this oxidized version.

by jagged-chisel

7/13/2026 at 11:13:00 PM

If it's written with nostd, I'd expect them to be similar.

by xedrac

7/14/2026 at 12:20:26 AM

That is indeed the expectation. But what’s the reality?

by jagged-chisel

7/13/2026 at 10:51:12 PM

How does the performance compare?

by drnick1

7/13/2026 at 9:48:46 PM

Nice project, with so many emojis at the start of every title of the README.

Wonder who could have done that?

by rvz

7/13/2026 at 11:47:34 PM

;)

by fpauser

7/14/2026 at 6:12:01 PM

What a waste of tokens.

by jedisct1

7/15/2026 at 6:57:21 AM

See also: Asterinas is a full rust rewrite of a minimal modern linux kernel that can run a full on modern desktop environment.

by lrvick

7/15/2026 at 8:03:03 PM

Interesting. Can it run a mainstream browser?

by hollerith

7/13/2026 at 10:24:09 PM

What is “un-idiomatic” rust?

by irishcoffee

7/13/2026 at 10:29:21 PM

With a project like this, I would expect that "idiomatic Rust" means "attempting to write as much safe code as is reasonably possible" rather than "translating the C to Rust directly".

by steveklabnik

7/13/2026 at 10:38:29 PM

Honestly -- and I know this project is just a toy/fun experiment -- with modern AI, I think this is the correct approach to Rust-ifying projects. Just fork it and do an AI-assisted wholesale conversion, and run in parallel for a while to make sure all the regressions are found. Then you can compare to the original for benefits and drawbacks, and you get a more idiomatic code-base... instead of trying to convince longstanding projects to go into a half-rust Frankenstein model, which is what I usually see.

by richard_todd

7/14/2026 at 10:09:58 AM

Just got downvoted few weeks ago for suggesting someone would soon rewrite Linux into Rust with LLMs and now he did, and this is topping HN.

Are you guys the same guys who read HM every day or some other completely new folk?

by larodi

7/14/2026 at 9:23:20 AM

There is one thing I admire about the Rustees: they really try to change things everywhere, including at the bottom. Whether they succeed or not is secondary to that. Personally I dislike Rust syntax-wise, but the Rustees are very motivated folks. That is interesting.

by shevy-java

7/13/2026 at 11:53:08 PM

rust evangelism is some people / youth of today trying to differentiate themselves from their parents, aka heavy metal of programming. its ok, its fun. i cant read their source code but i dont need to, theres a whole world out there of c/c++/python stuff that will get the job done faster and with less hassle.

by globalnode

7/14/2026 at 4:59:59 AM

Rock and roll is for people with limited musical ability. Heavy metal is for people with no musical ability. Your comparison of rust to heavy metal is apt and holds up well.

by dosisking

7/13/2026 at 10:02:40 PM

rewriting {PROGRAM} in rust is so fetch.

by xyst

7/13/2026 at 10:08:12 PM

Stop trying to make fetch happen

by sajithdilshan

7/13/2026 at 11:10:31 PM

I worked for Fetch Robotics (now defunct), and there were a bunch of people (especially in management) who would constantly reference the Mean Girls "stop trying to make fetch happen" line in company-wide slideshows.

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).

by larkost

7/13/2026 at 10:30:10 PM

They actually did make fetch happen. Once upon a time it was usual in Javascript to use a thing called XMLHttpRequest which despite its name isn't actually for XML, it's just that XML was a big deal when it was created. The replacement API for making normal HTTP requests is just named fetch, and it was "new" so long ago that popular web browsers had versions like 40 rather than 150.

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...

by tialaramex

7/14/2026 at 10:06:37 AM

The cool kids now use axios instead of fetch (LLMs really like using axios, so all the vibe coded stuff uses it).

by trollbridge

7/13/2026 at 10:34:14 PM

Wait? You guys have fetch?

by sscaryterry

7/14/2026 at 6:02:50 AM

Fetch is cringe and has been yeeted

by weregiraffe