I don't mind the inevitable death of System V. It's an archaic relic of the Linux era.
Going systemd-only is not necessarily a good choice (though I do understand it from a practical point of view). There are other, better alternatives for System V that are smaller and more modular so you still get the Unix "feel" without the absurd complexity of interlinked shell scripts that System V relies on.
I'd like to see OpenRC getting adopted in System V's place. Upstart seems to be dead (outside of ChromeOS) but it would also have sufficed. Alas, I'm not someone with the time or knowledge to maintain these tools for LFS, and unless someone else steps up to do all the hard work, we'll probably see LFS go systemd-only.
That said, there's no reason to go full-fat systemd, of course.
It's an archaic relic of the Unix era.
The reason it is being removed is precisely because now we are in the Linux era, no longer in the Unix era.
Have another vote in favour of OpenRC, and even Upstart, if it somehow revives.
I think systemd is the one to learn now if you want to learn Linux. Maybe someone can make a Unix from Scratch for people more interested in the Unix philosophy than Linux per se.
SysVInit on Linux isn’t true Unix though as the way it abuses runlevels to start daemons was never intended by the original designers of init.
Yeah, people forget the degree to which sysvinit was hated at the time - "why are you forcing me to deal with an impenetrable forest of symlinks rather than simply hand-edit a couple of basic rc scripts?!?".
If the intention is to create a system that users can reason about, then sysvinit offers the worst of all possible worlds.
> why are you forcing me to deal with an impenetrable forest of symlinks rather than simply hand-edit a couple of basic rc scripts?
Run levels. That's it, sysvinit is about run levels. Each run level starts or kills off its own specific list of runnable things like applications, daemons, capabilities, etc.
Run levels were a desirable feature back in the day amongst System V Unix vendors, so each run level required its own kill and start scripts for each item. Run levels, for example, could take a running system from single user (root admin) mode to multi-user, multi-login, NFS sharing, full X11 mode in one command immediately as the scripts ran. This allowed rapid reconfiguration of a system, such as from a GIS workstation to a headless file server, etc. etc. as needed. Each system could be configured to boot to a specific run level. Rather than duplicate some or all such scripts across some or all run levels, symlinks were the solution.
For example, Solaris had run levels 0 through 6. Zero was a blunt force system halt; 1 was single root user admin mode; 2 was multi-user headless mode with NFS; 3 was multi-user X11 windows mode with NFS; 4 was unspecified and therefore kept for purely local configuration as desired; 5 was a planned, orderly system shutdown; and 6 was a planned, orderly system reboot. The root user could implement their choice of run level directly with the init command.
Each run level had its own run control directory (rc.d) under /etc/rc.d for its appropriate kill and start scripts, which were run in order of their K or S number, so dependencies had to be kept in mind when numbering, and curing a dependency failure was as simple as changing a script's number to rearrange the list. So, why copy S04blahblah from rc2.d to rc3.d when a symlink is far better?
Its not hard to understand when you get the big picture, and it wasn't hard to administer if you had the proper overview of it all. Admittedly, admins coming in cold would have to sort through it all, which is partly why it gained a reputation for murkiness when not properly documented by/for local admins. Keep in mind it was the era of administering sendmail macros and NIS tables by hand and you get the picture.
NOTE: edited for clarity
systemd is most certainly the most pragmatic service to learn, but if you're doing LFS to "learn" how a Linux system gets brought up, something lower-level may be a better idea to pick up.
All this stuff is versioned anyway so if the point is learning youe can still read an old version of the book and use old versions of the repos.