dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

Post by op00to » Sat, Jul 17, 2021, 11:13 PM UTC

rkangel wrote: post #13

Denvercoder9 wrote: post #12

Earlier quoted context omitted.

> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sha…

systemd fundamentally made a branding mistake, not a technical one. Putting all of these components under one 'systemd' umbrella name meant that people simplistically think of them as one thing and then start making the 'Unix philosophy' argument.

Post by op00to » Sat, Jul 17, 2021, 11:15 PM UTC

tinus_hn wrote: post #6

bonzini wrote: post #2

> We are moving from a model where dhclient on 1 interface believes it is MASTER of /etc/resolv.conf and a bunch of system aspects, and the userbase is familiar with a pile of hacky control knobs in dhclient.conf. > Towards a model where multiple interfaces + unwind can advertise their DNS resolution abilities to resolvd, which then sorts the offers and maintains a configuration. > dhclient will remain available for…

I didn’t see the part where it’s a take it or leave it proposition and there’s politics to force people into accepting one part which is then used to force them to accept an ever growing list of unrelated parts.

Post by yosamino » Sun, Jul 18, 2021, 12:05 AM UTC

IgorPartola wrote: post #14

Denvercoder9 wrote: post #12

Earlier quoted context omitted.

> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sha…

What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working. systemd has a good init system and a decent set of other services. Could things be improved? Sure. But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switchin…

Post by notaplumber » Sun, Jul 18, 2021, 12:40 AM UTC

zdw wrote: post #26

rascul wrote: post #11

Might be useful to add OpenBSD in the title somewhere.

OpenBSD was in the title when I originally posted this but it was removed...

Post by someguydave » Sun, Jul 18, 2021, 12:44 AM UTC

Denvercoder9 wrote: post #20

throw0101a wrote: post #17

Earlier quoted context omitted.

> What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. Because some implementations have time jump while others have it slew it slowly. On boot-up a jump may be fine to get with ± some number of milliseconds, but once the system is running, there are situations where jumps could be a problem (especially in the negative direction, where a moment is "repeated"). > But hone…

> Because as a sysadmin it is your job to understand how a system works. No, as a sysadmin your job is to deliver a working system. To do that it usually helps to understand how the system works, but it's not a necessity. As long as something keeps working, and you're equipped to go digging if and when it's necessary, it's fine to not understand or know how something works.