[eqvinox]

> Can you give some more details, or do you have some examples of where systemd is bad here?

I can't, because it's death by a thousand cuts. I remember systemd-timesyncd having security issues, but not what exactly. systemd-resolved was initially missing basic security best practices (source port randomization, if I remember correctly), despite their being well established and well known in the DNS community - AFAIK the systemd people just didn't know of them.

> systemd-networkd seems trickier

Indeed; I was primarily speaking about servers, and there my answer is: either ifupdown-ng or ifupdown2. (The latter if your networking needs are more complex.)

On client devices the choice is between bad and worse. Personally speaking, I consider NetworkManager bad and systemd-networkd worse. So I'm using NetworkManager on my laptop... it still occasionally breaks IPv6 for me.

I will admit: this is burned-in experience for me, learned over several years, and the original reasons have expired from my brain's cache. And I probably didn't give systemd-networkd much of a chance (I don't remember anything on that, for resolved and timesyncd I have at least vague bits), with that being more recent (at least for me) than systemd-resolved and systemd-timesyncd.

Is it possible it has gotten better? Definitely. But TFA indicates at least systemd-resolved hasn't.

[justsomehnguy]

> systemd-resolved was initially missing basic security best practices (source port randomization, if I remember correctly), despite their being well established and well known in the DNS community

https://lists.dns-oarc.net/pipermail/dns-operations/2016-Jun...

It was fixed in 2016. RFC5452 is 2009.

As the first paragraph states it's not a big problem for a local forwarder but all other bullet points are on the case.

[fsflover]

A lot of knowledgeable people hate systemd, and I start suspecting that they have good reasons for that. However, it's extremely hard to get a good list of related substantiated facts about systemd in order to convince a larger community. If you encounter something specific, please write some kind of article about it.

[eqvinox]

So, it's 12 days later and we upgraded Debian stable on our production DFZ BGP routers.

Result: systemd-networkd in a restart loop continuously consuming 100% CPU. None of the systemd restart-limiting options are being applied. The only message in the log is "Could not enumerate links: Connection timed out".

It's not a strong data point, but it's a data point. I did say "death by a thousand cuts". There's enough of these to sum up.

To add insult to injury, I'm relatively sure systemd-networkd was disabled before the update, but I can't easily confirm that.

[eqvinox]

You're right in that I should really be able to back my position up better. I don't know if/when a situation where I have to deal with the systemd network components will come up though :/

[justsomehnguy]

> in order to convince a larger community

Even if you would get such a list it would be dismissed anyway, because 'works on my machine'. Eg: see a sibling response to the OP.