HN Reader

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety.

If 32-bit x86 support can be dropped for pragmatic reasons, so can these architectures. If people really, really want to preserve these architectures as ongoing platforms for the future, they need to step up and create a backend for the Rust toolchain that supports them.

I really like to write programs in rust. But my stance has changed a bit over the years ever since other languages caught up a bit. On top of that I’m very skeptical if the rewrite of an ancient tool brings more less security. I don’t know the apt source code or how it actually works behind the cli interface so I leave this judgement to the pros. But there seems to be a very strong move to rewrite all core systems in rust. My issue with that is the fact that these tools don’t even invent anything new. Or change / improve the status co. I understand that it’s hard to introduce a new system without breaking other stuff. But our systems are still based on decisions from the telegraph age. Layers on top of layers on top of layers.

I'm not sure if it's an insecurity thing or an immaturity thing, but when all these stories pop up, I always wonder why rust enthusiasts don't just prove their point by making their own "modern" and non-"retro" tech. If you can make something better, just do it already, and people will switch to it when they see the benefits. This parasitic "you must accept rust in your long-standing project" model is so off-putting, as is always evident by the complaints it causes. I love projects like Redox that try to do their own thing... why doesn't the rust community rally around projects like that and turn them into cve-free masterpieces that people will want to use?

One of the follow up messages is interesting: https://lists.debian.org/debian-devel/2025/10/msg00288.html

> Rust is already a hard requirement on all Debian release architectures and ports except for alpha, hppa, m68k, and sh4 (which do not provide sqv).

Wonder what this means for those architectures then?

> It's important for the project as whole to be able to > move forward and rely on modern tools and technologies > and not be held back by trying to shoehorn modern software > on retro computing devices.

Rust is the present and the future and it's quite logical that it becomes a key requirement in Linux distributions, but I'm really not convinced by the wording here… This last sentence feels needlessly antagonistic.

Wouldn't it make sense to wait for (or support) one of the rust-for-GCC ports to become viable? As far as I understand, rust in the kernel won't become mandatory either until it's supported by GCC, and as a boon, with multiple implementations you can be more certain that the language won't move as fast and break things anymore. There's already upstream rust support in GCC, so I don't reckon it's that far off from being usable, at least for projects choosing to target it specifically.

Furthermore, if these architectures are removed from further debian updates now, is there any indication that, once there's a rust toolchain supporting them, getting them back into modern debian wouldn't be a bureaucratic nightmare?

This is the same maintainer who broke KeePass on Debian and then flipped off everyone in the thread. Someone needs to pull him aside and let him know the world does not revolve around him and the problems he chooses to manufacture to justify his paycheck.

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages.

Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725

Interesting how a person's opinion can change: https://news.ycombinator.com/item?id=27594688

I guess this is fine if you are using the rust standard library, I just don't want to see cargo pulling 500 packages to build this deb parsing code.

I think this is the wrong way to promote rust. For me rust is just a hype. I know nobody that programms or even thinks about rust. I’m from the embedded world an there c is still king. I understand that some will see rust as a good alternative, but as long as the real money is made in c it is not ready

I think polyglot causes more problems than it solves. It is gross how many different toolchains and package managers it now takes to build a distro. One person wants python, another wants node, another wants go, and now this. with node we traded buffer overflows for supply chain attacks. If they don’t want C, it would be better to start fresh. Robert Morris re-wrote enough of Linux in golang to be usable, and the overhead was something like 5-15% slower than C. If the goal is Rust everywhere, contribute to Redox. They are further along that road.

I'm happy for all developers programming in their favorite programming languages. Programming for over 30 years I have seen entire ecosystems come and go.

What I don't get is the burning need for Rust developers to insult others. Kind of the same vibes that we get from systemd folks and LP. Does it mean they have psychological issues and deep down in their heart they know they need to compensate?

I remember C vs Pascal flame back in the day but that wasn't serious. Like, at all. C/C++ developers today don't have any need to prove anything to anyone. It would be weird for a C developer to walk around and insult Rust devs, but the opposite is prevalent somehow.

It makes me uncomfortable that this mandate is coming from a Canonical employee. After all, if this switch was a good idea on merit alone, it would happen organically without requiring this kind of combative communication.

What's the long-term play for Canonical here?

> It's important for the project as whole to be able to move forward and rely on modern tools and technologies and not be held back by trying to shoehorn modern software on retro computing devices.

... This is Debian we're talking about here?

... What distros are recommended for those who intend to continue trying to squeeze utility out of "retro computing devices"?

... And what sort of minimum specifications are we talking about, here?

Never tried to port LLVM. Is 6 months a reasonable timeframe to bring LLVM to a new architecture to production quality?

His much bigger will this make an embedded Linux Debian image?

The language is tough love, and I think it's important despite what the first respondent has said.

Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage.

I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe languages and defensiveness against adopting modern tooling/languages

In the end, only NetBSD will be standing in the breach after anything not x64 or ARMv8+ is declared "retro computing".

I've been trying to build a debian package recently. I didn't have any crashes but I couldn't work out how to do it especially with the unbelievably contradictory and confusing documentation. I'm so glad I mainly use makepkg on Artix which is MUCH easier.

I struggle to believe that this is really about a call to improve quality when there seem to be some other huge juicy targets.

They’d be better off just compiling the package manager with Fil-C

No changes required. Bringing up the fil-C toolchain on weird ports is probably less work than bringing up the Rust toolchain

The follow-up is solid gold:

    > I find this particular wording rather unpleasant and very unusual to what I'm used to from Debian in the past. I have to admit that I'm a bit disappointed that such a confrontational approach has been chosen.

Ref: https://lists.debian.org/debian-devel/2025/10/msg00286.html

From the mailing list on this: https://lists.debian.org/debian-devel/2025/10/msg00288.html :

  > Be careful.  Rust does not support some platforms well.[0]  ANything
  > that is not Tier 1 is not guaranteed to actually work.  And
  > architectures like m68k and powerpc are Tier 3.
  > 
  > [0] <https://doc.rust-lang.org/beta/rustc/platform-support.html>.

[ The rustc book > Platform Support: https://doc.rust-lang.org/beta/rustc/platform-support.html ]

[ The rustic book > Target Tier Policy: https://doc.rust-lang.org/beta/rustc/target-tier-policy.html... ]

  Thank you for your message.

  Rust is already a hard requirement on all Debian release
  architectures and ports except for alpha, hppa, m68k, and
  sh4 (which do not provide sqv).

Create a plan to add support for {alpha, hppa, m68k, and sh4,} targets to the Rust compiler

- 2.5pro: "Rust Compiler Target Porting Plan" https://gemini.google.com/share/b36065507d9d :

> [ rustc_codegen_gcc, libcore atomics for each target (m68k does not have support for 64-bit atomics and will need patching to libgcc helper functions), ..., libc, liballoc and libstd (fix std::thread, std::fs, std::net, std::sync), and then compiletest will find thousands of bugs ]

So, CI build hours on those actual but first emulated ISAs?

"Google porting all internal workloads to ARM, with help from GenAI" (2025) https://news.ycombinator.com/item?id=45691519

"AI-Driven Software Porting to RISC-V" (2025) https://news.ycombinator.com/item?id=45315314

"The Unreasonable Effectiveness of Fuzzing for Porting Programs" (2025) https://news.ycombinator.com/item?id=44311241 :

> A simple strategy of having LLMs write fuzz tests and build up a port in topological order seems effective at automating porting from C to Rust.

I don't care whether kernel developers want to use C or Rush or whatever. I judge the quality by using it in production. If it works well then I don't care how they are built.

Can we please also have the hard requirement that code should run without warnings under Valgrind?

Because that saves a lot of headaches down the line.

Is this the end of Debian as GNU/Linux? The main Rust toolchain isn't GNU, gccrs is still incomplete and most Rust rewrites of existing GNU libraries and tools use MIT or other non GPL licenses.

Rust is a great language for devs. They love it and how developer centric everything about it is.

But for end users on Debian trying to compile rust stuff is a nightmare. They do breaking changes in the compiler (rustc) every 3 months. This is not a joke or exaggeration. It's entirely inappropriate to use such a rapidly changing language in anything that matters because users on a non-rolling distro, LIKE DEBIAN, will NOT be able to compile software written for it's constantly moving bleeding edge.

This is an anti-user move to ease developer experience. Very par for the course for modern software.

Rust evangelists are tiresome. It's not gonna fix the tech debt problem, No matter how much rust crack you smoke. Disciplined use of c, with modern tools like valgrind, will give you safe code without having to lobotomize yourself into fighting the borrow checker for everything, even manifestly simple code.

Didn't they call Rust software "unpackageable" just a couple of months ago? IIRC they were talking about bcachefs-tools.

> This extends at first to the Rust compiler and standard library, and the Sequoia ecosystem.

By Sequoia, are they talking about replacing GnuPG with https://sequoia-pgp.org/ for signature verification?

I really hope they don't replace the audited and battle-tested GnuPG parts with some new-fangled project like that just because it is written in "memory-safe" rust.

The language is incredibly frank, and I agree with it completely. The retro-computing hobby doesn't need the ability to run contemporary operating systems.

It's insane that x86 Debian is still compiling all software targeting Pentium Pro (from 1995!).

x64 Debian is a bit more modern, and you must splurge for a CPU from 2005 (Prescott) to get the plethora of features it requires

Yes, let’s introduce a hard dependency on a language which has no specification, only one compiler and supports a pitiful number of architectures. That’s what true progress looks like.

Why do these matters often become such personal and ideological debates?

I don't get the need for Rust since I happily compile common lisp to machine code when I need fast binaries.

But the people who use the language have an amazing talent to make people on the fence hate them within half a dozen sentences.

They remind me of Christian missionaries trying to convert the savages from their barbarous religions with human sacrifice to the civilised religion with burning heretics.

That seems like a bad idea to me: Dependencies will be added, for very basic system utilities, on (parts of) a software ecosystem which is still a "moving target", not standardized, and IIANM itself has further dependencies. I wonder whether platform compatibility won't be jeopardized, either.

I would be worried if even C++ dependencies were added for basic system utilities, let alone something like Rust.

Now, granted, I'm not an expert on distro management, bootstrapping etc. so maybe I'm over-reacting, but I am definitely experiencing some fear, uncertainty and doubt here. :-(

>It's important for the project as whole to be able to move forward and rely on modern tools and technologies and not be held back by trying to shoehorn modern software on retro computing devices.

Loved this statement on the state of modern software using the backbone of C (in linux and elsewhere)

I think anyone who objects to Rust in userland as part of the system should also object to Perl, Python, Ruby, etc.

What would really be scary would be a distro that won't even boot unless a variety of LLM's are installed.

Boo!

Love Julian's email style. Polite, but firm and decisive.