LFS takes the wrong approach in my opinion. I did it once manually over a couple of days. I suppose I hoped enduring the pain of waiting for the packages to compile would somehow make me smarter. It didnāt. I didnāt learn much. It was like following a baking recipe. I know I need to add eggs and sugar in the ratio it says but Iād be damned if I could tell you why that specific ratio works.
Itās just too much to take in at once. You start by building a cross compilation toolchain butā¦ why? And you add the bootloader dead last, even though itās the first thing you see when you boot a Linux machine?
I reckon a better approach would be to build it step by step, only adding new things once youāve discovered a need for them. First you get the bootloader working, then you get it to actually load the initramfs and kernel, etcā¦ you could even create your own extremely simple initramfs first before adding dracut, etcā¦
This gets you to a system you can boot and play with asap. And then you can slowly start to discover why you actually need all these things through exploration and experimentation.
LFS helped me a lot. It taught me how to compile packages manually, and how GNU/Linux components fit together.
Armed with that knowledge, I could do things others could not do:
- Make applications that bundle/automatically download their dependencies, compile them with custom flags (static linking)
- Diagnose build errors buried in deep dependencies when using vcpkg
- Compile programs for esotheric systems: e.g: Intel MacOS X 10.5, an obsolete system noone else on earth is using except the company I worked at
- Create application targetting obsolete systems but using the latest version of its dependencies
- Compile recent programs on esotheric systems, by bootstraping a newer gcc on the newer system, patching as necessary
- Create my own stripped down distro, tuned to my specifications
- Use that stripped distro as a docker container
- Run recent linux on obsolete hardware no longer supported by mainstream distros
- Reformat a cloud dedicated server without physical access by first bootstraping a minimal distro on a ramdisk, unmounting the main drive, partitioning that drive, and installing the new distro on that drive. Reboot and pray.
- Build a cross-compiler for targetting a freestanding environment
- Build latest KDE/XFCE for debian stable. No more "but debian ships with outdated software!!11"
- Build applications on a distro they were not designed for (Zimbra OSE on debian)
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.
As pointed out already, LFS is a cookbook, and you learn most by having an idea about how you want to tune your Linux system.
So at points you want to dive deeper, you do ā and go off the beaten path.
It requires a desire not just to understand how bits and pieces fit together, but how you can make them work even better for yourself and what is and is not customizable?
Arguably, even if building it today is easier ā back when I did it in 2000, you sometimes struggled to find where the canonical source code of the package is, not to mention compilation errors, linking errors, etc. Only then did you get to configuring the init RC system, choosing between them (no systemd yet), etc.
But a requirement is ā IMO ā that you are strongly opinionated about how a system should serve you, and look for opportunities to tune it.
I've learned the most from LFS long time ago, when I had no internet. I had a mismatching set of Slackware and redhat source CDs, and LFS itself didn't match the versions on CDs too. Since then I can build anything and anywhere, even if it's not cooperating :)
> And you add the bootloader dead last, even though itās the first thing you see when you boot a Linux machine?
That actually makes perfect sense. If you did the bootloader first, how are you going to build it? How do you know what to boot from which filesystem on what device? By the time you've got your root filesystem complete, it's easy to tell.
If you do things step by step incrementally, you keep having to go further back in the process. Starting over repeatedly gets tedious, boring and frustrating. And it'll take ages to finish the complete OS.
Except that if you fail to install the bootloader - which happened to me many times - then you do not have a working system. So really the prior argument makes sense.
IMO the guy is right - LFS could be way better. But it has this current structure and does not deviate from it. That's the bad part.
> If you do things step by step incrementally, you keep having to go further back in the process. Starting over repeatedly gets tedious, boring and frustrating. And it'll take ages to finish the complete OS.
Pray tell how that is necessary for the bootloader? The chain used in LFS isn't the only one that makes sense or is required. IMO it would indeed be better to have a system you boot into as quickly as possible, on real hardware, then continue from there.
> It was like following a baking recipe. I know I need to add eggs and sugar in the ratio it says but Iād be damned if I could tell you why that specific ratio works.
I know a french cookbook[0] which contains not only recipes for dishes, but also for some of the intermediary ingredients, like stocks, that can now be bought at the supermarket.
I feel that Iāve learned a lot by following those recipes, be it simply in the structure of french cuisine.
And to me, LFS is a cookbook in a similar sense.
Sounds like a speedrun of the tutorial. How did you approach packaging then and what system did you use to compile everything?
I did the tutorial in the late 2000s I think and it took me 4-6 months if I remember correctly. At the time I wasn't completely new to Linux but setting up things like the boot loader was quite tricky for me.
For me the main motivation was getting a deeper understanding, being able to fine tune and customize my system. Of course I didn't go blindly through the tutorial but only did steps that I understood. (In case something goes wrong) Also I started to use (x)stow for everything.
It is possible to do it over a few days really, even with not too much knowledge.
Requiring four months seems as if it was a side project, which is of course totally fine, but for any main task it really should not take more than a few days, even on a semi-slow computer (well, depends on how slow).
well, if you happen to be in a 'rm -Rf /' situation (which with agentic AI seems to be more often the case) to know how to operate in a chroot environment could be helpful
This should be said more often, and in many other contexts as well.
Most educational resources are what- and how-based, only the best ones are primarily why-based, what Wirth once wrote in the preface to some Pascal book (I paraphrase) 'discussions are motivated, so that the learner gets coverage and understanding, instead of memorization'.
I learned a lot doing Gentoo stage 1. I was also following the guide like a recipe, but at the time I hadn't been exposed to the underlying machinery that is often automated, abstracted away, or done for me already. It was also a good test on how well I could follow instructions and later on apply my own customisations. Like lego.
To some extent I agree with you. I'd like to decouple some parts,
e. g. the tutorial part is great but it should ideally be distinct
from "just go at it" 1:1. I also fail to compile various things right
now, which is frustrating; two or three years ago all went well. The
whole LFS build up is too brittle. In part this is due to external
complexity, but LFS needs to re-think what it does. It's also sad that
they are now systemd-only, which further adds intrinsic uselessness. I
don't need anything systemd offers; all my boot up logic is stored in
yaml files and autogenerated to target formats via ruby as-is.
I second this a thousand million times. But with AI, i can't help but admit i find myself indulging in building things backwards, now that i can try a couple different approaches simultaneously for it.
I used CLFS (Cross-Linux From Scratch) once to bootstrap Linux on my SGI Indy, and I learned quite a lot from this. That was back in 2008 or so, so way before AI and extensive online guides for almost everything. It taught me how cross compilers work, what dependencies exist in the GNU toolchain, how the SGI boots, and much more.
Too bad Cross-LFS is no longer a thing. Then again, with all these microcontrollers and ARM and RISC-V systems today, cross-compiling is no longer as magic (and tricky) as it was back then...
Compiling the packages doesnāt teach much itās all the glue in between. No? Itās the startup scripts and the configs and creating a kernel and all the things.
Itās on my list of things to do when I have some free time
You know, you could also just read about each step to learn more. I mean if you feel you're following a baking recipe, you can just... read about it more. And then have LFS as a simple way to experiment if you want to change anything or not. Also, technically you don't need to have a bootloader installed on your main hard drive if you already have it on another disk.
I mean, eh... last time I checked, this was Hacker news. Yesterday, there was an Ask HN topic on how to enable dark mode on HN. Is this the new hacker culture? Complaining that the resources merely point in some direction instead of specifying details?
My journey was: Start off by clicking LFS among the links, and then "Read online" in the sidebar, and then being lost. I see a header, "Current Stable" but I can't see the link to the actual book. I only see the errata, the security advisory and a link labelled... stable LFS systemd? Maybe it's that one? Yes, yes it is.
Took me half a second to realize I would probably start with "LFS :: Linux From Scratch is the main book, the base from which all other projects are derived."
I kept an LFS system going for a few months (on a wretchedly awful by modern standards celeron ānet topā) until eventually making a mess I couldnāt figure out how to untangle during a system upgrade. this gave me the sheer force of will necessary to later do things like own the multiplatform build system for an ocaml based distributed system (mina)
For a long time (probably 2002-2010) I really wanted to do LFS. But I've been on Gentoo since 2004 which, over the last ~22 years, has probably exposed me to almost everything LFS would have, plus a lot more it wouldn't have. I still wish I'd did it way back when. I probably would stumbled through fewer issues had I.
I had the same experience. I think the only thing that LFS would add to that experience would be the package-manager-less experience (building without portage's help)
LFS is great. Unfortunately nowadays I often fail to compile
it; most recently with GCC complaining and failing at options.cc.
But I also get more issues here.
I kind of need a LFS variant that is more flexible. For instance,
the part up to having a working standalone compiler, should ideally
become more robust and/or decoupled from the actual LFS build process.
Once I have a sane toolchain, the rest is trivial, ruby scripts solve
that part for me. But the build up towards that is not so reliable.
Things also fluctuate so much in the build process; I still need perl
for instance, and python wants to add more and more complexity into the
build system as well, even though meson/ninja is a nice combo. For some
reason, the build situation on Linux is not very elegant to word this
nicely. Then we also "now you need LLVM and glslang and spirv" and so
forth, and so on. The complexity always increases. To some extent I
can understand why slackware crumbled. How can a single person, even
with scripts, keep that all working?
I do LFS every year, just to keep the chops sharp. It has been an immensely invaluable means of keeping informed with the way things are rolling in the Linux world.
I did LFS once, a long long time ago (days of RedHat 7.3, I'd say, 2002), and it was quite educational! It's a good way to learn the fundamentals of what comprises an actual Linux system
This whole project wastes time that could be spent learning operating system design and it spends it telling users to download files, extract them, and run ./configure; make; make install 100 times.
LFS is really, really bad. Also, reading the Linux kernel documentation to understand how to do it right is infuriating because it too is really, really bad.
LFS takes the wrong approach in my opinion. I did it once manually over a couple of days. I suppose I hoped enduring the pain of waiting for the packages to compile would somehow make me smarter. It didnāt. I didnāt learn much. It was like following a baking recipe. I know I need to add eggs and sugar in the ratio it says but Iād be damned if I could tell you why that specific ratio works.
Itās just too much to take in at once. You start by building a cross compilation toolchain butā¦ why? And you add the bootloader dead last, even though itās the first thing you see when you boot a Linux machine?
I reckon a better approach would be to build it step by step, only adding new things once youāve discovered a need for them. First you get the bootloader working, then you get it to actually load the initramfs and kernel, etcā¦ you could even create your own extremely simple initramfs first before adding dracut, etcā¦
This gets you to a system you can boot and play with asap. And then you can slowly start to discover why you actually need all these things through exploration and experimentation.
I'd like to counter your comment.
LFS helped me a lot. It taught me how to compile packages manually, and how GNU/Linux components fit together.
Armed with that knowledge, I could do things others could not do:
- Make applications that bundle/automatically download their dependencies, compile them with custom flags (static linking)
- Diagnose build errors buried in deep dependencies when using vcpkg
- Compile programs for esotheric systems: e.g: Intel MacOS X 10.5, an obsolete system noone else on earth is using except the company I worked at
- Create application targetting obsolete systems but using the latest version of its dependencies
- Compile recent programs on esotheric systems, by bootstraping a newer gcc on the newer system, patching as necessary
- Create my own stripped down distro, tuned to my specifications
- Use that stripped distro as a docker container
- Run recent linux on obsolete hardware no longer supported by mainstream distros
- Reformat a cloud dedicated server without physical access by first bootstraping a minimal distro on a ramdisk, unmounting the main drive, partitioning that drive, and installing the new distro on that drive. Reboot and pray.
- Build a cross-compiler for targetting a freestanding environment
- Build latest KDE/XFCE for debian stable. No more "but debian ships with outdated software!!11"
- Build applications on a distro they were not designed for (Zimbra OSE on debian)
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.
As pointed out already, LFS is a cookbook, and you learn most by having an idea about how you want to tune your Linux system.
So at points you want to dive deeper, you do ā and go off the beaten path.
It requires a desire not just to understand how bits and pieces fit together, but how you can make them work even better for yourself and what is and is not customizable?
Arguably, even if building it today is easier ā back when I did it in 2000, you sometimes struggled to find where the canonical source code of the package is, not to mention compilation errors, linking errors, etc. Only then did you get to configuring the init RC system, choosing between them (no systemd yet), etc.
But a requirement is ā IMO ā that you are strongly opinionated about how a system should serve you, and look for opportunities to tune it.
I've learned the most from LFS long time ago, when I had no internet. I had a mismatching set of Slackware and redhat source CDs, and LFS itself didn't match the versions on CDs too. Since then I can build anything and anywhere, even if it's not cooperating :)
> And you add the bootloader dead last, even though itās the first thing you see when you boot a Linux machine?
That actually makes perfect sense. If you did the bootloader first, how are you going to build it? How do you know what to boot from which filesystem on what device? By the time you've got your root filesystem complete, it's easy to tell.
If you do things step by step incrementally, you keep having to go further back in the process. Starting over repeatedly gets tedious, boring and frustrating. And it'll take ages to finish the complete OS.
Except that if you fail to install the bootloader - which happened to me many times - then you do not have a working system. So really the prior argument makes sense.
IMO the guy is right - LFS could be way better. But it has this current structure and does not deviate from it. That's the bad part.
> If you do things step by step incrementally, you keep having to go further back in the process. Starting over repeatedly gets tedious, boring and frustrating. And it'll take ages to finish the complete OS.
Pray tell how that is necessary for the bootloader? The chain used in LFS isn't the only one that makes sense or is required. IMO it would indeed be better to have a system you boot into as quickly as possible, on real hardware, then continue from there.
> It was like following a baking recipe. I know I need to add eggs and sugar in the ratio it says but Iād be damned if I could tell you why that specific ratio works.
I know a french cookbook[0] which contains not only recipes for dishes, but also for some of the intermediary ingredients, like stocks, that can now be bought at the supermarket. I feel that Iāve learned a lot by following those recipes, be it simply in the structure of french cuisine. And to me, LFS is a cookbook in a similar sense.
[0]: https://www.ferrandi-paris.com/fr/le-grand-cours-de-cuisine-... in French, sorry!
> I did it once manually over a couple of days.
Sounds like a speedrun of the tutorial. How did you approach packaging then and what system did you use to compile everything?
I did the tutorial in the late 2000s I think and it took me 4-6 months if I remember correctly. At the time I wasn't completely new to Linux but setting up things like the boot loader was quite tricky for me.
For me the main motivation was getting a deeper understanding, being able to fine tune and customize my system. Of course I didn't go blindly through the tutorial but only did steps that I understood. (In case something goes wrong) Also I started to use (x)stow for everything.
It is possible to do it over a few days really, even with not too much knowledge.
Requiring four months seems as if it was a side project, which is of course totally fine, but for any main task it really should not take more than a few days, even on a semi-slow computer (well, depends on how slow).
well, if you happen to be in a 'rm -Rf /' situation (which with agentic AI seems to be more often the case) to know how to operate in a chroot environment could be helpful
This should be said more often, and in many other contexts as well.
Most educational resources are what- and how-based, only the best ones are primarily why-based, what Wirth once wrote in the preface to some Pascal book (I paraphrase) 'discussions are motivated, so that the learner gets coverage and understanding, instead of memorization'.
You need to actually read the book and not just copy and paste commands. Many of the questions you have are answered in the book.
LFS is known but it is really more a cookbook than explanatory principles.
Principles can be studied from āOperating Systems: Three Easy Piecesā book - https://pages.cs.wisc.edu/~remzi/OSTEP/
Rob Love wrote the book āLinux Kernel Developmentā. https://rlove.org/
And then continue with reading LFS.
I liked KISS for this
It was like automated LFS from git
FreeBSDās Makefile system is also in this ballpark
I learned a lot doing Gentoo stage 1. I was also following the guide like a recipe, but at the time I hadn't been exposed to the underlying machinery that is often automated, abstracted away, or done for me already. It was also a good test on how well I could follow instructions and later on apply my own customisations. Like lego.
Setting up Oasis <https://github.com/oasislinux/oasis> taught me more than LFS personally. Everything being statically compiled makes it less magic.
To some extent I agree with you. I'd like to decouple some parts, e. g. the tutorial part is great but it should ideally be distinct from "just go at it" 1:1. I also fail to compile various things right now, which is frustrating; two or three years ago all went well. The whole LFS build up is too brittle. In part this is due to external complexity, but LFS needs to re-think what it does. It's also sad that they are now systemd-only, which further adds intrinsic uselessness. I don't need anything systemd offers; all my boot up logic is stored in yaml files and autogenerated to target formats via ruby as-is.
I second this a thousand million times. But with AI, i can't help but admit i find myself indulging in building things backwards, now that i can try a couple different approaches simultaneously for it.
I used CLFS (Cross-Linux From Scratch) once to bootstrap Linux on my SGI Indy, and I learned quite a lot from this. That was back in 2008 or so, so way before AI and extensive online guides for almost everything. It taught me how cross compilers work, what dependencies exist in the GNU toolchain, how the SGI boots, and much more.
Too bad Cross-LFS is no longer a thing. Then again, with all these microcontrollers and ARM and RISC-V systems today, cross-compiling is no longer as magic (and tricky) as it was back then...
> LFS takes the wrong approach in my opinion.
Shameless plug: I started a series of blog posts exactly because this. https://serversfor.dev/linux-inside-out/
Unfortunately due to some cervical spine issues and a surgery I wasn't able to finish it, but I am planning to pick it up and continue.
Thanks for posting this, I hope you will continue
Compiling the packages doesnāt teach much itās all the glue in between. No? Itās the startup scripts and the configs and creating a kernel and all the things.
Itās on my list of things to do when I have some free time
You know, you could also just read about each step to learn more. I mean if you feel you're following a baking recipe, you can just... read about it more. And then have LFS as a simple way to experiment if you want to change anything or not. Also, technically you don't need to have a bootloader installed on your main hard drive if you already have it on another disk.
I mean, eh... last time I checked, this was Hacker news. Yesterday, there was an Ask HN topic on how to enable dark mode on HN. Is this the new hacker culture? Complaining that the resources merely point in some direction instead of specifying details?
You can tell it's written by real Linux users because the landing page UX doesn't make it immediately obvious where to even start reading.
My journey was: Start off by clicking LFS among the links, and then "Read online" in the sidebar, and then being lost. I see a header, "Current Stable" but I can't see the link to the actual book. I only see the errata, the security advisory and a link labelled... stable LFS systemd? Maybe it's that one? Yes, yes it is.
It is indeed glorious.
it's like their brain is unaware of the concept of a timeline
... At the top? You're expected to read all of it! :)
[dead]
Took me half a second to realize I would probably start with "LFS :: Linux From Scratch is the main book, the base from which all other projects are derived."
You mean the link to a page which _also_ doesn't have the main book?
I kept an LFS system going for a few months (on a wretchedly awful by modern standards celeron ānet topā) until eventually making a mess I couldnāt figure out how to untangle during a system upgrade. this gave me the sheer force of will necessary to later do things like own the multiplatform build system for an ocaml based distributed system (mina)
From the news page:
> Bruce Dubbs - 2026/09/01
> The Linux From Scratch community announces the release of LFS Version 13.1.
For a long time (probably 2002-2010) I really wanted to do LFS. But I've been on Gentoo since 2004 which, over the last ~22 years, has probably exposed me to almost everything LFS would have, plus a lot more it wouldn't have. I still wish I'd did it way back when. I probably would stumbled through fewer issues had I.
LFS prepared me for Gentoo :)
I had the same experience. I think the only thing that LFS would add to that experience would be the package-manager-less experience (building without portage's help)
The last release of the no longer maintained sysvinit version is here (the default is systemd now) https://www.linuxfromscratch.org/lfs/downloads/12.4/
What's the news? This manual has been with us since forever.
https://news.ycombinator.com/item?id=49708089
I'm glad to see its still being maintained after more than 25 years since I last used it.
Didn't do it for a while, I would benefit from a little refresh.
Is there a Web version running in a VM/container in the browser?
We did that, but in containers. https://stagex.tools/
Confirmed Linux user with the good ol 2000 web style. Great job!
LFS is great. Unfortunately nowadays I often fail to compile it; most recently with GCC complaining and failing at options.cc. But I also get more issues here.
I kind of need a LFS variant that is more flexible. For instance, the part up to having a working standalone compiler, should ideally become more robust and/or decoupled from the actual LFS build process. Once I have a sane toolchain, the rest is trivial, ruby scripts solve that part for me. But the build up towards that is not so reliable. Things also fluctuate so much in the build process; I still need perl for instance, and python wants to add more and more complexity into the build system as well, even though meson/ninja is a nice combo. For some reason, the build situation on Linux is not very elegant to word this nicely. Then we also "now you need LLVM and glslang and spirv" and so forth, and so on. The complexity always increases. To some extent I can understand why slackware crumbled. How can a single person, even with scripts, keep that all working?
List of (not all Linux) distributions that can be bootstrapped from source:
https://github.com/vasi/bootstrappable-distros
The best way to learn linux !
I do LFS every year, just to keep the chops sharp. It has been an immensely invaluable means of keeping informed with the way things are rolling in the Linux world.
Related. Others?
Linux from Scratch - https://news.ycombinator.com/item?id=46709727 - Jan 2026 (103 comments)
Linux from Scratch - https://news.ycombinator.com/item?id=41747966 - Oct 2024 (159 comments)
Beyond Linux from Scratch - https://news.ycombinator.com/item?id=39547118 - Feb 2024 (17 comments)
Linux from Scratch Version 12.0 - https://news.ycombinator.com/item?id=37648808 - Sept 2023 (28 comments)
Linux from Scratch - https://news.ycombinator.com/item?id=33734685 - Nov 2022 (9 comments)
Linux from Scratch - https://news.ycombinator.com/item?id=30496018 - Feb 2022 (96 comments)
Linux from Scratch - https://news.ycombinator.com/item?id=29949311 - Jan 2022 (9 comments)
Linux from Scratch with Training Wheels - https://news.ycombinator.com/item?id=28820602 - Oct 2021 (41 comments)
Linux from Scratch 10.0 - https://news.ycombinator.com/item?id=24350738 - Sept 2020 (49 comments)
Linux from Scratch - https://news.ycombinator.com/item?id=24238015 - Aug 2020 (86 comments)
Major Proposed Changes to Linux From Scratch - https://news.ycombinator.com/item?id=23787526 - July 2020 (93 comments)
Linux from Scratch - https://news.ycombinator.com/item?id=20168343 - June 2019 (15 comments)
Ask HN: Is the Linux From Scratch project still relevant? - https://news.ycombinator.com/item?id=20149111 - June 2019 (7 comments)
Linux from Scratch - https://news.ycombinator.com/item?id=16823110 - April 2018 (1 comment)
Linux from Scratch Version 8.2 released - https://news.ycombinator.com/item?id=16510333 - March 2018 (2 comments)
Linux from Scratch ā build your own Linux distro - https://news.ycombinator.com/item?id=11829373 - June 2016 (57 comments)
Linux from Scratch - https://news.ycombinator.com/item?id=8392057 - Sept 2014 (1 comment)
Welcome to Linux From Scratch - https://news.ycombinator.com/item?id=4488162 - Sept 2012 (71 comments)
Linux From Scratch 7.1 Published - 3.2.6 Kernel + GCC 4.6.2 - https://news.ycombinator.com/item?id=3677350 - March 2012 (13 comments)
Linux From Scratch 7 Released - https://news.ycombinator.com/item?id=3171448 - Oct 2011 (27 comments)
Ask HN: Linux from Scratch.. Should I try it? - https://news.ycombinator.com/item?id=1779665 - Oct 2010 (58 comments)
How to build custom Linux from source code - https://news.ycombinator.com/item?id=743843 - Aug 2009 (1 comment)
The fastest way to learn and remember what Linux is about
I did LFS once, a long long time ago (days of RedHat 7.3, I'd say, 2002), and it was quite educational! It's a good way to learn the fundamentals of what comprises an actual Linux system
Very cool; good Job!
This whole project wastes time that could be spent learning operating system design and it spends it telling users to download files, extract them, and run ./configure; make; make install 100 times.
LFS is really, really bad. Also, reading the Linux kernel documentation to understand how to do it right is infuriating because it too is really, really bad.