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.
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.
I don’t hate it now, though I did when it first came out, as it borked my system on several occasions. I’m still not a fan, but it works so eh.
One borkage was that the behavior of fstab changed, so if there was e.g. a USB drive in fstab which was not connected at startup, the system would refuse to boot without some (previously not required) flags in fstab. This is not a big deal for a personal laptop, but for my headless server, was a real pain. The systemd behavior is arguably the right one, but it broke systems in the process. Which is somewhat antithetical to, say, Linus Torvalds’ approach to kernel development (“do not break user space”).
It also changed the default behavior of halt — now, it changed it to the “correct” behavior, but again…it broke/adversely affected existing usage patterns, even if it was ultimately in the right.
In addition to all of this, binary logs are very un-UNIXy, and the monolithic/do-everything model feels more like Windows than *NIX.
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.
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.
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.
I don’t hate it now, though I did when it first came out, as it borked my system on several occasions. I’m still not a fan, but it works so eh.
One borkage was that the behavior of fstab changed, so if there was e.g. a USB drive in fstab which was not connected at startup, the system would refuse to boot without some (previously not required) flags in fstab. This is not a big deal for a personal laptop, but for my headless server, was a real pain. The systemd behavior is arguably the right one, but it broke systems in the process. Which is somewhat antithetical to, say, Linus Torvalds’ approach to kernel development (“do not break user space”).
It also changed the default behavior of
halt— now, it changed it to the “correct” behavior, but again…it broke/adversely affected existing usage patterns, even if it was ultimately in the right.In addition to all of this, binary logs are very un-UNIXy, and the monolithic/do-everything model feels more like Windows than *NIX.
Systemd came out over 10 years ago
“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.”.
I remember the clusterfuck that existed before systemd, so I love systemd.
deleted by creator
Systemd came out before some people were even born
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!
I always thought it was because it was Linux only and wasn’t usable on FreeBSD.