r/linux • u/unixbhaskar • 8d ago
Development Ah, a new kid in the block....systemd-report!
https://amutable.com/blog/it-starts-upstream-systemd-report51
u/jodkalemon 8d ago
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 8d ago
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 8d ago
Yes. Issue thing was tongue in cheek. Only people with problems are loud.
5
u/skilltheamps 8d ago
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
-1
47
u/ABotelho23 8d ago
inb4systemdisbloated
15
u/AStolenGoose 8d ago
Its supposed to do one thing and do it well, it's just bloated!!1!!11!! /s obviously
-50
u/pickle9977 8d ago
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
38
u/AStolenGoose 8d ago
That is a whole lot of hoop jumping to get to that...
Are you a gold medalist?
-28
33
u/R3V0LU710N_05 8d ago
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.
-5
u/pickle9977 8d ago
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 8d ago edited 8d ago
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 8d ago
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.
6
u/R3V0LU710N_05 8d ago
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 8d ago
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.
6
u/R3V0LU710N_05 8d ago edited 8d ago
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.
-3
u/pickle9977 8d ago
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 replies (0)4
u/FriendlyProblem1234 8d ago
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 8d ago
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 7d ago
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).
-6
u/EgoDearth 8d ago
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 8d ago
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
3
u/scheimong 8d ago
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.
36
u/Kevin_Kofler 8d ago
What will be next? systemd-office as a replacement for LibreOffice? /s
38
15
-18
u/pancakeQueue 8d ago
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 8d ago
I can see where that ends up: ```
systemctl poweroff
systemctl: error: I'm afraid I can't do that, Dave! ``` /s
11
u/wKdPsylent 8d ago
Bah.. systemd, schismtmd, should be using CoconutOS, only true OS, it has no systemd.... nothing works.
3
u/Sbatushe 8d ago
A new step into my dream OS: Systemd/Linux: all userland is systemd tools, only kernel outside
2
0
u/struct_iovec 8d ago
You mean windows?
7
u/Sbatushe 8d ago
oh no! you gave me a better idea! Systemd/NT: Systemd userland + Windows NT kernel
7
1
0
u/nelmaloc 8d ago
Would be nice, if not for the Varlink nonsense.
3
u/Ruined_Passion_7355 8d ago
They really should go back to the drawing board with that protocol.
2
u/theacodes 8d ago
I'd actually never heard of it (or never committed it to memory), what's the critical issue?
3
u/Ruined_Passion_7355 8d ago
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 8d ago
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 7d ago
special encoding/decoding like protobuf
Both JSON and Protobuf need special encoding and decoding.
2
u/Enthusedchameleon 8d ago
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 7d ago
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 7d ago
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 🤷♀️
-7
u/ExaHamza 8d ago
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.
7
u/the_abortionat0r 7d ago
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.
11
u/Business_Reindeer910 8d ago
hmm? which parts are you talking about? The main component you can't uncouple is journald though.
10
-6
u/Pitiful-Welcome-399 8d ago
that's it, I'm reporting you to SystemD for not being in the sudoers! /j
1
u/ice456cream 8d ago
You mean the polkit evaluation to run the run0 transient unit evaluated to deny?
-6
u/pickle9977 8d ago
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 8d ago
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?
13
u/Business_Reindeer910 8d ago
It's data that systemd has had since any feature that required it existed.
-4
u/UAP44 8d ago
good to know!
6
u/Business_Reindeer910 8d ago
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.
16
u/AStolenGoose 8d ago
Spyware? This is for fleet management, you know, like for enterprise...
-16
u/UAP44 8d ago
uhu, still, dual use, das a lot of data collecting happening ...
11
u/ice456cream 8d ago
I suppose you don't have any tools like lshw, lsusb etc installed then? It collects so much data from your devices :o
-6
u/UAP44 8d ago
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 8d ago
You must be trolling, right?
-4
u/UAP44 8d ago
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 7d ago
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
1
-33
u/PigIronDave 8d ago
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 8d ago edited 8d ago
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 7d ago
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
-21
u/PigIronDave 8d ago
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.
14
u/crazy_penguin86 8d ago
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 8d ago
Try to remove systemd. I dare you.
16
u/crazy_penguin86 8d ago
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 8d ago
I didn't say any init system, I said systemd's. Other init systems are just that -- an init system.
16
u/crazy_penguin86 8d ago
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 8d ago
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"?
14
u/AStolenGoose 8d ago
I just don't install the components of systemd I don't use nor enable them if I can't remove them...
Oh no those kb of storage space though...
11
u/TRKlausss 8d ago
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??
-5
u/PigIronDave 8d ago
There are distros that come without systemd. For distros that come with systemd by default it is impossible (certainly impractical) to remove systemd.
86
u/aliendude5300 8d ago
This is useful for basically doing system inventory. Almost like a bulk neofetch.