6 ms·

You missed some: https://lwn.net/Articles/621895/ https://lwn.net/Articles/621895/ https://lwn.net/Articles/621003/ https://lwn.net/Articles/621003/ https://lw

You missed some: https://lwn.net/Articles/621895/ https://lwn.net/Articles/621895/ https://lwn.net/Articles/621003/ https://lwn.net/Articles/621003/ https://lwn.net/Articles/620879/ https://lwn.net/Articles/620879/ https://lwn.net/Articles/620878/ https://lwn.net/Articles/620878/ https://lwn.net/Articles/619749/ https://lwn.net/Articles/619749/ They are related in the sense that are all fall-out of the struggle to integrate or block systemd in Debian and/or how it exposed some problems with the Debian constitution. It's a shame to see that so much talent is lost and frustrated over what in my eyes seems to be a small issue. systemd and Upstart are both a large improvement over the System V init scripts. So, it's quite logical that it should be replaced at some point. Since systemd seems to have the most traction in other major distributions and upstream software, it makes sense to make that the default, while making it still possible to switch to Upstart et al. if someone wants to (at the risk of losing support for some upstream software). If it turns out in three years that systemd is a dead-end, rip it out, and use whatever is better then. Distributions did that with devfs, the old hotplug scripts, egcs (which was merged back in mainline), etc.

zaphar 12y ago
I get the impression which is admittedly informed by very cursory examination of the issues that ripping systemd out may be far more difficult than ripping say, Upstart. Systemd seems to have taken the approach of owning far more than just the Systemv init stuff and that removing it might entail sweeping changes to huge parts of a linux distribution. Systemd does seem to be pushing somewhat of a lock-in strategy and for many in the linux community that rubs them the wrong way. Personally I don't really care much either way.
- danieldk 12y ago
  I get the impression which is admittedly informed by very cursory examination of the issues that ripping systemd out may be far more difficult than ripping say, Upstart. Definitely. But this is probably true for many things at a low-level in the stack. E.g., it would also be hard to replace D-BUS or the Linux kernel (as evidenced by the fact that Debian/KFreeBSD will probably not be in Jessy). I agree that it is a worry. But you can never make progress without taking any risks. We have tried 'fully isolated init' for years and it does not really work for modern systems/applications.
  - zaphar 12y ago
    We have tried 'fully isolated init' for years and it does not really work for modern systems/applications. I keep hearing this but I haven't seen any concrete reasons why it would be true. I'm curious what those reasons are. As I said I don't personally care that much as I work far enough up the stack to not be affected for the most part.
    - Xylakant 12y ago
      I think it's not a problem primarily with "init" itself, but for example that systemd provides you with the capability of starting a service "after network is up" so it needs to be able to tell "when network is up". That's much easier to do if there's a canonical (from systemds POV) way to tell "what's networks state". That again leads to "bah, let's do that ourselves" so there's now an optional systemd component that does this, that, this and people start relying on those - systemd-logind is a requirement for gnome. You could write a replacement for systemd-logind that offers the same functionality, but as long as nobody does, you're stuck with systemd. The way I see it is that the systemd developers just plowed a way through the undergrowth and produced a suite of components that provide functionality that's appealing for people to build on. That's an offering that was accepted and now other people complain that the "systemd people are forcing their system on us and I want sysV init". The right course of action would be "meh, don't like systemd, I'll build a better offering." Talk is cheap, code is what counts. I very much like systemd. It's documentation is actually long, but clear and well structured. The init component is much simpler than the mess of shell scripts used before. There certainly are problems and issues with it, but I've met problems and issues with about any kind of software I had to deal with so far (including my own), so I take that as a given.
      - e7620 12y ago
        Your response only makes sense if your alternatives are: (1) systemd, (2) sysvinit and (3) a horrible death. I know dozens of init systems that do much more, markedly better than systemd, and are modular so you can easily replace them when the time for a new technology comes. systemd is very recent, and still its opinionated architecture is showing inflexible to changes.
lmm 12y ago
Systemd is seemingly deliberately designed to be difficult to replace. And it causes problems on some Debian platforms right now - as someone who was about to install Debian/kFreeBSD on a server, I am now very worried about the project's future.
- digi_owl 12y ago
  Yep. right around the announcement of the GR there was a bug reported where installing one package would result in pam-systemd getting pulled in, and then it would cascade until sysv was replaced by systemd. I do wonder how many such bugbears there will be before there is a collective "fuck this" and just a blanket mandate of requiring systemd components everywhere...
  - the_why_of_y 12y ago
    It's not a problem to have systemd installed; on Debian it doesn't actually run as init unless you install the systemd-sysv package.
Shish2k 12y ago
I'm starting to wonder if this is a problem with modern culture in general -- all over the place I'm seeing less "let's try our different approaches and see who has the best end result" and more "I will rape you to death with a flaming donkey for not running your project my way". It's like nobody wants to do any work to demonstrate that their way is superior, they just want to sit back and bitch about how the other way is inferior, until the other team gives up and our overall result is nothing :-/ (See also: both sides on pretty much any political issue in the past few years)
- jmnicolas 12y ago
  "rape you to death with a flaming donkey" Dude ...
  - jmnicolas 12y ago
    Downvote all you want, but this expression needed a reaction ! Of course English being not my mother tongue I didn't have enough vocabulary to express my distress at the mental picture that exploded in my brain when I read those words. I thought "dude" conveyed best my disgust, puzzlement and amazement :-) I don't hate you though.
- jjoonathan 12y ago
  Both sides did lots of work to make their solution better and each side had a sizable list of legitimate advantages over the other. The ultimate decision came down to a subjective value judgement about which advantages were more important and inevitably wound up ignoring about half of those honestly held priorities (not to mention the work that went into Upstart). I don't see how it could have happened any other way. It's sad that people resigned over it but the pain itself seems unavoidable from where I'm sitting.
  - Shish2k 12y ago
    > the pain itself seems unavoidable from where I'm sitting. If there's enough time and energy in the community to be throwing death threats around, surely there is enough energy to maintain debian/systemd and debian/upstart as separate distros, both of which live happily ever after, sharing the 99.999% of code and infrastructure that they have in common? Then if one side really IS technically superior, people will naturally end up moving to that one and the other will die a gentle natural death, no personal attacks and resignations needed. (For example, see what happened when Canonical wanted Debian to be more apple-like -- they didn't send death threats to Debian developers, they just did the work that they wanted to see done, and now both projects are a great success)
exarch 12y ago
>systemd and Upstart are both a large improvement over the System V init scripts. Userland utils like wget depending on a specific init package is a large improvement over sysvinit? Nope.
- pantalaimon 12y ago
  How is wget depending on systemd?
  - Macha 12y ago
    So I had to look this up. On Arch at least, wget depends on util-linux (package containing kernel tools like mount, dmesg etc.): https://www.archlinux.org/packages/extra/x86_64/wget/ https://www.archlinux.org/packages/extra/x86_64/wget/ And util-linux depends on systemd: https://www.archlinux.org/packages/core/x86_64/libutil-linux/ https://www.archlinux.org/packages/core/x86_64/libutil-linux... I have to assume this is Arch-specific, because I can't anything that basic as util-linux including a dependency on a specific init tool (and given there are still distros using other inits than systemd and still working fine...)
    - 1_player 12y ago
      The systemd is a make dependency only. Unless you plan on compiling it yourself, you don't need systemd to run it. ~ $ y -Qi libutil-linux | grep Depends Depends On : None EDIT: conversely, these are the packages depending on systemd: ~ $ y -Qi systemd | grep Required | fmt Required By : accountsservice chromium colord crda cups device-mapper gnome-session lib32-systemd libgdm libgusb libpulse libusb libvirt libwacom lvm2 media-player-info mesa mkinitcpio netctl polkit procps-ng qt5-base qtwebkit rtkit spotify subversion systemd-sysvcompat udisks2 upower xf86-input-evdev xf86-video-ati xf86-video-modesetting As a sysadmin and developer I don't understand this systemd-hate. If you ever have written a /etc/init.d script for a python non-daemoning script running in a virtualenv, or something to the same effect, you'd notice the improvement over SysV init scripts. Upstart is nice too, but as a Linux desktop user I love socket activation: I can have cups, avahi and other optional/non-critical daemons "active" but not actually using any resource, until effectively used by some other process.
porker 12y ago
I look forward to seeing what these people will all create now they're not involved in Debian. It's not a good situation, but it does mean there's talent free to tinker with new ideas.
rasz_pl 12y ago
>Since systemd seems to have the most traction Windows has even more traction, how about replacing all distributions with windows then?
- baldfat 12y ago
  How does another OS have anything to do with the need of replacing init system? Systemd has been very good for me in Arch and in OpenSUSE for me. I feel like it is a much better tool for my needs.
npsimons 12y ago
Debian has ports to FreeBSD and HURD; systemd doesn't support anything but Linux. I would assume that this would make systemd a non-starter in Debian (especially since there are no technical reasons systemd couldn't be ported). There are also other issues. Yes, sysvinit doesn't parallelize scripts or do automatic dependencies. If that's all systemd fixed, I'm sure everyone would be for it. But systemd seems to be consuming everything in its path (logging, cron, etc), ignoring the well-proven and time-tested design tenet of "do one thing well".
- makomk 12y ago
  I think Debian's supported parallel script execution and dependency resolution on top of sysvinit for a while anyway. It's not a true dependency-based init because the dependencies are resolved at configuration time rather than runtime, but whether that matters depends on what you're doing.
- the_why_of_y 12y ago
  The reason why sysvinit runs on FreeBSD and HURD kernels is that those kernels have implemented the Linux procfs file system. https://teythoon.cryptobitch.de/posts/on-portability-of-init-systems/ https://teythoon.cryptobitch.de/posts/on-portability-of-init... Besides, none of these are release architectures, so why should their limitations restrict what features >99.9% of Debian users have available?

zaphar 12y ago

I get the impression which is admittedly informed by very cursory examination of the issues that ripping systemd out may be far more difficult than ripping say, Upstart. Systemd seems to have taken the approach of owning far more than just the Systemv init stuff and that removing it might entail sweeping changes to huge parts of a linux distribution. Systemd does seem to be pushing somewhat of a lock-in strategy and for many in the linux community that rubs them the wrong way. Personally I don't really care much either way.

danieldk 12y ago
I get the impression which is admittedly informed by very cursory examination of the issues that ripping systemd out may be far more difficult than ripping say, Upstart. Definitely. But this is probably true for many things at a low-level in the stack. E.g., it would also be hard to replace D-BUS or the Linux kernel (as evidenced by the fact that Debian/KFreeBSD will probably not be in Jessy). I agree that it is a worry. But you can never make progress without taking any risks. We have tried 'fully isolated init' for years and it does not really work for modern systems/applications.
- zaphar 12y ago
  We have tried 'fully isolated init' for years and it does not really work for modern systems/applications. I keep hearing this but I haven't seen any concrete reasons why it would be true. I'm curious what those reasons are. As I said I don't personally care that much as I work far enough up the stack to not be affected for the most part.
  - Xylakant 12y ago
    I think it's not a problem primarily with "init" itself, but for example that systemd provides you with the capability of starting a service "after network is up" so it needs to be able to tell "when network is up". That's much easier to do if there's a canonical (from systemds POV) way to tell "what's networks state". That again leads to "bah, let's do that ourselves" so there's now an optional systemd component that does this, that, this and people start relying on those - systemd-logind is a requirement for gnome. You could write a replacement for systemd-logind that offers the same functionality, but as long as nobody does, you're stuck with systemd. The way I see it is that the systemd developers just plowed a way through the undergrowth and produced a suite of components that provide functionality that's appealing for people to build on. That's an offering that was accepted and now other people complain that the "systemd people are forcing their system on us and I want sysV init". The right course of action would be "meh, don't like systemd, I'll build a better offering." Talk is cheap, code is what counts. I very much like systemd. It's documentation is actually long, but clear and well structured. The init component is much simpler than the mess of shell scripts used before. There certainly are problems and issues with it, but I've met problems and issues with about any kind of software I had to deal with so far (including my own), so I take that as a given.
    - e7620 12y ago
      Your response only makes sense if your alternatives are: (1) systemd, (2) sysvinit and (3) a horrible death. I know dozens of init systems that do much more, markedly better than systemd, and are modular so you can easily replace them when the time for a new technology comes. systemd is very recent, and still its opinionated architecture is showing inflexible to changes.

lmm 12y ago

Systemd is seemingly deliberately designed to be difficult to replace. And it causes problems on some Debian platforms right now - as someone who was about to install Debian/kFreeBSD on a server, I am now very worried about the project's future.

digi_owl 12y ago
Yep. right around the announcement of the GR there was a bug reported where installing one package would result in pam-systemd getting pulled in, and then it would cascade until sysv was replaced by systemd. I do wonder how many such bugbears there will be before there is a collective "fuck this" and just a blanket mandate of requiring systemd components everywhere...
- the_why_of_y 12y ago
  It's not a problem to have systemd installed; on Debian it doesn't actually run as init unless you install the systemd-sysv package.

Shish2k 12y ago

I'm starting to wonder if this is a problem with modern culture in general -- all over the place I'm seeing less "let's try our different approaches and see who has the best end result" and more "I will rape you to death with a flaming donkey for not running your project my way". It's like nobody wants to do any work to demonstrate that their way is superior, they just want to sit back and bitch about how the other way is inferior, until the other team gives up and our overall result is nothing :-/ (See also: both sides on pretty much any political issue in the past few years)

jmnicolas 12y ago
"rape you to death with a flaming donkey" Dude ...
- jmnicolas 12y ago
  Downvote all you want, but this expression needed a reaction ! Of course English being not my mother tongue I didn't have enough vocabulary to express my distress at the mental picture that exploded in my brain when I read those words. I thought "dude" conveyed best my disgust, puzzlement and amazement :-) I don't hate you though.
jjoonathan 12y ago
Both sides did lots of work to make their solution better and each side had a sizable list of legitimate advantages over the other. The ultimate decision came down to a subjective value judgement about which advantages were more important and inevitably wound up ignoring about half of those honestly held priorities (not to mention the work that went into Upstart). I don't see how it could have happened any other way. It's sad that people resigned over it but the pain itself seems unavoidable from where I'm sitting.
- Shish2k 12y ago
  > the pain itself seems unavoidable from where I'm sitting. If there's enough time and energy in the community to be throwing death threats around, surely there is enough energy to maintain debian/systemd and debian/upstart as separate distros, both of which live happily ever after, sharing the 99.999% of code and infrastructure that they have in common? Then if one side really IS technically superior, people will naturally end up moving to that one and the other will die a gentle natural death, no personal attacks and resignations needed. (For example, see what happened when Canonical wanted Debian to be more apple-like -- they didn't send death threats to Debian developers, they just did the work that they wanted to see done, and now both projects are a great success)

exarch 12y ago

>systemd and Upstart are both a large improvement over the System V init scripts. Userland utils like wget depending on a specific init package is a large improvement over sysvinit? Nope.

pantalaimon 12y ago
How is wget depending on systemd?
- Macha 12y ago
  So I had to look this up. On Arch at least, wget depends on util-linux (package containing kernel tools like mount, dmesg etc.): https://www.archlinux.org/packages/extra/x86_64/wget/ https://www.archlinux.org/packages/extra/x86_64/wget/ And util-linux depends on systemd: https://www.archlinux.org/packages/core/x86_64/libutil-linux/ https://www.archlinux.org/packages/core/x86_64/libutil-linux... I have to assume this is Arch-specific, because I can't anything that basic as util-linux including a dependency on a specific init tool (and given there are still distros using other inits than systemd and still working fine...)
  - 1_player 12y ago
    The systemd is a make dependency only. Unless you plan on compiling it yourself, you don't need systemd to run it. ~ $ y -Qi libutil-linux | grep Depends Depends On : None EDIT: conversely, these are the packages depending on systemd: ~ $ y -Qi systemd | grep Required | fmt Required By : accountsservice chromium colord crda cups device-mapper gnome-session lib32-systemd libgdm libgusb libpulse libusb libvirt libwacom lvm2 media-player-info mesa mkinitcpio netctl polkit procps-ng qt5-base qtwebkit rtkit spotify subversion systemd-sysvcompat udisks2 upower xf86-input-evdev xf86-video-ati xf86-video-modesetting As a sysadmin and developer I don't understand this systemd-hate. If you ever have written a /etc/init.d script for a python non-daemoning script running in a virtualenv, or something to the same effect, you'd notice the improvement over SysV init scripts. Upstart is nice too, but as a Linux desktop user I love socket activation: I can have cups, avahi and other optional/non-critical daemons "active" but not actually using any resource, until effectively used by some other process.

porker 12y ago

I look forward to seeing what these people will all create now they're not involved in Debian. It's not a good situation, but it does mean there's talent free to tinker with new ideas.

rasz_pl 12y ago

>Since systemd seems to have the most traction Windows has even more traction, how about replacing all distributions with windows then?

baldfat 12y ago
How does another OS have anything to do with the need of replacing init system? Systemd has been very good for me in Arch and in OpenSUSE for me. I feel like it is a much better tool for my needs.

npsimons 12y ago

Debian has ports to FreeBSD and HURD; systemd doesn't support anything but Linux. I would assume that this would make systemd a non-starter in Debian (especially since there are no technical reasons systemd couldn't be ported). There are also other issues. Yes, sysvinit doesn't parallelize scripts or do automatic dependencies. If that's all systemd fixed, I'm sure everyone would be for it. But systemd seems to be consuming everything in its path (logging, cron, etc), ignoring the well-proven and time-tested design tenet of "do one thing well".

makomk 12y ago
I think Debian's supported parallel script execution and dependency resolution on top of sysvinit for a while anyway. It's not a true dependency-based init because the dependencies are resolved at configuration time rather than runtime, but whether that matters depends on what you're doing.
the_why_of_y 12y ago
The reason why sysvinit runs on FreeBSD and HURD kernels is that those kernels have implemented the Linux procfs file system. https://teythoon.cryptobitch.de/posts/on-portability-of-init-systems/ https://teythoon.cryptobitch.de/posts/on-portability-of-init... Besides, none of these are release architectures, so why should their limitations restrict what features >99.9% of Debian users have available?