4 ms·

> But it also introduced big nasty software full of bugs If a bug happens in this code, everything is affected, everyone screams at the same time, it is obviou

> But it also introduced big nasty software full of bugs If a bug happens in this code, everything is affected, everyone screams at the same time, it is obvious there is a bug, and once its fixed, its fixed everywhere and for every service. If there is a bug in one of the old init scripts, it may go unnoticed for several years, until suddenly someone needs service Bar depend on Service Foo, but Bar cannot figure out the state of Foo correctly, and good luck to whoever has to solve this: unless the combination of services is a popular one, whoever has this problem, is likely the first to encounter this, there is no general outcry because nothing else is affected by it. A fix may not be forthcoming because the behavior may not even be considered a bug (the maintainers of Foo and Bar may simply disagree how some service state is to be communicated), and usually someone has to trawl through a pile of sh scripts (because backward compatible all the way to the 90s it has to be!) and implements a fix, which then gets destroyed by an update when the guy who fixed it is on holiday. As someone who has been that exact guy, I have to say sorry but no, I don't want to do this any more.

posix_me_less 5y ago
Yes, but often only for major bugs that are deemed worthy of developer's attention. In practice it's not always so great. Read systemd's bug tracker, not all user-reported bugs get fixed to those users satisfaction, neither by redhat nor by systemd. Systemd is too big and developers refuse to accomodate everybody. Shell scripts are tunable to the specific system. If a rare bug is in a shell script, I can usually find and fix it, unless the script is insane, in which case I can write a sane one. If a bug is in systemd, I can't easily fix it myself. I now have to fight upstream to recognize my issue and fix it for me. I don't have a good experience with this. Nowadays I'd rather write a small script to work around that bug if possible. Much faster and much more effective.
- awrmc 5y ago
  >If a bug is in systemd, I can't easily fix it myself. I now have to fight upstream to recognize my issue and fix it for me. That's not true. You can do as you would with the shell script and patch it in your local copy. If this is too much hassle then that shell script workflow shouldn't be broken by systemd and you can always fall back to it. It's still possible to run shell scripts as systemd units. You could also run another service manager as a systemd unit as another workaround. Also, in my experience, if you're fixing an actual crash, those patches are really likely to get accepted. Upstream appreciates that, I haven't seen them fight anyone over an easily verified issue. If you're submitting giant 10,000 line patches that change the public interfaces and cause regressions, that's a different story.

posix_me_less 5y ago

Yes, but often only for major bugs that are deemed worthy of developer's attention. In practice it's not always so great. Read systemd's bug tracker, not all user-reported bugs get fixed to those users satisfaction, neither by redhat nor by systemd. Systemd is too big and developers refuse to accomodate everybody. Shell scripts are tunable to the specific system. If a rare bug is in a shell script, I can usually find and fix it, unless the script is insane, in which case I can write a sane one. If a bug is in systemd, I can't easily fix it myself. I now have to fight upstream to recognize my issue and fix it for me. I don't have a good experience with this. Nowadays I'd rather write a small script to work around that bug if possible. Much faster and much more effective.

awrmc 5y ago
>If a bug is in systemd, I can't easily fix it myself. I now have to fight upstream to recognize my issue and fix it for me. That's not true. You can do as you would with the shell script and patch it in your local copy. If this is too much hassle then that shell script workflow shouldn't be broken by systemd and you can always fall back to it. It's still possible to run shell scripts as systemd units. You could also run another service manager as a systemd unit as another workaround. Also, in my experience, if you're fixing an actual crash, those patches are really likely to get accepted. Upstream appreciates that, I haven't seen them fight anyone over an easily verified issue. If you're submitting giant 10,000 line patches that change the public interfaces and cause regressions, that's a different story.