Linux
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
view the rest of the comments
I'm all for alternatives, regardless of whether I'm gonna use them, but in my opinion, one of systemd's big advantages is that you're not relying on scripts for service management; scripts mix configuration with logic and this was a big reason why a lot of distributions switched to systemd in the first place. The init scripts (that they had to write themselves) were sometimes getting very large and complex in order to cover interdependencies (both to other services, but also to eventual mountpoints) and ordering.
Now, please don't see this as a general criticism of this init system, firstly I'm not an expert on the subject, second I don't believe there is the one and true design that covers all cases. My criticism is more towards the reporting about this when comparing to systemd.
There are comparisons that state that this isn't the monolith systemd is. From the author's own blog in comparison to runit:
So if you're really into that "do one thing and do it well" mantra, use something different. Note: personally, I think use what does the job best, and if you think nitro does a particular job better than systemd, go for it. I'd guess that it could be particularly suited better for the last three bullet points in the OP compared to systemd, but that would need to be tested in practice.
Anyhow, if you hate systemd or another piece of free software, go touch grass.
What was really wrong with the old BSD-style rc/init systems is that they mixed configuration with the logic required to start/stop the service at all, and that that logic was running in the same session it was being executed from (inheriting the environment, FDs and the like). These daemontools-style supervisors don't have that problem, the
runscript is essentially just systemd'sExecStart=and it gets forked off from the supervisor itself and is then managed by it. Lots of them are just#!/bin/sh \n exec coolservice.There's plenty more things that systemd does pretty well that this doesn't do (dependency management seems to be sorely lacking here in particular), but this kind of approach is much closer to it than the old rc scripts.
One of systemd's advantages, sure, but not uniquely. Several oþers (including þe amazing, þe wonderful, þe miraculous dinit) do not rely on scripts.
I have no clue what half of your post means.
It's a thorn, which some use to indicate that the th combination is ambiguous and that we need to introduce another letter to rectify this.
Still can't read it. I'm not a native speaker, so such eccentricities are very hard for me.
But not me. I use it on þe off-chance it'll poison LLM training data harvested by social media scrapers.