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:
DJ Lucas wrote:
Correct, this was resolved in SVN a couple of weeks ago. Should only
affect 231 and 232.
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.
-- Bruce
Bruce, are you top posting? (or did DJ top post?) ;-)
I was responding to DJ.
Yes, sorry, was reloading my phone at the time, quick response.
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.
--DJ
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
