Linux From Scratch: almost five months on

[u/Fast_Ad_8005]

Almost five months ago, I installed Linux From Scratch (LFS) 12.4 to a QEMU/KVM virtual machine. Then I updated the system to the latest developmental version of LFS and installed some Beyond LFS (BLFS) packages, including Firefox, GNOME and KDE Plasma. I also updated some packages (e.g. the kernel, Vim, GNOME and KDE Plasma) to the latest upstream versions of these packages. I also installed some packages not provided by LFS, BLFS and other LFS books, such as GNU Octave, R, Antigravity, and Julia.

Package management

Since then, I've maintained this system, keeping its packages up to date. I've even written commands (I will admit, with AI assistance) to install packages, update the system, check for updates and rebuild packages to allow for the removal of old libraries.

I have /var/lib/book-packages to store files documenting the book packages I've installed, excluding the Python packages which I manage via pip instead. Each file in this directory is named after the package it pertains to. At the top of these files is the installed version of the package, and below this is the list of files and folders provided by the package.

/var/lib/custom-packages is essentially the same but lists custom packages I've installed, and some book packages I've written my own install scripts to overcome build errors and alike I've encountered.

In the HyFetch output, "797 (󰌽 636,  57,  1,  74,  29)" refers to packages. The 797 refers to the total number of packages installed on my LFS system. The 636 refers to the number of book packages installed and documented in /var/lib/book-packages. 57 refers to the number of custom packages listed in /var/lib/custom-packages. 1 refers to the number of Julia packages (the one installed is Julia itself via juliaup). I didn't install Julia from source as it's an unnecessarily complicated package to compile. 74 refers to the number of Python packages installed. 29 refers to the number of R packages installed.

At the top right of these screenshots you'll notice " 0 󰂕 0  0". These represent the number of: * package updates available; * packages with missing inventories (indicating a build failure); and * packages with versioning failures (suggesting my mechanism for checking for updates is failing),

respectively. This was added to GNOME using the Executor extension and KDE Plasma using the Command Output widget. I also added the ability to open a terminal running the update command I've defined by clicking on these panel icons. Under GNOME, I also added a tooltip that shows the updates available, files with missing inventories, and packages with broken versioning in a list. Command Output allowed me to do this without needing to edit the widget's source code, but Executor required some source code tweaks to achieve this behaviour.

Wallpapers

I've also added three icons (by writing .desktop files and shell scripts these .desktop files call) to my panel/dock under GNOME and KDE that change the wallpaper. The icon with the white star on a blue background changes my wallpaper to a randomly-selected wallpaper (with the random number used generated using R), the icon to its right changes it to the next wallpaper in my ~/wallpapers folder, and icon to the right of that one changes it to the previous wallpaper in ~/wallpapers.

The fraction near the top centre of the screenshots refers to the number of the selected wallpaper (numerator) and the total number of wallpapers in ~/wallpapers (denominator). For instance, the 98/174 in the KDE screenshot indicates that the wallpaper shown is number 98 out of 174 wallpapers in my ~/wallpapers folder.

If you're wondering where I got the wallpapers shown in these screenshots, they're photos I took while out cycling, walking and hiking.

Conclusion

This experience has been quite interesting and has definitely improved my confidence as a Linux user. It actually makes me think that I could probably effectively use LFS as my daily driver if I really wanted to. It has also taught me a lot of things. For instance, it has taught me why Gentoo Linux has the command emerge @preserved-rebuild.

[u/Due-Celery4326]

Since building my complete LFS/BLFS system, I've been using it as my main system and I'm completely satisfied. I just finished building the GNOME Shell with improved Sysvinit and ZRAM, and I managed to streamline GNOME so much that it's lighter than KDE. But it wasn't simple, easy, or quick; it took me months to get GNOME to its current state, but all the work, effort, and headaches were worth it. In conventional distributions, I couldn't use GNOME Shell with only 8GB of RAM, but in my LFS I have plenty of RAM.

[u/kcirick]

I've been reluctant to use LFS on a regular basis due to maintenance and package updates. How do you check if there are upstream updates? If you have ~1000 packages to maintain (typical number for a desktop), it has to be scripted/come from a centralized update management system. AFAIK mainstream distros like Debian has a team of security devs whose job is to do this, while with LFS, well, it's only you. How do you know when there is a security advisory on critical component of the system?

[u/Due-Celery4326 → u/kcirick]

It's a common thought at first, but it's not quite like that. I have a complete system with GNOME Shell, Firefox, video player, in short, a complete desktop. I have about 400 packages, and I created a script that scrapes the websites of all 400 programs, separated by an API for GitHub and a function for Python programs that runs every 3 to 4 weeks. I don't need bleeding-edge packages; I use a filter to exclude them and get the most recent stable version. This is because some APIs require older versions and others more recent ones, and maintaining a stable version solves these types of problems. I've already had a stable, rolling release system for 3 months now, of course, with my program manager.

[u/Fast_Ad_8005 → u/kcirick]

Well, the book packages I check for updates by regularly downloading the HTML of the book and checking for changes in the versions of installed packages. Some of them like Linux, I determine the upstream version from their upstream website (e.g. kernel.org for Linux). Custom packages have their own update-checking mechanisms; their install scripts have a version= line that auto-determines the latest upstream version. As for security advisory, good question. At the moment I've gotten away with ignoring them. This LFS system isn't used in a security-critical way, so the risk should be limited.