4 ms·

When did Linux get so complicated?

25 points by geerlingguy 4y ago

pxc 4y ago
> in a way that seemingly nobody knows about when you’re Googling? On the first page of results on DuckDuckGo for the query resolvconf unbound configuration you can find: https://wiki.archlinux.org/title/Unbound#Using_openresolv https://wiki.archlinux.org/title/Unbound#Using_openresolv which describes the issue/feature and links to the upstream documentation. So that seems pretty Google-able. You can also get it via man resolvconf.conf https://man.archlinux.org/man/resolvconf.conf.5 https://man.archlinux.org/man/resolvconf.conf.5 To return to > at what point... Maybe about a decade, in the case of openresolv? Looks like it's been the most common resolvconf implementation since the early 2010s at least, maybe longer. I could see myself running into this if I tried to run a DNS server with a dynamic IP for some reason (maybe I fix the IP with a DHCP reservation instead of configuring it on the server?). It would probably take me some time to figure out what was going on, and I'd be frustrated, too.
AlbertoGP 4y ago
> Until complicated Linux stuff gets in the way. I mean all that stuff that tries to manage network connections and alter the sacred resolv.conf file. At what point did people decide one Linux package should poke itself into the config of another package in a way that seemingly nobody knows about when you’re Googling? > Well, until you find some random post online where some poor person is being berated for daring to suggest a slightly hacky way to fix things, and someone with zero personal skills wades in with “that’s a dumb way, why aren’t you reading the docs and doing it correctly like this? You’ll break things”. I guess that one reason might be that when I installed Slackware from floppies on a 486 there wasn’t that much stuff in that Linux system. Few things worked, but the way I remember it, the error messages were immediate and clear. Nowadays things break suddenly without even error messages. Some times I do get some hint in one of the log files, often I get no clue. I’ve developed a conspiracy theory that people don’t want to be the ones that report an error because that makes their software look bad when the cause might be someone else’s code, so they just catch an exception or ignore an error code and go on, until so many things have failed that there are no workarounds left.
- sgt 4y ago
  I also got started with Slackware installed from floppies back in 1996 or so. But what I do remember was that I was recompiling my kernel almost every weekend. There was always something that didn't quite work or needed to be tweaked, often device driver related. I have fond memories of that, but I think I must have wasted quite a bit of time as well.
  - fragmede 4y ago
    Kernels compile in minutes these days. A far cry from the overnight jobs we used to have to run.
  - richardjam73 4y ago
    I remember having to manually edit the kernel source in order for it to see my hardware. Things are so much better these days.
Kukumber 4y ago
When all these cloud companies started to fiddle with it, and most importantly, since microsoft systemd was forced on everyone If you don't use all of that crap and stick to a simple workflow, things become easier to manage In fact, your distribution is what makes it complicated, they ship with bloat you don't need
- raffraffraff 4y ago
  I would probably have agreed 2+ years ago, but I have recently switched to systemd in place of autofs and NetworkManager on a bunch of my devices. Systemd's networkd is actually a joy. A few simple text files, and that's it. Autofs was always awful.
- nwah1 4y ago
  systemd is from Red Hat.
  - deleted 4y ago
    [deleted]
johnklos 4y ago
> It took me forever to realise DHCP was overwriting resolv.conf, Always expected and well documented. > but that some sneaky bullshit was also overwriting part of unbound’s config using DHCP config data too. Absolutely unacceptable and should never happen. I wish the author had actually shared details. That's a bug, and it should be reported, publicized and fixed. > This is your weekly reminder that cosplaying as a sysadmin can waste your Friday evening and Saturday morning, and to add your own time into the cost/benefit calculations of running servers at home or on a cloud service. This illustrates the value of OSes and OS projects that don't change gratuitously, that don't change to differentiate themselves because of their need to appeal to businesses, that don't make decisions about things based solely on usage and profits. This is why I use NetBSD. The BSDs are clean and quite consistent. If someone wants to pooh-pooh systems administration, they should at least direct their ire properly. Nobody's forcing you to use messy, inconsistent Linux distros :)
- pxc 4y ago
  > > but that some sneaky bullshit was also overwriting part of unbound’s config using DHCP config data too. > Absolutely unacceptable and should never happen. I wish the author had actually shared details. That's a bug, and it should be reported, publicized and fixed. Looks like they're talking about the feature of openresolv that lets you configure it to write to an extra config file for unbound which you can configure unbound to source/include from its main config file. The distro default configuration probably just included an include line with the path usually used by resolvconf for this file. https://roy.marples.name/projects/openresolv/configuration/ https://roy.marples.name/projects/openresolv/configuration/ > This is why I use NetBSD. The BSDs are clean and quite consistent. NetBSD's implementation of resolvconf is likewise openresolv; see the credits and link at the bottom of the resolvconf manpage from NetBSD: https://man.netbsd.org/resolvconf.8 https://man.netbsd.org/resolvconf.8
- trynewideas 4y ago
  > and someone with zero personal skills wades in with “that’s a dumb way, why aren’t you reading the docs and doing it correctly like this? You’ll break things”.
rlpb 4y ago
> When did Linux get so complicated? When our needs got so complicated. We have dynamic networking environments now, where a static DNS resolver configuration just doesn't make sense any more. And when one DNS server is unavailable, we like to have the system remember that and not try it every single time because the resolv.conf model doesn't allow different process to share that information. Mostly backwards compatibility works fine if you just replace /etc/resolv.conf with a static file. But if you do that, then various modern expectations will fail, such as what happens to your DNS when you connect to a VPN, or use the wifi at your local coffee shop, or your LAN connection dies and your laptop automatically switches to some available guest wifi or perhaps your phone hotspot.
- deleted 4y ago
  [deleted]
phendrenad2 4y ago
> cosplaying as a sysadmin can waste your Friday evening This is why I always look for the least "professional" way to do things. Instead of Linux, I'll use Windows. Instead of messing with BIND9 config files, I'll use something like TechnitiumDNS, which has GUI tools built-in. I lose flexibility, but usually don't need it.

25 points by geerlingguy 4y ago

pxc 4y ago

> in a way that seemingly nobody knows about when you’re Googling? On the first page of results on DuckDuckGo for the query resolvconf unbound configuration you can find: https://wiki.archlinux.org/title/Unbound#Using_openresolv https://wiki.archlinux.org/title/Unbound#Using_openresolv which describes the issue/feature and links to the upstream documentation. So that seems pretty Google-able. You can also get it via man resolvconf.conf https://man.archlinux.org/man/resolvconf.conf.5 https://man.archlinux.org/man/resolvconf.conf.5 To return to > at what point... Maybe about a decade, in the case of openresolv? Looks like it's been the most common resolvconf implementation since the early 2010s at least, maybe longer. I could see myself running into this if I tried to run a DNS server with a dynamic IP for some reason (maybe I fix the IP with a DHCP reservation instead of configuring it on the server?). It would probably take me some time to figure out what was going on, and I'd be frustrated, too.

AlbertoGP 4y ago

> Until complicated Linux stuff gets in the way. I mean all that stuff that tries to manage network connections and alter the sacred resolv.conf file. At what point did people decide one Linux package should poke itself into the config of another package in a way that seemingly nobody knows about when you’re Googling? > Well, until you find some random post online where some poor person is being berated for daring to suggest a slightly hacky way to fix things, and someone with zero personal skills wades in with “that’s a dumb way, why aren’t you reading the docs and doing it correctly like this? You’ll break things”. I guess that one reason might be that when I installed Slackware from floppies on a 486 there wasn’t that much stuff in that Linux system. Few things worked, but the way I remember it, the error messages were immediate and clear. Nowadays things break suddenly without even error messages. Some times I do get some hint in one of the log files, often I get no clue. I’ve developed a conspiracy theory that people don’t want to be the ones that report an error because that makes their software look bad when the cause might be someone else’s code, so they just catch an exception or ignore an error code and go on, until so many things have failed that there are no workarounds left.

sgt 4y ago
I also got started with Slackware installed from floppies back in 1996 or so. But what I do remember was that I was recompiling my kernel almost every weekend. There was always something that didn't quite work or needed to be tweaked, often device driver related. I have fond memories of that, but I think I must have wasted quite a bit of time as well.
- fragmede 4y ago
  Kernels compile in minutes these days. A far cry from the overnight jobs we used to have to run.
- richardjam73 4y ago
  I remember having to manually edit the kernel source in order for it to see my hardware. Things are so much better these days.

Kukumber 4y ago

When all these cloud companies started to fiddle with it, and most importantly, since microsoft systemd was forced on everyone If you don't use all of that crap and stick to a simple workflow, things become easier to manage In fact, your distribution is what makes it complicated, they ship with bloat you don't need

raffraffraff 4y ago
I would probably have agreed 2+ years ago, but I have recently switched to systemd in place of autofs and NetworkManager on a bunch of my devices. Systemd's networkd is actually a joy. A few simple text files, and that's it. Autofs was always awful.
nwah1 4y ago
systemd is from Red Hat.
- deleted 4y ago
  [deleted]

johnklos 4y ago

> It took me forever to realise DHCP was overwriting resolv.conf, Always expected and well documented. > but that some sneaky bullshit was also overwriting part of unbound’s config using DHCP config data too. Absolutely unacceptable and should never happen. I wish the author had actually shared details. That's a bug, and it should be reported, publicized and fixed. > This is your weekly reminder that cosplaying as a sysadmin can waste your Friday evening and Saturday morning, and to add your own time into the cost/benefit calculations of running servers at home or on a cloud service. This illustrates the value of OSes and OS projects that don't change gratuitously, that don't change to differentiate themselves because of their need to appeal to businesses, that don't make decisions about things based solely on usage and profits. This is why I use NetBSD. The BSDs are clean and quite consistent. If someone wants to pooh-pooh systems administration, they should at least direct their ire properly. Nobody's forcing you to use messy, inconsistent Linux distros :)

pxc 4y ago
> > but that some sneaky bullshit was also overwriting part of unbound’s config using DHCP config data too. > Absolutely unacceptable and should never happen. I wish the author had actually shared details. That's a bug, and it should be reported, publicized and fixed. Looks like they're talking about the feature of openresolv that lets you configure it to write to an extra config file for unbound which you can configure unbound to source/include from its main config file. The distro default configuration probably just included an include line with the path usually used by resolvconf for this file. https://roy.marples.name/projects/openresolv/configuration/ https://roy.marples.name/projects/openresolv/configuration/ > This is why I use NetBSD. The BSDs are clean and quite consistent. NetBSD's implementation of resolvconf is likewise openresolv; see the credits and link at the bottom of the resolvconf manpage from NetBSD: https://man.netbsd.org/resolvconf.8 https://man.netbsd.org/resolvconf.8
trynewideas 4y ago
> and someone with zero personal skills wades in with “that’s a dumb way, why aren’t you reading the docs and doing it correctly like this? You’ll break things”.

rlpb 4y ago

> When did Linux get so complicated? When our needs got so complicated. We have dynamic networking environments now, where a static DNS resolver configuration just doesn't make sense any more. And when one DNS server is unavailable, we like to have the system remember that and not try it every single time because the resolv.conf model doesn't allow different process to share that information. Mostly backwards compatibility works fine if you just replace /etc/resolv.conf with a static file. But if you do that, then various modern expectations will fail, such as what happens to your DNS when you connect to a VPN, or use the wifi at your local coffee shop, or your LAN connection dies and your laptop automatically switches to some available guest wifi or perhaps your phone hotspot.

deleted 4y ago
[deleted]

phendrenad2 4y ago

> cosplaying as a sysadmin can waste your Friday evening This is why I always look for the least "professional" way to do things. Instead of Linux, I'll use Windows. Instead of messing with BIND9 config files, I'll use something like TechnitiumDNS, which has GUI tools built-in. I lose flexibility, but usually don't need it.