7 ms·

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

> 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.
- throw0101a 5y ago
  > Yes, there's some code sharing between different components, but it's not a monolith. So I can take the code for just systemd-resolved and port it to FreeBSD or Solaris?
  - deleted 5y ago
    [deleted]
  - op00to 5y ago
    What part of “not a monolith” requires portability to other operating systems?
    - pwdisswordfish8 5y ago
      The use of stable, documented, orthogonal interfaces. That part.
- rkangel 5y ago
  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.
  - op00to 5y ago
    Moving the goalposts yet again. Not only must it be technically superior for everyone, not only must it adhere to decades old computing dogma, but now it must be branded in such a way that it’s individual components must be unidentifiable?
  - dralley 5y ago
    We're in a thread about OpenBSD, a Unix that keeps literally the entire OS (except for ports) in one repo, and ships them together. So this is a strange criticism to make.
notaplumber 5y ago
> 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: To be clear, OpenBSD's dhclient is not ISC dhcp client, it is a version that has been maintained in OpenBSD for many years and has a weaker form of privsep, but dhcpleased is a new daemon written to be more in-line with other OpenBSD daemons. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhcpleased/ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhcpleased... OpenBSD's previous dhclient: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/ https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/

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.

throw0101a 5y ago
> Yes, there's some code sharing between different components, but it's not a monolith. So I can take the code for just systemd-resolved and port it to FreeBSD or Solaris?
- deleted 5y ago
  [deleted]
- op00to 5y ago
  What part of “not a monolith” requires portability to other operating systems?
  - pwdisswordfish8 5y ago
    The use of stable, documented, orthogonal interfaces. That part.
rkangel 5y ago
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.
- op00to 5y ago
  Moving the goalposts yet again. Not only must it be technically superior for everyone, not only must it adhere to decades old computing dogma, but now it must be branded in such a way that it’s individual components must be unidentifiable?
- dralley 5y ago
  We're in a thread about OpenBSD, a Unix that keeps literally the entire OS (except for ports) in one repo, and ships them together. So this is a strange criticism to make.

notaplumber 5y ago

> 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: To be clear, OpenBSD's dhclient is not ISC dhcp client, it is a version that has been maintained in OpenBSD for many years and has a weaker form of privsep, but dhcpleased is a new daemon written to be more in-line with other OpenBSD daemons. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhcpleased/ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhcpleased... OpenBSD's previous dhclient: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/ https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/