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

31–40 of 54 posts

Re: Systemd: The Biggest Fallacies

#31

Post by pessimizer »

uselessdguy wrote: post #10

First of all, thanks for linking to uselessd. The writeup was quite nice. I was actually in the process of writing my own notes to respond to Poettering's "The Biggest Myths", but your approach is better. I'll definitely use it as a reference to link to in discussions. That said, I have a little caveat for #9. Though systemd violating KISS is virtually undeniable, you should reword it so as to point it out on systemd…

I have absolutely no idea why this comment has been voted to the bottom of the page. Friendly, innocuous, and thoughtful.

Re: Systemd: The Biggest Fallacies

#32

Post by ptx »

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…

Well, following your line of reasoning: If you don't like these articles, too bad! You have been outvoted. Go build your own news website from scratch.

Re: Systemd: The Biggest Fallacies

#33

Post by pessimizer »

general_failure wrote: post #23
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.

Looks like 'you can do it, or you can not do it, or somebody you depend on can do it, and if you don't like it you can leave, everybody has made the decision and you have lost, get out, yadda yadda' has been deemed a good argument in this thread. Scary.

Re: Systemd: The Biggest Fallacies

#34

Post by snogglethorpe »

vinkelhake wrote: post #25

> 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.

... and in this case systemd is popular not because users decided to use it, but because distributions decided to use it, which means that systemd is going to have a stronger support network and more developer attention than a system which is not popular.

Good support and active development are pretty big advantages.

Re: Systemd: The Biggest Fallacies

#35

Post by profsnuggles »

astine wrote: post #16
bronson wrote: post #11

Earlier quoted context omitted.

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.

Arch is using systemd and openrc comitted to using POSIX sh in their init scripts some time ago. So you can use dash or whatever posix compatible shell you want with it.

Re: Systemd: The Biggest Fallacies

#36

Post by rdtsc »

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

270k lines sure do a lot more, but I don't want to do more, I just want my machine to boot.

If it doesn't boot I want to debug shell scripts not muddle through thousands of lines of C dealing the time syncing or socket activation.

Re: Systemd: The Biggest Fallacies

#37

Post by TheCondor »

imanaccount247 wrote: post #29
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.

That doesn't really invalidate the argument. Upstart and systemd units are dramatically easier and less bug prone than the existing sysv alternative. If it was nontrivial to fix they would have.

The missing beef here is actual bugs and problems with systemd. Post some zero days... Nobody challenges that businesses with paying customers all indepdently came up with the need for smf, launchd, upstart, and systemd. Are they just adding shit to add it or do the see value and need?

Re: Systemd: The Biggest Fallacies

#38

Post by jerf »

dnr wrote: post #22

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…

As a bit of a disinterested observer (I'm mostly in the "just make it work" camp), I can't help but feel that if you pile up the problems that systemd seems to solve on one side, and pile up the enormous piles of code that are apparently necessary to solve the problem on the other, that systemd does not come out looking too good.

(Writing this in C was probably a silly idea.)

Re: Systemd: The Biggest Fallacies

#39

Post by imanaccount247 »

TheCondor wrote: post #37
imanaccount247 wrote: post #29

Earlier quoted context omitted.

>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.

That doesn't really invalidate the argument. Upstart and systemd units are dramatically easier and less bug prone than the existing sysv alternative. If it was nontrivial to fix they would have. The missing beef here is actual bugs and problems with systemd. Post some zero days... Nobody challenges that businesses with paying customers all indepdently came up with the need for smf, launchd, upstart, and systemd. Are…

> If it was nontrivial to fix they would have.

There is no basis for that assertion. It is trivial to fix, again, see BSDs. Just because nobody bothers (or people bother and their effort is rejected due to politics) doesn't mean it is nontrivial.

Re: Systemd: The Biggest Fallacies

#40

Post by stonith »

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…

Apologies if you already knew this, but you may be interested in pleaserun[1] which attempts to manage the differences in init formats from a common interface.

It's still quite new but I've been reasonably happy with it so far. I did have to extend it a little to allow commands like bootstrapping for clustered software.

[1] https://github.com/jordansissel/pleaserun

Post reply on HN