4 ms·

This article is a great condemnation of how badly Unix networking has gone in the last 10 years. For many, many, many years we used /etc/resolv.conf to configur

This article is a great condemnation of how badly Unix networking has gone in the last 10 years. For many, many, many years we used /etc/resolv.conf to configure name service. Easy and simple, but not very flexible. All the tools this article talks about turning off are trying to solve problems. They're trying to let resolv.conf be configured with DHCP, or handle VPNs correctly, or roam across networks. You need software to do that, not just a static config file. The problem is every Linux distro has a different tool. And those tools behave opaquely or do bizarre things like use 127.0.0.53 as the loopback address. No one built the One True Tool that got it right. And so we have a mess that has the sysadmin throwing up their hands, disabling all the tools, and making immutable config files just to get back to basic static file functionality.

aj3 6y ago
Linux != UNIX
rlpb 6y ago
> No one built the One True Tool that got it right. Finding the One True Tool takes time. Developers need to experiment to explore the various corners of the problem space. Eventually we'll settle on the best way to solve the problem for the majority of use cases, and distributions will in time settle on that solution. In the meantime, sysadmins who only need the simple 20 year old use case can continue to disable the modern tooling and get what they want. Those who need the newer use cases can do so, provide feedback, and the ecosystem can slowly develop and settle on the best solution. This is open development of Free Software in action. Tools can evolve incrementally or new tools can take big leaps, taking advantage of both the lessons learnt and the code produced in older tools. It's how the ecosystem gets better. I don't see it as a condemnation at all.
m463 6y ago
> No one built the One True Tool that got it right. not systemd. gah!
JdeBP 6y ago
It's not bizarre, and it's an idea that is a lot more than 10 years old. * http://cr.yp.to/dnsroot.html http://cr.yp.to/dnsroot.html * http://jdebp.uk./Softwares/nosh/guide/services/djbdns.html http://jdebp.uk./Softwares/nosh/guide/services/djbdns.html You don't erroneously think that the systemd people invented this idea, do you? It's in RFC 1122.
floatingatoll 6y ago
> And so we have a mess that has the sysadmin throwing up their hands, disabling all the tools, and making immutable config files just to get back to basic static file functionality. I’m not a big fan of sysadmins coasting on their existing knowledge, and this sentiment sums up what I object to precisely. Complexity has increased somewhat since the Slackware days, and it doesn’t always seem to be for the best, but that’s no excuse for disabling it. Expressing this viewpoint in an interview would materially harm a sysadmin candidate’s chances: it suggests that they are inflexible, unable to adapt to change, and prefer to simply sweep issues under a rug rather than document them and resolve them. I empathize with the desire to set it all aside and go back to bare metal, but it’s not a position I would take as much pride in.
- aflag 6y ago
  In my opinion, the current mess with resolv.conf is a case of accidental complexity. I don't think there's anything wrong with disabling badly designed systems that aren't useful for the problem at hand, assuming the admin is managing an environment where none of those tools are actually needed (which is not at all uncommon in a enterprise setting).
- thaumasiotes 6y ago
  > it doesn’t always seem to be for the best, but that’s no excuse for disabling it. Seriously, this is the best possible reason to disable something. You don't just submit to downgrades because progress is progress.
tinus_hn 6y ago
> No one built the One True Tool that got it right. The problem is they all think they did.

aj3 6y ago

Linux != UNIX

rlpb 6y ago

> No one built the One True Tool that got it right. Finding the One True Tool takes time. Developers need to experiment to explore the various corners of the problem space. Eventually we'll settle on the best way to solve the problem for the majority of use cases, and distributions will in time settle on that solution. In the meantime, sysadmins who only need the simple 20 year old use case can continue to disable the modern tooling and get what they want. Those who need the newer use cases can do so, provide feedback, and the ecosystem can slowly develop and settle on the best solution. This is open development of Free Software in action. Tools can evolve incrementally or new tools can take big leaps, taking advantage of both the lessons learnt and the code produced in older tools. It's how the ecosystem gets better. I don't see it as a condemnation at all.

m463 6y ago

> No one built the One True Tool that got it right. not systemd. gah!

JdeBP 6y ago

It's not bizarre, and it's an idea that is a lot more than 10 years old. * http://cr.yp.to/dnsroot.html http://cr.yp.to/dnsroot.html * http://jdebp.uk./Softwares/nosh/guide/services/djbdns.html http://jdebp.uk./Softwares/nosh/guide/services/djbdns.html You don't erroneously think that the systemd people invented this idea, do you? It's in RFC 1122.

floatingatoll 6y ago

> And so we have a mess that has the sysadmin throwing up their hands, disabling all the tools, and making immutable config files just to get back to basic static file functionality. I’m not a big fan of sysadmins coasting on their existing knowledge, and this sentiment sums up what I object to precisely. Complexity has increased somewhat since the Slackware days, and it doesn’t always seem to be for the best, but that’s no excuse for disabling it. Expressing this viewpoint in an interview would materially harm a sysadmin candidate’s chances: it suggests that they are inflexible, unable to adapt to change, and prefer to simply sweep issues under a rug rather than document them and resolve them. I empathize with the desire to set it all aside and go back to bare metal, but it’s not a position I would take as much pride in.

aflag 6y ago
In my opinion, the current mess with resolv.conf is a case of accidental complexity. I don't think there's anything wrong with disabling badly designed systems that aren't useful for the problem at hand, assuming the admin is managing an environment where none of those tools are actually needed (which is not at all uncommon in a enterprise setting).
thaumasiotes 6y ago
> it doesn’t always seem to be for the best, but that’s no excuse for disabling it. Seriously, this is the best possible reason to disable something. You don't just submit to downgrades because progress is progress.

tinus_hn 6y ago

> No one built the One True Tool that got it right. The problem is they all think they did.