Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd, 10 years later (2020)

blog.darknedgy.net

Post reply on HN
Print view View original

71–80 of 332 posts

Re: Systemd, 10 years later (2020)

#71

Post by Blikkentrekker »

dharmab wrote: post #58
MuffinFlavored wrote: post #49

Earlier quoted context omitted.

Like what if you don't mind me asking, and what did people used to use as an alternative?

For the init system, the most common predecessor was a combination of sysvnit and "initscripts" (a shell script for each daemon on your system). Writing the init scripts was simple for the most basic cases but quite complex for complete, bug free case coverage. A big appeal of systemd for packagers and sysadmins was the relative simplicity of unit files. Now we just have to fill out a simple boilerplate INI style fil…

It was not.

There is strange false history that systemd replaced sysvinit, which occurred only on Debian, because Debian was the last major system to discard sysvinit.

Gentoo had replaced sysvinit with OpenRC in 2006; Fedora and Ubuntu were using Upstart in 2005. systemd primarily replaced Upstart and systems that used Runit or OpenRC tended to have stayed with them.

Frankness be, this false history seems to be crafted in order to compare it with very outdated technology to make it look good. Obviously systemd is better than sysvinit, technology that almost all systems but Debian had discarded long before systemd was even started. The issue is whether it compares favorably to Upstart, runit, and OpenRC, and to the first I would say yes, because Upstart was full of very ugly hacks and didn't deliver it's ambition. In the second two cases, their mode of operation is so different that it's hard to compare. runit was inspired by daemontools and is very simple and effective and works in a very different way from most models of service management; OpenRC is backwards compatible with sysvinit and is essentially a large library so that init scripts typically need nothing more than something such as:

   #!/sbin/openrc-run
   command=sshd
   args="-D"
   daemon=no
   provides=ssh
   after=net
Or something similar to work. I forgot the exact syntax but it works similar to simply assigning some variables and it handles the rest, but it still gives one full access to the shell to use whatever shell functionality one wants.

Re: Systemd, 10 years later (2020)

#72

Post by rnd0 »

api wrote: post #61
marcodiego wrote: post #3

Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.

It’s a functional improvement over old init, but the thing I hate about it is how unnecessarily arcane it is. It seems “designed for job security” or more likely designed for consulting revenue. There is absolutely no need for its command names and everything else about it to be so counterintuitive.

>It seems “designed for job security” or more likely designed for consulting revenue.

Exactly this, yes; and that's why it was pushed the way it was.

I dread the day when systemd or an init system just like it consumes the BSD world.

Re: Systemd, 10 years later (2020)

#73

Post by diegocg »

MuffinFlavored wrote: post #49
klysm wrote: post #8

Earlier quoted context omitted.

I’m young enough to have missed the transition and really like systemd, I rely on it for as much as I can

Like what if you don't mind me asking, and what did people used to use as an alternative?

A bunch of very large bash scripts that were entirely different in each distro, had tons of races and were much slower to boot (one of the reasons why systemd became so popular and there was popular pressure to switch to it is that it would speed up booting by several seconds).

Also upstart, which was actually pretty good, but systemd was more ambitious.

Re: Systemd, 10 years later (2020)

#74

Post by ratorx »

rlonn wrote: post #57
ratorx wrote: post #42

Earlier quoted context omitted.

I’m a fan of this description. It might not be the easiest to understand or the first one you should read, but I wish more things had this kind of description somewhere (but not necessarily on the introductory materials or front page).

It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.

Which words do you think are buzzwords in the description? What I think of by buzzwords are things like “Blockchain”, “Machine Learning” etc. which are generic topics used to build hype whilst not really explaining anything.

In this case however, the words are all fairly precise and accurate (at least from my basic understanding of systemd). They might not be words used in everyday conversation, but they don’t need to be unless the document is targeted as introductory material (which I don’t think is the case).

That’s not to say this is the only way to explain it, but it is a very concise way, which I at appreciate.

Re: Systemd, 10 years later (2020)

#75

Post by cesarb »

zodiakzz wrote: post #54

I miss Systemd inside Docker containers so much. IMO, for an app, "one-process per container" is a huge pain and very messy. I have a massively popular software to back up that claim: https://github.com/discourse/discourse_docker I use phusion/baseimage-docker[1] right now, love every bit of it. Having the database, web server(nginx) and the java backend all in one place works beautifully. The only pain point is havi…

You can use systemd inside Docker containers. There are images (like RedHat's ubi8-init) which start systemd by default, and there are others which can be easily adapted to start systemd (for instance, the following 3 lines for a Debian image which starts systemd: "FROM debian:10", "RUN apt -y update && apt -y install systemd-sysv", "CMD ["/sbin/init"]").

Re: Systemd, 10 years later (2020)

#76

Post by Gigachad »

jandrese wrote: post #37
akagusu wrote: post #26

I am old enough to remember that problems with systemd were less technical and more political. People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency. Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.

SystemD is kind of like MacOS, if you have a typical use case then it makes everything very easy. If you are doing something weird it can make your life a living hell.

Can you give some examples?

Re: Systemd, 10 years later (2020)

#77

Post by jcrawfordor »

Denvercoder9 wrote: post #66
jandrese wrote: post #37

Earlier quoted context omitted.

SystemD is kind of like MacOS, if you have a typical use case then it makes everything very easy. If you are doing something weird it can make your life a living hell.

> If you are doing something weird it can make your life a living hell. I find it much easier to reliably accomplish non-standard things with systemd unit definitions, than it used to be with the ill-defined complex set of shell scripts we had before.

This issue is a lot bigger outside of services... I think the systemd service architecture is a clear improvement over SysV. The bigger issues I run into with systemd flexibility are related to the many other aspects of it. systemd-resolved, for example, has a very "opinionated" (to be polite) set of expectations about the environment and the systemd project tends to view any complaints about it not working outside of that environment as being the fault of the complainant. This leads to, well, DNSSEC is basically just broken and split horizon DNS is extremely unreliable. The former is sad but mostly doesn't matter, the latter leads to a lot of corporate networks having to disable resolved (I think configuring it to remove the semi-hardcoded "backup" resolvers reliably fixes this problem but honestly I find it completely ridiculous that resolved has a hardcoded list of DNS servers it just uses instead sometimes. It's unclear to me whether or not that's a bug at this point and I got tired of trying to follow the issues and mailing list threads where the developers were, uh, not amazingly helpful).

systemd management of mounts can be similarly narrow about the types of configurations it supports, and systemd-firewalld just sort of openly only claims it can support simple use-cases.

systemd-journald is also a net loss of flexibility compared to rsyslog but, on the other hand, rsyslog could quickly turn into an inscrutable mess if you used any of the advanced features (rainerscript...), so this may not be an entirely bad thing.

And in general systemd is, well, opinionated. I hate to bang on resolved too much but I just happen to have spent quite a few hours last week figuring out resolved problems. Resolved does not handle "dotless" domains correctly in a lot of existing environments (it's very particular about exactly how the search domain is set up). Poettering has basically responded that it's because dotless domains are stupid and no one should use them, so it won't be changed. I don't necessarily disagree that dotless domains are not a good idea today but it does mean that resolved breaks a lot of older corporate and institutional environments that have been using them successfully for decades. This manifests as "I updated my distro and the intranet stopped working." That kind of breaking change is not very common with core Linux services and isn't going to make many friends in the IT crowd.

Re: Systemd, 10 years later (2020)

#78

Post by bollu »

Spooky23 wrote: post #67
rlonn wrote: post #57

Earlier quoted context omitted.

It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.

Exactly. “Idempotent” is one of the key words used as a cudgel in this way. It’s great for the bullshit artist, as to a layman the dictionary definition is completely inscrutable.

Idempotence is a desirable property of systems whereby repeating an action has no effect. Mathematically, an operator is idempotent if f(f(x)) = f(x).

Idempotence is handy because it implies that one can retry safely if one isn't sure whether something succeeded or failed. Not sure if your file was saved? Save again! If it was indeed saved, the file continues to be saved. If the file was not saved, it is now. Yay.

I would kill for such descriptions of every system I work with.

Re: Systemd, 10 years later (2020)

#79

Post by lifeisstillgood »

Spooky23 wrote: post #67
rlonn wrote: post #57

Earlier quoted context omitted.

It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.

Exactly. “Idempotent” is one of the key words used as a cudgel in this way. It’s great for the bullshit artist, as to a layman the dictionary definition is completely inscrutable.

Idempotent is surely a valuable piece of software jargon. I know exactly what the user intends, and have good ideas of how hard it is and what likely trade offs they will be making behind the scenes

surely it is the very opposite of bullshit.

Re: Systemd, 10 years later (2020)

#80

Post by tracnar »

zodiakzz wrote: post #54

I miss Systemd inside Docker containers so much. IMO, for an app, "one-process per container" is a huge pain and very messy. I have a massively popular software to back up that claim: https://github.com/discourse/discourse_docker I use phusion/baseimage-docker[1] right now, love every bit of it. Having the database, web server(nginx) and the java backend all in one place works beautifully. The only pain point is havi…

Podman supports running systemd units inside containers: https://developers.redhat.com/blog/2019/04/24/how-to-run-sys...

One process per container is indeed strange in a lot of use cases, you lose the self-contained advantage of a container...

Post reply on HN