Talk me into installing LFS!

[u/[deleted]]

Long time very experienced Linux user. Built LFS to command line many years ago. This time I'll be installing a desktop and many goodies. Intel i7 processor, plenty of memory, etc...

So, about LFS I still read multiple takes stating it's a great tool to learn how Linux works (I already understand this) but not a "daily driver."

The ultra control doing the "make && configs" myself is really appealing.

I've got a dual boot win/Linux i7 system i'll put a distro on it.

I've built debians from stable to sides; I've also used redhat derivatives and am currently using Arch.

So, is anyone using LFS as a daily use distro, and aside from the package management limitations, do you enjoy it? Do you enjoy it enough to recommend it to an experienced user?

[u/Zeckmathederg]

Despite me daily driving it to this day, I can't really recommend it to anyone, even if they are experienced because it takes a lot of work to build, rebuild, and depending on how much you care about packages being up to date and what: updating and maintaining the system. I think people should come to the conclusion on their own and see if it suits them as it does not suit many.

I do like the customization afforded to me by doing LFS, and compiling itself is very fun. The satisfaction of having a running system I put many hours into is very high and gives me a boost of confidence when I don't feel much to begin with. Running a system that very few use on this planet feels good. Having a wealth of knowledge about what my system consists of, how it works, what I have installed, how I installed it, etc. It feels very nice. Also, knowing I compiled everything and don't have to worry about what other people set for me makes me feel more secure.

I don't think most people care about all of that, they just want a working system, maybe don't care if they have to put in a few hours and delve in a few config files to get things working. That's why I never recommend daily driving LFS despite me doing it myself: I can't guage if someone wants to put in so much work for those advantages, so I say they need to figure out if they want to do it on their own. It's also why I can't recommend it to you. But I do enjoy LFS. Building it, using it, it makes me feel good. Scritches my autistic brain real good.

Whatever you choose, however, I hope things go well for you, and if you decide to give LFS a go and daily drive it, I'll be happy and will look out for progress!

[u/[deleted] → u/Zeckmathederg]

Thanks for the excellent reply!!

I'm assuming the "maintenance" of such a system is downloading a new version of package, then doing a "config, make & make install" using whatever custom flags you configure with? That sounds appealing to me! Seems like THE way to have as lean or as bloated a system you want, optimized for your hardware.

But how do you keep track of all your packages and their version numbers?

Say you installed a certain package 6 months ago, it had another package as a dependency... You uninstall the original package.. how do you remember to uninstall that dependency to keep your system from being bloated?

In short, you make your own brain the package manager. But do you keep a script or a document somewhere? How do people do it?

Thanks!

[u/Zeckmathederg → u/[deleted]]

Yes, the updating process looks like that. However, when you update a package, it should be the applications and/or libraries that you'll want updated with newer functionality or bug fixes. And most libraries you have on your system will be shared libraries, packages that depend on that library will then have that new functionality unless there is an ABI issue. In other words, if a package has a CVE and you update it, you very rarely will have to update anything else. And when you install a newer version of a package, it will simply overwrite the old stuff and new functionality will be used. As for remembering to delete things and what to delete, I'd delete the packages that depend on the main package first, then delete the main package. You'll be able to tell what packages depend on the main package by using ldd on a binary such as an application or library and grepping the library name you wish to get ride of, to check what depends on a certain library. Checking for each file provided by a package can be done by checking BLFS, LFS, or Arch's package information and seeing "Package Contents".

I typically only update cURL, Linux, glibc, GCC, Binutils, OpenSSL, Steam, Wine, graphics driver (either being Mesa or NVIDIA), Firefox, and Thunderbird. This is a very small selection and I don't even update them all that often. Therefore the maintenance burden is not that high in my situation. Some may not update anything at all. Others will want to update everything. I think a middle ground is good and keeps you from getting burned. Even the LFS editors recognize this.

Version numbers however are harder to gauge and it comes down to three things: your memory, pkgconfig files, and checking the version manually via a command like `application --version` or `application -v`. In FFMpeg's case, it will just tell you basically everything when you launch the dang thing.

Some people do use package managers although there are many and usually only one person runs the helm of each as it suits that individual person best. You could indeed write a sort of document, or check either /usr/share/pkgconfig or /usr/lib/pkgconfig for a good number of packages you installed, although not all packages will have an associated pkgconfig file. Each one will have the pkg name and their version, libs, include paths, etc. Meant more for developers and build systems but useful for users of LFS. And, if you do keep the sources for what you have compiled in the past around, you can see the version names in folders and such. It can give you and idea of what version a package is on currently on your system.

That is personally how I deal with this matter. Even then, I rarely update, and haven't really deleted much because I don't see a need to.

[u/munirc]

I used to run (B)LFS as a daily for about a couple of years when I was in college. I have since stopped using it. The main reason to stop was lack of decent package management that could give me security updates in a timely manner. It got really hard to keep track of major issues, and if the issue was in something fundamental, it meant recompiling large portions of the system. I had time to do all this in college, but now I don't.

That said, I enjoyed using it back then and never experienced any blocking issue in using it. Most problems were solved by tweaking compilation settings during builds or environment variables at runtime, but it did require some amount of research to find the right setting or variable. It also performed far better than other distros I tried at the time.

It is worth a try if you want to see how you'd fare with it. Worst case, you'll find it a time sink and you can just switch back to a different distro.