> systemd has no f*cking clue what they're doing on networking. You need to not use systemd-resolved, and not use systemd-networkd or systemd-timesyncd either.

Can you give some more details, or do you have some examples of where systemd is bad here? Because I'm quite happy with systemd-resolved and systemd-networkd, but I admittedly know hardly anything about networking.

> [...] But don't let them touch your networking, aside from service-managing on that.

What do you recommend as an alternative then? systemd-resolved and systemd-timesyncd are easy to replace, since there is lots of good DNS/NTP software available, but systemd-networkd seems trickier: I don't like NetworkManager, I'd rather not write a bunch of ad-hoc shell scripts, and I'm not aware of any other alternatives.

▲

eqvinox 5 hours ago | parent | next [-]

> 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 2 hours ago | parent | next [-]

> 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 2 hours ago | parent | prev [-]

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 2 hours ago \| parent [-]
		> 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.

▲

kotaKat 2 hours ago | parent | prev [-]

hot take "predictable network names" should have been a kernel flag - give us all our eth0 in peace. i shouldn't need to set a flag to get back a default feature.

just what i needed to do: configure ens328452356aflhjdslhfda to get my network going.

	▲	6 minutes ago \| parent [-]
		[deleted]