Posted by cf100clunk 4 days ago
LFS should stick to academic pedagogy, instead of trying to compete in the Linux Distro space.
Most modern programmers don't learn COBOL60 or Commodore BASIC. Modern mathematician very rarely study writings of Euler or Gauss; even 50 years old math books may be hard to grasp for modern students.
I agree that using a simpler tool for educational purpose is useful, but since SysVinit is obsoleted almost everywhere, it made sense to drop it. LFS could have chosen a simpler init than the domain standard, like runit or s6-init.
See this GIANT argument with hundreds of comments? It seems some people believe that SysVinit is, in fact, not even close to obsolete.
If Gnome/KDE can't support the init system I choose to use, then I don't choose to use their garbage software anymore.
Do people who really uses LFS even want GNOME or KDE on their system ?
I remember LFS from way back in the day.
What do we all think the overlap between LFS users and Gnome or KDE users is? I think it's pretty small.
I used the SVR4 packaging system from heirloom-pkgtools (using this of a Claude port of V4 unix to x86_64 as well at the moment) for fun, and compiled up CDE on top of this to boot. I wanted to see what Linux would look like if you dressed it up as much like SVR4 as possible. I liked the result actually. It was kind of like what Sun might have done if they dumped their own kernel and switched to Linux instead.
Originally it used SysVinit, and I started working getting systemd to work with it (because after several years I've come to appreciate it) - but that's the point I stopped working on Headrat - I realised if I wasn't adding SVR4 stuff and was removing it instead, it wouldn't be SVR4 enough.
I don't know how I feel about it - after all I could do an LFS straight out of my head these days without referring to the LFS docs - but I do feel there is something lost when as a Linux community, we try to shove the baggage under the rug and pretend that things like SysV init didn't play a massive part in Linux's rise throughout the 90's and 00's.
History is important, even if we don't like the code today and have more capable tools. But I guess SysV init is deader than dead at this point.
There is still interesting code patches here and there, and interesting info on brain damaged SDKs (gcc, glibc, etc).
Most of the time I remove the SDK itself, basically I write a linear and brutal shell script with fine grained control on the compiler/linker. I do push down to nearly remove completely the compiler driver (a spectacular failure) namely CPP->C->ASM->O.
I would like to move away from ELF too for a modern file format for dynamic libs and executable, but the "geniuses" using complex computer languages (mostly c++) for critical open source components make that a massive pain (runtime, ELF relocation requiring obsolete infrastructure, etc).
FreeBSD has a general utility that does this for you, daemon(8): https://man.freebsd.org/cgi/man.cgi?query=daemon&sektion=8
https://github.com/openbsd/src/blob/master/etc/rc.d/watchdog...
Your link is irrelevant. It points to OpenBSD which uses rc, not sysv. The 3 lines of this rc startup script use a file of 400 lines of shell with commands that don't exist in SysVinit.
With sysv, the difficulty depended on the local tools because the launching scripts could not be shared across Linux distributions. Debian used the compiled helper `start-stop-daemon` while Redhat did not.
With sysv, some sysadmin tasks require external tools. Try to write a launching script with a smart autorestart in case of crash. Make it work even when the daemon forks. Do not assume that the daemon writes its initial PID anywhere. IIRC, to get this feature, we had to drop sysv for runit, two decades ago. Now it's just 2 lines in a systemd unit.