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

21–30 of 54 posts

Re: Systemd: The Biggest Fallacies

#21

Post by [deleted] »

uselessdguy wrote: post #8
zanny wrote: post #7

I am getting so sick of these blogs for or against systemd. It is free software. If you do not want to use it, use a distro without it. And vice versa if you want it. And if you don't like that Debian or Canonical or Arch a few years back or OpenSuse have switched to using it... too bad, you are not the maintainer of the repos, and if you were an active member of the community with voting power, you were outvoted. Th…

It's obvious you didn't even read the article. EDIT: I don't know the motivation for the downvotes. I replied like this because the commenter posted a canned cookie-cutter reply that is addressed in the article as Fallacy #6.1.

[deleted]

Re: Systemd: The Biggest Fallacies

#22

Post by dnr »

He's missing the point about socket activation. The problem it solves is different: if you have daemon B that depends on daemon A, you want to express that dependency in the init system, so that it starts A before B. But just starting process A isn't enough to ensure that A is actually listening on the socket that B wants to connect to, since it takes some time to load the binary and do initialization. There's a race condition there, where B can try to connect before A binds to the socket. To fix the race, the init system needs to either monitor for the availability of the socket, or do it systemd-style where it opens the socket itself.

Re: Systemd: The Biggest Fallacies

#23

Post by general_failure »

zanny wrote: post #7

I am getting so sick of these blogs for or against systemd. It is free software. If you do not want to use it, use a distro without it. And vice versa if you want it. And if you don't like that Debian or Canonical or Arch a few years back or OpenSuse have switched to using it... too bad, you are not the maintainer of the repos, and if you were an active member of the community with voting power, you were outvoted. Th…

Terrible logic. With this kind of logic anything can be justified.

Re: Systemd: The Biggest Fallacies

#24

Post by marcosdumay »

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…

The postgres daemon already works that way. Nearly every daemon that listen to a socket works that way (a few don't, surprizingly).

That's the point.

Re: Systemd: The Biggest Fallacies

#25

Post by vinkelhake »

> Fallacy #2: "Lots of people use systemd, therefore you should too" > This is a classic example of the bandwagon fallacy.

On the other hand, network effects are real. You'll have an easier time finding help if the system you use is used by many others.

Re: Systemd: The Biggest Fallacies

#26

Post by felixgallo »

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.

You've already been corrected with regard to the rest of your argument, but I'll correct you on the last part too: they could do so just fine. That's the power of a modular, non-tightly coupled system. Any script that uses ksh, zsh, bash, csh, tcl, lua, rc, whatever, runs fine under sysvinit.

Re: Systemd: The Biggest Fallacies

#27

Post by lobster_johnson »

jojo3000 wrote: post #18

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: "…

I think we need a separate term for "internal modularity" (Linux, Systemd) and "external modularity" (Unix, the Internet).

The former depends on internal interfaces, where individual modules help separating concerns but can't be swapped out or reused in other contexts, whereas the latter relies on formal interfaces, allow components to be swapped, and promote reusability. (Also, the former can be monolithic or not, but the latter can never be monolithic.)

"Unixy" is sometimes used, but it's not a great term.

Re: Systemd: The Biggest Fallacies

#28

Post by astine »

wmf wrote: post #17
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.

I understand the author's point; he's not being oblique at all. I just disagree. He explicitly claims that the kernel providing socket functionality is enough. But it's not. The example using mkfifo for example, is terrible for instance. It provides no lifecycle management and you'll end up launch multiple versions of a daemon if you accidentally send multiple signals to the pipe. There is a huge difference between "this is technically possible," and this is doable in a way that doesn't have many unforeseen pitfalls. Systemd asks much less of professionals than sysv and that's it's chief selling point.

Re: Systemd: The Biggest Fallacies

#29

Post by imanaccount247 »

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…

>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

Except that is a false dilemma, which he points out. Sysv init takes more work because nobody has bothered to fix it. You don't need a massive complex set of software like systemd to make this easy, see the BSDs init scripts like he suggests.

Re: Systemd: The Biggest Fallacies

#30

Post by astine »

felixgallo wrote: post #26
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.

You've already been corrected with regard to the rest of your argument, but I'll correct you on the last part too: they could do so just fine. That's the power of a modular, non-tightly coupled system. Any script that uses ksh, zsh, bash, csh, tcl, lua, rc, whatever, runs fine under sysvinit.

No, my point is that you cannot just take a script written for bash and run it on Zsh or Ksh and expect it to just work. (Well, sometimes you can, but that's beside the point.) Yes you can write your init scripts in whatever language you want, even Lisp or Python, but you have to do that for every daemon you switch over. Imagine a lot of these Linux distros which often implement their own init scripts for each program they support having to switch shells. That's hundreds of scripts to rewrite, or at least proofread and test.
Post reply on HN