It’s also “infectious” software. The way systemd positions itself on the system, it can make it more difficult for software to be written in an agnostic way. This isn’t all software, and is often more of a complaint by lower level software, like desktop environments. https://catfox.life/2024/01/05/systemd-through-the-eyes-of-a-musl-distribution-maintainer/
This isn’t a terrible summary of some of the aspects of it.
Another aspect is that when it was first developed, the lead on the project was exceptionally hostile to anyone who didn’t immediately agree that systemd definitely should take over most of the system, often criticizing people who pointed out bugs or questionable design decisions as being afraid of change or relics of the past.
It’s more of a social reason, but if people feel like the developer of a tool they’re forced to use doesn’t even respect their concerns, they’re going to start rejecting the tool.
It’s that it also decided to take over log management, event management, networking, DNS resolution, etc, etc.
If it were just an init system that would be perfectly portable. People were able to write software that way with sysv for years.
It’s that in order to do certain low level tasks on a systemd system, you need to integrate with systemd, not just “be started by it”. Now if a distro wants that piece of software, it needs to use systemd, and other pieces of software that want to be on that distro need to implement integration with systemd.
A dependency isn’t infectious, but a dependency you can’t easily swap out is, particularly if it’s positioned near the base of a dependency tree.
Almost all of my software can run on x86 or arm without any issues beyond changing compiler targets.
It’s closer to how it’s tricky to port software between Mac and Linux, or Linux and BSD. Targeting one platform entails significant, potentially prohibitive, effort to support another, despite them all being ostensibly compatible unix like systems.
log management, event management, networking, DNS resolution
and this is a bad thing? the distro can choose to not use it, but because every systemd distro uses it, it’s a 1000x easier to implement it without needing to put a fuck tons of if-else’s for every distro
No, not everyone thinks it’s a bad thing. It is, however, infectious, which is a reason some people don’t like it.
Knowing why people dislike something isn’t the same as thinking it’s the worst thing ever, and liking something doesn’t mean you can’t acknowledge it’s defects.
I think it’s a net benefit, but that it would be better if they had limited the scope of the project a bit, rather than trying to put everything in the unit system.
and what’s the problem?, it’s not like everything is in the same binary or it’s a monstrosity that can’t be used without using every single feature, it’s a project that just has different programs under the same project name, because no one wanted todo theoe programs
That’s why I personally try very hard to only rely on POSIX stuff, even when it’s massively inconvenient. The only thing I haven’t gotten around to replacing yet is GNU make.
I think the init system is the best part of systemd. It is sooo easy to use. You don’t have to write the same complicated shell script for your software like everyone else. You just give systemd the path to your executable and that’s basically it. It does the rest and you don’t have to worry about PID files or forking the actual software. Systemd basically runs it like you did while developing it.
I think what people don’t like are all the other parts of systemd that seem to be tightly coupled. I don’t know if it is even possible to run just the systemd init without any other systemd package.
The last time I got angry at systemd was when resolvd did some DNS shit I did not approve of.
I may be wrong but I believe that all of the systemd programs are decoupled. You can run the systemd init system without any resolved or networkd. They just happen to be used by default on a lot of distros.
it doesn’t run a job it waits for your jobs to end. You can set the default want time. Its the same thing on windows that asks programs to close before shutting down. If a critical application got stuck systemd has nothing to do with it
I know what it is. But it literally says “A stop job is running” and since english is not my first language, I had no good idea how to better express the technicalities of it in a short sentence.
As for it having nothing to do with systemd:
I am dual booting arch and artix, because I am currently in the middle of transitioning. I have the exact same packages on both installs (+ some extra openrc packages on artix).
About 30% of the shutdowns on arch do the stop job thing. It happens randomly without any changes being done by me between the sessions.
0% of the shutdowns on artix take more than 5 seconds.
I know that I can configure it. But why is 90 seconds a default? It is utterly unreasonable. You cite windows doing it, but compare it instead to mac, which has extremely fast powerups and shutdowns.
And back to the technicalities, openrc doesn’t say “a stop job is running”, so who runs the stop job if not systemd?
The question you should be asking is what’s wrong with that job which is causing it to run for long enough that the timeout has to kill it.
Systemd isn’t the problem here, all it’s doing is making it easy to find out what process is slowing down your shutdown, and making sure it doesn’t stall forever
I will not debug 3rd party apps. I don’t even want to think about my OS nor ask any questions about it. I want to use a PC and do my job. That includes it shutting down asap when I need it to shut down asap.
systemd default - shutdown not always asap
openrc default - shutdown always asap
whatever the heck macs init system is - shutdown always asap
It may be not the “fault” of systemd, but neither does it do anything helpful to align itself with my needs.
Indeed, the Unix philosophy was do one thing and do it well. ls just list directory’s and files it’s not a network manager too. Systemd crams a lot of extra shit into an init.d/rc.
I still prefer the old system-v/openRC setup or BSD’s setup. It’s simple does 1 job and does it well. But I can work with systemd just fine in creating scripts these days and it does have some nice features like user startup scripts baked into it and podman integrates very nicely with it.
My understanding is that some people are die hards to the software philosophy of “do one thing really well”. systemd at the very least does many different things. These people would prefer to chain a bunch of smaller programs together to replicate the same functionality of systemd since every program in the chain fits the philosophy of “does one thing really well”.
Systemd breaks all three of though by being monolithic and binary. It actually makes you have to jump through more hoops to do things in certain cases. I understand it’s a mindset shift but it really starts making it feel more like Windows with how it works and the registry and event log.
I don’t see how systemd has anything like the Windows registry. At least its journals are leagues ahead of Windows event logs, I hate those things and the awful viewer they have.
People don’t like it because it’s declarative. It felt cool to be able to just put bash files into certain directories to have them executed on startup. That was elegant, in the sense of “everything’s a file”.
systemd is more of an api than a framework, so it’s a different design paradigm.
I hated systemd until I printed out the docs, for some coffee, and sat in a comfy chair to read them front to back. Then I loved it.
Mostly I hated it because I didn’t know how to do things with it.
Also, “journalctl” is kind of an ugly command. But really, who gives a fuck. It’s a well-designed system.
And if a person absolutely must execute their own arbitrary code they can just declare a command to execute their script file as the startup operation on a unit.
Developer cognition is the most expensive resource on any programming project. It is entirely rational to stick to tried and true ways of doing things. A developer’s mind is generally at capacity, and putting some of that capacity into learning new tricks comes at the cost of all the other things that developer can be doing.
And it’s not just a matter of time. Generally speaking, a developer can only do so much mental processing between sleep cycles.
That’s not to say it’s always bad to learn new things. In fact one has to in order to keep the system working in a changing world.
But throwing shade at developers who hesitate to learn new things is foolish. I’d recommend every developer do shamatha and vipassana meditation so that they can more accurately monitor the state of their own mental resources. Those mental resources are the most valuable and most expensive resources on the project.
Good that you’ve enjoyed it. But a fundamentally wrong thing about systemd is that it is actively harming the best thing about Linux – freedom. Some programs won’t work on a non-systemd distro because how tightly coupled and vendor non-agnostic anything that becomes dependent on might become at times. Of course it’s not as bad as glib(loat)c, but still if something can be done without any degradation of functionality via standard POSIX facilities, WHY either incur additional maintenance overhead for non-systemd implementations or punish people for their computing choices if there’s no one to maintain it?
Units and service files are confusing, and the documentation could be a lot better.
That said, when systemd came out the traditional init stack was largely abandoned. Thanks to systemd (and the hatred of it) there are now a couple of traditional-style init systems in active development.
systemd tries to unify a Wild West situation where everyone, their crazy uncle, and their shotgun-dual-wielding Grandma has a different set of boot-time scripts. Instead of custom 200-line shell scripts now you have a standard simple syntax that takes 5 minutes to learn.
Downside is now certain complicated stuff that was 1 line need multiple files worth of workarounds to work. Additionally, any custom scripts need to be rewritten as a systemd service (assuming you don’t use the compat mode).
People are angry that it’s not the same as before and they need to rewrite any custom tweaks they have. It’s like learning to drive manual for years, wonder why the heck there is a need for auto, then realizing nobody is producing manual cars anymore.
There is also the argument that it’s more complicated under the hood and harder to troubleshoot, particularly because of it’s inherent parallelism and dependency-tree design, whereas initv was inherently serial. It was much more straightforward to pick the order in which services started and shut down on an initv system.
For example, say I write a service and I want it to always be the first service stopped during a shutdown, and I want all other services to wait for it to stop before shutting down. That was trivial to do on an initv system, it’s basically impossible on systemd.
For those wondering, yes I did run into this situation. My solution was clobbering the shutdown, poweroff, and restart binaries with scripts earlier in path search that stop my service, verify that they’re stopped, and then hook back to systemd to do the power event.
I had numerous situations where systemd didn’t let me abort a hanging service startup during boot or stop during shutdown.
So what do I do now, systemd? Wait till infinity??
That never happened while using other init systems. Because they simply fail properly (“sorry I did my best to stop this, I needed a SIGKILL finally”). Or simply let me log in: “sorry, some services failed to start and now it’s a huge mess, but at least you can log in and fix it.”.
Someone please convince me why I should hate systemd because I still don’t understand why all the hate exists.
The idea as far as I can tell is that it’s responsible for too many things and gives a massive point of failure.
Man, wait until these people hear about the filesystem and kernel.
The very existence of a defined kernel is an insult to the Linux philosophy
The Linux kernel (the part that gives Linux the name) is antithetical to Linux philosophy? I could understand it being contrary to GNU philosophy
hurd “exists”
That’s GNU/Hurd thank you
yes mr stallman
Does it ? I thought it was never completed !
On the other hand, if you want a microkernel that does exist, there’s Mach. But I don’t think you can replace Linux with it 😆
It’s been two years away for the last 30 years.
Yeah, there’s a Debian implementation of GNU/hurd. Debian recommend you run it in a VM
I won’t bother. Sounds like hurd work.
Hurd is supposed to work with GNU mach afaik
It’s also “infectious” software. The way systemd positions itself on the system, it can make it more difficult for software to be written in an agnostic way. This isn’t all software, and is often more of a complaint by lower level software, like desktop environments.
https://catfox.life/2024/01/05/systemd-through-the-eyes-of-a-musl-distribution-maintainer/ This isn’t a terrible summary of some of the aspects of it.
Another aspect is that when it was first developed, the lead on the project was exceptionally hostile to anyone who didn’t immediately agree that systemd definitely should take over most of the system, often criticizing people who pointed out bugs or questionable design decisions as being afraid of change or relics of the past.
It’s more of a social reason, but if people feel like the developer of a tool they’re forced to use doesn’t even respect their concerns, they’re going to start rejecting the tool.
What do you expect from an init system? It’s like saying my cpu is infectious because my computer depends on it
It’s that it also decided to take over log management, event management, networking, DNS resolution, etc, etc.
If it were just an init system that would be perfectly portable. People were able to write software that way with sysv for years.
It’s that in order to do certain low level tasks on a systemd system, you need to integrate with systemd, not just “be started by it”. Now if a distro wants that piece of software, it needs to use systemd, and other pieces of software that want to be on that distro need to implement integration with systemd.
A dependency isn’t infectious, but a dependency you can’t easily swap out is, particularly if it’s positioned near the base of a dependency tree.
Almost all of my software can run on x86 or arm without any issues beyond changing compiler targets. It’s closer to how it’s tricky to port software between Mac and Linux, or Linux and BSD. Targeting one platform entails significant, potentially prohibitive, effort to support another, despite them all being ostensibly compatible unix like systems.
and this is a bad thing? the distro can choose to not use it, but because every systemd distro uses it, it’s a 1000x easier to implement it without needing to put a fuck tons of if-else’s for every distro
No, not everyone thinks it’s a bad thing. It is, however, infectious, which is a reason some people don’t like it.
Knowing why people dislike something isn’t the same as thinking it’s the worst thing ever, and liking something doesn’t mean you can’t acknowledge it’s defects.
I think it’s a net benefit, but that it would be better if they had limited the scope of the project a bit, rather than trying to put everything in the unit system.
and what’s the problem?, it’s not like everything is in the same binary or it’s a monstrosity that can’t be used without using every single feature, it’s a project that just has different programs under the same project name, because no one wanted todo theoe programs
That’s why I personally try very hard to only rely on POSIX stuff, even when it’s massively inconvenient. The only thing I haven’t gotten around to replacing yet is GNU make.
Bro I’m with you on this but the systemd bots will just keep arguing with and downvoting you. Don’t bother.
I think the init system is the best part of systemd. It is sooo easy to use. You don’t have to write the same complicated shell script for your software like everyone else. You just give systemd the path to your executable and that’s basically it. It does the rest and you don’t have to worry about PID files or forking the actual software. Systemd basically runs it like you did while developing it.
I think what people don’t like are all the other parts of systemd that seem to be tightly coupled. I don’t know if it is even possible to run just the systemd init without any other systemd package.
The last time I got angry at systemd was when resolvd did some DNS shit I did not approve of.
I may be wrong but I believe that all of the systemd programs are decoupled. You can run the systemd init system without any resolved or networkd. They just happen to be used by default on a lot of distros.
I expect it to not run a stop job for 90 seconds by default every time I want to quickly shut down my laptop. /s
it doesn’t run a job it waits for your jobs to end. You can set the default want time. Its the same thing on windows that asks programs to close before shutting down. If a critical application got stuck systemd has nothing to do with it
I know what it is. But it literally says “A stop job is running” and since english is not my first language, I had no good idea how to better express the technicalities of it in a short sentence.
As for it having nothing to do with systemd:
I am dual booting arch and artix, because I am currently in the middle of transitioning. I have the exact same packages on both installs (+ some extra openrc packages on artix).
About 30% of the shutdowns on arch do the stop job thing. It happens randomly without any changes being done by me between the sessions.
0% of the shutdowns on artix take more than 5 seconds.
I know that I can configure it. But why is 90 seconds a default? It is utterly unreasonable. You cite windows doing it, but compare it instead to mac, which has extremely fast powerups and shutdowns.
And back to the technicalities, openrc doesn’t say “a stop job is running”, so who runs the stop job if not systemd?
The question you should be asking is what’s wrong with that job which is causing it to run for long enough that the timeout has to kill it.
Systemd isn’t the problem here, all it’s doing is making it easy to find out what process is slowing down your shutdown, and making sure it doesn’t stall forever
I will not debug 3rd party apps. I don’t even want to think about my OS nor ask any questions about it. I want to use a PC and do my job. That includes it shutting down asap when I need it to shut down asap.
systemd default - shutdown not always asap
openrc default - shutdown always asap
whatever the heck macs init system is - shutdown always asap
It may be not the “fault” of systemd, but neither does it do anything helpful to align itself with my needs.
the develope receive a fuck ton of hate too, and he keep the project going, against every one unix-way haters
Well, I don’t give him too much credit for that given that it was his day job, not some passion project.
Most of the hate towards him was because he took an abrasive stance against anyone who disagreed with him, or pointed out bugs.
Indeed, the Unix philosophy was do one thing and do it well. ls just list directory’s and files it’s not a network manager too. Systemd crams a lot of extra shit into an init.d/rc.
I still prefer the old system-v/openRC setup or BSD’s setup. It’s simple does 1 job and does it well. But I can work with systemd just fine in creating scripts these days and it does have some nice features like user startup scripts baked into it and podman integrates very nicely with it.
It isn’t though, systemd is broken into smaller parts.
My understanding is that some people are die hards to the software philosophy of “do one thing really well”. systemd at the very least does many different things. These people would prefer to chain a bunch of smaller programs together to replicate the same functionality of systemd since every program in the chain fits the philosophy of “does one thing really well”.
For me it’s 3 things
Systemd breaks all three of though by being monolithic and binary. It actually makes you have to jump through more hoops to do things in certain cases. I understand it’s a mindset shift but it really starts making it feel more like Windows with how it works and the registry and event log.
I don’t see how systemd has anything like the Windows registry. At least its journals are leagues ahead of Windows event logs, I hate those things and the awful viewer they have.
systemd-bsod is incoming
You forgot: use as many dependencies as you need. For example, my init system does not use
xz-utils.People don’t like it because it’s declarative. It felt cool to be able to just put bash files into certain directories to have them executed on startup. That was elegant, in the sense of “everything’s a file”.
systemd is more of an api than a framework, so it’s a different design paradigm.
I hated systemd until I printed out the docs, for some coffee, and sat in a comfy chair to read them front to back. Then I loved it.
Mostly I hated it because I didn’t know how to do things with it.
Also, “journalctl” is kind of an ugly command. But really, who gives a fuck. It’s a well-designed system.
And if a person absolutely must execute their own arbitrary code they can just declare a command to execute their script file as the startup operation on a unit.
Your comment summarizes my entire programming career.
These steps:
Be taught that there’s a specific way to do something because the other ways have major issues
Find something that goes against that specific way and hate it
After a lot of familiarity, end up understanding it
Have a mix emotion of both loving it because it functions so well and hating it because it doesn’t align with the rules you’ve set up
Developer cognition is the most expensive resource on any programming project. It is entirely rational to stick to tried and true ways of doing things. A developer’s mind is generally at capacity, and putting some of that capacity into learning new tricks comes at the cost of all the other things that developer can be doing.
And it’s not just a matter of time. Generally speaking, a developer can only do so much mental processing between sleep cycles.
That’s not to say it’s always bad to learn new things. In fact one has to in order to keep the system working in a changing world.
But throwing shade at developers who hesitate to learn new things is foolish. I’d recommend every developer do shamatha and vipassana meditation so that they can more accurately monitor the state of their own mental resources. Those mental resources are the most valuable and most expensive resources on the project.
Good that you’ve enjoyed it. But a fundamentally wrong thing about systemd is that it is actively harming the best thing about Linux – freedom. Some programs won’t work on a non-systemd distro because how tightly coupled and vendor non-agnostic anything that becomes dependent on might become at times. Of course it’s not as bad as glib(loat)c, but still if something can be done without any degradation of functionality via standard POSIX facilities, WHY either incur additional maintenance overhead for non-systemd implementations or punish people for their computing choices if there’s no one to maintain it?
It’s different from what the init system was like in the 80’s.
I don’t hate systemd. However:
Units and service files are confusing, and the documentation could be a lot better.
That said, when systemd came out the traditional init stack was largely abandoned. Thanks to systemd (and the hatred of it) there are now a couple of traditional-style init systems in active development.
“we would never use such a sucky piece of bloatware near anywhere we cared about security.”
Damn systemd is LGPL and not GPL? Another reason to hate lol
Because
systemd tries to unify a Wild West situation where everyone, their crazy uncle, and their shotgun-dual-wielding Grandma has a different set of boot-time scripts. Instead of custom 200-line shell scripts now you have a standard simple syntax that takes 5 minutes to learn.
Downside is now certain complicated stuff that was 1 line need multiple files worth of workarounds to work. Additionally, any custom scripts need to be rewritten as a systemd service (assuming you don’t use the compat mode).
People are angry that it’s not the same as before and they need to rewrite any custom tweaks they have. It’s like learning to drive manual for years, wonder why the heck there is a need for auto, then realizing nobody is producing manual cars anymore.
There is also the argument that it’s more complicated under the hood and harder to troubleshoot, particularly because of it’s inherent parallelism and dependency-tree design, whereas initv was inherently serial. It was much more straightforward to pick the order in which services started and shut down on an initv system.
For example, say I write a service and I want it to always be the first service stopped during a shutdown, and I want all other services to wait for it to stop before shutting down. That was trivial to do on an initv system, it’s basically impossible on systemd.
For those wondering, yes I did run into this situation. My solution was clobbering the shutdown, poweroff, and restart binaries with scripts earlier in path search that stop my service, verify that they’re stopped, and then hook back to systemd to do the power event.
I had numerous situations where systemd didn’t let me abort a hanging service startup during boot or stop during shutdown.
So what do I do now, systemd? Wait till infinity??
That never happened while using other init systems. Because they simply fail properly (“sorry I did my best to stop this, I needed a SIGKILL finally”). Or simply let me log in: “sorry, some services failed to start and now it’s a huge mess, but at least you can log in and fix it.”.
deleted by creator
Systemd came out before some people were even born
I always thought it was because it was Linux only and wasn’t usable on FreeBSD.
Ever seen a log file be a binary file, not text?
Ever seen an init system that was also cron?
Do you want to be forced to use a specific init system in order to use udev?
Then SystemD is for you!