this post was submitted on 19 Apr 2024
886 points (98.8% liked)
linuxmemes
20473 readers
873 users here now
I use Arch btw
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules
- Follow the site-wide rules and code of conduct
- Be civil
- Post Linux-related content
- No recent reposts
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
In some ways I think the filesystem is philosophically the exact opposite of systemd
I can boot my system with an ext4 root, with a btrfs /home...or vice versa. Or add some ZFS, or whatever. The filesystem is (with the exception of some special backup schemes) largely independent of the rest of the system, despite being of core importance.
On the other hand, I can't change my init system (i.e., systemd) without serious, serious work.
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.
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.
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
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.
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
haltnow, 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.
"we would never use such a sucky piece of bloatware near anywhere we cared about security."
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 remember the clusterfuck that existed before systemd, so I love systemd.
Systemd came out before some people were even born