4 ms·

Instead of complaining just drop anything that contains Systemd. I did and my frustration with IT related tasks has gone way down.

ticviking 3y ago
I'm curious what alternative you make use of. My issue has been that getting an alternative set up was just painful enough that the related learning doesn't fit into a very full schedule.
stingraycharles 3y ago
I took the opposite route, accepting defeat and embracing systemd. My purist self doesn’t like it, but my pragmatic self is happy and cannot be bothered by all the people complaining about it.
Aardwolf 3y ago
But how can I do that if I like Archlinux for the rest but everything around is based on Systemd, and most other distros also do that?
- arjvik 3y ago
  Try Artix Linux instead! It's essentially Arch, but with an alternative unit system.
op00to 3y ago
Huh. Since learning more about systemd my frustration with IT related tasks has gone way down. Unit files are far more functional for the same amount of effort as SysV scripts.
- lloeki 3y ago
  beyond init and udev script cobbling, I've recently plunged deep into networkd and resolved for the heck of it, discovered networkctl and resolvectl in the process, and it's been a very pleasant experience so far, making easy things trivial and hard things easy.
  - op00to 3y ago
    It really has made things much easier after a slightly frustrating knowledge speed bump.
- ticviking 3y ago
  Unit files seem like a good idea. Does systemd need to do everything it does in order to gain that benefit?
  - tapoxi 3y ago
    Yes? People don't realize that systemd is a project, and systemd the init system isn't journald or systemd-boot or systemd-resolved. Those are other compatible utilities by the same project. They aren't required to use systemd itself.
  - bravetraveler 3y ago
    Not entirely, for example: Units can depend on networking managed outside of systemd-networkd using the target -- think of this as a 'run level' Units can depend on mounts outside of systemd .mount units -- there's a generator that considers fstab At a certain point, you might want to go further into systemd... but it doesn't require it. The basic 'this service wants/needs these other ones' is very self-contained, and inherits a lot.
  - op00to 3y ago
    Yes. It needs to know what mounts and networks are needed for my various services. It needs to be sure the system is synced with NTP before moving past a certain point. And so on.
  - matthews2 3y ago
    Many of the systemd components are separate and optional. You can easily eschew from systemd-timesyncd and systemd-resolved, for example.
  - deleted 3y ago
    [deleted]
tekla 3y ago
I've ported dozens of services many production critical over to SystemD over several companies. The only thing I've ever had issue with is systemd-timesyncd. Otherwise, its been rock solid. What the hell are you doing that gives you so much trouble with SystemD
- bravetraveler 3y ago
  Ditto, much success with systemd here. The 'overreach' people complain about exists for a good reason. Services need mounts/networks/etc to actually do their job reliably. If people could discard the 'nyeh' sentiment, use recent releases, and actually engage with the system, they can only find more reliability. What was once tailored in scripts for each service/job/whatever is now provided by the system It's about clearly laying out dependencies. Not a lot more. The only bad experience I've had with systemd is on Ubuntu 18; where I've been forced at work. It's common for systemctl daemon-reexec to be needed, to resuscitate it. It's woefully far behind.
  - freedomben 3y ago
    18.04 is EOL! unless they're paying for that extended support, it's time to upgrade
    - bravetraveler 3y ago
      I should've probably mentioned this, but we've got that covered! ESM until we can finish our move to the New Home I appreciate the mention though, never know how long people intend to keep things running.
  - deleted 3y ago
    [deleted]
palebluedot 3y ago
I find systemd amazing, and worlds better than sysvinit. I'll be happy to never admin a sysvinit box again!
- sophacles 3y ago
  I don't know how I feel about the implication that sysvinit ever did something that could be called "working".
bogwog 3y ago
What kind of frustrations has systemd caused you? I know there are a lot of very valid criticisms of it, but the only time I’ve experienced actual frustration is when I’m fighting with the timer syntax that I can never seem to memorize. Besides Nix, it’s the easiest way I’ve found to declaratively define a system that just works.
TacticalCoder 3y ago
I agree although I still run systemd. I run both Debian (with systemd) and Devuan (a Debian fork with anything systemd removed). The reason I still run a systemd-less fork is to not forget that Linux still works fine without systemd. Linux is not systemd. I did actually write systemd services and I'm not sure the "convenience" warrants what Microsoft (and Poettering) are doing to Linux. The only one true savior we still have is Linus and, so far, Poettering still hasn't found a way to control the kernel's development. But Microsoft/Poettering already won PID 1 on most distros/installs and, although I run systemd on several machines (including servers), it is not good that PID 1 is lost. It simply isn't. Even if there were no technical objections (but there are: gigantic attack surface, lame binary logs, bugs regularly tagged as "not bugs" because Poettering feels like they're not bugs, etc.), it's still a huge problem how this gigantic squid spreads its tentacle everywhere. Anyone finding it totally normal that the person in charge of PID 1 works for Microsoft is totally delusional. People should at least acknowledge there are reasons to be concerned about that. And whether sysvinit scripts do actually suck or not has nothing to do with PID 1 being controlled by someone working for Microsoft.
- stryan 3y ago
  Poettering didn't join Microsoft until 2022, systemd has been around since 2010.
  - jmclnx 3y ago
    True, but soon he will be dropping script integration, not that I care, but the coincidence is a interesting. Join M/S, drop shell scripts :)
    - op00to 3y ago
      Script integration is not dropped. You can easily run a script from a unit file.
      - bravetraveler 3y ago
        Yea, they're dropping the native generator for /etc/init.d, I believe. Scripts placed here implicitly became systemd services. Nothing of huge value is lost. Distributions play an important part, we shouldn't forget. They can maintain something like this for users, if so inclined. This mostly hurts third party/ancient/naive packages that you probably, eventually, won't want to install on your distribution for other reasons. This won't affect any packages natively provided by your distribution of choice. Think those random RPMs/DEBs you get from an external vendor -- UPS, keyboard, whatever. They've had over a decade to see the writing on the wall, adding ~12 lines to their entire codebase/packaging spec. Probably a net-reduction given the NIH-syndrome of these scripts. Instead, I've seen them make this directory, put their scripts inside, and just expect things to work out. It did, arguably by chance. The compatibility was deliberate, but support isn't forever.
kaba0 3y ago
I would also have no IT related problems if my computer wouldn’t boot..

ticviking 3y ago

I'm curious what alternative you make use of. My issue has been that getting an alternative set up was just painful enough that the related learning doesn't fit into a very full schedule.

stingraycharles 3y ago

I took the opposite route, accepting defeat and embracing systemd. My purist self doesn’t like it, but my pragmatic self is happy and cannot be bothered by all the people complaining about it.

Aardwolf 3y ago

But how can I do that if I like Archlinux for the rest but everything around is based on Systemd, and most other distros also do that?

arjvik 3y ago
Try Artix Linux instead! It's essentially Arch, but with an alternative unit system.

op00to 3y ago

Huh. Since learning more about systemd my frustration with IT related tasks has gone way down. Unit files are far more functional for the same amount of effort as SysV scripts.

lloeki 3y ago
beyond init and udev script cobbling, I've recently plunged deep into networkd and resolved for the heck of it, discovered networkctl and resolvectl in the process, and it's been a very pleasant experience so far, making easy things trivial and hard things easy.
- op00to 3y ago
  It really has made things much easier after a slightly frustrating knowledge speed bump.
ticviking 3y ago
Unit files seem like a good idea. Does systemd need to do everything it does in order to gain that benefit?
- tapoxi 3y ago
  Yes? People don't realize that systemd is a project, and systemd the init system isn't journald or systemd-boot or systemd-resolved. Those are other compatible utilities by the same project. They aren't required to use systemd itself.
- bravetraveler 3y ago
  Not entirely, for example: Units can depend on networking managed outside of systemd-networkd using the target -- think of this as a 'run level' Units can depend on mounts outside of systemd .mount units -- there's a generator that considers fstab At a certain point, you might want to go further into systemd... but it doesn't require it. The basic 'this service wants/needs these other ones' is very self-contained, and inherits a lot.
- op00to 3y ago
  Yes. It needs to know what mounts and networks are needed for my various services. It needs to be sure the system is synced with NTP before moving past a certain point. And so on.
- matthews2 3y ago
  Many of the systemd components are separate and optional. You can easily eschew from systemd-timesyncd and systemd-resolved, for example.
- deleted 3y ago
  [deleted]

tekla 3y ago

I've ported dozens of services many production critical over to SystemD over several companies. The only thing I've ever had issue with is systemd-timesyncd. Otherwise, its been rock solid. What the hell are you doing that gives you so much trouble with SystemD

bravetraveler 3y ago
Ditto, much success with systemd here. The 'overreach' people complain about exists for a good reason. Services need mounts/networks/etc to actually do their job reliably. If people could discard the 'nyeh' sentiment, use recent releases, and actually engage with the system, they can only find more reliability. What was once tailored in scripts for each service/job/whatever is now provided by the system It's about clearly laying out dependencies. Not a lot more. The only bad experience I've had with systemd is on Ubuntu 18; where I've been forced at work. It's common for systemctl daemon-reexec to be needed, to resuscitate it. It's woefully far behind.
- freedomben 3y ago
  18.04 is EOL! unless they're paying for that extended support, it's time to upgrade
  - bravetraveler 3y ago
    I should've probably mentioned this, but we've got that covered! ESM until we can finish our move to the New Home I appreciate the mention though, never know how long people intend to keep things running.
- deleted 3y ago
  [deleted]

palebluedot 3y ago

I find systemd amazing, and worlds better than sysvinit. I'll be happy to never admin a sysvinit box again!

sophacles 3y ago
I don't know how I feel about the implication that sysvinit ever did something that could be called "working".

bogwog 3y ago

What kind of frustrations has systemd caused you? I know there are a lot of very valid criticisms of it, but the only time I’ve experienced actual frustration is when I’m fighting with the timer syntax that I can never seem to memorize. Besides Nix, it’s the easiest way I’ve found to declaratively define a system that just works.

TacticalCoder 3y ago

I agree although I still run systemd. I run both Debian (with systemd) and Devuan (a Debian fork with anything systemd removed). The reason I still run a systemd-less fork is to not forget that Linux still works fine without systemd. Linux is not systemd. I did actually write systemd services and I'm not sure the "convenience" warrants what Microsoft (and Poettering) are doing to Linux. The only one true savior we still have is Linus and, so far, Poettering still hasn't found a way to control the kernel's development. But Microsoft/Poettering already won PID 1 on most distros/installs and, although I run systemd on several machines (including servers), it is not good that PID 1 is lost. It simply isn't. Even if there were no technical objections (but there are: gigantic attack surface, lame binary logs, bugs regularly tagged as "not bugs" because Poettering feels like they're not bugs, etc.), it's still a huge problem how this gigantic squid spreads its tentacle everywhere. Anyone finding it totally normal that the person in charge of PID 1 works for Microsoft is totally delusional. People should at least acknowledge there are reasons to be concerned about that. And whether sysvinit scripts do actually suck or not has nothing to do with PID 1 being controlled by someone working for Microsoft.

stryan 3y ago
Poettering didn't join Microsoft until 2022, systemd has been around since 2010.
- jmclnx 3y ago
  True, but soon he will be dropping script integration, not that I care, but the coincidence is a interesting. Join M/S, drop shell scripts :)
  - op00to 3y ago
    Script integration is not dropped. You can easily run a script from a unit file.
    - bravetraveler 3y ago
      Yea, they're dropping the native generator for /etc/init.d, I believe. Scripts placed here implicitly became systemd services. Nothing of huge value is lost. Distributions play an important part, we shouldn't forget. They can maintain something like this for users, if so inclined. This mostly hurts third party/ancient/naive packages that you probably, eventually, won't want to install on your distribution for other reasons. This won't affect any packages natively provided by your distribution of choice. Think those random RPMs/DEBs you get from an external vendor -- UPS, keyboard, whatever. They've had over a decade to see the writing on the wall, adding ~12 lines to their entire codebase/packaging spec. Probably a net-reduction given the NIH-syndrome of these scripts. Instead, I've seen them make this directory, put their scripts inside, and just expect things to work out. It did, arguably by chance. The compatibility was deliberate, but support isn't forever.

kaba0 3y ago

I would also have no IT related problems if my computer wouldn’t boot..