4 ms·

Why? It was simple and understandable. systemd has everything and a kitchen sink, it is a big blob of software. Finding out why the heck my resolv.conf contai

by krzyk 4y ago

Why? It was simple and understandable. systemd has everything and a kitchen sink, it is a big blob of software. Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver was the final thing that made me question sanity of distro maintainers and author of two worse pieces of software: pulseaudio and systemd. (I was very surprised that it was the same person).

vetinari 4y ago
> Why? It was simple and understandable. Also brittle and unreliable. Every distribution needed custom-made init.d script, incompatible with every other distribution. No, thanks. > systemd has everything and a kitchen sink, it is a big blob of software. You can still pick and choose. Systemd is an umbrella project. > Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver systemd-resolved is exactly one of the things that you can pick and choose. > was the final thing that made me question sanity of distro maintainers And there are good reasons for that: 1) /etc/resolv.conf cannot be extended; you cannot express all the configuration that is needed for resolver today (e.g. per subnet zones) or dynamic enough (user-managed network links that go up and down). 2) applications are not supposed to use resolv.conf directly anyway; if they do, they are broken. The local nss config may be such, that they won't be able to find all hostnames, or the above mentioned per subnet zones, which they won't be able to resolve. Hence, they are supposed to use libc, which does the right thing. Even golang runtime respects this and thunks into libc for nss.
Avamander 4y ago
> Why? It was simple and understandable. Maybe conceptually simple, but far from it in terms of reliability, predictability and ease-of-use. > Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver was the final thing [...] So you read the comment at the top of the file and that made you question someone's sanity?

by krzyk 4y ago

vetinari 4y ago

> Why? It was simple and understandable. Also brittle and unreliable. Every distribution needed custom-made init.d script, incompatible with every other distribution. No, thanks. > systemd has everything and a kitchen sink, it is a big blob of software. You can still pick and choose. Systemd is an umbrella project. > Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver systemd-resolved is exactly one of the things that you can pick and choose. > was the final thing that made me question sanity of distro maintainers And there are good reasons for that: 1) /etc/resolv.conf cannot be extended; you cannot express all the configuration that is needed for resolver today (e.g. per subnet zones) or dynamic enough (user-managed network links that go up and down). 2) applications are not supposed to use resolv.conf directly anyway; if they do, they are broken. The local nss config may be such, that they won't be able to find all hostnames, or the above mentioned per subnet zones, which they won't be able to resolve. Hence, they are supposed to use libc, which does the right thing. Even golang runtime respects this and thunks into libc for nss.

Avamander 4y ago

> Why? It was simple and understandable. Maybe conceptually simple, but far from it in terms of reliability, predictability and ease-of-use. > Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver was the final thing [...] So you read the comment at the top of the file and that made you question someone's sanity?