4 ms·

> 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 system

by eqvinox 5mo ago

> 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.

fsflover 5mo ago
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.
- justsomehnguy 5mo ago
  > 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.
- eqvinox 5mo ago
  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 :/
- eqvinox 5mo ago
  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.
justsomehnguy 5mo ago
> 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-June/014966.html 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.

by eqvinox 5mo ago

fsflover 5mo ago

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.

justsomehnguy 5mo ago
> 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.
eqvinox 5mo ago
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 :/
eqvinox 5mo ago
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.

justsomehnguy 5mo ago

> 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-June/014966.html 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.