It does things in a way that it’s hard to use other init without banning Systemd completely from your repo. And because it has feature and scope creep and causes dependencies to it everywhere, that does not happen once you’re on it, too much work. Which most distros are, because at it’s time it was either Systemd or SysV scripts.
Roughly speaking, it is because it does not follow the Unix philosophy and proposes to do several tasks making the code very complex and therefore more susceptible to bugs.
As opposed to which other tools that respect Unix philosophy. Philosophy which I might add is severely outdated. That could have been a thing when you have simple command line interfaces but pretty much every application today violates that philosophy and nothing of value was lost.
The joke being “systemd does everything poorly”. First heard someone say this about X and Wayland. People were saying Wayland violated Unix philosophy and the speaker said “name one thing X does well” lol.
The linux kernel unfortunately does not follow unix philosophy.
It would be better in various ways if the linux kernel used a micro kernel architecture following the unix philosophy, something Torwalds acknowledged in the past.
Philosophical ideas being lost does not mean they’re outdated.
How old in the past did Linus acknowledge it? my source says he dislikes/disliked microkernel, it dates to 2001 ,if you have a more recent source proving that he no longer thinks it I’ll look at it
Unfortunately I can’t remember the timestamp, but it’s right around when he starts speaking about when the MINIX creator bashed him, IIRC (not to bash on you, but this implies the point you’re making, that Linux shouldn’t have a monolithic kernel is 30 years old,)
I simply don’t care. I am in a position lucky enough that I can trust distro maintainers, without the need to care about the details, as long as my system behaves as I expect, satisfying my requirements of reliability and stability
Same, I interact with it so rarely that it could work with fairies and unicorns for all the difference it makes to me.
I don’t know what people do with their machines that they keep poking at the damn thing anyway. For the most part I stay out of systemd’s way, it stays out of mine and we’re both happy.
I’d argue systemd has bad, borderline incorrect design. I didn’t like SysV because it caused inconsistencies and hard to understand processes. systemd fixed the inconsistencies but the rest is sort of hacked together bullshit that developers play wackamole with. That hackery is the reason it can’t be used in Docker for example. It has a complicated parser for a language that’s basically a DSL that doesn’t really solve the problem of complexity for the user. It requires a whole slew of random non-sense to work and it feels like stars have to align perfectly for things to function. It encourages bad behavior like making everything socket activated for literally no reason.
Compared to SysV, I’ll take systemd. I don’t find it ideal at all though. It’s serviceable… much like how Windows services are serviceable. S6 is I think what the ideal init would look like. I’m more impressed with it’s execline and utilities suite but that’s another story.
The only thing I think systemd did right is handling cgroups.
Some docker containers come with systemd. Of note, the RedHat ubi8-init and ubi9-init containers. Not that they’re wonderful and perfectly open, but that it is possible and available.
Right, but is it just residual? This topic is interesting but mostly in a historical way now. Of course if you want drama, there’s always drama to be found.
I underatand, but I just don’t care. Give me a functioning linux desktop and I will also run your garbage proprietary nvidia software. The alternative is windows, so I have to take what I can get.
I don’t have anything against systemd that is until I tried void linux for the first time. The working of runit seemed very simple and efficient compared to the complexity of systemd.
I still don’t hate systemd, but I just wish it was simpler.
And most importantly you don’t have to deal with things like environment variables or other session state leaking into your startup scripts as you had with all the init script based init systems.
I seriously do not miss services that worked when starting them from an ssh session but did not work on startup (because e.g. PATH had fewer directories).
I feel like, at this point, it has more than proved itself as a general purpose desktop scheduler. But there are situations where you would want something different but a lot of software depends on it anyway.
I also kinda don’t understand the hate toward the project itself, other than hearing some of the technical guidance on it has been a bit arrogant in the past or something. Sounds like sily open source drama to me honestly.
For a desktop it’s suitable for 99% of what you’d want to do. Might not be the best tool for large servers or something (I really don’t know) but I’m sure all that depends on use case.
Linux power-users hate it when a tool tries to become a platform.
It breaks the principle of single responsibility and becomes a threat to the evolution of alternatives.
It’s pros and cons. Having a platform is better because everyone works together on a single effort. But it also becomes a risk because now everyone depends on a single thing that does too much.
It’s a pretty bridge, they’d say, but be careful you don’t look at the supports. It was built using bad techniques, bad procedures, no coordination and no inspection.
Just cross your fingers as you drive over and hope it doesn’t blow up because of its flawed construction.
I find it’s a great way to cross the river, today.
In a quiet village, two monks stood on the bank of a wide river. The older monk asked the younger, “How do you cross this river?”
The younger monk pointed at the grand bridge a short distance away, “Through that bridge, master.”
The older monk shook his head, "You see a bridge, yet the river flows beneath. In seeking to cross, you are already on the other side. Tell me, where is the true bridge?
At that moment, the young monk became enlightened, supposedly, because that’s how most zen koans end.
Do scripts in /usr/lib/systemd/system-sleep/ not block? I’ve never had one fail to complete before suspend. I had to use one last year to dump debug stats before and after sleep while we were helping debug Cezanne sleep issues.
I guess not because in my attempts to get this working I did put a script there. Does * expansion not work in these scripts? Mind sharing your script if you still have one? I have 3 tabs open to learn systemd when I have time, I did watch a video so far :)
SysV was just intuitive for me and my knowledge. There was just one directory with all the startup scripts in it. And they were run in their alphanumerical ordner. Just that simple. If I wanted to change the order in which the scripts started, I just had to rename the file. You don’t want a script to run at all? Just remove it.
I assume, systemd has many advantages for a knowledged user. But for me, it still is just a hassle.
Never really, because they don’t contain logic. You craft a command line and stuff works.
The problem with sysv was that almost all of the logic lived in the scripts. They all worked slightly different and all the duplication introduced bugs. Systemd has APIs that take over all the duplicated stuff and implement it once. Bugs have to get fixed once only.
I just debuged it like every other of my scripts that failed. Again, I didn’t need any special knowledge of the init process, just general (and for me: very limited) knowledge.
The answer to your other questions: I don’t thing I ever did that.
I think the main difference is that one option is easier for the end user to occasionally take a look at what’s happening and debug without needing much context or previous knowledge, while the other is much easier for the actual maintainer to actually keep the thing working properly and predictably, as well as supporting every sort of edge case for their users in advance.
An exaggerated stupid analogy: “back in the day we had horse carts and if it wasn’t moving we could just look at the tires to check if they were stuck in a hole or blocked by some rock, but now with cars there are so many things going on that the tires depend on some internal parts that are connected to an engine that depend on some fuel and there are so many elements that can go wrong in-between that often if the car is not moving it requires someone with very specific expertise to diagnose”
(analogy is extra stupid because the horse cart is by nature inferior to the car and this is not the case with the init files and systemd, analogy would work better if the cart still had engines and fuel but that operated with the same simplify as the carts tires).
Add comment