Hacker News Reader

Comment by antirez | Hacker News Reader

The tragedy of systemd is that it's the wrong solution to a real problem. Because most people against systemd will keep saying that the old init system was ok, they don't move forward trying to provide a true alternative. So systemd became a standard despite the issues, because it solves certain real problems that people have, even if not great.

View on HN

I concur. Before systemd, I used supervisor because I wanted to avoid using any init system like hell.

Since systemd, I just do a service file.

So despite all its shortcommings, I now have a standard, well documented, init system that I can use accross all the distros I use, which happens to provide all the features I need.

I'm sure all the power user complaints about systemd are legitimate, but I really don't care about those. I just want an easy way to setup custom deamon on ubuntu and centos.

Provide a better system, that solve those problems, and I'll use it. I really don't care as long as my problem is solved.

> So despite all its shortcommings, I now have a standard, well documented, init system that I can use accross all the distros I use, which happens to provide all the features I need.

Same couldn't be said about supervisor, the solution you already had running (well, maybe strike init)?

It's not installed by default on any distro. I don't want to install something as basic as an init system.

And it's not installed by default because it doesn't solve the problem of a service dependancy graph.

Sorry, but that first argument seems a bit random to me. Couldn't even use a proper editor like nano with that argumentation, having a usable editor available is after all also pretty basic.

I doubt that supervisor is not installed because of not solving something it evidently does not want to solve, but that argument at least looks valid to me. Just in case you are not aware, https://github.com/Supervisor/supervisor/issues/122 lists two solutions (wait_for_it.sh and a supervisor plugin that adds dependency resolution).

I think "basic" in this case means "integral to the system". Many people don't want to replace the init system, nor the desktop display system, nor an authentication system (e.g. PAM).

The more systems something sits under the more places there are for it to cause a problem because it doesn't work quite how the upper components expect. At a bare minimum, you'll often run into problems with the included package management system (and how it may reload systems for security purposes after patching) if you don't take care.

nano sits on top of everything, and the few things that might rely on it use a very standard and not very extensible interface (the EDITOR environment var). It's not really equivalent at all.

> proper editor like nano

Not sure what your point is (well ok, I am, and I agree), but you just lost

I'm not tring to convince you, i'm sharing my pov. Systemd is here because of pov like this, and people not liking it end up with it anyway because they fail to aknowledge others pov.

systemd is far more than an init system though, it's a total rethink of how linux systems are controlled and managed.

Rewatch the first half of the video and imagine it was a bunch of random tools with proper names (like grep, ntpd, syslogd) etc, that had all been built separately but happen to nicely tie into each other, rather than "systemd-blah"

>Because most people against systemd will keep saying that the old init system was ok, ...

There isn't and wasn't hardly anyone saying that. It is and was well known that there were better things out there than the hacked up sysV style init systems produced by the various Linux distributions.

This is a common strawman that seems to get rolled out any time any discussion involves systemd.

A few of the authors of one of the Debian based distributions dropping systemd are friends of mine and all of them see things in that way, that the good old init is fine and there is no need to replace it. In the Facebook group where they use to stay the others I don't know first-hand seem to share this POV.

And yet basically no alternative to systemd was produced by any of those people.

Does upstart not count as an alternative?

Is upstart better in any way?

Upstart doesn't include implementations on NTP, DNS, DHCP, or anything that opens a network port. It does however allow parallel boots with dependency analysis for quick boots.

Systemd on the other hand seems to be trying to take over syslog, ntpd, dhcpd, named, and related with generally poorer implementations. Feature creep seems constant with systemd, for no particularly good reason.

Upstart is older then systemd and it was mainly developed by Ubuntu who dropped it. After that is continued to exist as a project but its basically not used anywhere and id didn't continue to develop all that much.

I didn't mean to imply that it was built as a competitor to systemd, more that it exists as a different alternative. I'm aware of what happened with Ubuntu dropping it, and I think it's a shame, as I like it as a simple response to the problem.

Nearly every systemd-disliking person I've personally spoken to, has trotted out that exact line about sysV init being fine.

It's not just a strawman, unfortunately. I wish it were.

But it's not just replacing init - it's replacing a dozen other services including things like ntp or dns, and often it's replacing them with inferior solutions.

Yes, that's a design problem due to what the systemd main author believes to be a good thing.

systemd can be used without most of these things. systemd as a project has other services in but those you can use or not use.

And the claim that they are 'inferior solutions' is just absolutely false in most cases. It often replaced horrible old tools that haven't been updated in 30 years. It often provides far better interfaces and tooling then the existing solutions.

The DNS resolver seems to break DNS, the time system no longer acts as a server

This isn't necessarily a problem with the systemd project, it's more on the distros that bundle these service, but when you have the same branding across multiple systems, you have to take the bad with the good.

Had they called it "multidnsd" or "ntpclientd" then people wouldn't think "systemd sucks because when MyDistro 9 came along", they've blame multidnsd and let the systemd init system stand on it's own.

I don't recall the DNS resolver actually breaking DNS without it being fixed. And I'm not sure why most systems need NTP to run as a server.

You can always disable them at runtime or during compile and use your own though.

My understanding is that the reason it started replacing other services is that there's a dependency graph that ends up pulling them in, and very early in the boot process depending on configuration[1]. That, and in some cases the available solution did not support their needs[2] (which might have been solved better through upstream work, or maybe not, if the targeted project was slow or unwilling, I'm not sure).

1: https://lists.freedesktop.org/archives/systemd-devel/2014-Ma...

2: https://www.reddit.com/r/linux/comments/6kdcme/why_does_syst...

>Because most people against systemd will keep saying that the old init system was ok, they don't move forward trying to provide a true alternative.

The problem with systemd it is not just an init system. Its network-state-aware, device-state-aware container launcher(nspawn), cron, logind and syslog implementation.

The scope creep of systemd is enormous, nobody asked for that when they wanted reliable daemons.

More or less this. Gummiboot is nearly pointless, and ntpd and resolved have both caused problems for me. As an init system, systemd is fine, but shipping these bad components while giving them the systemd "seal of approval" is dumb.

On the other hand, I've had no issues with logind and gdm. I've been interested in trying S6 but given it's quite easy to substitute out the bad parts of systemd, so I just haven't bothered.

Probably the biggest problem with systemd is that it's hurting BSD. Then again, gnome devs are having enough trouble getting things working on Linux... also binary format journals are so dumb. How have they not changed that?

The tragedy of systemd is tight coupling. What makes Linux great is that I used to always have a choice - regarding what kernel I use, what editor, what shell, even what Init I use... Systemd changed all that. Distro makers gave up supporting alternatives because it would mean too much work. (I almost flipped out when I read somewhere they had to do it because of some Gnome-related component... I mean I don't care about Gnome, I don't even use X, but I have hundreds of servers to manage - now let's change everything because one guy said it's the only way...)

Nobody would make what Lennart did if we had a choice. Those who liked Systemd would use it, and the rest would use the init of their choice. As simple as that.

systemd became a standard because the guy works at Red Hat so he can make GNOME require it (there is no way to use GNOME without systemd; distros that allow that such as Gentoo do so by patching GNOME, which is costly.)

I agree that a more modern init system is necessary, but the idea of systemd is meh and the implementation is subpar.

systemd became a standard because Debian adopted it after a lengthy discussion, partially because big Debian users like Spotify expressed an interest in systemd.

https://lists.debian.org/debian-ctte/2014/01/msg00287.html

Conspiracy nonsense. It became standard because the existing solutions were crappy and nobody else bothered to do anything about it.

I don't believe this to be a "conspiracy". It's nothing shadowy, really. What they did is completely natural. That doesn't mean I support the idea though.

The intentional and willful breaking of screen and tmux was to fix a GNOME bug of GNOME not closing up as it should when the user logs out, so systemd was changed to mass kill processes. The interplay between GNOME and systemd in backroom dealings is a major pain point.

I think that's an oversimplification. There are definitely cases where some thing started as a daemon under a user session, graphical or not, should be killed to be safe. For example, ssh-agent.

There are other things that are meant to be left around, as that's their purpose, such as screen and tmux.

I would say the safe solution would be to kill everything in the user session at multiple levels (GNOME, and user session management demon like logind, etc), and to provide a defined safe way for the very few programs that want to stick around to do so. That seems like what systemd came up with as well.

You make it sound like the systemd author was something the CEO of all Linux Distros.

The maintainers of Arch Linux have given an explicit list[1] of the reasons why they decided to introduce systemd:

    0) it is hotplug capable
    1) we can know the state of the system
    2) it is modular
    3) it allows dbus/udev to go back to doing the task they are meant to do
    4) we can reduce the number of explicit ordering dependencies between daemons
    5) we get a lot of security/sandboxing features for free
    6) systemd service files can be written and distributed upstream
    7) systemd is a cross-distro project
    8) logind will finally deliver on what consolekit was supposed to do
    9) systemd is fast

[1]: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

Reply on news.ycombinator.com