4 ms·

The article and discussion are about runit, why bring systemd into it? Diversity in solutions is a good thing, there’s no need to feel threatened by that.

by rahen 11mo ago

udev4096 11mo ago
Least sane systemd hater, try using runit or sysvinit on a production system and come back crying when your runit bash scripts fail all the time
- DaSHacka 11mo ago
  You never addressed GP's point... This is just a thread about runit, what good is bringing tribal console-war like arguments about systemd to it?
- deleted 11mo ago
  [deleted]
- yjftsjthsd-h 11mo ago
  I've had systemd fail/freeze in weird ways very few times. I've had non-systemd init scripts fail zero times.
  - udev4096 11mo ago
    "My opinions are universal fact and not a skill issue"
    - yjftsjthsd-h 11mo ago
      The number of times I've had something break is not an opinion. You claimed that anything but systemd would "fail all the time", I pointed out that in many years of using other options I've never had them do that. The most egregious systemd bug I've hit was it just freezing on shutdown, with zero error message or even warnings; there's nothing a user should be able to do to produce that outcome that's a "skill issue" and not a bug. In any event, you're just making up claims without evidence.
    - blueflow 11mo ago
      It is bad enough that systemd developers belittle users for the breakages they suffer from systemd, it is worse that you join this behavior. The lockup/freeze bugs from fifos/cdevs/sockets are real and systemd is the only init system affected, as the other init systems do not have functionality that would need the open() calls. Example bug: https://github.com/systemd/systemd/issues/30690 https://github.com/systemd/systemd/issues/30690
fullstop 11mo ago
I'm okay with it for comparison's sake. As a long-time runit user, systemd does far better with sequencing things. With runit you have to have a check executable, and then run 'sv check servicename' in the start script of the service which depends on another.

The article and discussion are about runit, why bring systemd into it? Diversity in solutions is a good thing, there’s no need to feel threatened by that.

by rahen 11mo ago

The article and discussion are about runit, why bring systemd into it? Diversity in solutions is a good thing, there’s no need to feel threatened by that.

udev4096 11mo ago

Least sane systemd hater, try using runit or sysvinit on a production system and come back crying when your runit bash scripts fail all the time

DaSHacka 11mo ago
You never addressed GP's point... This is just a thread about runit, what good is bringing tribal console-war like arguments about systemd to it?
deleted 11mo ago
[deleted]
yjftsjthsd-h 11mo ago
I've had systemd fail/freeze in weird ways very few times. I've had non-systemd init scripts fail zero times.
- udev4096 11mo ago
  "My opinions are universal fact and not a skill issue"
  - yjftsjthsd-h 11mo ago
    The number of times I've had something break is not an opinion. You claimed that anything but systemd would "fail all the time", I pointed out that in many years of using other options I've never had them do that. The most egregious systemd bug I've hit was it just freezing on shutdown, with zero error message or even warnings; there's nothing a user should be able to do to produce that outcome that's a "skill issue" and not a bug. In any event, you're just making up claims without evidence.
  - blueflow 11mo ago
    It is bad enough that systemd developers belittle users for the breakages they suffer from systemd, it is worse that you join this behavior. The lockup/freeze bugs from fifos/cdevs/sockets are real and systemd is the only init system affected, as the other init systems do not have functionality that would need the open() calls. Example bug: https://github.com/systemd/systemd/issues/30690 https://github.com/systemd/systemd/issues/30690

fullstop 11mo ago

I'm okay with it for comparison's sake. As a long-time runit user, systemd does far better with sequencing things. With runit you have to have a check executable, and then run 'sv check servicename' in the start script of the service which depends on another.