On 2025-09-01 09:05, Davide Biondi wrote:
>
> Hello Devuan community,
>
> my name is D. I am not a computer scientist, but I have been a long-time Linux user with some entry-level coding experience.
> I am writing because I am concerned about the growing adoption of Rust in the Linux kernel and in core packages (such as uutils-coreutils).
> >From my point of view, Rust brings several risks:
>
> 1-It introduces permissive MIT/Apache licensing into the very core of Linux, which could favor closed-source derivatives and weaken the GPL reciprocity that made Linux strong.
>
> 2-The Rust toolchain is complex, not fully bootstrappable from 100% free sources, and relies on binary distributions. This reduces auditability and increases dependency on external actors.
>
> 3-The expansion of Rust in the kernel and in base utilities may bind the Linux ecosystem to non-fully-free toolchains and reduce long-term freedom for users and developers.
>
> 4-Combined with the ever-growing scope of systemd, this convergence of design and licensing risks turning Linux into something more monolithic and Windows-like, moving it away from the traditional Unix philosophy.
>
> Devuan has already solved the problem of systemd by providing a systemd-free Debian fork.
>
> My question is: what steps, if any, is the Devuan developer community considering in order to provide or support a Rust-free kernel option?
>
> Thank you for your time and for the great work you are doing.
> Best regards,
> D.
>
>
I have chosen this mailing-list because the Devuan creators went against
monolithic design in favor of atomicity and simplicity,
in accordance with the Unix philosophy, but Rust in the kernel follows
the same pattern as systemd: monolithic design and complexity.
So Devuan is unfinished business, unless it becomes Rust-free. And Rust
acts as a political Trojan horse, infiltrating Linux projects under the
cover of permissive licenses, putting Linux back behind a paywall,
in practice. That's why the kernel is going to be developed in Rust
instead of Zig, which could be a reasonable alternative.
It is never about safety, it is always about control, especially when
big corps and political organizations talk about "safety".
Rust is a sophisticated form of "cyber-entrism", as far as
I am concerned. My point is:

Why has a language so young, untested, and immature been implemented in
a project as old, complicated, and critical as the Linux kernel itself?

Let's read the opinions of experts on the Unix philosophy and kernel
development
Stallman: he rejected the philosophy of Unix.
In an interview, he (RMS) said:

Moderator: Let me explain. So there's another thing that hampers that
and that and that's accidental complexity. So basically, so if I have a
regular personal computer with a GNU/Linux system installed on it, it's
so huge and complex that even though all of the source code is available
it's just so tremendously complex there is necessarily going to be a bug
by which I mean that it doesn't do exactly what its users and creators
expect it to.

RMS: Yeah. That's normal.

M: Yeah. That's normal. Exactly. But what I would like to hear your
opinion about is whether there is some way to encourage a kind of going
back to the original GNU and UNIX philosophy of small modules that
provably do one thing and do it well. Because I think that we are moving
away from it even in the Free Software community.

RMS: I think you're mistaken. I think we never started from there. I
never endorsed that UNIX philosophy. I was not interested in proving
anything about what the programs did. I wanted to make them work
in practice. And then work in practice means we fixed bugs. Of course
there were always bugs. There were lots of features and there were lots
of features because we wanted lots of features. So basically, I just
never agreed with that because the goal I had was different. You want an
entire system which is so simple that people can prove it will do some
particular thing correctly, and I can see how for some purposes that
might be useful. But my purposes weren't in that direction. I wanted a
system that would do all the things I wanted it to do which meant it
would be big and complicated and we would fix the bugs until it worked.
And so I'm happy with that. I never wanted to go in the UNIX philosophy
direction. And that's why I didn't.

The question to RMS was framed incorrectly in several ways, according to
an associate; "one is that it was pointed to the past decisions and not
about goals going forward. The other is that it is about proving
software works rather than focusing simplicity and clarity as
facilitators of both access to the source code and prerequisites for
modification."

"The freedom to study the source code and make changes is a corollary of
being able to understand the code which derives from it being neither
obfuscated nor overly complex," the associate continued.
"I'm sure the above phrasing can be refined, but it gets at the point
made above that simplicity and clarity are desirable and maybe even
necessary traits. Because otherwise, looking forward, large companies
could make their code violate the spirit of the GPL
(and I'd say the letter, too) by writing code that is obfuscated enough
through complexity and size that no normal programmers would have any
chance of exercising their software freedom."
[https://techrights.org/n/2023/10/28/For_Better_or_For_Worse_Richard_Stallman_Does_Not_View_Growing_.shtml]

Kernighan: he defended the philosophy of Unix 40 years ago, and probably
still does.
As Kernighan explained in an interview...
"Many UNIX programs do quite trivial tasks in isolation, but, combined
with other programs, become general and useful tools."
[https://math.albany.edu/pers/hammond/unixphil.html]

""I have written only one Rust program, so you should take all of this
with a giant grain of salt," he said. "And I found it a — pain… I just
couldn’t grok the mechanisms that were required to do memory safety, in
a program where memory wasn’t even an issue!""
"Speaking of Rust, Kernighan said “The support mechanism that went with
it — this notion of crates and barrels and things like that — was just
incomprehensibly big and slow.”

“And the compiler was slow, the code that came out was slow…”

All in all, Kernighan had had a bad experience. “When I tried to figure
out what was going on, the language had changed since the last time
somebody had posted a description! And so it took days to write a
program which in other languages would take maybe five minutes…”

It was his one and only experience with the language, so Kernighan
acknowledged that when it comes to Rust “I’m probably unduly cynical.

“But I’m — I don’t think it’s gonna replace C right away, anyway.”"
[https://thenewstack.io/unix-co-creator-brian-kernighan-on-rust-distros-and-nixos/]

Torvalds: His behaviour is incomprehensible at the very least, if not
suspicious. He endorsed the infiltration of Rust into the Linux Kernel,
in an experimental, prudent way, ignoring the huge red flag of the
relationship between the Rust programming language and Microsoft. At the
same time, however, he expelled Russian developers from the project of
the Linux Kernel, adding geopolitical reasons...so now open source
commits from Russian developers are considered bad because they are
linked to the FSB...but we are ignoring the connection between Rust
and Microsoft...really?!
[https://www.tomshardware.com/software/linux/linus-torvalds-kicked-the-russians-out-of-linux-now-theyre-creating-a-sovereign-linux-community-in-russia-ministry-of-digital-development-steps-in#xenforo-comments-3859264]

Paradoxically, the Russians declared that they will make their own
fork of the Linux Kernel, but if they work alone in a country in which
the digital gulag called "Max" is going to become mandatory for all
smartphones...it is hard to take the Russians seriously either.

Stroustrup: he called out government agencies for their attempts to
undermine the open-software projects.
"Bjarne Stroustrup, creator of C++, has issued a call for the C++
community to defend the programming language, which has been shunned by
cybersecurity agencies and technical experts in recent years for its
memory safety shortcomings."
[https://www.theregister.com/2025/03/02/c_creator_calls_for_action/]
"There's been pushback from C++ creator Bjarne Stroustrup and others.
In response to a November 2022 NSA memo [PDF] urging memory safety,
Stroustrup argued [PDF] that C++, with proper tooling, can match Rust's
memory safety guarantees "at a fraction of the cost of a change to a
variety of novel 'safe' languages.""
[https://www.theregister.com/2024/03/31/rust_google_c/]

Ken Thompson: You must be able to trace the bugs all the way back to the
 source, ESPECIALLY if these bugs are in the compiler itself.
"You can't trust code that you did not totally create yourself.
(Especially code from companies that employ people like me.) No amount
of source-level verification or scrutiny will protect you from using
untrusted code. In demonstrating the possibility of this kind of attack,
I picked on the C compiler.
I could have picked on any program-handling program such as an
assembler, a loader, or even hardware microcode. As the level of program
gets lower, these bugs will be harder and harder to detect.
A well-installed microcode bug will be almost impossible to detect."
"First we compile the modified source with the normal C compiler to
produce a bugged binary. We install this binary as the official C.
We can now remove the bugs from the source of the compiler and the new
binary will reinsert the bugs whenever it is compiled. Of course,
the login command will remain bugged with no
trace in source anywhere."
[https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf]

"Compilers are often written in the language they are compiling.
This creates a chicken-and-egg problem that leads users and distributors
to rely on opaque, pre-built binaries of those compilers that they use
to build newer versions of the compiler.
To gain trust in our computing platforms, we need to be able to tell
how each part was produced from source. We believe that opaque binaries
are a threat to user security and user freedom since they are not
auditable; our goal is to minimize the amount of bootstrap binaries."
[https://bootstrappable.org/]

There are also developers who abandoned the project of infiltrating
Rust into Linux kernel:
""Keep the wrappers in your code instead of making life painful for
others," and went on to argue that "interfaces to the DMA API should
stay in readable C code and not in weird bindings so that it [remains]
greppable and maintainable." Hellwig's wish seems to be that
non-C drivers have their own private bindings to C code, and that these
abstractions are not maintained in a separate shared space, not even in
the rust/kernel tree."
"Every additional bit that another language creeps in drastically
reduces the maintainability of the kernel as an integrated project.
The only reason Linux managed to survive so long is by not having
internal boundaries, and adding another language completely breaks this.
You might not like my answer, but I will do everything I can do to stop
this. This is NOT because I hate Rust. While not my favorite language
it's definitely one of the best new ones and I encourage people to use
it for new projects where it fits. I do not want it anywhere near a
huge C code base that I need to maintain."
[https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux/]

Why is Rust implemented in the Linux kernel if its own features are
*still* unstable?
"Initial support for Rust in the kernel was merged in October 2022,
for Linux 6.1, but there are obstacles to progress – including that Rust
for Linux still requires use of unstable features in Rust. This is
recognized as undesirable, but there are many such features, as
documented on GitHub, and they cover areas including the language,
standard library, compiler, and more."
[https://devclass.com/2024/09/18/rustconf-speakers-affirm-rust-for-linux-project-despite-challenges-of-unstable-rust-maintainer-resignation/]
And this is a very long list of unstable features they are
*still* working on ("Rust unstable features needed for the kernel"):
[https://github.com/Rust-for-Linux/linux/issues/2]

Kernel drivers in Rust...Pip in Rust...sudo rewritten in Rust...
GNU coreutils rewritten in Rust...what could possibly go wrong?
After all, Microsoft has always been Linux's best friend, right?
 
"DOVER, DELAWARE, Tuesday May 7, 2024 – The Rust Foundation,
an independent, nonprofit organization dedicated to advancing
the performance, safety, and sustainability of the Rust
programming language, is pleased to announce that funds from
an unrestricted donation of $1M from Microsoft in December 2023
will be allocated to support a variety of critical Rust language
and Project priorities.
This $1M donation from Microsoft a Rust Foundation Platinum Member,
will be invested over a two year period and applied to the
following high-priority areas of need in the Rust ecosystem:

Hiring an additional Rust Foundation infrastructure engineer
Funding the Rust Foundation’s capstone “Fellowship” program
Developing new systems and programs to support the work of
Rust Project maintainers and reduce workload strain."
[https://rustfoundation.org/media/1m-microsoft-donation-to-fund-key-rust-foundation-project-priorities/]
 
So again, I ask: why introduce such instability and complexity at
the very heart of Linux?