None of that requires LFS; I compiled KDE via scripts many years ago. Why would LFS be needed for that? That makes no sense. Debian being slow is their problem, other distributions aren't snail-like like that. The default compiler used in LFS is also hardly a real cross-compiler, it is more a bare-minimum compiler for C/C++. This annoys me because e. g. I need fortran for R, so a bare-minimum compiler isn't as useful as a more feature-complete GCC. And GCC also causes some issues, e. g. like my problem with options.cc.

I think you missed the main argument though - LFS isn't quite as good as it could be. That is a correct statement that was made.

"Requires"/"needed".

LFS is about the muscle memory; the documentation; the cohesiveness.

I always recommend it to people and consider it foundational to my understanding of How Stuff Works.

Whether that amounts to a hill of beans in the AI world remains to be seen.

It is more how stuff is compiled than how stuff works.

Fundamental things like how processes are scheduled are not explained by LFS.

"works" is a loaded term. LFS is how the rubber meets the road, you want how the rubber is made, for that you need something like https://www.baeldung.com/linux/processes-guide or https://linux-kernel-labs.github.io/refs/heads/master/lectur...

And if you want to get to at least the bottom most visible turtle you go with something like NAND to Tetris https://www.nand2tetris.org/

>LFS is how the rubber meets the road

Again I disagree. Way too much time is spent building software than actual practical OS development.

LFS is not OS development. You build a distribution by assembling all the components. If you want to develop an OS from scratch, perhaps you're looking for osdev.org.

What is the point of making a distro, if not to make an OS? It's the same thing.

One supports the other, they aren't laid in opposition, but they are different, well-defined disciplines

OK: "How *nix tools functioned together in command-line days".

Learning how to compile packages manually it was a common skill long before Linux came to be, and how GNU/Linux fits together could also easily be learnt with Slackware or Yggdrasil.

As someone who started using Linux in 1996 (Slackware, of course), I learnt the hard way about compiling packages. I remember trying to compile the kernel, and doing "make config" and following hundreds of options, and not knowing that I then needed to do "make" or "make zimage" or "make install" after any of the config stuff. Obvious, dumb, rookie errors, but still understandable for a teenager coming from Windows. Doing LFS really taught me a lot about dependencies and complexity, as well as understanding of the actual boot process. All of this helped me greatly in later years.

Your experience sounds exactly like mine. I downloaded Linux 2.6 which took 2 days to compile. Then when I installed it on my Slackware system completely hosed it. But learned so much…

I started with Slackware 1.0 on i386.

I certainly do not miss compiling X11!

>Learning how to compile packages manually it was a common skill long before Linux came to be

Right. I used to compile many open source packages from source on many flavors of Unix back in the day, for years. Perl, Python, MySQL, many others. Miscellaneous utilities. Esoteric languages. Even Oracle, once, on a Unix server, right at a large manufacturing company site. Even building Unix kernels from source was common on some Unix versions. And not just for a regular install. Many times, (re)building Unix kernels from source, was the only way to get some software packages or hardware devices or peripherals, like printers or terminal controllers or even hard disk controllers, to work on the system. Typically you would edit some config files or settings files manually, change values of params, or in some cases use a TUI to do that, and then rebuild via a makefile. You had to save the old kernel in case the new one didn't work, and if so, lather, rinse, repeat, till everything did work.

And that practice was nothing special. A lot if people did it routinely. Most, in fact, I'd say. Talking about devs and sysadmins here, not end users, although some of the latter probably did it too.

Many apps, tools and utilities came as source code, often in a .tar or .tar.gz file. You would untar or gunzip it into a new directory, and do your stuff, running makefiles, other shell commands, setting env. vars., etc.

I agree with you. Maybe the person from the first comment read first few pages only which basically give some context.

For me also helps me to cross compile Nvidia kernel drivers for other version of kernel than running one. Plus compile stripped-down version of X.

All this for running on embedded Linux with 32MB flash drive running from read-only volume powering two kiosk displays.