[andrewstuart]

systemd is incredibly useful and powerful.

If you are a developer on Linux then you really owe it to yourself to learn as much as you can about systemd.

If you really understand systemd then you'll find yourself architecting your software around its capabilities.

systemd, if you understand it, can mean you can completely avoid large chunks of development you might otherwise have assumed you need to do.

socket activated services, nspawn, traffic accounting, the list of juicy goodness goes on and on....

Ignore the haters, they wouldn't hate if they dedicated their energy to understanding systemd instead of hating on it.

In 2022 you are a really an incomplete full stack developer if systemd is not one of the technologies you know very well.

[coredog64]

> systemd is incredibly useful and powerful.

In that one sentence I think you've highlighted what garners hate from the haters. It's powerful, and it's great when that power is used for good. Those times when it's not is where people get agitated.

[qbasic_forever]

Do you have an example of when systemd is not used for good?

[houzi]

It's quite annoying to not be able to use common tools for DNS queries like `dig`, when using `systemd-resolved` for DNS. I think you might have to sometimes flush the caching feature of `systemd-resolved` as well.

It's fine, I guess. But it did take a while to learn the new ways.

I think this is the main complaint from users with decades of experience. Their scripts and old knowledge stops working.

[egberts1]

it kills production daemons having long running stateful data whenever the netdev goes offline., systemd-networkd, that is.

[viraptor]

Only if you configure it to do that. You can use Wants= and After= for your service to start it after the network, but not restart otherwise.

The behaviour you describe is not unreasonable to want: If your network device goes away, what exactly are you binding the socket to? How are you restoring the listening when it comes back up? But it's up to you to say which one you want.

[egberts1]

Its never a good systemd-networkd default to be killing daemon whenever a netdev goes “cricket”.

[viraptor]

It's not a networkd default. Networkd doesn't kill or even care about other services. The setting exists on the service's unit side. You have to explicitly specify how you want to depend on networking.

[axy]

I don't hate systemd, it simply makes me upset from time to time. If you're a developer, I'd suggest to look around and try writing portable software. Investing your precious time in systemd is pointless IMHO unless you're a systemd developer. It's alike windows: if you a developer on windows learn its incredibly powerful service subsystem... If people made systemd they definitely needed it but I gave it a try and became convinced I don't need it. So why pushing it to me in my favorite distro without any alternative? To force me stop using that distro? To force me to look around and choose another one? Is that the ultimate goal of higher forces? Well, I have to agree, that's not bad, but this distracts me from more important things.

[gavinhoward]

systemd was the first init/supervision system I used. I was able to understand how to use it pretty well.

I still hate it.

Sorry, but understanding systemd does not preclude hating it.

In fact, it's because of the "haters" that I decided to dive deep into what init/supervision systems are and can be. Without that deep dive, I would have always thought that systemd was great. Afterward, however, I know just how wrong that is.

If a developer's only interaction with init systems was SysV init, yes, of course, systemd is the greatest thing since sliced bread.

But systemd could have been so much better...

Disclaimer: I'm writing an init/supervision system to be so much better. And simpler. Orders of magnitude simpler. Oh, and one that doesn't reach its fingers into every part of your OS.

tl;dr: systemd is better than SysV init, but it's not the end-all-be-all of init/supervision systems.

[ahartmetz]

I have similar experience with PulseAudio. First look: it's unstable: Second look: it's fairly well thought out. Third look (using it as a programmer to implement some audio routing thing): it's kind of garbage. I am now using Pipewire, and Pipewire is pretty great and very flexible because it has the right foundations, so it can do anything.