logoalt Hacker News

eqvinoxtoday at 5:41 AM2 repliesview on HN

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


Replies

fsflovertoday at 8:09 AM

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.

show 2 replies
justsomehnguytoday at 8:40 AM

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