Forgot your password?
Close
typodupeerror
Linux

Systemd Merges Support for Rust Programs (phoronix.com) 42

Posted by EditorDavid from the init-to-win-it dept.
"As of today in systemd Git it's now possible for the systemd programs to be written in the Rust programming language as an alternative to C," reports Phoronix: Core systemd code like the systemd library doesn't yet support Rust code, but for the various systemd programs / leaf components there is now support for using Rust... The new systemd-keyring-setup utility in Rust is used for provisioning keyrings and enrolling X.509 certificates into the kernel's dm-verity / fs-verity / BPF keyrings during the boot process while dealing them afterward. This systemd-keyring-setup code hasn't been merged yet but is expected soon now that the Rust infrastructure has landed. Originally it was all part of a single big commit before being split-up for the Rust enablement, systemd-keyring-setup, and other preparations for this new component.

Systemd developers aren't planning on porting existing C code to Rust, all the Rust code is built with Meson [no Cargo usage], and C linkage only is mandated.

Systemd Rust components come out slightly larger than C with a test program being 32KB compared to 20KB for its C twin. For now at least the systemd Rust support is optional and toggled by the -Drust= Meson option with it being auto by default.

Systemd Merges Support for Rust Programs More | Reply

Systemd Merges Support for Rust Programs

Comments Filter:

  • I look forward to a mature discussion about what this might mean as opposed to 400 comments all talking about how much they hate systemd and it is the devil.!

    • That's so last year. Everybody know that on Slashot AI is the devil now and the biggest trick it did was convince people that it exists.

    • Re:This will certainly be great discussion (Score:4, Insightful)

      by fuzzyfuzzyfungus ( 1223518 ) on Sunday October 25, 2026 @08:50PM (#66393054) Journal
      I'm not really qualified to deliver a good holy war; but it does seem like there may be something to the criticism that monolithic integration has gone a bit far if supporting one utility being written in a different language is a special feature rather than a matter of the rest of the system not knowing or caring what is on the opposite side of an interface so long as it can act as expected.

      • Re: (Score:2)

        by tlhIngan ( 30335 )

        SystemD isn't a monolithic application. It's a collection of utilities that all share the SystemD banner. You can pick and choose what bits of the SystemD utility set you wish to use. It is entirely possible to not use the init portion but use the system logging daemon, for example. Or other bits and pieces.

        In fact, there's no distribution out there that uses everything SystemD has to offer. Most use a majority of the components, but there's often a few that are not used. systemd-networkd versus Network Man

        • Re:This will certainly be great discussion (Score:5, Insightful)

          by fluffernutter ( 1411889 ) on Monday October 26, 2026 @03:15AM (#66393316)
          Then why are all the separate little config files monolithic? What cron did with one file you now need many multilinr files for? And what is the format of those config files anyway? It seems like INI which is a Windows thing. The only software that uses that on Linux was made by people who don't really understand Linux.

          • Yes, because being declarative about your dependencies is terrible. I'd much rather have the complexity of making sure that crons fire in order, on a timer, instead of being event-driven and declaring everything it needs.

        • I didn't mean to imply that it is a single monolithic application, it does consist of several, but the relations must be pretty tight for there to be an article not even about language-independence; but about support for a single additional language, one often targeted by "C but cleaned up" efforts,

          I was honestly surprised to see this myself. Regardless of its reputation for being more monolithic than classic init systems it still is, and has to be, capable of interacting with basically any flavor of ser

        • SystemD isn't a monolithic application. It's a collection of utilities that all share the SystemD banner.

          It's a bunch of utilities that depend on the same libraries and one another, you cannot just separate out any pieces you want and use them independently, some of them come in packs and using one implies using the next, or having a real bad time. That is the root of the complaint about systemd not following the Unix way.

          Heck, I think there was one now-deprecated component of KDE that was dependent on one SystemD utility that was Linux-specific. It got dropped over a more generic version that used more portable components.

          Yes, the KDE devs are smarter and more competent than the GNOME devs.

          • > you cannot just separate out any pieces you want and use them independently,

            Except when you can, which is most of the time. Grow up.

        • SystemD isn't a monolithic application. It's a collection of utilities that all share the SystemD banner.

          Literally every monolith ever is a collection of smaller parts.

          Your example proves you don't understand monoliths. For example, it is perfectly possible to use Google Maps without using Google search, even though they are both part of the same monolith. "using" and "not using" aren't what determine a monolith. What determines a monolith is improper separation of concerns, and that is a design mistake made by systemd.

          Systemd is a monolith.

      • I'm not really qualified to deliver a good holy war; but it does seem like there may be something to the criticism that monolithic integration has gone a bit far if supporting one utility being written in a different language is a special feature rather than a matter of the rest of the system not knowing or caring what is on the opposite side of an interface so long as it can act as expected.

        The summary isn't clear on this. I also initially thought that it was talking about programs written in Rust and being managed by systemd's init/service management. But that can't be what's now supported, because systemd should be able to launch anything that's executable (any compiled binary, shell or Python scripts, etc.). So my guess is that this is some kind of systemd library that now has a Rust version.

    • I also hate rust, so this is putting all the bad things in one basket. Next step: drop basket.
    • I'm more triggered by the claim that Meson is not using Cargo, it's a Cargo wrapper that also links. Of course, systemd is what ran down Satan's leg when he made Satan spawn, it's Satan spawn leftovers.
      • should add Meson does building of code in many other languages too, I was only speaking of Rust and C libraries in systemd context
    • It's not the devil; it's just garbage and is only used by inferior people who don't know any better -- and are too lazy to learn. In that sense it's useful: it allows us to easily identify the incompetent and stupid, which is why I use it as an interview question. (Seriously. It's just one in a list, and it's not the first or last, so there's no particular indication that it's a key. Of course I permanently reject any applicant who answers it incorrectly, but one thing I've noticed is that these people

      • It's not the devil; it's just garbage and is only used by inferior people who don't know any better -- and are too lazy to learn. In that sense it's useful: it allows us to easily identify the incompetent and stupid, which is why I use it as an interview question. (Seriously. It's just one in a list, and it's not the first or last, so there's no particular indication that it's a key. Of course I permanently reject any applicant who answers it incorrectly, but one thing I've noticed is that these people also tend to be seriously lacking in other areas as well. For example, a couple of months I interviewed someone who considered themselves a senior Linux expert but couldn't write a single line of awk(1) -- which is pathetic. I didn't hire them but I did recommend some remedial reading to them in the hopes that they might invest some minimal effort in self-improvement.)

        That my good man, is some worthy trolling. Well played indeed!

  • Systemd Rust components come out slightly larger than C with a test program being 32KB compared to 20KB for its C twin

    Who's going to be able to scrounge up an extra 12KB of RAM in today's market?

    • Systemd Rust components come out slightly larger than C with a test program being 32KB compared to 20KB for its C twin

      Who's going to be able to scrounge up an extra 12KB of RAM in today's market?

      Most things expand [wikipedia.org] when they rust. :-)

    • Who's going to be able to scrounge up an extra 12KB of RAM in today's market?

      That was just one single test program of only 20 KB. Extrapolate that out and it's significant.

    • Males are slightly larger - just 50% taller. Does not sound like slightly to me.

  • 32KB compared to 20kb

    That's more than 50% larger for that one test program. I don't consider a 50% increase "slight". Maybe a 10% increase can be considered slight, but that much difference is significant. Especially talking about embedded systems and the like.

  • My AI overlords will eat your Rust slop for breakfast!

  • Rust is pretty powerful and permits creating relatively safe software but what's missing in software engineering is formal testing and verification regardless of platform and shrinking tools/components to be minimal as per UNIX philosophy. Celebrating more complexity and more trendiness is just cringy to me. If anything positive were to come from phrekin' AI bullshit, it should be to usefully augment software project management with testing and verification infrastructure.

  • I intensely disliked being force to relearn the init system, DNS resolution, system and application logging, and other aspects of system management, several years ago. It really pissed me off. But, I did what I had to and it's no longer such a big deal for me. But, there is still a level of vociferous internet rage toward systemd that I am struggling to understand.

    If systemd is so bad, then why are the experts(system developers, distro builders) supportive of it?

    If it's just one guy at Red Hat's bad idea, a

    • If it's just one guy at Red Hat's bad idea, as is often claimed, then why does Debian and Arch rely on it?

      We had discussions about this here at the time. You may feel free to locate and review them so we don't have to have them again. TL;DR: no clue about Arch, but Debian pushed the decision through with less consensus than usual to support the new GNOME, which depended on it, and which statistically no one was asking for.

    • I intensely disliked being force to relearn the init system, DNS resolution, system and application logging, and other aspects of system management, several years ago. It really pissed me off. But, I did what I had to and it's no longer such a big deal for me. But, there is still a level of vociferous internet rage toward systemd that I am struggling to understand.

      If systemd is so bad, then why are the experts(system developers, distro builders) supportive of it?

      If it's just one guy at Red Hat's bad idea, as is often claimed, then why does Debian and Arch rely on it?

      I feel like the experts know better than me as a user. Why are the experts wrong? Why are the distros that do not use systemd such tiny niche players?

      Oh - you didn't hear about how Linux was destroyed by systemd, and the only functioning distros remaining are free of the abomination?

      Me either.

      • Yeah I absolutely love the fact that my init system has a say about DNS servers and how logging happens. The journalctl system is dumb. Most of what it logs is useless dbus messages. I prefer good old syslog.

        • Yeah I absolutely love the fact that my init system has a say about DNS servers and how logging happens. The journalctl system is dumb. Most of what it logs is useless dbus messages. I prefer good old syslog.

          And the wonderful thing is that you have choices that don't use systemd. Or do you want everyone to use what you prefer? MacOS doesn't use it so maybe that would suit! 8^/ MacOS uses launchd. Anyhow, use the OS version that pisses you off the least.

          • Re: (Score:2)

            by ksw_92 ( 5249207 )

            Anyhow, use the OS version that pisses you off the least.

            Sigh...pulls out CP/M floppies...

            • Anyhow, use the OS version that pisses you off the least.

              Sigh...pulls out CP/M floppies...

              I salute you sir!

    • This gives some insight to the voting by the Debian team to adopt systemd. https://lwn.net/Articles/58531... [lwn.net]

      All I can say is that it's very telling that Poettering now works for Microsoft.

    • Also, it's a set of tools, that is more-or-less standardized at this point. In some circles (such as avionics) it's actually a godsend because systemd system extensions (sysext) is an implementation that replaces brittle bullshit that had to be built and maintained by each manufacturer to meet ARINC standards. Now we don't have situation with multiple implementations of the same concept, and every avionics manufacturer owning their own implementation, tooling, and proprietary transfer tools. Now, you jus

      • Oh, along those lines, it's well reported that Hyundai used systemd in recent models of their Tuscon braking system, Samsung used systemd in the Galaxy Note 7, that Toyota used systemd in their 2009-2011 accelerator systems. In addition, GM is rumored to be using system in their recent models of Cadillac, Chevy, and GMC; especially in the braking system.

        Systemd makes an explosion everywhere it is used. It keeps the old rust off the tires.

    • If systemd is so bad, then why are the experts(system developers, distro builders) supportive of it?

      Because it is a tool aimed at distro builders. It does the things they want. That doesn't mean it's good design, and it doesn't follow the Unix way.

      Lennart Poettering kissed distro builder's asses until they included his tool. Once he got it in, he did whatever he wanted.

    • I suspect the people who hate it don't have problems it solves.

      Maybe a very basic home laptop is fine with SysV today and they don't want to learn anything new.

      Personally I've been able to retire thousands of lines of scripts I'd written to handle complex things with many edge cases and ugly devops modules that are no longer needed with more recent releases.

      There's just no userland interface to many of the events it can respond to and it's not easy to write a new C++ daemon to handle each need that comes up

Slashdot Top Deals

"Why can't we ever attempt to solve a problem in this country without having a 'War' on it?" -- Rich Thomson, talk.politics.misc

Close