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

Systemd: The Biggest Fallacies

judecnelson.blogspot.com

Post reply on HN
Print view View original

11–20 of 54 posts

Re: Systemd: The Biggest Fallacies

#11

Post by bronson »

astine wrote: post #9
felixgallo wrote: post #4

Earlier quoted context omitted.

It's not shell scripts, it's /bin/bash -- the guy fieri of shells.

Which also happens to be the default or expected shell in the majority of sysv installs on Linux. '/bin/sh' symlinks to bash, shell scripts specify '/bin/sh' So it's another example of a distinction without a difference to single out bash. Most sysadmins cannot just switch to ZSH to to write their init scripts.

Debian and its many derivatives (including Ubunutu) use Dash, and the BSDs tend to use some form of Ash. I don't have the statistics but, if it's true that a majority of distros still use Bash for noninteractive use, it's a tiny majority.

Re: Systemd: The Biggest Fallacies

#12

Post by vlad003 »

astine wrote: post #9
felixgallo wrote: post #4

Earlier quoted context omitted.

It's not shell scripts, it's /bin/bash -- the guy fieri of shells.

Which also happens to be the default or expected shell in the majority of sysv installs on Linux. '/bin/sh' symlinks to bash, shell scripts specify '/bin/sh' So it's another example of a distinction without a difference to single out bash. Most sysadmins cannot just switch to ZSH to to write their init scripts.

On Ubuntu, since 6.10, Dash has been the default system shell rather than Bash. '/bin/sh' symlinks to '/bin/dash'.

Re: Systemd: The Biggest Fallacies

#13

Post by sciurus »

Some of these are arguments I'm glad to see getting more attention, such as Fallacy #1: "Systemd is multiple binaries, therefore it is not monolithic".

Others strike me as a stretch. For example, Fallacy #4.1: "Unit files reduce complexity". No, I don't want the least complex init system init system possible. I think it's obvious to people who have written both system v init scripts and systemd or upstart configurations that the latter are dramatic improvements. The chance that I will write a buggy init script is, unfortunately, high. The chance that I will need to debug systemd when writing a unit file is very low.

Re: Systemd: The Biggest Fallacies

#14

Post by [deleted] »

astine wrote: post #9
felixgallo wrote: post #4

Earlier quoted context omitted.

It's not shell scripts, it's /bin/bash -- the guy fieri of shells.

Which also happens to be the default or expected shell in the majority of sysv installs on Linux. '/bin/sh' symlinks to bash, shell scripts specify '/bin/sh' So it's another example of a distinction without a difference to single out bash. Most sysadmins cannot just switch to ZSH to to write their init scripts.

[deleted]

Re: Systemd: The Biggest Fallacies

#15

Post by astine »

"For Internet socket activation, all you have to do is start your daemon the old way, have it bind on the port, and let it sit there idly. If the kernel needs the RAM, it will swap the (idle) daemon to disk. If the kernel receives an incoming connection, it will swap the daemon back into RAM so it can handle it. Systemd doesn't need to be involved at all here."

So you want me to patch my Postgres instance to implement this? Or should I just do it in the init script? I guess that's possible, but it requires your sysadmin also be a programmer.

Re: Systemd: The Biggest Fallacies

#16

Post by astine »

bronson wrote: post #11
astine wrote: post #9

Earlier quoted context omitted.

Which also happens to be the default or expected shell in the majority of sysv installs on Linux. '/bin/sh' symlinks to bash, shell scripts specify '/bin/sh' So it's another example of a distinction without a difference to single out bash. Most sysadmins cannot just switch to ZSH to to write their init scripts.

Debian and its many derivatives (including Ubunutu) use Dash, and the BSDs tend to use some form of Ash. I don't have the statistics but, if it's true that a majority of distros still use Bash for noninteractive use, it's a tiny majority.

Well, a lot of them then... I know that Arch and Gentoo at least use Bash and I'd be surprised if they were the only ones.

Re: Systemd: The Biggest Fallacies

#17

Post by wmf »

astine wrote: post #15

"For Internet socket activation, all you have to do is start your daemon the old way, have it bind on the port, and let it sit there idly. If the kernel needs the RAM, it will swap the (idle) daemon to disk. If the kernel receives an incoming connection, it will swap the daemon back into RAM so it can handle it. Systemd doesn't need to be involved at all here." So you want me to patch my Postgres instance to implemen…

That's how daemons normally work. The author is obliquely pointing out that socket activation isn't that much of a benefit. Historically, "socket activation" using inetd was common but as hardware got cheaper people gradually dropped inetd in favor of just starting all their daemons at startup.

Re: Systemd: The Biggest Fallacies

#18

Post by jojo3000 »

Some of his arguments look a little bit botched.

For example: > Fallacy #1: "Systemd is multiple binaries, therefore it is not monolithic"

Well following Wikipedia (http://en.wikipedia.org/wiki/Monolithic_application) means either a non-modular application, or a self-contained application. In this sense either his counter-argument is simply wrong, or the examples list he gives at the and is wrong.

> Fallacy #4.1: "Unit files reduce complexity"

Here he compares the ca. 275.000 LoC of systemd with the 10.000 LoC of shell scripts used as initscripts on Debian. Lets ignore that the 275.000 LoC contains much more than the unit management in the systemd daemon. But why are the bugs always in the scripts and never in the shell as he claims? And sorry, I don't take his word that C is always more error prone than the shell. This is true when the shell is used for its intended purpose: to start commands, pipe btw them and having a little bit of flow control. For everything else you surely want to have a general purpose language.

> Fallacy #7: "Systemd gives you socket activation!"

Well, according to boot charts, socket activation is not only a marketing gimmick.

EDIT: Add Fallacy 7

Re: Systemd: The Biggest Fallacies

#19

Post by wmf »

sciurus wrote: post #13

Some of these are arguments I'm glad to see getting more attention, such as Fallacy #1: "Systemd is multiple binaries, therefore it is not monolithic". Others strike me as a stretch. For example, Fallacy #4.1: "Unit files reduce complexity". No, I don't want the least complex init system init system possible. I think it's obvious to people who have written both system v init scripts and systemd or upstart configurati…

Really the only "monolithic" problems I see are with journald and logind. For the other pieces people don't want to use them and they don't have to. The fact that e.g. networkd can't run without systemd is fairly irrelevant since no one is asking for that; they're asking to not run networkd which works fine.

Re: Systemd: The Biggest Fallacies

#20

Post by SwellJoe »

sciurus wrote: post #13

Some of these are arguments I'm glad to see getting more attention, such as Fallacy #1: "Systemd is multiple binaries, therefore it is not monolithic". Others strike me as a stretch. For example, Fallacy #4.1: "Unit files reduce complexity". No, I don't want the least complex init system init system possible. I think it's obvious to people who have written both system v init scripts and systemd or upstart configurati…

This. I would have been happy with anything that turned initscripts, which are often hundreds of lines, including tons of decisions and variables, into a simple declarative conifguration file. systemd seems to do OK at that, though I am vaguely uncomfortable with how tightly coupled things are in a systemd system.
Post reply on HN