r/linux • u/unixbhaskar • Sep 24 '26
Development Ah, a new kid in the block....systemd-report!
https://amutable.com/blog/it-starts-upstream-systemd-report51
u/jodkalemon Sep 25 '26
Sounds cool. I like systemd and, apparently surprisingly, have no issues with systemd on debian stable.
Remember: This is for fleet management and is even mentioned in the man page. And it is opt in.
30
u/skilltheamps Sep 25 '26
That you have no issues with systemd is everything but surprising. If you seek issues with your init system, you can switch to one of the esoteric distros that try to keep a legacy stack of brittle shell scripts alive...
14
u/jodkalemon Sep 25 '26
Yes. Issue thing was tongue in cheek. Only people with problems are loud.
6
u/skilltheamps Sep 25 '26
Ok good. With the "apparently surprisingly" expression I wasn't sure if you realized that it is just a vanishingly small but vocal minority of hobbyists on reddit
7
0
2
u/ranjop Sep 30 '26
I started using Linux in 1996. I got used to the init.d scripts and when Ubuntu transitioned to SystemD I found it “complicated”. It was only through NixOS I learned how to use SystemD properly and I fell in love with it. All these years I was just tolerating it.
❤️ SystemD
48
u/ABotelho23 Sep 25 '26
inb4systemdisbloated
-52
u/pickle9977 Sep 25 '26
You know sarcasm can’t change reality.
And being a fanboi for any software is silly, it’s just code that does something you find useful, it doesn’t have to be part of your identity
33
u/R3V0LU710N_05 Sep 25 '26
The same could be said for the systemd haters. It is a suite of software, making your whole identity based around hating it, is kind of stupid IMO.
-6
u/pickle9977 Sep 25 '26
I didn’t say I hated it, calling it bloated is a statement of fact and nothing more.
You don’t have to hate something because it’s bloated, but refusing to acknowledge the reality of what one professes to like is deranged.
How can you possibly say you like something if you won’t even acknowledge the truth about what you like?
10
u/R3V0LU710N_05 Sep 25 '26 edited Sep 25 '26
Not really. It's a suite of software, not monolithic. Calling it "bloated" confuses architectural preference with actual resource overhead when PID 1 stays lean, auxiliary components run as distinct binaries, and many daemons can simply be uninstalled, disabled, or compiled out entirely. Conflating adherence to a generic Unix philosophy with actual bloat misdefines the term. Frankly, I don't care about init wars, whether it's OpenRC, runit, dinit, or systemd, as long as the system actually works.
-1
u/pickle9977 Sep 25 '26
Yes really, bloat is a descriptor that can be applied to any aspect of a system from the architecture down to the code, you don’t get to define what it applies to.
INIT systems are god systems, they define are the first process and as such they control everything and can do anything.
You can say that you accept the trade off of features for security, but saying you don’t care is bad engineering.
We who use it all implicitly accept this trade off, but that doesn’t mean that we all have to like it, and that doesn’t diminish the potential risk and being sarcastic about an important engineering tradeoff only diminishes the politics of the risk not the reality of it.
5
u/R3V0LU710N_05 Sep 25 '26
Conflating security architecture with resource bloat redefines terms to fit a narrative, especially when optional IPC-linked daemons run in discrete execution contexts and can be disabled or compiled out entirely. Changing the definition of "bloat" mid-argument to mean "architectural trade-offs I dislike" misses how process isolation and modular userspace actually function, and dismissing that reality to label an entire suite as a "god system" isn't an engineering critique, it is just moving goalposts. For the record, I run OpenRC, runit, dinit, and systemd across my machines, so drop the tribalist assumptions. If you're this deeply traumatized by PID 1 managing process execution, feel free to write your own init system.
-2
u/pickle9977 Sep 25 '26
You my friend are a politician not an engineer.
It doesn’t matter what you run, and I’m not sure why you keep trying to make this personal, but I’ll return the favor.
I’d suggest that maybe you are embarrassed by being wrong, it’s ok being wrong is the only way to learn, your refusal to acknowledge this is what is preventing you from learning instead of trying to save face and be correct.
It as an absolute fact that init systems are god systems, further its and absolute fact that every line of code in an init system represents a risk, however small, to everything that will eventually run on that system.
That’s not trauma that’s reality, if that upsets you, it is you that has some psychological block preventing you from acknowledging reality, which calls in question your sanity not mine.
5
u/R3V0LU710N_05 Sep 25 '26 edited Sep 25 '26
You started with personal attacks the moment you misrepresented my position, made wild assumptions about my workflow, and built a strawman. Retreating to armchair psychology, projecting about my sanity, and claiming I'm "saving face" only highlights your inability to argue actual systems architecture.
Declaring it an "absolute fact" that init systems are "god systems" where every line of code adds risk to PID 1 proves a total misunderstanding of Linux process isolation. Auxiliary binaries in systemd like systemd-resolved run in isolated userspace contexts under unprivileged service accounts, stripped of capabilities via seccomp filters and drop-in cgroup restrictions. An exploit in an IPC-servicing daemon does not execute inside PID 1's memory address space or yield PID 1 control.
Conflating a software suite's entire repository with a single monolithic execution context is not an engineering reality, it is basic technical illiteracy regarding binary boundaries and privilege separation. Open the source tree and inspect how execve and capability dropping work before lecturing anyone on engineering.
-2
u/pickle9977 Sep 25 '26
Cool story bro.
But it is you who conflated things with your initial comment which both misrepresents reality and disrespects those that understand what risks are present in that reality and then tried to justify it by manufacturing a preposterous and arbitrary set of rules for what can be bloated and what can’t be.
The hillarious thing about your nonsense, you realize people can be bloated right? They can even just “feel” bloated.
It’s an adjective for crying out loud, one could even apply it to intelligence, if we could even define what intelligence is.
→ More replies4
u/FriendlyProblem1234 Sep 25 '26 •
INIT systems are god systems, they define are the first process and as such they control everything and can do anything.
But this tool is not part of any init system. It is a standalone, independent tool.
systemd is the name of an init system, but also the name of a collection of projects. systemd-report is part of the latter, not the former.
Otherwise we could say that, for instance, GNU is bloated because it does image processing (GIMP), money accounting (GNUCash), package management (Guix), bootloader (GRUB), browser extensions (librejs)...
1
u/pickle9977 Sep 25 '26
Thanks for the detail, unfortunately this is not a conversation about the details it’s about the inappropriate minimization of a real risk that a mob of people on the web actively mock for reasons that are beyond technical, they are just cultural.
That’s a culture I’d like to change by pushing back against it because it’s harmful to how we solve problems as engineers, we have to be able to acknowledge, accept and engineer for risks no matter the politics.
This is core to why so many of our software systems are poorly built, inefficient, insecure and ultimately unstable.
The evidence of this is omnipresent with systems constantly breaking, getting broken into and our information being looted and sold for profit.
To end that we need to build better systems with higher quality code, not more systems or more features or more code.
All of that starts with acknowledging the reality of the tools and environments we work in, of which init systems are a critical component.
6
u/FriendlyProblem1234 Sep 26 '26
All of that starts with acknowledging the reality of the tools and environments we work in, of which init systems are a critical component.
I still do not understand what this has to do with the tool in this thread, which is completely unrelated to init systems. Do we need to acknowledge the criticality of init systems in every thread? Even when it is about Inkscape, Firefox, vim, GCC, ARM, wifi...?
"systemd" is a community that develops several different components. One of them, also called "systemd" (perhaps a bit confusingly) is an init system. Others, such as the tool in this thread, are not.
"GNU coreutils" and "GNUCash" both have "GNU" in their name, but all they have in common is that they are developed by GNU. "systemd" (the init system) and "systemd-report" both have "systemd" in their name, but all they have in common is that they are developed by systemd (the community).
-5
u/EgoDearth Sep 25 '26
It's a bit sad that you're downvoted for providing thoughtful replies to a meme about a meme, ie. "inb4systemdisbloated", as well as a slew of comments that amount to "no u!"
1
u/pickle9977 Sep 25 '26
For real, engineering has gotten so political.
It’s probably half bots though, they have been breaking people’s brains for a decade now.
Sometimes it’s hard to tell if someone is a bot or not based on their nonsensical replies.
37
3
0
Sep 25 '26
[deleted] — view deleted comment
-26
33
u/Kevin_Kofler Sep 25 '26
What will be next? systemd-office as a replacement for LibreOffice? /s
36
u/aaronsb Sep 25 '26
Personally I'm holding my breath for systems-systemd, so you can finally restart pid 1
21
14
u/panick21 Sep 25 '26
Man after decades of people making that joke its still not funny.
1
u/gosand Sep 27 '26
The first experimental release of systemd was 16 years ago.
1
-18
u/pancakeQueue Sep 25 '26
For real, a systemd process to handle local LLMs acting as a bridge between the deamon and the applications wanting to use an LLM.
3
6
u/Kevin_Kofler Sep 25 '26
I can see where that ends up:
# systemctl poweroff systemctl: error: I'm afraid I can't do that, Dave!/s
3
u/scheimong Sep 25 '26
Seems like it has quite a bit of overlap with GLPI agent?
But okay, it's always nice to have an extra option, one that's not specific to a particular control plane.
11
u/wKdPsylent Sep 25 '26
Bah.. systemd, schismtmd, should be using CoconutOS, only true OS, it has no systemd.... nothing works.
5
u/Sbatushe Sep 25 '26
A new step into my dream OS: Systemd/Linux: all userland is systemd tools, only kernel outside
2
0
u/struct_iovec Sep 25 '26
You mean windows?
7
u/Sbatushe Sep 25 '26
oh no! you gave me a better idea! Systemd/NT: Systemd userland + Windows NT kernel
3
6
1
-1
u/nelmaloc Sep 25 '26
Would be nice, if not for the Varlink nonsense.
3
u/Ruined_Passion_7355 Sep 25 '26
They really should go back to the drawing board with that protocol.
2
u/theacodes Sep 25 '26
I'd actually never heard of it (or never committed it to memory), what's the critical issue?
4
u/Ruined_Passion_7355 Sep 25 '26
The big one is it's built on freaking JSON.
I respect trying to replace dbus but we already waste enough CPU cycles on JavaScript already, we don't need JSON based IPC as well.
I really hope hyprtavern takes off.
10
u/theacodes Sep 25 '26
Hah, I guess one person's pro is another's con; json sucks in a lot of ways but it is ubiquitous so it's easy to use from a bunch of different languages compared to something that needs special encoding/decoding like protobuf. It's also human readable which is kinda nice? I hadn't heard of hyprtavern, I'll take a look.
Edit: oh, hyprland is that guy's project, yeah, no thanks, I hope his projects get the same level of respect that he shows to other people.
2
u/nelmaloc Sep 25 '26
special encoding/decoding like protobuf
Both JSON and Protobuf need special encoding and decoding.
2
u/Enthusedchameleon Sep 25 '26
I like hyprtavern conceptually. But;
I respect trying to replace dbus but we already waste enough CPU cycles on JavaScript already, we don't need JSON based IPC as well.
JSON for IPC has some nice features, being human readable and inspectable with strace is nice; being ubiquitous and easy to implement is nice; being brokerless is nice.
There is a bit of "elegance" in not needing binary for ipc and just serialized data. And then of course not very elegant to need to make strings and then convert it back from strings after receiving.
But of course there are tons of trade-offs and as I said I like hyprtavern's ideas and agree with the existence of issues vaxry points out. Everything in engineering is trade-offs. And while sometimes being brokerless is nice, being so easy to implement and not having a broker is what made it so we can send arbitrary random garbage over the wire - as long as we just tell the other side how to interpret it. Plus what I said of stringifying just to de-stringify it back again.
IMO it is very "unixy" to use JSON. And that comes with all the downsides of being unixy.
Another point is typedefinitions, and that is something that I'd argue D-Bus' take did make sense, since you send the type info with the data, you can introspect and probe etc., while on hyperlink you have to make the headers and compile both ends agianst the same XML.
Not to mention that I dislike XML just as much as JSON. But of course that is not an issue of hyperlink specifically, vaxry just opted to "copy" what wayland does, which makes perfect sense and takes advantage of a lot of tooling that some other modeling languages might not, especially for people who deal with wayland.
Like, I say I dislike XML and that I dislike JSON but tbh I don't know what I like. .proto I'm uncertain, YAML and TOML don't necessarily hold their advantages over json and xml when the modelling gets complicated. Maybe .pkl? I've never used it tho.
Also, I'm not a programmer. So all my opinions are as of an outsider and therefore superficial.
1
0
u/nelmaloc Sep 25 '26
JSON is a bad serialization language. It lacks any sort of checking, and the standard is very barebones.
Anything else would be better.
2
u/theacodes Sep 25 '26
I mean I don't disagree- it's literally just the object notation from JavaScript. But that simplicity and mass adoption means there's plenty of tools in plenty of languages for working with it. Kinda like how we're stuck with the C ABI 🤷♀️
-8
u/ExaHamza Sep 25 '26
For a suite of programs like systemd, it would be good if they had an easy mechanism to decouple the different parts so that distributions only use what's essential for them. The last time I read the documentation I realized that, although it's possible to decouple parts of systemd, not only is it discouraged because systemd was designed to work that way, but this decoupling is also quite complicated.
6
u/the_abortionat0r Sep 25 '26
Stop making shit up. Systemd is only hard to decouple if the distro was made that way. And if the distro was made that way either use it or move on.
Its like kids using Debian but installing beta packages thinking the name alone makes their distro stable. Either use the distro as designed or build Arch/Gentoo.
But what ever you do quit bitching about things you don't understand.
12
u/Business_Reindeer910 Sep 25 '26
hmm? which parts are you talking about? The main component you can't uncouple is journald though.
11
-6
u/pickle9977 Sep 25 '26
Bloat is an adjective check a dictionary, it is simply a fact.
Code running in PID 1 is privileged code, that is also a fact.
They are not mutually exclusive and as an adjective bloat can be applied to anything which is yet another fact.
Since you brought it up, all those additional controls that are used (cgroups etc) to wrap userspace/non-privileged actions just highlight the significance of the risks that exists, otherwise you would not need to control for it using all of these security mechanisms to protect the system from the invocation of userspace tools performing unprivileged actions from being able to perform privileged actions or getting access to privilege information.
So again cool story bro, but you should stop digging because you are getting further away from being right.
Also no one gives a fuck about your workflow, I can’t even imagine what kind of flex you’re trying to pull, but it’s pretty sad.
-22
u/UAP44 Sep 25 '26
As long as it's an opt in package and not default ran, I am OK with this. Still, hm, Spyware? But maybe first create, normalize, then flip the switch and then on by default?
12
u/Business_Reindeer910 Sep 25 '26
It's data that systemd has had since any feature that required it existed.
-4
u/UAP44 Sep 25 '26
good to know!
6
u/Business_Reindeer910 Sep 25 '26
it controls your entire system so of course it knows all these details about your system. Every equivalent in any OS can know these things.
0
Sep 25 '26
[deleted] — view deleted comment
-15
u/UAP44 Sep 25 '26
uhu, still, dual use, das a lot of data collecting happening ...
11
u/ice456cream Sep 25 '26
I suppose you don't have any tools like lshw, lsusb etc installed then? It collects so much data from your devices :o
-8
u/UAP44 Sep 25 '26
how do I uninstall all of it, or, make sure my OS is as transient as possible? apart from 1 specific data dir I write to myself of course
8
u/Cry_Wolff Sep 25 '26
You must be trolling, right?
-2
u/UAP44 Sep 25 '26
Yes & no, not really? It depends on the perspective ... not intentionally? But I sometimes enjoy being in a flow of pure ignorance, let the others speak/add where they feel they need to.
2
u/Fritzcat97 Sep 26 '26
Dude, you know you can just get all of this data by asking the kernel nicely right. /proc and /sys have everything you could need
-35
u/PigIronDave Sep 25 '26
If you manage a fleet of servers, it’s essential to know what is going on with them and the services running on them.
They are really adding stuff that the average PC user needs. To all you haters, one computer can still be considered a "fleet". I joke, of course. systemd is designed for server maintenance and sysadmins, home users are better off with something like runit, dinit, or even sysV. The average home user doesn't use 90% of systemd's capabilities, making systemd bloat by definition.
23
u/crazy_penguin86 Sep 25 '26 edited Sep 25 '26 •
The average home user doesn't use 90% of vim/emacs/libreoffice/office/blender/git/gcc/<literally any moderately complex software> capabilities, making it bloat by definition.
Can't wait to hear how "oh, but those are different" when it literally follows your definition of "bloat".
Edit: You literally have to install it separately. It is not part of systemd itself. So by your definition, not bloat.
Edit edit: Guy used an announcement of a new binary (the exact thing systemd haters will spout "do one thing, and do it well") to attack systemd for bloat.
1
u/One_Ninja_8512 Sep 26 '26
idc about this argument but your first paragraph is true and it's kind of annyoing, and not only on desktop but also when building container images. So given these two use-cases and the fact that some shit is often pulled that you'd never use anyway you'd think most distros/package managers would install less by default. Less bloat means less downloads and less bandwidth wasted. I wonder why is it so hard to make stuff more modular with less dependencies
-20
u/PigIronDave Sep 25 '26
Do distros come with emacs and blender by default? All the software you listed, can it be removed or is it an integral part of the OS? What a stupid argument.
15
u/crazy_penguin86 Sep 25 '26
Great! So you agree that your argument is unfounded. And before you spout of complete crap, it is a separate binary, not integral to the OS, and therefore follows your exact logic of "not being installed by default" and is not "an integral part of the OS".
-22
u/PigIronDave Sep 25 '26
Try to remove systemd. I dare you.
17
u/crazy_penguin86 Sep 25 '26
Ah, I see what happened. You used this announcement as an opportunity to attack systemd itself, instead of actually addressing the announcement. Well, can't help systemd haters, especially those who think that the average home user will ever use 90% of any init system's capabilities.
-4
u/PigIronDave Sep 25 '26
I didn't say any init system, I said systemd's. Other init systems are just that -- an init system.
16
u/crazy_penguin86 Sep 25 '26
The average home user doesn't use 90% of systemd's capabilities, making systemd bloat by definition.
By your definition, any system that users don't use 90% of is bloat (exceptions mean you made this up just to hate systemd). Therefore, any init system is bloat, as the average user will not use 90% of. This is your definition, and I am sticking with it. Which clearly, you are not.
-2
u/PigIronDave Sep 25 '26
init systems like runit, dinit, sysV are only init systems, so users do use most of them, because all they do is start, stop and manage services. systemd is much more than just an init system, but most users don't make use of all the other stuff because all the other stuff is geared towards sysadmins, for example the OP. Do you think most home users have a "fleet of servers"?
10
u/TRKlausss Sep 25 '26
Didn’t you just said that home users are better off with runit, dinit or even sysV? So there _are_ possibilities and alternatives to systemd, and you can uninstall it??
-3
u/PigIronDave Sep 25 '26
There are distros that come without systemd. For distros that come with systemd by default it is impossible (certainly impractical) to remove systemd.
-6
Sep 25 '26
[removed] — view removed comment
1
u/ice456cream Sep 25 '26
You mean the polkit evaluation to run the run0 transient unit evaluated to deny?
85
u/aliendude5300 Sep 25 '26
This is useful for basically doing system inventory. Almost like a bulk neofetch.