> From: DJ Lucas <[email protected]> > Date: Sun, 27 Nov 2016 14:05:44 -0600 > Subject: Re: [lfs-dev] LFS 7.10-systemd DNS issue with CNAME???s > > On 11/26/2016 11:55 PM, Bruce Dubbs wrote: > > Douglas R. Reno wrote: > >> On Sat, Nov 26, 2016 at 10:15 PM, Bruce Dubbs <[email protected]> > >> wrote: . . > >>> For someone who does not use systemd (me), all this sounds terribly > >>> complex. Why not pass --disable-resolved to systemd and just use the > >>> resolver in glibc? > >>> > >>> Alternatively, there is unbound or bind in BLFS that can provide a > >>> caching > >>> name server in a straightforward (one task, one application) way. . . > >> Anyway, I think we have to give up networkd if we do that, which will > >> require network connectivity to be handled by yet another layer, which > >> seems way more complicated to me than just keeping networkd. We'd have to > >> provide links to something like NetworkManager. > > > > I wasn't really suggesting a change. It was just a snide comment about > > how systemd is the antithesis of Unix. Complexity that replaces > > simplicity for no real benefit to the user. > > > > The "no real benefit" argument is opinionated at best. Numero uno on > that list for me is a service manager as opposed to the rc script. A > unified way to write simple services where upstream can provide startup > scripts is pretty high on the list as well, but not all that valuable in > practice. The distribution provides other niceties (as above) and some > headaches as well. Of course, it is effectively the reference > implementation for setting up userspace as far as new kernel features > are concerned. The "antithesis" bit has been fought so many times I > don't care to revisit it. :-) While I partially agree, the devil is in > the details. While systemd is not ideal, it is more palatable (but not > drastically so) for my taste than our current SysV setup. > > At any rate, there is nothing requiring us to use systemd-networkd or > systemd-resolved (or many of the other utilities included), but they are > already there and reduce the number of packages that must be installed > on the system (in the example above, a dhcp client, sntp client, and a > caching nameserver). Nothing prevents me from writing an @service file > to use the same tools we use in the SysV book and disabling the then > unused parts of systemd. At this point, all of systemd can be replaced > with near functional parity, but there is a reason most haven't. Add > something like OpenRC, elogind (dbus required), and maybe LXC (or > Docker) to LFS, and a lot of additional scripting, and we are mostly on > par (we'd loose user slices). This will eventually be a fun exercise, > but not something I'll be doing any time soon. >
D-Bus next to be 'integrated' into sysd? : ---- https://lwn.net/Articles/705479/ -- Nov. 2016 -- "D-Bus is incompatible with a chroot() environment because there is a need to drop policy files into the host filesystem. For now, that is an unsolved problem, but the goal is to move D-Bus functionality into systemd itself. That is something the project should have done a long time ago, Poettering said. The systemd D-Bus server would then use a different policy mechanism that doesn't require access to the host filesystem." ---- rgds, akh -- -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
