8 ms·

Well, I don't know anybody in the FOSS community which would be worried it systemd became endangered ;)

ddingus 8y ago
You win! Truth I know. It is perfectly OK. I will bever be a fan of systemd.
bdavis__ 8y ago
redhat had a lot of love in the world. any other vendor that shoved systemd down everyones throat would have been villified. redhat was given a pass. (karma, anyone?)
- village-idiot 8y ago
  Indeed. Canonical tried and failed, hard.
- icebraining 8y ago
  Karma? Red Hat shareholders will be getting a 60% premium over the current value.. if it's karma, then pushing systemd was a good action.
pritambaral 8y ago
1. Every distro that already uses systemd (which is close to 100%) 2. (Close to 100% of) packagers and maintainers of system services 3. System administrators using distros from #1 (which is, again, practically everyone)
- dijit 8y ago
  The warnings for #1 were clear. Nobody wanted to hear or heed them. I have little sympathy for those that adopted it despite many people begging them (distro maintainers) not to.
  - geofft 8y ago
    I do not think that there were any clear warnings that you should avoid using systemd because it's good software that might stop being developed soon. I also don't think avoiding using systemd solves the problem. My preferred alternative to an abandoned systemd is a well-developed systemd, not sysvinit.
    - dijit 8y ago
      >because it's good software that might stop being developed soon. Having looked at the code. Calling it good software is a dubious proposition at best. As mentioned in another comment. There are other init replacements that are seeking to solve the same issues as systemd. I bet you can’t name them though since they were never properly evaluated.
      - acdha 8y ago
        Of all the standard anti-systemd talking points this one is one of the most puzzling rejections of reality. Every major distribution reviewed the landscape. Look through https://wiki.debian.org/Debate/initsystem/systemd https://wiki.debian.org/Debate/initsystem/systemd and all of the votes, countless threads, etc. You can disagree with the conclusions but it’s just absurd to say that people weren’t aware that there were alternatives.
        dijit 8y ago
        In the end it was a tie in the Debian technical committee. The chairman’s vote was counted twice so systemd won. Then the people who had voted for systemd resigned rather than actually implement their choice. Not as cut and dry as you make it seem.
        geofft 8y ago
        This is just not true at all. (I'm a Debian package maintainer; I paid close attention to both the vote itself and the discussion around it.) Debian uses ranked preference voting. Of the nine committee members, only one ranked sysvinit above either systemd or upstart. The rest were split about which of the two, with systemd winning the tie-break vote, but both were acceptable choices to all eight. There was no tie about whether systemd would have been an acceptable choice; both systemd and upstart were accepted 8-to-1. The one member who voted in favor of sysvinit resigned after trying to start a general resolution (a vote of the entire project) to overrule the committee, and being told by basically everyone that this was inappropriate. He did not resign over systemd; he resigned, at best, over the process, and really I'd say he resigned because the project had lost confidence in him as someone able to act reasonably in contentious technical situations, which is basically the job of a technical committee member. Nobody on the technical committee had refused to implement systemd support. The technical committee is not an implementation body anyway, but none of the members have refused to, say, implement systemd support in their packages, and they all remain members of the project. All of this is public record, e.g.: https://lwn.net/Articles/585504/ https://lwn.net/Articles/585504/ (Also, none of what you said is a counterargument to the post you replied to.)
- severino 8y ago
  Now talking seriously, even if IBM stopped funding the project, it wouldn't be such a disaster. First of all, it's open source. A new mantainer could take over the project (for free) so the distributions can keep using it. But even if a replacement had to be found, the process wouldn't be traumatic... just like when Debian, the base of many other distributions, adopted systemd some years ago.
  - geofft 8y ago
    A new maintainer could take over the project, but Red Hat was funding their labor, and the chances that someone takes over the project and continues contributing regularly goes up significantly if their labor is reliably funded. (Working for a large company is not the only way to fund labor, but it seems to be the most common one in our society.) Similarly, having something worth switching to also depends on labor to develop such an alternative. Upstart is no longer funded, and was the closest (including in terms of mindshare that caused people to spend labor developing integration between their software and the init system).
    - severino 8y ago
      That's right, but we've plenty of "plumbing" software for the Linux ecosystem whithout funding companies behind, and they get regular contributions. The same should happen with the init system. Of course, it's different when the software pretends not just to be an init system but also a replacement for tons of other daemons like cron, inetd, networking, etc, making it a huge piece of software. But maybe that's the problem in the first place.
      - dfox 8y ago
        The point there is that most of the underlying user space plumbing of modern Linux system is in fact funded by Red Hat in one way or another. (And in this context it is probably useful to realize that on the kernel side of things the amount of funding from Red Hat and IBM is comparable)
        8y ago
eliaspro 8y ago
So you'd rather go back to Upstart or SysV? Really?
- throwaway76543 8y ago
  Yes, without question. Systemd provides me absolutely no benefit when running a server and adds considerable complexity and fragility in a critical component. A traditional SysV init is just fine. Want orchestrated service invocation on startup? Run it from SysV init instead of replacing SysV init. There is no need to conflate the "sysv rc system" with "sysv init." They are entirely separate things.
  - pcwalton 8y ago
    So you're saying to just use SysV init to launch processes from inittab, and have one of those processes be a systemd/launchd clone that launches everything else. I mean, I guess that's a possible design, but at that point I would question whether using the SysV init program is really buying you anything. In any case, most people wouldn't consider that design "SysV init". The SysV init ecosystem is built around rc files.
    - JdeBP 8y ago
      It's not only possible, it is how the System Resource Controller worked in AIX from version 3.2 back in 1992 onwards. srcmstr is run from an entry in inittab, which at the same time shrank to just one run level in real use. You have erroneously conflated rc and init, as others have pointed out.
    - throwaway76543 8y ago
      I teach unix internals to engineers as part of my job and I've found most engineers aren't intimately familiar with the distinction between the RC system and the init system at all. I agree there isn't widespread understanding of this distinction but I think it is because most engineers simply don't know how any of this works. The reason to keep these things modular is flexibility and ease of analysis and improvement. The major criticism I see with systemd is that has undefined operational scope and unbounded feature creep. It has no stable interface between components and changes behavior in incompatible and difficult to predict ways fairly regularly. From a systems perspective it's a big ball of mud and the lack of a formal interface makes it prohibitively difficult to change or replace its subsystems. I don't like that systemd performs ANSI animations on my machine's serial console, for example. Have you seen the "marquee" animations it does when certain services start? I sure would like to force it to print sequential lines of text instead, but I can't. I don't like that when systemd updated basic utilities like "reboot" I lost the ability to use them in a chroot. Even "reboot -f" which does not need to talk to init. I had to write my own one-liner to call reboot(2) myself not too long ago. System components need to be well scoped and replaceable. There's a major design problem brewing in this area.
MindTooth 8y ago
That made my day... Thank you :) Haven't laughed as hard in a while.
craftyguy 8y ago
I'm in the FOSS community and I like systemd, so find some other dead horse to beat.
dang 8y ago
Please don't troll threads, intentionally or not, by throwing in classic flamebait. It seems funny at the time, and then we get another systemd or whatever flamewar. We detached this subthread from https://news.ycombinator.com/item?id=18322395 https://news.ycombinator.com/item?id=18322395 and marked it off-topic.

You win! Truth I know. It is perfectly OK. I will bever be a fan of systemd.

redhat had a lot of love in the world. any other vendor that shoved systemd down everyones throat would have been villified. redhat was given a pass. (karma, anyone?)

village-idiot 8y ago
Indeed. Canonical tried and failed, hard.
icebraining 8y ago
Karma? Red Hat shareholders will be getting a 60% premium over the current value.. if it's karma, then pushing systemd was a good action.

pritambaral 8y ago

1. Every distro that already uses systemd (which is close to 100%) 2. (Close to 100% of) packagers and maintainers of system services 3. System administrators using distros from #1 (which is, again, practically everyone)

dijit 8y ago
The warnings for #1 were clear. Nobody wanted to hear or heed them. I have little sympathy for those that adopted it despite many people begging them (distro maintainers) not to.
- geofft 8y ago
  I do not think that there were any clear warnings that you should avoid using systemd because it's good software that might stop being developed soon. I also don't think avoiding using systemd solves the problem. My preferred alternative to an abandoned systemd is a well-developed systemd, not sysvinit.
  - dijit 8y ago
    >because it's good software that might stop being developed soon. Having looked at the code. Calling it good software is a dubious proposition at best. As mentioned in another comment. There are other init replacements that are seeking to solve the same issues as systemd. I bet you can’t name them though since they were never properly evaluated.
    - acdha 8y ago
      Of all the standard anti-systemd talking points this one is one of the most puzzling rejections of reality. Every major distribution reviewed the landscape. Look through https://wiki.debian.org/Debate/initsystem/systemd https://wiki.debian.org/Debate/initsystem/systemd and all of the votes, countless threads, etc. You can disagree with the conclusions but it’s just absurd to say that people weren’t aware that there were alternatives.
      - dijit 8y ago
        In the end it was a tie in the Debian technical committee. The chairman’s vote was counted twice so systemd won. Then the people who had voted for systemd resigned rather than actually implement their choice. Not as cut and dry as you make it seem.
        geofft 8y ago
        This is just not true at all. (I'm a Debian package maintainer; I paid close attention to both the vote itself and the discussion around it.) Debian uses ranked preference voting. Of the nine committee members, only one ranked sysvinit above either systemd or upstart. The rest were split about which of the two, with systemd winning the tie-break vote, but both were acceptable choices to all eight. There was no tie about whether systemd would have been an acceptable choice; both systemd and upstart were accepted 8-to-1. The one member who voted in favor of sysvinit resigned after trying to start a general resolution (a vote of the entire project) to overrule the committee, and being told by basically everyone that this was inappropriate. He did not resign over systemd; he resigned, at best, over the process, and really I'd say he resigned because the project had lost confidence in him as someone able to act reasonably in contentious technical situations, which is basically the job of a technical committee member. Nobody on the technical committee had refused to implement systemd support. The technical committee is not an implementation body anyway, but none of the members have refused to, say, implement systemd support in their packages, and they all remain members of the project. All of this is public record, e.g.: https://lwn.net/Articles/585504/ https://lwn.net/Articles/585504/ (Also, none of what you said is a counterargument to the post you replied to.)
severino 8y ago
Now talking seriously, even if IBM stopped funding the project, it wouldn't be such a disaster. First of all, it's open source. A new mantainer could take over the project (for free) so the distributions can keep using it. But even if a replacement had to be found, the process wouldn't be traumatic... just like when Debian, the base of many other distributions, adopted systemd some years ago.
- geofft 8y ago
  A new maintainer could take over the project, but Red Hat was funding their labor, and the chances that someone takes over the project and continues contributing regularly goes up significantly if their labor is reliably funded. (Working for a large company is not the only way to fund labor, but it seems to be the most common one in our society.) Similarly, having something worth switching to also depends on labor to develop such an alternative. Upstart is no longer funded, and was the closest (including in terms of mindshare that caused people to spend labor developing integration between their software and the init system).
  - severino 8y ago
    That's right, but we've plenty of "plumbing" software for the Linux ecosystem whithout funding companies behind, and they get regular contributions. The same should happen with the init system. Of course, it's different when the software pretends not just to be an init system but also a replacement for tons of other daemons like cron, inetd, networking, etc, making it a huge piece of software. But maybe that's the problem in the first place.
    - dfox 8y ago
      The point there is that most of the underlying user space plumbing of modern Linux system is in fact funded by Red Hat in one way or another. (And in this context it is probably useful to realize that on the kernel side of things the amount of funding from Red Hat and IBM is comparable)
      - 8y ago

eliaspro 8y ago

So you'd rather go back to Upstart or SysV? Really?

throwaway76543 8y ago
Yes, without question. Systemd provides me absolutely no benefit when running a server and adds considerable complexity and fragility in a critical component. A traditional SysV init is just fine. Want orchestrated service invocation on startup? Run it from SysV init instead of replacing SysV init. There is no need to conflate the "sysv rc system" with "sysv init." They are entirely separate things.
- pcwalton 8y ago
  So you're saying to just use SysV init to launch processes from inittab, and have one of those processes be a systemd/launchd clone that launches everything else. I mean, I guess that's a possible design, but at that point I would question whether using the SysV init program is really buying you anything. In any case, most people wouldn't consider that design "SysV init". The SysV init ecosystem is built around rc files.
  - JdeBP 8y ago
    It's not only possible, it is how the System Resource Controller worked in AIX from version 3.2 back in 1992 onwards. srcmstr is run from an entry in inittab, which at the same time shrank to just one run level in real use. You have erroneously conflated rc and init, as others have pointed out.
  - throwaway76543 8y ago
    I teach unix internals to engineers as part of my job and I've found most engineers aren't intimately familiar with the distinction between the RC system and the init system at all. I agree there isn't widespread understanding of this distinction but I think it is because most engineers simply don't know how any of this works. The reason to keep these things modular is flexibility and ease of analysis and improvement. The major criticism I see with systemd is that has undefined operational scope and unbounded feature creep. It has no stable interface between components and changes behavior in incompatible and difficult to predict ways fairly regularly. From a systems perspective it's a big ball of mud and the lack of a formal interface makes it prohibitively difficult to change or replace its subsystems. I don't like that systemd performs ANSI animations on my machine's serial console, for example. Have you seen the "marquee" animations it does when certain services start? I sure would like to force it to print sequential lines of text instead, but I can't. I don't like that when systemd updated basic utilities like "reboot" I lost the ability to use them in a chroot. Even "reboot -f" which does not need to talk to init. I had to write my own one-liner to call reboot(2) myself not too long ago. System components need to be well scoped and replaceable. There's a major design problem brewing in this area.

MindTooth 8y ago

That made my day... Thank you :) Haven't laughed as hard in a while.

craftyguy 8y ago

I'm in the FOSS community and I like systemd, so find some other dead horse to beat.

dang 8y ago

Please don't troll threads, intentionally or not, by throwing in classic flamebait. It seems funny at the time, and then we get another systemd or whatever flamewar. We detached this subthread from https://news.ycombinator.com/item?id=18322395 https://news.ycombinator.com/item?id=18322395 and marked it off-topic.