this post was submitted on 25 Oct 2026
211 points (96.9% liked)

Linux

68405 readers
284 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 7 years ago
MODERATORS
 

EEE

The systemd project has officially introduced support for developing programs in Rust, following the merger of a pull request submitted by Linux kernel developer Christian Brauner. The change, merged into the project’s main branch, establishes a new development option for systemd while keeping its existing C-based architecture intact.

And before anyone assumes systemd is preparing a complete rewrite in Rust, that’s not the case. The maintainers agreed on a deliberately limited approach: Rust may be used only for new, standalone components that other parts of systemd do not depend on. Existing C code will remain untouched.

Another important decision concerns the build process. Rather than introducing Cargo, Rust’s standard package manager and build tool, systemd continues to use Meson for all builds. This keeps Rust development integrated into the project’s existing build infrastructure.

The implementation also places strict limits on dependencies. Rust programs use the no_std approach, meaning they do not rely on Rust’s standard library or external third-party crates. Instead, they interact with systemd’s existing C libraries through generated bindings.

For memory management, systemd provides its own Rust implementations of common container types, with allocation failures handled explicitly rather than causing the program to abort. The new infrastructure also includes wrappers for logging, command-line argument handling, event processing, and error management, allowing Rust utilities to behave consistently with their C counterparts.

Rust support is optional and automatically detected during configuration. Developers wishing to enable it need Rust 1.85 or later, bindgen 0.71.1 or later, and Meson 1.4 or later. Systems without the required toolchain can continue building systemd without Rust support.

Interestingly, initial tests show that a stripped Rust command-line utility occupies about 32 KB, compared to 20 KB for its C equivalent built with link-time optimization. This gives an early indication of the additional overhead, though the comparison involves only a small test program.

The first planned real-world application of this infrastructure is systemd-keyring-setup, a new utility intended to help manage certificates in Linux kernel keyrings. Its implementation is being developed separately, alongside additional Rust wrappers for systemd’s shared libraries.

For Linux distributions, the change introduces packaging considerations. Builds that enable all available features will need the appropriate Rust compiler and bindgen dependencies or must disable Rust support to avoid build failures.

Whether Rust becomes widely used within systemd will depend on future development, but the necessary groundwork is now in place.

top 50 comments
sorted by: hot top controversial new old
[–] thingsiplay@lemmy.ml 47 points 5 days ago (4 children)

At this point, I think Rust should be installed and available on most distributions. Its just part of Linux now, like C and Python. Maybe this will be, once GCC can compile Rust too.

[–] Ephera@lemmy.ml 20 points 5 days ago (58 children)

Firefox and Python's cryptography toolchain have a build dependency on Rust, which are two packages that virtually all Linux distributions have packaged. So, some version of the Rust compiler is going to be available on virtually all Linux distributions.

There's no real reason to have the Rust compiler installed on non-dev systems, as you don't need it for running Rust programs (although I kind of assume you know this).
But yeah, it seems to be possible to dynamically link the standard library into Rust programs, so Linux distros could try to share that between them, and then it would effectively be installed by default.

load more comments (58 replies)
[–] protogen420@lemmy.blahaj.zone 2 points 4 days ago (1 children)

doesnt really work due to unstable ABI, unless you already have packaged all currently support std lib versions, and supporr muktiple of them being imstalled at same time, you oretty much have to vendor it, same thing 3rd party libs

[–] thingsiplay@lemmy.ml 2 points 4 days ago

If they are packaged in the repository itself or like C and Python packages with your distribution, then it's not different.

[–] HelloRoot@lemy.lol 4 points 5 days ago (2 children)

Only if it is packaged like python on arch.

I never had so many problems with anything else on linux but pip, npm, and cargo.

[–] badmin@lemmy.today 5 points 5 days ago

That's python's problem. You have no idea how much of a life improvement simply using uv + an older python version (uv natively supports this) is.

[–] thingsiplay@lemmy.ml 6 points 5 days ago* (last edited 5 days ago) (1 children)

I don't think that a package manager and cargo should be included by default, if Rust compiler and the standard library was installed. One can use the compiler rustc without Cargo. Also there are works to create a new independent compiler for the GCC framework, but that takes forever it seems.

That would off course mean that many projects cannot be compiled without a package manager and all their dependencies. But it would make it like Python (and C compilers) be possible to compile individual files. That could make it to a standard way of distributing simple projects which does not require any external libraries at all. This could encourage such projects too, which isn't a bad thing at all to me.

And it just occurred to me that probably some Rust libraries could be installed as a separate Archlinux package too, so you don't need external package manager. Haskell in example does that, and off course Python packages.

load more comments (1 replies)
load more comments (1 replies)
[–] Mio@feddit.nu 3 points 4 days ago

The problem with Rust is the compile time and build temp files. But that is not a problem once shipped. It is more about developers need to know more now

[–] MonkderVierte@lemmy.zip 7 points 5 days ago (2 children)

Uh, why is Systemd stuff dependent on any specific language, except for (C) kernel calls?

[–] Ephera@lemmy.ml 23 points 5 days ago (1 children)

This is about the official systemd repository. They use a mono-repo-approach, where all the official components are in one repository and use the same build system, so adding a second language into that is a bigger hurdle.

If you develop a third-party tool that somehow hooks into systemd, then you can use whatever language you want.

[–] MonkderVierte@lemmy.zip 5 points 5 days ago* (last edited 5 days ago)

Ah, makes sense, thanks!

While i don't think that a monorepo with no scope guard rails is a good idea.

load more comments (1 replies)
[–] blobjim@hexbear.net 5 points 5 days ago* (last edited 5 days ago) (1 children)

Is Rust support in GCC ready yet? It's worrying that Linux is now becoming dependent on the massive LLVM project and the Rust reference implementation (also presumably complex?).

[–] badmin@lemmy.today 6 points 5 days ago (1 children)

To not depend on LLVM, you only need a non-LLVM code generator (i.e. replacing the LLVM IR generation step with another representation). A full fledged implementation in GCC is not strictly necessary. The "presumably complex" Rust implementation is actually modular like that. Multiple code generators already exist.

rustc_codegen_gcc is progressing nicely. Priority is given to targets with no LLVM support whatsoever (architectures you probably never heard of) and x86_64. Using the latter as a target could become fully usable within months (90%+ of the work is already done).

Another code generator that exists and is even more well supported is cranelift, but that strictly targets fast compilation (at the expense of slower binaries), so it's mostly useful for faster development workflows.

There are even code generators that generate C code, which manage to turn the full reference rust compiler itself to C 😉

The implement-Rust-in-GCC project is called gccrs, but that's years away from reaching a fully usable state.

[–] blobjim@hexbear.net 1 points 4 days ago

rustc_codegen_gcc looks pretty cool!

[–] Ephera@lemmy.ml 4 points 5 days ago (1 children)

Those are some wild restrictions. You're using the syntax and presumably compiler (rustc), but almost nothing else from Rust...

[–] badmin@lemmy.today 3 points 5 days ago (1 children)

You’re using the syntax and presumably compiler (rustc)

but almost nothing else from Rust

waat 😲

[–] Ephera@lemmy.ml 3 points 4 days ago (7 children)

Yeah, in detail, they use or can use:

  • Syntax + tooling for it, like editors, linters, formatters
  • Compiler (rustc, which enforces memory+thread-safety for the parts not implemented in C)

They've replaced:

  • std library → core library + their own implementation of types that do memory allocations, so in particular dynamically-sized types like lists and strings
  • Cargo → their own Meson definitions

What they don't use:

  • the library ecosystem of Rust (although apparently they've got own implementations of "logging, command-line argument handling, event processing, and error management")

It does sound like someone thought about this stuff, but yeah, as a Rust dev, it also sounds like I would struggle...

load more comments (7 replies)
load more comments
view more: next ›