Mattias Schlenker wrote:
Am 09.09.2014 um 06:31 schrieb Bruce Dubbs:
The other day I was trying to understand how updatedb was scheduled to
run on my Arch install, as there was no entry in cron. It turns out
it's "scheduled" via systemd: "When mlocate is installed, a script is
automatically scheduled to run daily via systemd" [1]. Really?
Systemd is also a cron replacement too now?
[1] https://wiki.archlinux.org/index.php/locate
and a dhcp client and a login client and a syslog client ...
You can disable them or ignore them, but you can't remove them if you
are using systemd for other things.
...and a replacement for ntp client and server. I guess at some point it
will also include a IPP printing daemon and other daemons as well.
To be honest: a properly configured systemd can accelerate the startup
massively which is of great advantage on notebooks.
Really? On my laptop, boot time is:
Sep 09 01:16:52 -05:00 (none) Mounting virtual file systems:
...
Sep 09 01:16:58 -05:00 toshiba-lfs Starting SSH Server... OK
The last line in dmesg is:
[ 8.163599] alx 0000:07:00.0 eth0: NIC Up: 1 Gbps Full
That's six seconds for the boot scripts. When I add a few more apps it
may expand to about 10 seconds. How much will systemd speed that up?
Maybe the problem is all the junk the commercial distos add to the boot
sequence.
This advantage is
much smaller on desktops (that you usually boot five times a week) and
virtually not existing on a server that you just reboot every few weeks
after updating kernels. Giving the complexity of this PID 1 I am really
wondering why many server distributions move to systemd.
For LFS as a flexible base for building tailored distribution, including
systemd is a great benefit. To keep LFS understandable as an educational
tool systemd just is a PITA. As an educational tool I would even strip
it down further: Try to use busybox to replace some of the packages in
chapter 5, try the same in chapter 6 (will not completely work, might
require some patches), BLFS still will need coreutils, diffutils and
stuff. And even replace the SysV init with busybox' init configured BSD
style. If I should have too much time one day, I'll probably fork this
kind of simplified LFS.
The objective is not to build the smallest possible system. In a sense
Busybox has some of the same issues as systemd. It hides too much
detail, however I certainly agree that Busybox is right for some
environments, especially embedded systems.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
