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

Post by IgorPartola » Sun, Jul 18, 2021, 2:40 AM UTC

throw0101a wrote: post #17

IgorPartola wrote: post #14

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. 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…

> 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…

Post by chmod775 » Sun, Jul 18, 2021, 2:54 AM UTC

xyzzy_plugh wrote: post #33

yosamino wrote: post #25

Earlier quoted context omitted.

> What can I possibly gain by switching which DHCP client Yesterday I switched to systemd-networkd on debian to gain the feature of having the hostname be set via DHCP and not have to write a script myself. In the process I pulled in a javascript dependency via policykit, which is giving me pause and I am re-evaluating if my approach is correct here. But for this feature I had to switch DHCP server and client. TBF it…

> In the process I pulled in a javascript dependency via policykit, which is giving me pause and I am re-evaluating if my approach is correct here. To be fair, policykit is great. It solves a real problem (namely is this user allowed to peform this action , which traditional POSIX permissions do not solve in a portably) in a very sane way that is totally optional to opt in to. Should polkit use a different, turing co…

Post by djrogers » Sun, Jul 18, 2021, 3:00 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 richardfey » Sun, Jul 18, 2021, 4:58 AM UTC

Denvercoder9 wrote: post #12

throw0101a wrote: post #9

Earlier quoted context omitted.

> An old and somewhat crusty cross-platform daemon replaced by an OS-specific set of daemons, that takes care of managing /etc files that have been there forever. The older solution remains available, but may bitrot or otherwise become harder to maintain in the future. > Wait, isn't this what systemd is "accused" of doing all the time? Each of these do one thing and one thing only. The code is loosely coupled between…

> 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…

Post by nine_k » Sun, Jul 18, 2021, 6:02 AM UTC