9 ms·

> 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

> 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 people who want that old model, but I suspect they will encounter increasing difficulty sticking to it. > Because the default configuration is changing. 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?

egberts1 5y ago
We can’t block systemd from making a network socket/connection so we daemonized the network aspects.
Denvercoder9 5y ago
Also interesting to note that dhcpleased and resolvd are loosely analogous to systemd-networkd and systemd-resolved.
- egberts1 5y ago
  Makes it easier for embedded system to exist without systemd.
1vuio0pswjnm7 5y ago
But in the case of Linux distributions do they let the older solution remain available.
- Denvercoder9 5y ago
  Debian has, on paper at least, still support for sysvinit, and ships with the old ifupdown-based network configuration by default. In practice it's increasingly bitrotting because it turns out that the majority of users and developers don't care.
- theamk 5y ago
  Sure they do, I run a few systems which use systemd with older dhcp daemons. And for example Raspbian uses systemd for process management, but completely disables its network parts, using their own solutions instead. One of the best parts of the systemd is how easy it is to disable/replace any part of it. The resolved and timesyncd are easy, but even things like journald have a mode when it keeps no files on disk, and just forwards data to your existing syslog daemon. Quite a difference from "will encounter increasing difficulty sticking to it."
  - 1vuio0pswjnm7 5y ago
    How about removing all of it and just running daemontools, runit or s6. Is this easy.
    - epse 5y ago
      Not that bad, if you consider writing your own unit files for each service because the system only provides systemd
  - yrro 5y ago
    TBH you still take the performance hit for journald doing all the lookups for each received message that populate all the fields of each message. In most cases you won't notice but I have seen some people complain that this extra processing can't be disabled.
  - 1vuio0pswjnm7 5y ago
    This is what Torvalds had to say about the developers of systemd https://web.archive.org/web/20161210172826/http://article.gmane.org/gmane.linux.kernel/1368617 https://web.archive.org/web/20161210172826/http://article.gm...
tinus_hn 5y ago
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.
- op00to 5y ago
  I didn’t see this with systemd either, so that’s good.
  - kasabali 5y ago
    Which part of "gently pushing" didn't you see? https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
    - op00to 5y ago
      The last time I read that thread I was just learning to ride a dinosaur.
      - tinus_hn 5y ago
        That must have been a long time ago. Remind me, when did the project recant this position?
throw0101a 5y ago
> 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 the two, so you can use or not use either/both. Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. And while it is likely that dhclient will eventually be removed from OpenBSD Base, it will live on in Ports, where it will be available to those who desire to use it: * https://cvsweb.openbsd.org/ports/net/isc-dhcp/ https://cvsweb.openbsd.org/ports/net/isc-dhcp/ * https://github.com/openbsd/ports/tree/master/net/isc-dhcp https://github.com/openbsd/ports/tree/master/net/isc-dhcp 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. One of the programs does DHCP. One does resolve.conf(5) changes. Each does nothing else. It may even be possible to port each of these programs to another operating system, as I suspect they don't need special APIs (*cough*dbus*cough*) and may mostly just use POSIX-y stuff.
- Denvercoder9 5y ago
  > 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 sharing between different components, but it's not a monolith. On my Debian system it ships 50+ different binaries split across 8 different packages. You can use the network management without using the NTP service, the journal without using the device manager, the tmpfiles manager without using the user manager, etc. Most, if not all, of these components only depend on the service manager (i.e. PID 1). That's more or less unavoidable for an event-driven system, there'll always be a dependency on the event bus. The components itself can be freely swapped out for different, even incompatible, implementations. If you don't even want to run the service manager, all external interfaces are stable, pretty well-documented and relatively straightforward, so it's even possible to write a completely independent implementation without breaking external dependencies. By the way, if we're talking about loose coupling and POSIX, this OpenBSD implementation isn't it either. resolvd has an hardcoded reference to the unwind socket, and they use a special BSD-only socket type to communicate between the different processes.

egberts1 5y ago

We can’t block systemd from making a network socket/connection so we daemonized the network aspects.

Denvercoder9 5y ago

Also interesting to note that dhcpleased and resolvd are loosely analogous to systemd-networkd and systemd-resolved.

egberts1 5y ago
Makes it easier for embedded system to exist without systemd.

1vuio0pswjnm7 5y ago

But in the case of Linux distributions do they let the older solution remain available.

Denvercoder9 5y ago
Debian has, on paper at least, still support for sysvinit, and ships with the old ifupdown-based network configuration by default. In practice it's increasingly bitrotting because it turns out that the majority of users and developers don't care.
theamk 5y ago
Sure they do, I run a few systems which use systemd with older dhcp daemons. And for example Raspbian uses systemd for process management, but completely disables its network parts, using their own solutions instead. One of the best parts of the systemd is how easy it is to disable/replace any part of it. The resolved and timesyncd are easy, but even things like journald have a mode when it keeps no files on disk, and just forwards data to your existing syslog daemon. Quite a difference from "will encounter increasing difficulty sticking to it."
- 1vuio0pswjnm7 5y ago
  How about removing all of it and just running daemontools, runit or s6. Is this easy.
  - epse 5y ago
    Not that bad, if you consider writing your own unit files for each service because the system only provides systemd
- yrro 5y ago
  TBH you still take the performance hit for journald doing all the lookups for each received message that populate all the fields of each message. In most cases you won't notice but I have seen some people complain that this extra processing can't be disabled.
- 1vuio0pswjnm7 5y ago
  This is what Torvalds had to say about the developers of systemd https://web.archive.org/web/20161210172826/http://article.gmane.org/gmane.linux.kernel/1368617 https://web.archive.org/web/20161210172826/http://article.gm...

tinus_hn 5y ago

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.

op00to 5y ago
I didn’t see this with systemd either, so that’s good.
- kasabali 5y ago
  Which part of "gently pushing" didn't you see? https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
  - op00to 5y ago
    The last time I read that thread I was just learning to ride a dinosaur.
    - tinus_hn 5y ago
      That must have been a long time ago. Remind me, when did the project recant this position?

throw0101a 5y ago

> 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 the two, so you can use or not use either/both. Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. And while it is likely that dhclient will eventually be removed from OpenBSD Base, it will live on in Ports, where it will be available to those who desire to use it: * https://cvsweb.openbsd.org/ports/net/isc-dhcp/ https://cvsweb.openbsd.org/ports/net/isc-dhcp/ * https://github.com/openbsd/ports/tree/master/net/isc-dhcp https://github.com/openbsd/ports/tree/master/net/isc-dhcp 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. One of the programs does DHCP. One does resolve.conf(5) changes. Each does nothing else. It may even be possible to port each of these programs to another operating system, as I suspect they don't need special APIs (*cough*dbus*cough*) and may mostly just use POSIX-y stuff.

Denvercoder9 5y ago
> 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 sharing between different components, but it's not a monolith. On my Debian system it ships 50+ different binaries split across 8 different packages. You can use the network management without using the NTP service, the journal without using the device manager, the tmpfiles manager without using the user manager, etc. Most, if not all, of these components only depend on the service manager (i.e. PID 1). That's more or less unavoidable for an event-driven system, there'll always be a dependency on the event bus. The components itself can be freely swapped out for different, even incompatible, implementations. If you don't even want to run the service manager, all external interfaces are stable, pretty well-documented and relatively straightforward, so it's even possible to write a completely independent implementation without breaking external dependencies. By the way, if we're talking about loose coupling and POSIX, this OpenBSD implementation isn't it either. resolvd has an hardcoded reference to the unwind socket, and they use a special BSD-only socket type to communicate between the different processes.