Hacker News Reader

Comment by freebuju | Hacker News Reader

Genuinely curious, for both casual and advanced users, what *major* reasons are there for not using systemd?

I've used systemd for years bug-free

My POV: SystemD is a software driven not really by technical, but political reasons by RedHat, to put the most important parts of a GNU/Linux system under their control. (Appart from the kernel of course). It is modular, but also dependant as a whole, so in the end, it spreads almost like an invasion, slowly leaving the admins not other option than accepting it. That's quite off from the Unix philosophy (do one thing, do it well, be really modular)... so my conclusion going back to the beggining, that didn't happen by mistake, but is a deliberate design choice, with shaddy political reasons behind it, so I reject it. And then we could talk about the convenience or not of putting such amount of tools and complexity under PID 1, the crazy binary logs, the weird behavior of the service utilities, and the possibility of being able to modify/add services using regular scripts instead of binary excutables...

> My POV: SystemD is a software driven not really by technical, but political reasons by RedHat, to put the most important parts of a GNU/Linux system under their control.

it's really a dumb POV to have, given that systemd is FOSS (licensed LGPLv2.1+) like most of the software that red hat produces.

as a sysadmin, systemd is a godsend. really, it brings uniformity and waaay better debuggability/predictability and tooling in system startup and configuration and troubleshooting.

and, again, systemd is foss so red hat hasn't really that much control over other distros (and each distro had its own internal discussion and choose freely to adopt it).

on another side, red hat took the time and spent the money to bring that improvement to the world. other people just complain under the shield of a throwaway hn account.

I think people's beef with it is that it's hard to understand when things go wrong, Lennart's projects don't leave the best initial impression, and it's had significant scope creep since it was initially introduced.

well in fairness systemd's task (managing the system) is fairly complex as well.

I am not surprised I had to actually sit down and go through a short course on systemd and read some of the manpages to understand it enough and profit off its presence.

And that's the rub - it was initially advertised as a quick way to start the system, which is a simple enough concept to understand, then changed its scope to manage the entire system/service land.

It also ended up being tightly coupled, with poorly documented APIs and major bugs, which drew the ire of some longer-term professionals.

I don't think the idea systemd shim layer of services is necessarily bad, but I do think that having its design and implementation centralized within Red Hat isn't the best ; it would be nice if there was a complement to the Linux foundation doing its development, as having the process be managed by someone as competent as respected as Linus would go a long way into quieting the storm around it.

> but I do think that having its design and implementation centralized within Red Hat

oh don't be silly.

systemd's development is not centralized at all.

it's LGPL licensed and its developent happens on github at https://github.com/systemd/systemd -- anybody is free to fork it off to another project -- yet pretty much nobody does, how comes that?

PS. I was expecting the kind of answers I received... as the whole subject stinks, talking about it stinks even more. What I wasn't waiting is to see people, in another time caring and loving this OS quietly yielding about such a big insanity. Thinking right now specially about Debian and ArchLinux mantainers.

It's fine when it works, but it's very hard to solve problems when they happen as it's so complex, and doing stuff outside of "the standard thing" can be difficult.

I once had "systemctl restart unbound" reset my volume, consistently. How do you even start debugging something like that without a deep dive in systemd? This particular issue turned out to be a systemd bug, and that such a bug can exist in the first place didn't exactly increase my confidence in the system.

In another case I couldn't get my NFS to work at all, and it turned out that rpcbind.service somehow went missing. Not sure how that happened and it's a simple enough problem, but it was really non-obvious because systemd doesn't issue clear errors on this and the system is so complex it's not easy to spot either.

> I once had "systemctl restart unbound" reset my volume

That's fascinating, do you have more information on this particular bug?

Bug report and commit that fixed it:

https://bugs.freedesktop.org/show_bug.cgi?id=88401

https://cgit.freedesktop.org/systemd/systemd/commit/?id=6e39...

You should know that this is a religious topic like vim vs emacs, but worse: vim and emacs users don't feel that the other side is a threat to allowing them to continue using the software they prefer.

Also kind of like religious syncretism, bridging the emac vs vim divide, there is evil mode.

Something I can't accept is the use of binary logs and the requirement for programs to access the contents of the logs.

Yes, most distros will put compatibility layers in place and create text "logs" in parallel. But if everyone is doing that maybe systemd's paradigm isn't right for the desktop even if it's great for servers.

Binary logs sound like a good thing to me since in most cases I want to just ship them off, and if I don't, a local consumer that can parse is just fine.

Is there something I'm missing?

Yes. The ability to use the giant ecosystem of text processing and piping infrastructure that underlies the entire idea of the unix philosophy. That something besides eyes is required to parse the logs is absurd and unacceptable. And no one on desktop is shipping off logs to somewhere else. That's cargo cult behavior.

How do you "ship off" .journal files? Whenever I do it either the timestamps are off or you can't read the file at all. I resort to `journalctl xyz.journal > xyz.log` and send the resulting text file to outside the system.

It isn't right for server either. I want my server logs to be files in filesystem and readable with standard tools.

> what major reasons are there for not using systemd?

    ps aux | wc -l

I don't get it.

Probably too many useless systemd-related processes.

I imagine that the respective user wouldn't want to see the number of background processes for all the other modern OSes, in this case :-)

Alpine Linux boots with a fairly clean process table.

Of course, this is the internet... Someone is going to point out exceptions.

I was talking about Windows, MacOS, Android, iOS, all mainstream Linux distros.

What you did was like seeing someone talk about family cars and interjecting: yeah, but they're slower than my motorbike. It's not the same thing, is it?

You said

> all the other modern OSes

Alpine is a modern OS; I've been quite happy running on my desktop. I would argue that you're moving the goalposts because I pointed out an example that disagrees with you.

https://tirania.org/blog/archive/2011/Feb-17.html

Reply on news.ycombinator.com