Live data from Hacker News

Why pro-systemd and anti-systemd people will never get along

uselessd.darknedgy.net

31–40 of 113 posts

Re: Why pro-systemd and anti-systemd people will never get along

#31
post #21
post #13

Earlier quoted context omitted.

I think the point is that you can't have two competing init systems: the market will eventually need to standardize on one of them or risk forking the entire Linux ecosystem. What you call "modern sysv" would look a lot like systemd depending on your definition of modern. I think that definition of what modern should look like is what's being debated here. The big features sysvinit are missing require user space appl…

We've had multiple competing init systems for years without forking the entire Linux ecosystem any worse than before.

Because they all largely did the same things that sysv did with a few bolt-on features. After many years, it's become apparent that approach won't work when you need multiple processes to be able to coordinate and schedule threads, power management, etc. Things need to be done at the hardware level, and sometimes those need to be triggered from user applications. But you can't have random applications tinkering in the kernel, so systemd arose and took over a number of those functions.

So I guess I can amend that to say "you can't have multiple init systems that do the things that systemd does".

Re: Why pro-systemd and anti-systemd people will never get along

#32
The referenced article that criticizes both SysV and BSD inits is from 2002. BSD systems have had separate scripts in a folder (rc.d) since, like, forever. And "[package installation] needs to edit one of the existing boot scripts" is the only criticism there.

There might be more current issues, but I believe it's good enough. For example, BSD init doesn't have super web scale auto restarting and monitoring and log routing. Well... it doesn't need to. Just use it to launch supervisord or something. Also, it's not super fast because it uses the shell. Again, it doesn't need to be. It's fast enough for general purpose servers and desktops. For special cases like containers and whatnot you need special tools.

Re: Why pro-systemd and anti-systemd people will never get along

#33

It will be very interesting to see how this all plays out in the long run, though the short term is utterly depressing. My hunch is Lennart will be vindicated, on the basis that systemd as it exists right now is not right, but it can be evolved into something much better, and while that may not have occurred to other projects here the stakes are enormous. There is a definite strand to the resistance that any change t…

Shell scripting isn't "archaic nonsense" at all, it's just that the warts from how most shells implement their command language (ksh/bash/POSIX sh) are holding us back. If you go look at Plan 9 rc shell scripts, you'll see how much cleaner they are. In addition, the s6 people have done some interesting things with execline (which looks kind of like Tcl), which works as a chain loader instead of holding the shell resi…

> The more I realize all the untapped potential lying around, the more I realize how so many Linux users are living in their monoculture. Unfortunately there is no one there to amplify all the good efforts and hidden gems scattered all over the place, so you have people just reading Phoronix and LWN articles and standing in their bubble. Meanwhile, all the non-Linux Unices and the "toy project" builders are doing great things, but everyone thinks they're irrelevant and dying.

This is one of the main reasons I approve of systemd. It is something completely new fighting against the old entrenched cruft. End result might be good, might be bad, but at least it is activity instead of sedateness.

For all bad things that could be said about Poettering, at least he has ideas and the confidence to execute on them.

Re: Why pro-systemd and anti-systemd people will never get along

#34
post #12

Earlier quoted context omitted.

At least one of each side of the debate. Preferable there should be two, one on each side which implements the good/novel ideas and others where aggressive experimentation takes part.

Just to be clear: I know that among the bigger projects it's just GNOME3 that is planning to hard-depend on systemd and even they want a shim, externnal or internal, to accomodate systemd-less systems (not necessarily BSDs, maybe other linux distros too). Currently systemd is very much optional (opt-out, not opt-in, learn the difference) and I personally mantain an Arch flavour that uses sinit, smdev and a bunch of o…

TBH, I currently feel the same way because of the opt-out, not opt-in situation. On one machine running Debian Sid I just found myself running systemd after an dist-upgrade..blowing my mind considering that I didn't choose Arch in the first place for the rolling release machine because of the systemd. But GNOME3 is to blame making systemd a hard dependency(Even if they mostly seem to be from the same camp, RH).

Re: Why pro-systemd and anti-systemd people will never get along

#35
post #31
post #21

Earlier quoted context omitted.

We've had multiple competing init systems for years without forking the entire Linux ecosystem any worse than before.

Because they all largely did the same things that sysv did with a few bolt-on features. After many years, it's become apparent that approach won't work when you need multiple processes to be able to coordinate and schedule threads, power management, etc. Things need to be done at the hardware level, and sometimes those need to be triggered from user applications. But you can't have random applications tinkering in th…

Because they all largely did the same things that sysv did with a few bolt-on features.

That is a total misrepresentation, I'm sorry. The fact is SysV was probably one of the weakest init systems around, besides deliberately minimal ones like busybox-init and sinit.

I devoted the "sysvinit: the eternal red herring" section precisely to debunk that. I just want people to stop comparing everything to SysV, because it only demonstrates that you're unwashed or closed-minded more than anything. The recent parody site forkfedora.org really aggravated me for that same reason. Instead of doing some witty response to the Debian fork stupidity, they just basically posted "LOL look at this SysV initscript, and now this systemd service file. Checkmate, systemd-haters!"

Much to my disappointment, people keep committing the same fallacies even when discussing an article meant to try and silence them at least this one time. I guess it only proves my point, I don't know.

Re: Why pro-systemd and anti-systemd people will never get along

#36
post #16
post #2

Could someone ELI5 this pro-systemd/anti-systemd thing?

Linux/unix has a bit of an issue with it's init aging systems. One simple example is that they are serial, meaning that services start one by one with little to no concurrency. This causes several issues. Also, the most popular variant, system V is difficult to maintain having multiple directories for various run levels and other cumbersome features. I won't go into details here, just know that the popular init syste…

Could someone just fork systemd and make a version that relaces the init system and nothing else?

Re: Why pro-systemd and anti-systemd people will never get along

#37
What I really dislike about these debates about systemd is that usually nobody mentions the alternatives. From reading the debate I get the impression that both sysvinit and systemd have major problems, but I'm never presented with a solution. So if I'm going to be against sysvinit as well as systemd, then what should i be supporting?

Re: Why pro-systemd and anti-systemd people will never get along

#38
post #25
post #13

Earlier quoted context omitted.

I think the point is that you can't have two competing init systems: the market will eventually need to standardize on one of them or risk forking the entire Linux ecosystem. What you call "modern sysv" would look a lot like systemd depending on your definition of modern. I think that definition of what modern should look like is what's being debated here. The big features sysvinit are missing require user space appl…

They're good points, but from the philosophical point The Unix Way , systemd leaves some things to desire. Is there a modern Unix way? I don't see a lot of exploring in this area/side, but I see a lot of this is the way it's gonna be from now on on the other side. I'm not on either side, but I appreciate the way some complexity is dealt with simple little things. So elegantly solving problems: https://www.youtube.com…

I'm not on either side myself, either. But "this is the way we've always done things" is a terrible reason to keep doing them that way. Systems change, requirements change, and so implementations and methods must change as well. I'm not saying this is warranted or not in the case of systemd (I don't know enough of the details to opine either way) but it has been a cultural problem in the Linux community for a number of years. Modern use cases require a more coordination between multiple parts of the system, which is I think where a lot of the friction comes from.

The entire systemd debate is as bad as it is because this is a can that has been kicked down the road for two decades because nobody wanted to have the same argument again. Everyone has known for a long time that at some level, Linux needed better coordination between user applications, hardware, and system services. systemd seems to deliver on most of the functional requirements of such a system, though the implementation method has upset some people on a philosophical level because they believe it's counter to the Unix way, whatever that means.

I would argue that software development in general has drifted away from "the Unix way". Modern software development is a mess of dependencies, abstraction layers, control points and dominant standards controlled by individuals/companies with a vested interest. Linux is a good counterbalance to that, but at the same time it can't stray too far away from the way that people use systems or it becomes too outdated to matter. Is systemd the answer? Who knows. But in the absence of something that performs its function, companies will step up with proprietary solutions for their use cases (launchd on OS X/iOS, whatever Android uses) that lead to more walled gardens, not less.

Re: Why pro-systemd and anti-systemd people will never get along

#39
post #33

Earlier quoted context omitted.

Shell scripting isn't "archaic nonsense" at all, it's just that the warts from how most shells implement their command language (ksh/bash/POSIX sh) are holding us back. If you go look at Plan 9 rc shell scripts, you'll see how much cleaner they are. In addition, the s6 people have done some interesting things with execline (which looks kind of like Tcl), which works as a chain loader instead of holding the shell resi…

> The more I realize all the untapped potential lying around, the more I realize how so many Linux users are living in their monoculture. Unfortunately there is no one there to amplify all the good efforts and hidden gems scattered all over the place, so you have people just reading Phoronix and LWN articles and standing in their bubble. Meanwhile, all the non-Linux Unices and the "toy project" builders are doing gre…

> This is one of the main reasons I approve of systemd. It is something completely new fighting against the old entrenched cruft.

Most people aren't anti-systemd because it's new, but because it doesn't conform to their philosophy of how their computer should run. There could be newer init systems that conform to their ideals, but systemd is not one of them.

Re: Why pro-systemd and anti-systemd people will never get along

#40
post #34

Earlier quoted context omitted.

Just to be clear: I know that among the bigger projects it's just GNOME3 that is planning to hard-depend on systemd and even they want a shim, externnal or internal, to accomodate systemd-less systems (not necessarily BSDs, maybe other linux distros too). Currently systemd is very much optional (opt-out, not opt-in, learn the difference) and I personally mantain an Arch flavour that uses sinit, smdev and a bunch of o…

TBH, I currently feel the same way because of the opt-out, not opt-in situation. On one machine running Debian Sid I just found myself running systemd after an dist-upgrade..blowing my mind considering that I didn't choose Arch in the first place for the rolling release machine because of the systemd. But GNOME3 is to blame making systemd a hard dependency(Even if they mostly seem to be from the same camp, RH).

systemd provides things and does things that are useful. That is why GNOME depends on those. Blaming us? Try actually understanding why. It's not a hard dependency btw, you still have ConsoleKit support. A project not maintained for almost 3 years or so. Then there is that systemd-shim. Initially very very buggy, but now ok-ish. OpenBSD is working on some shim thing as well.
Post reply on HN