As for Linux from Scratch - This is something that's been on my radar, but without the part I'm truly interested in (learning more about SysV) then I'm less inclined to bother. I don't buy the reason of Gnome/KDE - isn't LfS all about the basics of the distro than building a fully fledged system? If it's the foundation for the other courses, but it still feels weak that it's so guided by a future GUI requirement for systemd when it's talking about building web servers and the like in a 500Mb or less as the motivation.
If the project is even split in different parts that you need to understand... already makes the point.
OpenRC recently added user "units" aka services running as a user after a session start. Something that many new GUI user space applications rely on for various things.
There are growing pains. https://bugs.gentoo.org/936123
Especially when upstream hard requires systemd. More annoying when there's no real reason for it.
But there is a way forward and I highly recommend people try to build software to work without systemd before assuming it's always there.
I believe maintaining the base book is the most important part, BLFS has some really good hints but a very significant amount of packages have few differences, collecting these in a separate hints file or similar would help a bit, at least for things that don't hard-depend on systemd like gnome.
But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup.
To give you concrete examples:
1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts.
2. Except that you can, but only if you use the /etc/fstab compat.
3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device.
4. Systemd has separate behaviors for network and local filesystems.
5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!!
6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching.
7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1.
I can go on for a looooong time.
The attitude that you don't need to learn what is inside the magic black box is exactly the kind of thing LFS is pushing against. UNIX traditionally was a "worse is better" system, where its seen as better design to have a simple system that you can understand the internals of even if that simplicity leads to bugs. Simple systems that fit the needs of the users can evolve into complex systems that fit the needs of users. But you (arguably) can't start with a complex system that people don't use and get users.
If anyone hasn't read the full Worse Is Better article before, its your lucky day:
The iSCSI loop issue: https://github.com/systemd/systemd/issues/34164 It keeps popping up again and again and is summarily ignored.
The remote FS detection also came up multiple times, and the maintainers don't care.
Are you referring to the developer of Xlibre, who submitted multiple broken patches & kept breaking ABI compatibility for little to no reason[0]? Or someone else?
[0]: see discussion & linked issues in the announcement >>44199502
Here's some nice GTK3 patches for you:
http://killthe.net/patches/gtk-3.24.43-allow-disabling-atk-b...
http://killthe.net/patches/gtk-3.24.43-allow-transparent-win...
http://killthe.net/patches/gtk-3.24.43-allow-wheel-scrolling...
http://killthe.net/patches/gtk-3.24.43-appearance-tweaks-and...
http://killthe.net/patches/gtk-3.24.43-disable-mnemonics-del...
http://killthe.net/patches/gtk-3.24.43-file-chooser-tweaks.p...
http://killthe.net/patches/gtk-3.24.43-remove-dead-key-under...
http://killthe.net/patches/gtk-3.24.43-restore-old-context-m...
http://killthe.net/patches/gtk-3.24.43-set-default-settings....
http://killthe.net/patches/gtk-3.24.43-show-alternating-row-...
Note that GTK 3.24.43 is the last version of GTK3.
My system is full of patches like this to tweak, improve, and adjust things. The point is to get off the "upgrade" treadmill and focus on making things work right.
The only other page that covers it is how to compile it and it install it (make configure, make, make install essentially- with a bunch of flags).
It kind of touches upon a few commands that will let you know what its doing and how to get it started, but from this page you don't learn much about how it works.
In fact, one of my takeaways from LFS was that I already kind of knew how a linux system starts... and what I really wanted to learn was how the devices are discovered and configured upon startup to be used, and that is pretty much all done in the black box that is SystemD.
This fella would like to have a word with you:
https://github.com/openbsd/src/blob/master/etc/rc.d/watchdog...
Like systemd authors do! Hard-code the list of them in the kernel, including support for fuse and sshfs. Everything else is pure blasphemy and should be avoided.
Me? I'd have an explicit setting in the mount unit file, with defaults inferred from the device type. I would also make sure to not just randomly add landmines, like systemd-update-done.service. It has an unusual dependency requirements, it runs before the network filesystems but after the local filesystems.
I bet you didn't know about it? It's a service that runs _once_ after a system update. So the effect is that your system _sometimes_ fails to boot.
> systemd has .mount units which are way more configurable than /etc/fstab lines
It's literally the inverse. As in, /etc/fstab has _more_ options than native mount units. No, I'm not joking.
Look at this man page: https://www.freedesktop.org/software/systemd/man/latest/syst... The options with "x-systemd." prefix are available for fstab.
Look for the string: "Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file."
Design-wise, I think having users modify service on/off state *and* systemd itself modify those states is a terrible design, which leads to stuff turning back on when you turn it off, or things turning off despite you wanting them on, etc. (also mentioned higher up)
FWIW after making puteron I found dinit https://github.com/davmac314/dinit which has a very similar design, so presumably they hit similar issues.
They actually did, but they made the mistake of packaging only the bare basics with it, and hiding it away as much as they could: https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
The American government added some obscure law that forced POSIX compatibility on operating systems for certain grants, so Microsoft made their business OS POSIX-compliant.
In theory, nothing stopped you from downloading and installing up-to-date versions of common UNIX tools. Had Microsoft had the necessary foresight, they could've killed deverlopers' dependency on tools like Cygwin and Git Bash and Linux entirely for many pieces of software, but they were too busy trying to make Win32 the standard ABI.
Funnily enough, Win32 became the standard for proprietary software on Linux (thanks to Wine+Proton) while many Unix/Linux-based tools became the norm for development, even on Windows (git, Qt). How different things could've been!
FreeBSD has a general utility that does this for you, daemon(8): https://man.freebsd.org/cgi/man.cgi?query=daemon&sektion=8
https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
When Windows Services for UNIX came to be, it was already too late to matter, it wasn't really from Microsoft, and came with its own set of problems.
I am speaking from when Linux was still in baby steps, and basic stuff like ELF had just been added with the kernel version 1.0.9, in 1995.
Things could be even more different, had Microsoft kept Xenix, which was my introduction to UNIX, and one of Bill Gates darlings, actually.
https://www.theregister.com/2002/03/20/bills_vision_for_the_...
"The Future of Xenix"
https://archive.org/details/Unix_World_Vol02_10.pdf/page/n21...
In case you never read it, https://web.mit.edu/~simsong/www/ugh.pdf
Hardly the piece of OS beauty that gets praised about FOSS circles.
I'd just like to interject for a moment. What you're referring to as Linux, is in fact, Linux plus systemd, or as I've recently taken to calling it, Linux/systemd.
Linux is not an operating system unto itself, but rather another free component of a fully functioning systemd system made useful by the systemd corelibs, systemd daemons, and vital systemd components comprising a full OS as defined by Poettering.
Kids and their Parents learned it in the 80s and they had nothing but a manual. Either these people were massively more intelligent, or the same approach, using modern methods, would work again and again and again.
Considering the 1% rule of the internet (it's about the ratios, not the numbers!), shifting more people from the 90% to, at least, the 9%, seems to be one of the better courses of actions to take.
What we, MY FELLOW HUMANS [1], absolutely do not need is more people being optimized towards using a computer solely as a tool for someone else ... especially because AI can replace 99%+ of them anyway.
Are you surprised that such a service exists? I certainly was. And doubly so because it has unusual dependency requirements that can easily lead to deadlocks. And yes, this is known, there are open issues, and they are ignored.
> From a "what can you do in /etc/fstab without knowing systemd is working behind the scenes" point of view, then yes, systemd units are vastly more configurable.
No, they are not. In my case, I had to use fstab to be able to specify a retry policy for mount units (SMB shares) because it's intentionally not exposed.
And yes, there's a bug: https://github.com/systemd/systemd/issues/4468 with the expected GTFO resolution: https://github.com/systemd/systemd/issues/4468#issuecomment-...
So there's literally functionality that has been requested by people and it's available only through fstab.
To give an example, let's say a package depends on systemd because it uses sd_journal protocol, presumably because it wants to send enriched logs. That protocol is fully described (in [0]), and is actually pretty trivial to implement, on both server and client side. It even have a build-in "upgrade" mechanism (via $JOURNAL_STREAM) to allow seamless switch between base/systemd-logs, although AFAIK sd_journal_* functions do not implement it by default.
So this brings us a question: if a program wants to provide rich logs, and it is is using a documented protocol to do so, but there is only one implementation of the receiver, is this a problem? Is the onus on the program's authors to support multiple log sending functions, or on the distributions to provide a log receiver that the program expects?
Imagine that you have a service that has a configuration-dependent dependency on rsyslog. For whatever reason, journald's not an option... maybe it's simply not installed, or this service depends on rsyslog-specific behaviors that journald simply doesn't replicate. It doesn't matter why this configuration-dependent dependency exists, it simply exists and there's no workaround.
Assuming that the rsyslog service is named 'rsyslog', the service with the dependency is named 'stupid-service', the configuration file is named '/etc/stupid-service/stupid-service.conf', and the configuration option to search that config file for is 'logging = syslog', what would the systemd service file generator look like to make 'stupid-service' depend on 'rsyslog' if and only if that config file contains 'logging = syslog'?
You appear to have worked with these service file generators, which is why I'm asking. I expect you'd know what the generator to accomplish this trivial task would look like, or if it was even possible with generators.
Also:
> Yeah parsing config files with regular expressions that may or may not properly handle quoting or line continuations
Nah, this is substring matching and column-cutting. The only use of regexes ("#.*") is to remove comments. Go check out the format docs for the PostgreSQL config file. [0] It's pretty basic and straightforward.
[0] <https://www.postgresql.org/docs/17/config-setting.html#CONFI...>
Turns out, a lot of people are not happy with "Come on man. It's been done for decades." attitude, and they wanted something new and much better. And so when something new came up, they jumped on it with both feet.
It's instructive to read Debian CTTE discussion on init systems (btw I think it's best tech drama of 2013, highly recommend) - a lot of people dismissed the sysvinit early on because it had no features (example [0]), which means the choices were either upstart and systemd. And between two of those, systemd is a clear win.
Read the thread and look at how many highly technical people with no relation to Fedora or Poettering is ready to choose _anything else_ just to get away from "it's been done for decades".
[0] https://lists.debian.org/debian-ctte/2013/12/msg00234.html
Where's that documented?
I tried the obvious things followed by a config reload. Here are the results (the 'log_destination' parameter is on line 482 of the config file):
log_destination = \
'stderr'
LOG: received SIGHUP, reloading configuration files
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "\"
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'stderr'"
LOG: configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied
log_destination = 'std
err'
LOG: received SIGHUP, reloading configuration files
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "'"
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'"
LOG: configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied
log_destination = 'std\
err'
LOG: received SIGHUP, reloading configuration files
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "'"
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'"
LOG: configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied
log_destination = 'stderr'
LOG: received SIGHUP, reloading configuration files
<No additional output is produced because 'stderr' is the default>
#log_destination = 'stderr'
LOG: received SIGHUP, reloading configuration files
LOG: parameter "log_destination" removed from configuration file, reset to default
The general format of the pg_hba.conf file is a set of records, one per line. Blank lines are ignored, as is any text after the # comment character. A record can be continued onto the next line by ending the line with a backslash. (Backslashes are not special except at the end of a line.)
That's truly a lovely and laudable goal. In this system, how does you propose one processes a flat text config file with a mix of 'K = V' and 'K V' settings without doing ordinary, boring text processing? Do you propose that one waits until "systemd-configd" gets created and every daemon of any importance is updated to put its config in there instead of in flat files? If so, has there been any notable progress on this in the last ~fifteen years?
> Put a script in /etc/systemd/system-generators/...
Thanks for finally answering my question. Is the way to conditionally update service dependencies really to dump text files in magic locations? Is there no 'systemctl' (or similar) command that allows one to manipulate dependencies for a specific service that one can call from a generator?
[0] <https://www.postgresql.org/docs/17/auth-pg-hba-conf.html>
I have read the first couple pages of these results. Would like you like to highlight one of these in particular?
I am very sorry to inform you but efivarfs is something coming from the Linux kernel. Being able to rm -rf it is squarely something that is entirely on the kernel implementation, WHICH THE AUTHOR OF EFIVARFS EVEN ADMITS[0]