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.
Exactly and that’s one of the advantages to not rely on dependencies. Not every application need those packages. Otherwise they would be included in the standard library. This would encourage people to build software that is self confined, even if it is harder to do. And not every type of tool needs to be this, this is only meant for projects where it makes sense.
You guys need to stop thinking that I’m suggesting a complete replacement of cargo and crates io. It doesn’t need to be one or the other, we can have both solutions and choose which ever works best for the project or you.
The reason they are not included is not to prevent including them when not needed (the Rust compiler makes a good job at cleaning up dead code, so even if they were part of the standard library, they would not be in the binary anyway), but because it allows iterating, optimizing, and patching security flaws in those libraries much faster than the release cycle of the compiler itself.
And yeah, that’s also what cargo’s goal is, only pull what you need in your dependency graph. But what do you mean by self-confined? I hope you don’t mean writing everything from scratch because not only would that be duplicating efforts but it also can potentially lead to security gaps…
If by “self-confined” you mean “vendoring”, then that does not necessarily mean you have fewer dependencies, it just means you commit the raw source code of your entire dependency tree directly into your own Git repository instead of fetching it from crates.io during the build. I don’t think you get much benefit from doing that manually, and it just adds maintenance burden.
“self-confined” I think my weak English showed up again. I mean projects that has all dependencies in the project itself. And don’t get me wrong, I’m not suggesting to write Regex Parser, GUI system and other huge tasks and put them in the project. If you need those, then its better to use the libraries that are available, with Cargo.
Not every program needs all those dependencies and features. Also relying on those dependencies, that rely on other dependencies and so on can also be a security nightmare. My point is to have those projects that are much more simple, maybe even part of other projects like Python (just a random idea, don’t over analyze that).
Ok, that’s vendoring.
So for example, Rust
regexcrate also tries to prevent duplicating efforts so it also has its own dependencies (like “memchr”, some library for fast dictionary matching, some regex-* modules it’s split into, etc)… Rust packages are very modular with the goal of keeping very simply reusable pieces, and this is what makes something like cargo necessary. If you want to vendorregexby including it into your code, you also need to include those tiny modules.You are right having big dependency trees has risks, but I’d argue that avoiding a dedicated package manager that helps you manage those risks makes that security nightmare worse.
Cargo generates a
Cargo.lockfile that guarantees the version you want will be used, but it also allows devs to runcargo audit, to scan the dependencies against a live database of vulnerabilities. You don’t get any of that when you vendor, and you’ll have to manually actively monitor your dependencies for vulnerabilities anyway. It’s not like including the code of the dependencies in your repo makes the problem go away.Incorrect. Vendoring done right (via
replace-with, as done bycargo vendor) is not mutually exclusive with the rest of the tooling. You can have both.True. But you still need to configure cargo there, the vendoring he’s talking about is one where cargo is not used.
And both are still not mutually exclusive. Just like how in C or C++ projects you can both use a proper build system, and still have Makefile(s) around (as fallback, or used as simple runners, or also for tooling reasons).
Putting vendoring aside, using and not using
cargois itself not an either or. Some projects that incorporate Rust as a non-primary language can still use their own build system, and yet still optionally have cargo around for tooling reasons (e.g. to make LSP just work without much hassle), both at the same time. See this demo for an example (mesonfor actual building,cargofor tooling/development).I also have no idea why you exchanged this long with a person who clearly lacks basic knowledge. But maybe I grew more abrasive and less patient than the average person with my greying hair.
You are agreeing with me. I didn’t mean they were mutually exclusive. What I said is that avoiding a dedicated tool like cargo that helps you manage those risks makes the security issues worse.
Yeah sure.
The problem with those people is that they don’t actually know how any software is really built. Even in their simple “Makefile” supposed utopia, tools like
pkg-config, just to name one example, could be running from behind their backs, and they wouldn’t know what that is, that it’s getting executed, and what purpose is it serving in the build process.