Am 09.09.2014 um 19:09 schrieb Bruce Dubbs:
Mattias Schlenker wrote:
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.
It might be partially about the junk they add, but partially you are
getting unfair. "Commercial" distros usually use an one size fits all
kernel and an initramfs to load drivers, initialize hardware and wait
for the root device. I assume you use a kernel with drivers included
tailored to your hardware. You probably do not use an initramfs with
scripts that have to search for a filesystem with a certain UUID. You
just specify root=/dev/sda1. Loading and unpacking the initramfs usually
already adds two to five seconds (depending on size and hardware).
The boot time is one of the aspects the Chromium/Chrome OS guys and
girls do right. They do not use an initramfs, but kernels tailored to
their reference hardware. Getting quick to a login is the first
objective. If the login appears faster than the network is connected the
user might have to wait a moment for the network. In most cases the
network is up when the user finishes entering the password. Everything
else can wait. On most notebooks you do not need an IPP daemon ready at
login time. These are lots of aspects where a properly configured SysV
or BSD init (with scripts that allow some parallelization and
dependencies) can be faster. At least in theory a properly configured
systemd or upstart should shave off another second or two. BTW: This
fear of forking is overestimated. Forking and invoking lots of shell
scripts was expensive fifteen years ago, nowadays this does not
legitimatize putting all logic into bad to maintain binary blobs.
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.
For embedded systems we have CLFS and derived stuff like
https://github.com/mschlenker/TinyCrossLinux Regarding the hidden detail
I mostly disagree with you if carefully selected which functionality
from busybox to cover. SysV init itself evolved into something quite
complex. So complex that distributions like S.u.S.E. (with dots) ignored
runlevel 2,4,5 completely and started the graphical login in runlevel 3.
SysV init soon became so complex that an extra set of tools for managing
the scripts had to be developed. So, to teach how UNIX like operating
systems boot busybox init is a nice thing. To speed up chapter 5,
busybox also is a nice thing. In practice I hope that runit gains enough
traction to be widely adopted in the next few months.
In the mid to long term, the LFS project has to decide on init. I do not
like systemd in its current incarnation since it tries to incorporate to
many tools that always worked standalone for rather small benefits. SysV
init is a dinosaur from 25 years ago that proves to be flexible but
reaches its limits and really does not excel at a managing todays needs
for booting on changing hardware in changing environments. upstart is
dead and being replaced by systemd in Ubuntu. BSD or busybox init is
great for embedded and teaching purposes. So what's next? Are we left
without a proper init that follows the Unix philosophy of "make every
program do one thing well"?
Yours,
Mattias
Disclaimer: I moved from BSD to Linux. I started with SunOS 4.1, later
used FreeBSD 3 to 7 and only recently (kernel 2.4) switched to Linux
because my work required it.
--
Mattias Schlenker - Freier IT-Fachredakteur und -autor
redakt...@mattiasschlenker.de
Mattias Schlenker - IT-Consulting, Softwareentwicklung
consult...@mattiasschlenker.de
Address__ August-Bebel-Str. 74 - D-04275 LEIPZIG - GERMANY
Call me! (VoIP)__________________________ +49 341 39290767
Call me! (PoTS + Faksimile)______________ +49 341 30393578
Call me if it's urgent! (Mobile)_________ +49 163 6953657
VATIN_________________________________________ DE240998538
Fork me!____________________ https://github.com/mschlenker
Website.__________________ http://www.mattiasschlenker.de/
My books!___________ http://www.arduino-hausautomation.de/
Google+_________ https://www.google.com/+MattiasSchlenker1
Xing_______ https://www.xing.com/profile/Mattias_Schlenker
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
