Back when systemd was a hot topic I jumped on the bandwagon of using systemd-less distros just because people were telling me how bad it was. To this day I still use openrc but the reality is that systemd works very well and is easy to understand and use. The average user gains no benefit to using another init besides having a better understanding of how the system works.
Well and a faster boot time but it’s definitely a learning curve and not really worth it unless you want to try a Distro that ships something else by default (E.g. Alpine).
I never had a fast NVME SSD so my devices boot significantly slower than yours but unless you are actually at the point of instant booting it’s about half the boot time for me. I only use OpenRC on my Pinephone because it’s the default for PostmarketOS (a Alpine based OS for mobile phones) and never found a good enough reason to use it on my actual computer but it’s quite a bit faster and also quite a bit less convinient so all in all probably not worth it but still impressive to watch!
I am on an NVMe drive, however most of my boot time actually comes from the POST process so even if I were to switch to an OpenRC (or runit / another init system), it wouldn’t really have any meaningful impact on my system’s boot time unfortunately.
<span style="color:#323232;">❯ systemd-analyze time
</span><span style="color:#323232;">Startup finished in 17.412s (firmware) + 2.684s (loader) + 3.587s (kernel) + 2.134s (initrd) + 9.244s (userspace) = 35.063s
</span><span style="color:#323232;">graphical.target reached after 9.208s in userspace.
</span>
Yeah I’m not sure where the idea that systemd is “trash” in the enterprise world is coming from. Of all the contacts that I know who work in an enterprise environment say this, nor have I even seen anyone on the internet mention this.
I mean if there’s an actual reason for it other than just the usual bandwagon of “systemd bad” I’m all ears.
Yeah, that’s the point. Again, the average user (as in desktop user) gains nothing from using a different init. There may have been some crazy server-side scenario where the type of init you used actually mattered but we’re talking about desktop Linux, which the answer is a clear-cut no. I’m not stopping the people that are interested in trying a different init out, I’m just telling them that there’s little to no benefit in the end if they’re expecting an improvement in performance or whatever else.
Wait, people really believe writing boilerplate filled bash scripts to implement just the idea of dependencies does scale into enterprise environments? Which don’t come even close to emulate most of the very useful and important features systemd provides?
Seriously that’s a take I have never heard one say while keeping a serious face. There is a reason systemd is as popular as it is for every desktop and server distro out there.
It is far from perfect, but who in their right mind would want sys-v init or similar systems back? I can’t even imagine what a mess it would be managing all the contexts and implementing it securely and portable with an init script.
I have a friend that used to be super into watching morbid stuff like gore and snuff videos. He stopped a few years ago and last time I asked him he told me that he can’t handle them anymore, same goes for another person I know.
In my case I’ve never been able to watch too much of those things, but I know I’m able to handle situations where blood and stuff is involved as I’ve studied anatomy with dead human bodies and also worked with injured people. I like to think I’ve had a bit of a healthier relationship with the effects of violence on humans.
I don’t personally like SystemD, but Devuan sucks. They advertise “init freedom”, but in reality all of the scripts by default are just sysV init scripts that runit and openrc can’t control.
My wife has been dealing with a lot of sleep paralysis lately. The other night she just told her sleep paralysis demon, “I’m too damn tired to deal with you right now.” And just went back to sleep.
I asked Midjourney to draw itself. Somewhat similar of a look, though Midjourney seems to think itself a bit godlike. Edit: difficulty uploading from mobile. https://imgur.com/gallery/TETnZqg
Short version: some people (I’m one of them) object to systemd on grounds that are 75% philosophical and 25% the kind of tech detail that’s more of a matter of taste than anything else. The older sysV init is a smaller program, which means that it has a smaller absolute number of bugs than systemd but also does less on its own. Some of us regard “does less” as a feature rather than a bug.
If systemd works for you and you don’t know or care about the philosophical side of the argument, there is probably no benefit for you in switching.
Which means that you trade some speed for making it easier to understand what’s going on at any point during init. (Also, OpenRC does have a parallel mode, although it isn’t commonly used.) “Serial” isn’t inherantly evil, it’s just another tradeoff.
I’m more bothered by the very concept of an integrated supervision suite (running as PID 1 and managing services in runtime). And with the feature creep (not-invented-here syndrome despite being mostly worse on all metrics), the following heavy binding of applications to it’s services and that it can’t coexist, because of that, with any other init/service manager in a repo without an uncount number of wrapper scripts (some distros tried).
taking a breath Which is why we must have specialized not-systemd distros instead of Choose-your-iso-with-bootloader-X-and-Desktop-Y distros, like Artix does (a not-systemd distro).
The attitude of the devs to technical issues and even security holes is another issue. Systemd is really bad software in that regard.
I basically lump everything you’ve listed under “philosophy”—poorly chosen design goals and no one at the project doing anything about dev behaviour are not technical flaws per se, as the software is functioning as intended and expected.
systemd and init+OpenRC can exist together in the same repository, though—it just means that the repository also needs to contain both init scripts and service files, both of which are trivially small.
As a Gentoo user since 2005, I’ve been able to watch the entire debacle as it’s progressed, and the various efforts required to keep udev and friends working separately from systemd. (Currently, there are 7 Gentoo packages on the “absolutely requires systemd” list—6 optional daemons that I don’t perceive as being very useful, although maybe it’s just me, and one library that I’ve never heard of in any other context. So what’s being done to keep it from taking over is working.)
Devuan is the outlet of a bunch of people that don’t want Linux to evolve, become better and have more flexibility because it violates the UNIX philosophy and/or it is backed by big corp. Systemd was made to tackle a bunch of issues with poorly integrated tools and old architectures that aren’t as good as they used to be. If you look at other operating systems, even Apple has a better service manager (launchd).
Systemd is incredibly versatile and most people are unaware of its full potential. Apart from the obvious - start services - it can also run most of a base system with features such as networking (IPv4+IPV6, PBR), NTP, Timers (cron replacement), secure DNS resolutions, isolate processes, setup basic firewalls, port forwarding, centralize logging (in an easy way to query and read), monitor and restart services, detect hardware changes and react to them, mount filesystems, listen for connections in sockets and launch programs to handle incoming data, become your bootloader and… even run full fledged containers both privileged and non-privileged containers. Read this for more details: tadeubento.com/…/systemd-hidden-gems-for-a-better…
The question isn’t “what is the benefit of removing this init system”, it is “what I’ll be missing if I remove it”. Although it is possible to do all the above without Systemd, you’ll end up with a lot of small integration pains and dozens of processes and different tools all wasting resources.
The philosophical arguments are pretty garbage. I generally want to know if the “it violates the UNIX philosophy” people use browser extensions… That violates the UNIX philosophy too. Systemd “is backed by big corp” but who do you think is actually contributing time/effort/code to the Linux kernel? It’s the device manufacturers who are trying to get you to buy their products… So that fails too.
No offense to anyone reading this but if you’re really passionately anti-systemd, I would not hire you. This is a dumb hill to die on and a red flag.
What worries me about the “systemd does everything as a tightly integrated package” is the too-big-to-fail aspect. I’d be worried that we’re seeing a lot of configurations that can’t be pulled apart piecemeal-- for example, if you need a feature not available in systemd, or you need to deactivate a systemd component due to an unfixed vulnerability. It feels like there’s value in supporting a non-systemd init in the same way there’s value for individual packages to support an architecture beyond x86-64-- you get some extra checks that you aren’t making assumptions that only work for a specific happy path.
The problem of not having systemd is the mess what’ve seen before. It doesn’t make sense to have 200 different services to be able to have usable dual-stack networking. Furthermore Init and Cron are aging, having everything based on bash scripts doesn’t cut it anymore - they don’t scale, you can’t monitor and audit things properly and worse it creates a dependency on some very specific shell.
What worries me about the “systemd does everything as a tightly integrated package” is the too-big-to-fail aspect.
It’s been the default for ~10 years and it hasn’t been an issue yet… Even if it did “fail” the solution would never be to roll an entirely different init system. That would be absurd. If there is a bug, it gets patched.
I’d be worried that we’re seeing a lot of configurations that can’t be pulled apart piecemeal-- for example, if you need a feature not available in systemd
You can run services independently of systemd. There is no reason you couldn’t have whatever feature you want and systemd at the same time.
you need to deactivate a systemd component due to an unfixed vulnerability.
When vulnerabilities are discovered there is disclosure to maintainers, a patch is released, and then an announcement is made publicly with the instructions on how to fix the problem. I’ve never seen an instance where the industry collectively says “There’s a vulnerability here but we aren’t going to fix it. Good luck!” Especially for such an important layer of the stack… There’s no way that is going to happen.
Yeah, I just have a question about that community. Debian maintainers told them they were open to a multi init architecture (as in have Debian support both systemd and init) as long as they maintained it, they just rumbled around and decided to fork Debian instead. This is the kind of people we’re dealing with.
lemmy.ml
Hot