Hacker News Reader

Comment by gorgoiler | Hacker News Reader

It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend.

How long until “Systemd: The Good Parts”?

*The most trivial new name would be système which would at least be in keeping with the French naming.

**In Debian stable if you create a new user, ssh in as that user, logout, then delete the user, you can’t because systemd is still running a detached housekeeping process as that user. If you wait a bit then the systemd process goes away but that, to me, makes it a worse bug not a better one.

View on HN

From the logind.conf man page [1]:

> KillUserProcesses=

> Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and all processes inside that scope will be terminated. If false, the scope is "abandoned", see systemd.scope(5), and processes are not killed. Defaults to "no", but see the options KillOnlyUsers= and KillExcludeUsers= below.

> In addition to session processes, user process may run under the user manager unit user@.service. Depending on the linger settings, this may allow users to run processes independent of their login sessions. See the description of enable-linger in loginctl(1).

> Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the session scope. See example in systemd-run(1).

[1]: https://www.freedesktop.org/software/systemd/man/logind.conf...

Ahhh, thanks. Now you mention it, wasn’t there some major scandal about this when it first shipped?

There were a lot of noises made about it, yes, because people had been "nohup"ing things for decades, and using stuff like screen and tmux to keep sessions going over poor connections.

All of a sudden, without much warning, someone made the decision to kill all user processes on logout. It broke a lot of folks workflow.

One would be tempted to say that deleting a user and logging out are definitely different operations with expected different outcomes.

It’s part of the same session-management feature that had unexpected (and undesirable) effects.

The "scandal" was the exact opposite of your complaint. People where SSHing in, starting a screen/tmux, disconnecting and complaining about the process being killed.

Not really an exact opposite. There was a preexisting convention for how to intentionally keep a process running after logout, which systemd broke. That's quite different from a case of a background process the user did not explicitly ask to be started in the first place, let alone flag to keep running after logout.

You mean the distros broke it by not toggling that option. As you can read from the parent comment here, that "convention" was also broken and causes issues in Debian. There's no solution here that isn't going to break something, that's why the best systemd can do is ship a toggle and tell the distros to figure it out.

Don't we already have multiple, alternate systems that are significantly simpler?

The primary reason why I don't use systemd at all, on any desktop or server I manage, is not that I think it isn't powerful or reliable but, I cannot fit it into my head.

The scope and complexity of it goes beyond what I'm personally willing to invest into any one subsystem designed to regulate my operating system.

I find that because I can't easily integrate day to day systemd operations into my general knowledge of the Unix / Linux shell environment, it essentially creates a cognitive switching cost that I'm not willing to pay given the efficiency and utility I get from my existing knowledge and skills.

Systemd seems to work well for a lot of people, but doesn't sell itself to me given my objective, and capacity, to internalize simpler tools for high levels of mastery.

That's why I don't use systemd but do use other, more simpler systems, that are readily available.

You don't have to fit anything in your head. I often find myself consulting the index at `man systemd.directives` to remember things: https://www.freedesktop.org/software/systemd/man/systemd.dir...

In lot of cases I've found systemd units much to actually be simpler and easier to maintain due to everything being in a simple declarative format. The old alternative is to have a lot of shell scripts that can get very complex, and to consult another few hundred man pages for various shell utilities...

True. However, my objective is to internalise the tooling that routinely use, the scope of systemd is beyond what I need. Also, I find constantly looking up unique directives fatiguing and would rather use that energy elsewhere. I find working with the same general tooling results in faster & easier mental recall across a broader range problems that I tackle. Just my experience, no doubt different for others.

> It feels like the time is ripe for something simpler and more modern to replace* systemd.

Well then do what Poettering did and write it.

It's threads like this why I am eternally grateful that Linux kernel uses a merit driven approach and not concessus driven one.

Yeah, but Redhat has been slowly getting control of more of the infrastructure. Want to make your own? Well even if you make something backwards compatible with Gnome or udev, get popular and they will probably find some way to break your compatibility.

You end up needing to fork all the projects that Redhat has gotten their tentacles around.

That's a pretty negative way to make an innocuous statement: that it's expensive to make an OS. You can't expect Red Hat (or any other Linux company) to maintain backwards compatibility forever for every single possible project they've ever had an employee contribute to. They'll maintain some as long as their customers pay to support it for that long, but even that ends after a while. Yes, if you don't want to pay them for it, then you get to spend the immense amount of time and money needed to fork it; because shipping a full commercial operating system with millions of lines of code is a complex task with a lot of interlocking parts and no one wants to do it for free. It makes no sense to single out complaints towards random projects for this.

> Well then do what Poettering did and write it.

This is such a superficial and ignorant take I'm having hard time forcing myself to believe it was written in good faith.

Dozens of alternatives already exist. The problem isn't writing, problem is having politicial power Poettering had. (ie. He was employed by Red Hat and had close connections with other Freedesktop developers.)

That isn't "political power" it's called knowing your audience and knowing what they want. The audience here is Linux distribution upstreams who also participate in Freedesktop. The other alternatives had ample time to talk to these people and copy the features of systemd and improve on them but they refuse to do it. They seem more interested in building for their own niche use cases and ignoring everyone else. That's a fine decision, but it's their decision. They can't say it's anyone else's fault.

Edit: If those other developers were really serious about trying to replace systemd they would be going around to every distro maintainer they can possibly find and asking them what systemd is doing badly and what they'd like to see in a better project. Then they'd have to think really hard about whether it's easier to fix those issues just by contributing to systemd, or whether a full replacement is warranted. Every now and then I see comments about writing replacements in Golang or Rust or some other memory safe language but there's no other interesting ideas there to warrant a rewrite. Maybe you do all this and conclude there are no major complaints from the big systemd users, and that's just how it is.

Ubuntu had the alternative software called Upstart.

It was killed because of the Red Had power behind Systemd.

Technically, I don't know which one is better, but politically, Systemd was a power move by Red Hat.

>It was killed because of the Red Had power behind Systemd.

That is an absurd, untrue conspiracy theory. Whoever told you that should be ashamed. The author of Upstart said that it died because of a restrictive CLA. Read the thread linked here for an explanation: https://news.ycombinator.com/item?id=27176807

To quote the relevant parts:

>I entirely agree with Kay and +Greg Kroah-Hartman that it was the CLA that caused systemd to be written instead of Upstart.

>But I don't need that self-affirmation anyway :) I wrote Upstart, I got paid for it, I moved on to do other things, something else came along and replaced it. If Upstart hadn't been under the CLA, and systemd hadn't've happened, all my code would have long since been rewritten by now anyway.

It happened for PulseAudio, perhaps something compatible but leaner can emerge for systemd.

It happened to Pulse after the project stopped being a moving target. Just look at the changelog of this systemd release.

Just because the project is moving, doesn't mean it's moving in the right direction.

What I like about linux in general, is that there are lots of small tools, with a reduced and specific scope, that do their job well. Systemd seems to want to do and control everything.

I don't understand this comment. Systemd is a lot of small tools with a specific scope that do their job well.

Wait, what French naming?

I don't know if it was intended, but "système D" in French means hacking together something with whatever you have available. D meaning "démerde" (literally getting out of shit or a shitty situation) or "débrouille" depending on the language registry you want.

It's a rather common expression.

Funny tidbit, sure. Basically "[made] from shit and sticks".

ah, that makes sense, thanks for the explanation.

"e" following "d" in the alphabet, the successor to systemd would be called "systeme", which is the french translation (système) for "system".

Thanks, but I was refering to the "...in keeping with the French naming" part, as if systemd previously had a french name or something

“[The] name is suitably reminiscent of the French term "système D", an expression that relates to thinking on your feet and describes high-speed technical problem-solving abilities such as those displayed by TV action hero MacGyver.”

— Poettering, Sievers and Leemhuis, the Systemd authors, in http://www.h-online.com/open/features/Control-Centre-The-sys...

Interesting. However, the link they provide as reference where apparently "The developers thought that its name is suitably reminiscent of the French term système D" does not have this term anywhere. My guess is this was just made up by a 3rd party (h-online in this case) and everyone just went with it?

I have that c't magazine they're referring to somewhere, I'll look it up there

I expect there will be a system that is not necessarily less complex (as what systemd does IS quite complex); but is more:

* safe (uses Rust with unsafe)

* modular (systemd is pretty all-or-nothing)

* open access (less RedHat dominated)

Probably it will be using some of the same standards as systemd or at lease be BW compatible to some extend. Once Debian picks it up, it's game over systemd.

Reply on news.ycombinator.com