5 ms·

Especially considering that Debian/kFreeBSD and Debian/HURD are closer to interesting experiments than systems used for real work, holding back the init system

Especially considering that Debian/kFreeBSD and Debian/HURD are closer to interesting experiments than systems used for real work, holding back the init system solely for the non-Linux Debian variants doesn't seem justified. So this roadmap seems pretty sane.

deleted 13y ago
[deleted]
- redbad 13y ago
  _delirium is saying Debian on {kFreeBSD,HURD} are near-experimental, not that Debian itself is.
- deleted 13y ago
  [deleted]
asveikau 13y ago
But what exactly is "holding back"? I feel like Linux distros today come with too many crappy, overthought, over-engineered daemons that don't really offer much over the previously available interfaces. I guess parallelizing init scripts or making dependencies more explicit is a good thing in some sense, but I have to say, it's a breath of fresh air to see something like a *BSD system, which has an /etc/rc shell script that is easy to follow. Unlike Linux which frequently seeks out complex solutions from simple problem spaces.
- Jasper_ 13y ago
  Process and service management is not a simple problem space, especially with POSIX semantics. Try doing something like "stop apache". It turns out that trying to simply kill the Apache processes isn't going to work right, as Apache forks out lots of worker processes that won't be guaranteed to be killed when the Apache process stops. And now since the parent has gone away, they're reparented to PID1, so there's all these worker processes littering your system. systemd uses cgroups to tag every single forked out process with a service file, so that all of the processes associated with a service can be stopped at once.
  - regularfry 13y ago
    Right, but is systemd necessary for that, or can you use a cgroup from within a conventional sysvinit script?
    - bkor 13y ago
      systemd also logs stderr + stdout, so if some daemon fails to start up, you can easily see it in 'service $SERVICE status'. A lot of things could theoretically be done by putting that all in a sysvinit script. That means duplicating that in every sysvinit script. Bugs galore :P
      - thwarted 13y ago
        initscripts have used libraries of routines since like forever. Good programming methodology applies equally to shell programming and initscripts as it does to programming anything else.
        bkor 13y ago
        Initscripts are specific to one distribution. A bug in an initscript in one distribution is not fixed in another distribution. This is practical real life example that has happened for 10+ years. With systemd, there is just a configuration file that is used. The logic is within the daemon and bugs are fixed in one place, then shared across distributions (+ embedded world and others). Maybe you could redo what systemd does by changing those libraries. I very much doubt it though, I also do not see the point of reimplementing this. Systemd way guarantees consistensy, you're proposing something which may or may not work, depending on the init script. Does not seem like a good practice, nor a good alternative to propose. But all means, go for it.
        thwarted 13y ago
        Many initscripts are provided by the software and distributions replace them with their own. The distributions themselves are at fault for not using an upstream initscript. There is also nothing stopping a distribution from replacing the software provided systemd config file, which themselves can contain snippets of executable shell code and thus not reap the benefits of upstream fixed bugs.
- qwerta 13y ago
  This 'simplicity' changes quickly into hairball of scripts if anything non-trivial is requested.
  - asveikau 13y ago
    So you'd like to trade one hairball (shell script) for another (systemd).
    - _delirium 13y ago
      To me the new hairball does seem much cleaner and better thought out. Sysvinit scripts are copy/paste programming at its worst, every one doing a half-assed, buggy reimplementation of an init system copy/pasted from another package and then tweaked until it sort of worked.
    - jfb 13y ago
      There's value in declaring hairball bankruptcy, though. The world changes. Complexity can grow non-linearly, and assumptions valid in one context can rapidly change.
unethical_ban 13y ago
They'll stay experiments if barriers are intentionally put up to prevent package compatibility. Debian/kFreeBSD is an awesome idea, especially since FreeBSD's package system sucks and ZFS is unparalleled. However, I don't think that's the only reason to avoid Systemd.
- bkor 13y ago
  systemd is not something that is intentionally put up to prevent Hurd or FreeBSD from being popular. When I asked about the Hurd of FreeBSD versions of Debian, it seems that stuff has to compile against it. Every Debian maintainer has to already spend a lot of time on it, while the usage is pretty low. Furthermore, it seems rarely useful. At most in the 'it compiles, but does not run, ship it anyway!' stage. If people want Hurd or FreeBSD, then why not have them put in a bit more effort? Not like sysvinit will be completely broken.

deleted 13y ago

[deleted]

redbad 13y ago
_delirium is saying Debian on {kFreeBSD,HURD} are near-experimental, not that Debian itself is.
deleted 13y ago
[deleted]

asveikau 13y ago

But what exactly is "holding back"? I feel like Linux distros today come with too many crappy, overthought, over-engineered daemons that don't really offer much over the previously available interfaces. I guess parallelizing init scripts or making dependencies more explicit is a good thing in some sense, but I have to say, it's a breath of fresh air to see something like a *BSD system, which has an /etc/rc shell script that is easy to follow. Unlike Linux which frequently seeks out complex solutions from simple problem spaces.

Jasper_ 13y ago
Process and service management is not a simple problem space, especially with POSIX semantics. Try doing something like "stop apache". It turns out that trying to simply kill the Apache processes isn't going to work right, as Apache forks out lots of worker processes that won't be guaranteed to be killed when the Apache process stops. And now since the parent has gone away, they're reparented to PID1, so there's all these worker processes littering your system. systemd uses cgroups to tag every single forked out process with a service file, so that all of the processes associated with a service can be stopped at once.
- regularfry 13y ago
  Right, but is systemd necessary for that, or can you use a cgroup from within a conventional sysvinit script?
  - bkor 13y ago
    systemd also logs stderr + stdout, so if some daemon fails to start up, you can easily see it in 'service $SERVICE status'. A lot of things could theoretically be done by putting that all in a sysvinit script. That means duplicating that in every sysvinit script. Bugs galore :P
    - thwarted 13y ago
      initscripts have used libraries of routines since like forever. Good programming methodology applies equally to shell programming and initscripts as it does to programming anything else.
      - bkor 13y ago
        Initscripts are specific to one distribution. A bug in an initscript in one distribution is not fixed in another distribution. This is practical real life example that has happened for 10+ years. With systemd, there is just a configuration file that is used. The logic is within the daemon and bugs are fixed in one place, then shared across distributions (+ embedded world and others). Maybe you could redo what systemd does by changing those libraries. I very much doubt it though, I also do not see the point of reimplementing this. Systemd way guarantees consistensy, you're proposing something which may or may not work, depending on the init script. Does not seem like a good practice, nor a good alternative to propose. But all means, go for it.
        thwarted 13y ago
        Many initscripts are provided by the software and distributions replace them with their own. The distributions themselves are at fault for not using an upstream initscript. There is also nothing stopping a distribution from replacing the software provided systemd config file, which themselves can contain snippets of executable shell code and thus not reap the benefits of upstream fixed bugs.
qwerta 13y ago
This 'simplicity' changes quickly into hairball of scripts if anything non-trivial is requested.
- asveikau 13y ago
  So you'd like to trade one hairball (shell script) for another (systemd).
  - _delirium 13y ago
    To me the new hairball does seem much cleaner and better thought out. Sysvinit scripts are copy/paste programming at its worst, every one doing a half-assed, buggy reimplementation of an init system copy/pasted from another package and then tweaked until it sort of worked.
  - jfb 13y ago
    There's value in declaring hairball bankruptcy, though. The world changes. Complexity can grow non-linearly, and assumptions valid in one context can rapidly change.

unethical_ban 13y ago

They'll stay experiments if barriers are intentionally put up to prevent package compatibility. Debian/kFreeBSD is an awesome idea, especially since FreeBSD's package system sucks and ZFS is unparalleled. However, I don't think that's the only reason to avoid Systemd.

bkor 13y ago
systemd is not something that is intentionally put up to prevent Hurd or FreeBSD from being popular. When I asked about the Hurd of FreeBSD versions of Debian, it seems that stuff has to compile against it. Every Debian maintainer has to already spend a lot of time on it, while the usage is pretty low. Furthermore, it seems rarely useful. At most in the 'it compiles, but does not run, ship it anyway!' stage. If people want Hurd or FreeBSD, then why not have them put in a bit more effort? Not like sysvinit will be completely broken.