4 ms·

Oh goodie, another way for shit to break and force maintainers to write systemd only service scripts.

by genmud 3y ago

rubiquity 3y ago
Good riddance! Sysvinit shell scripts are a pain to read and maintain. Developers that perpetuate systemd flamewars have gone from mildly entertaining memes to being a serious red flag and not anyone I’d ever want to work with. systemd and its ecosystem is proven and always getting better.
- jmclnx 3y ago
  [flagged]
  - sidpatil 3y ago
    Which is fair, since Linux Is Not UniX.
  - rubiquity 3y ago
    I guess I didn’t get the hint that UNIX is not for me over two decades ago! Do you also dislike launchd and generally being productive?
    - jmclnx 3y ago
      I have no idea what launchd is.
- Bombinator 3y ago
  Don't you think it does a bit too much as an init system?
  - rubiquity 3y ago
    It’s not just an init system and you can opt into resolved, networkd, etc. but you knew that already!
  - op00to 3y ago
    No, it does what I want well. It never surprised me.
  - tekla 3y ago
    What does it do as an init system that is too much?
  - tptacek 3y ago
    No. It’s great, replacing and unifying a whole collection of random tooling you otherwise had to cobble together yourself.
  - diffeomorphism 3y ago
    Not really, no. Systemd-init seems fairly focused. systemd the project also makes other stuff, which all neatly fits together.
  - akerl_ 3y ago
    Just being able to treat period tasks the same as I treat long-lived services, and never having to think about crontab vs cron.d vs cron.hourly vs /etc/crontab, has improved my quality of life dramatically. I also use systemd-timesyncd / networkd / resolved on most of my systems, but in places where I've wanted to not, swapping them out is as easy as swapping any other services (looking at you, rsyslog and syslog-ng).
- washadjeffmad 3y ago
  Certainly! It can also be difficult to distinguish between being genuinely liked and politely tolerated because of being "good to have around". I mean init systems, of course.
mqus 3y ago
"will be removed in a future release" So this is not even planned to be removed for some releases. TBH I'm surprised it wasn't already deprecated.
- bravetraveler 3y ago
  Yea, woe is me - having to be aware of an init system. If you want users, you'll cater to them. Distribution maintainers do. Here's the Unit, what this provides: [Unit] Description=Whatever After=network.target network-online.target [Service] Type=forking ExecStart=/etc/init.d/your_awesome_initscript start ExecStop=/etc/init.d/your_awesome_initscript stop ExecReload=/etc/init.d/your_awesome_initscript restart [Install] WantedBy=some.target For bonus points - and smaller repositories and more reliability... ... one could skip the init script, offloading whatever nonsense it does to the DSL of systemd. It takes hardly any effort, searching for obvious keywords with 'man systemd.{unit,service,exec}' at your disposal. A likely one is 'Environment' for, well, environment variables. Save yourself dozens of lines of code and support it. It's noble to work without, but why deliberately limit yourself beyond making an unheard statement? It's not removed yet, there's time.
vkazanov 3y ago
You do realise that sysvinit scripts are much, much, much more fragile? Systemd has its share of problems but it's vastly better than a bag of spaghetti shell scripts.
- haolez 3y ago
  The bag of spaghetti in systemd's case is not visible to you, but it's there in thousands and thousands of C code (and I use systemd).
  - sophacles 3y ago
    Can you define spaghetti in this context, and point to examples in the code?
    - haolez 3y ago
      My point is that the complexity is still there, but hidden. There is good and bad code in systemd as there is good and bad sysv init scripts.
  - vkazanov 3y ago
    Yes, systemd is far from trivial. The model of its operation is rather convoluted. But most people just don't care. long running applications are wrapped in a control group, can be reliably killed, stopped, etc. There some questions around binary logs, yes, but nothing truly unbearable.
  - kaba0 3y ago
    Which is the proper place for complexity to live in and get properly tested by millions of boots each minute. Remember, essential complexity of a task can never be reduced. As opposed to that shitty bash script you pasted from 3 stackoverflow answers that already has 3 bugs just from existing, let alone all the indeterminacy that comes with it execution with all the other similarly shitty bash scripts, all unique to your system.
Karellen 3y ago
As someone else has pointed out, this is only a deprecation at this point. For comparison, support for `cgroups v1` which is being removed in this release, was described as "legacy", and to be removed in a later version, happened with systemd v233 released in March 2017. That's more than 6 years between deprecation and removal. Also, `cgroups v1` systems were marked as "tainted" starting in v248 released in March 2021. Based on that, you've probably got a few years yet before your sysv scripts actually start breaking, and you'll probably get a more visible heads-up a couple of years before it actually happens.

Oh goodie, another way for shit to break and force maintainers to write systemd only service scripts.

by genmud 3y ago

Oh goodie, another way for shit to break and force maintainers to write systemd only service scripts.

Good riddance! Sysvinit shell scripts are a pain to read and maintain. Developers that perpetuate systemd flamewars have gone from mildly entertaining memes to being a serious red flag and not anyone I’d ever want to work with. systemd and its ecosystem is proven and always getting better.

jmclnx 3y ago
[flagged]
- sidpatil 3y ago
  Which is fair, since Linux Is Not UniX.
- rubiquity 3y ago
  I guess I didn’t get the hint that UNIX is not for me over two decades ago! Do you also dislike launchd and generally being productive?
  - jmclnx 3y ago
    I have no idea what launchd is.
Bombinator 3y ago
Don't you think it does a bit too much as an init system?
- rubiquity 3y ago
  It’s not just an init system and you can opt into resolved, networkd, etc. but you knew that already!
- op00to 3y ago
  No, it does what I want well. It never surprised me.
- tekla 3y ago
  What does it do as an init system that is too much?
- tptacek 3y ago
  No. It’s great, replacing and unifying a whole collection of random tooling you otherwise had to cobble together yourself.
- diffeomorphism 3y ago
  Not really, no. Systemd-init seems fairly focused. systemd the project also makes other stuff, which all neatly fits together.
- akerl_ 3y ago
  Just being able to treat period tasks the same as I treat long-lived services, and never having to think about crontab vs cron.d vs cron.hourly vs /etc/crontab, has improved my quality of life dramatically. I also use systemd-timesyncd / networkd / resolved on most of my systems, but in places where I've wanted to not, swapping them out is as easy as swapping any other services (looking at you, rsyslog and syslog-ng).
washadjeffmad 3y ago
Certainly! It can also be difficult to distinguish between being genuinely liked and politely tolerated because of being "good to have around". I mean init systems, of course.

mqus 3y ago

"will be removed in a future release" So this is not even planned to be removed for some releases. TBH I'm surprised it wasn't already deprecated.

bravetraveler 3y ago
Yea, woe is me - having to be aware of an init system. If you want users, you'll cater to them. Distribution maintainers do. Here's the Unit, what this provides: [Unit] Description=Whatever After=network.target network-online.target [Service] Type=forking ExecStart=/etc/init.d/your_awesome_initscript start ExecStop=/etc/init.d/your_awesome_initscript stop ExecReload=/etc/init.d/your_awesome_initscript restart [Install] WantedBy=some.target For bonus points - and smaller repositories and more reliability... ... one could skip the init script, offloading whatever nonsense it does to the DSL of systemd. It takes hardly any effort, searching for obvious keywords with 'man systemd.{unit,service,exec}' at your disposal. A likely one is 'Environment' for, well, environment variables. Save yourself dozens of lines of code and support it. It's noble to work without, but why deliberately limit yourself beyond making an unheard statement? It's not removed yet, there's time.

vkazanov 3y ago

You do realise that sysvinit scripts are much, much, much more fragile? Systemd has its share of problems but it's vastly better than a bag of spaghetti shell scripts.

haolez 3y ago
The bag of spaghetti in systemd's case is not visible to you, but it's there in thousands and thousands of C code (and I use systemd).
- sophacles 3y ago
  Can you define spaghetti in this context, and point to examples in the code?
  - haolez 3y ago
    My point is that the complexity is still there, but hidden. There is good and bad code in systemd as there is good and bad sysv init scripts.
- vkazanov 3y ago
  Yes, systemd is far from trivial. The model of its operation is rather convoluted. But most people just don't care. long running applications are wrapped in a control group, can be reliably killed, stopped, etc. There some questions around binary logs, yes, but nothing truly unbearable.
- kaba0 3y ago
  Which is the proper place for complexity to live in and get properly tested by millions of boots each minute. Remember, essential complexity of a task can never be reduced. As opposed to that shitty bash script you pasted from 3 stackoverflow answers that already has 3 bugs just from existing, let alone all the indeterminacy that comes with it execution with all the other similarly shitty bash scripts, all unique to your system.

Karellen 3y ago

As someone else has pointed out, this is only a deprecation at this point. For comparison, support for `cgroups v1` which is being removed in this release, was described as "legacy", and to be removed in a later version, happened with systemd v233 released in March 2017. That's more than 6 years between deprecation and removal. Also, `cgroups v1` systems were marked as "tainted" starting in v248 released in March 2021. Based on that, you've probably got a few years yet before your sysv scripts actually start breaking, and you'll probably get a more visible heads-up a couple of years before it actually happens.