Rendered at 23:40:34 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
rando103747202 7 days ago [-]
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.
degaart 7 days ago [-]
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)
pjmlp 7 days ago [-]
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.
Intermernet 6 days ago [-]
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.
abhiyerra 6 days ago [-]
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…
fuzztester 7 days ago [-]
>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.
6 days ago [-]
immmmmm 7 days ago [-]
I started with Slackware 1.0 on i386.
I certainly do not miss compiling X11!
mobilio 6 days ago [-]
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.
motbus3 6 days ago [-]
I agree with you. Maybe the person from the first comment read first few pages only which basically give some context.
shevy-java 7 days ago [-]
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.
smitty1e 7 days ago [-]
"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.
charcircuit 7 days ago [-]
It is more how stuff is compiled than how stuff works.
Fundamental things like how processes are scheduled are not explained by LFS.
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/
charcircuit 6 days ago [-]
>LFS is how the rubber meets the road
Again I disagree. Way too much time is spent building software than actual practical OS development.
mid-kid 6 days ago [-]
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.
charcircuit 6 days ago [-]
What is the point of making a distro, if not to make an OS? It's the same thing.
gchamonlive 6 days ago [-]
One supports the other, they aren't laid in opposition, but they are different, well-defined disciplines
smitty1e 6 days ago [-]
OK: "How *nix tools functioned together in command-line days".
wazdra 7 days ago [-]
> 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.
Tangential, but how good/useful/approachable is the book you cited as example?
How would it compare, in your experience, to other (modern) cooking books with a similar scope?
binarin 7 days ago [-]
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 :)
tosti 7 days ago [-]
> 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.
notme43 7 days ago [-]
Agreed, it's near the end of the Gentoo installation as well. If you forget to install GRUB, just chroot back into it and continue.
If I installed the bootloader first, I'd have to remember to run dracut after the system was installed. Or I install it last, create the init at the same time and make a habit of it.
aragilar 7 days ago [-]
Debian and Arch are the same, grub at the end.
mrheosuper 7 days ago [-]
You build it on your non-lfs computer. What is the other option?
And you dont need to boot anything, just a busy loop after a log "Hello World" is enough, if you feel fancy, maybe make a simple shell ?
tosti 7 days ago [-]
You could do that, but if that were to happen to me I'd say the installer sucks and my boss should hire someone else ;)
shevy-java 7 days ago [-]
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.
tosti 7 days ago [-]
If you're going to run the OS, you have to make sure it compiles and runs the bootloader and its installer. The toolchain could be different enough for that to fail. And you do boot into a reasonably small OS and continue from there. That's what BLFS is all about.
cogman10 6 days ago [-]
TBH, though, the only lesson you learn from BLFS is that value of package managers.
If you like the idea of everything being purpose built for your computer, then after you do LFS you should switch to gentoo.
necovek 7 days ago [-]
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 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...
jan_m_savage 7 days ago [-]
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'.
IslandRebel 7 days ago [-]
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.
numlock86 7 days ago [-]
> 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.
Exactly my experience. Back in the day when all I knew was Windows and a couple of BSDs I wanted to get into Linux, because it seemed like it was going to become very relevant in the next decades. After years of slacking I thought LFS would probably be the ideal choice. Turned out it wasn't, at least for me. I ended up "learning Linux" with distros like Gentoo, Arch and later even Ubuntu, and by just replacing my production systems with Linux, which were still running on OpenBSD mostly. I have revisited LFS a couple of years ago and honestly didn't take much from it. I get the appeal, but it's not for everyone.
zvmaz 6 days ago [-]
Exactly my experience. I tried LFS several times, but I didn't learn much. I learned more with Arch Linux, but I truly appreciate the work that was put in LFS, marvelous for the right type of learner.
myaccountonhn 7 days ago [-]
Setting up Oasis <https://github.com/oasislinux/oasis> taught me more than LFS personally. Everything being statically compiled makes it less magic.
sylware 7 days ago [-]
The step by step is the right approach... but you'll discover that many 'components' are _INSANE_ and that includes their SDK.
Bare LFS is not enough (I run my own): you need a kind of userland (above glibc) multi-version system which some kind of "atomic-ish" switching (always have a stable SSH running in case something goes wrong, better than unplugging the system disk and fix it on another computer).
For linux, same thing, with a kind of flip-flop-ing for updates/fix/etc.
The insight that gives you will probably scare you: the current "open source" stack is an abomination (the worst is the SDKs I think).
That's why we need _LEAN_ open source, and that includes the SDKs.
tosti 6 days ago [-]
If you think that's an abomination, try corporate billed-by-the-hour enterprise software where nothing ever changes unless it's approved by several layers of management.
I promised myself not to work for any of those anymore :)
sylware 6 days ago [-]
Well, in this very case, it is more complicated than that: they have to protect their software against planned obsolescence and developer tantrum (it would be the same for any "in production software").
Modifications and changes must be weighted very carefully. For instance "removing" (including in the SDK) is usually a less worse modifications than
the others and it decreases the global technical size and complexity/number of layers of the stack/SDK (which is top priority in "security"), namely most of the time but not everytime a good thing.
Because, on most complex software (open source or not), a "believed" benign modification can be disastrous. It is even worse if close to bare metal involving complex hardware (even with massive QA[testing]).
tosti 5 days ago [-]
Free software doesn't typically have an SDK. A compiler is just one of the available programs. So is a text editor, a shell and script interpreters, some incarnation of make, etc. There's nothing really special about the compiler and you can write perfectly fine programs without ever touching it.
That said, port trees usually have devel-* sections. Does that count?
sylware 5 days ago [-]
Ohohoh! The complexity and cost of the various "open source SDKs" is on stellar scale. I build my own distro, and I usually remove SDKs to switch to linear orthogonal brutal build shell scripts... and I am going to warn you, you are going to see a lot of ugly close to insane.
You'll see also a good amount of more than questionable code generators. And when you will have a look at some _GNU_ makefiles of big corner-stone projects, you will question the sanity of their authors (the "makefile" itself is often, but not all the time, very questionable too nowdays). Everything was with a good intent, turned sour and painful on the long run.
On our modern computers, we should have "one-compilation-units" for most, if not all binary products (exes or shared libs) anyways. "Same language" binary static linking in the open source world should not be a thing anymore (have a look at those 'header-only' projects).
The invisible backdoor injectors (namely compilers) are a problem, for many reasons that most know here (barrier to implementation of real-life alternatives, [open source] developer lock-in, etc). The more complex is the syntax of a computer language, the worst it is (on c++ syntax complexity scale, or with a heavy/intrusive required runtime like many "new" languages do shove down your throat).
If you don't see any issue, get cproc/qbe C compiler (and the binutils gas assembler), then you compile linux (with a brutal and linear shell script, let's say for a real life x86_64 desktop) and we'll talk again after, ok? And once you succeed, we'll see how it holds in 7-10 years (the time ISO takes to break in a non pertinent way many things).
tosti 4 days ago [-]
I reckon what you call SDK is what I'd call the build tools. C++ projects tend to use CMake and that's what I dread most. There have been projects where I brute forced my way on the command line towards succesfully compiling a binary. It's rare, but I kinda know the pain.
If I'd want to roll my own distro again, I'll have a look at an old dir with lots of scripts and patches where I tried doing just that. (I bet almost none of it works with current tarball versions.)
I think I'll retire with NetBSD. Keep up the good work though, someone ought to highlight the insanity of build tools building build tools.
sylware 4 days ago [-]
In the SDK, I do include the "compiler": the computer language syntax complexity is critical here since it is a barrier of entry of any new "real-life" alternative compiler.
NetBSD won't protect you here.
For this major reason, computer languages with a "simple" syntax and "alternative" real-life compilers should be favored (or you know it is reasonable to build one from scratch). The current _LESS WORSE_ alternative is C and similar. But this is far from a silver bullet. I think our only way out, namely getting rid of all this toxicity is assembly without abuse of any macro-preprocessor, that's why worldwide non-IP locked ISA standard like RISC-V are so much important.
tosti 4 days ago [-]
NetBSD can be compiled from another OS and a compiler can be compiled to shell script. You'd take a minimal compiler (eg lcc), compile it to shell script, run it on the target, have it compile itself, older gcc and work your way up to one that builds the rest of the OS.
If you really want to start over from scratch, some form of assembly is indeed required :) And the first assembler would have to be assembled by hand. I'm not sure if riscv is useful for that, I'd try finding the oldest m68k still serviceable. And the sooner you get to C, the better. Starting from scratch is one thing, doing it all in asm takes more than a lifetime. And from C to various interpreters, of course. Most programs can be written in a scripting language and have fewer bugs than if they were written in more verbose languages.
sylware 3 days ago [-]
I did not get everything you said, sorry.
But where I do agree: I presented the "assembly saving the world from big tech toxicity" would come with very high level scripting languages (probably a mess... but less toxic than what we have today), but with their interpreters/JIT "compilers" written is such assembly without abuse of any macro pre-processor.
I gave some thoughts about porting Bellard quickjs to pure hand written/tool assisted RISC-V assembly.
tosti 3 days ago [-]
I'd favor more incremental steps. The sooner you get the specific CPU instructions out of the way the better. Otherwise your liberation party might be short lived.
Here, only regulation can help, there is no going against corpos with billions of $ and backed by funds of thousands of billions of $. Much of Big Tech abuses non pertinent complexity and size, not to mention their manic usage of planned obsolescence.
There, the regulation should secure and set in ice a basic subset of file formats and protocols for interoperability which are known to be reasonable to implement again from scratch with "Small Tech". And by subset, I meant for instance noscript/basic HTML for the web; UTF-8 text files for text; I guess JSON should be favored over XML; a subset of PDF (certainly not all of it...);etc. If an online service have a 'chat', a basic IRC bridge should be there with a properly display access URL, etc, etc. That does not block "new" and "innovative" things to happen in any way.
Some of Big Tech hates "small is beautiful" and stability in time then will fight hard with their $ for that not to happen (administration "corruption"). Complexity and size (including the SDK then the computer language syntax complexity) is their bread and butter to keep "control" and keep alternatives away.
For the "bootstrappable", it is the starting point of building from 'small and simple' toward big and complex, aka the SDK 'binary seed'. At the time anybody would expect a 'simple C compiler' with a simple linker and assembler buildable with that simple C compiler... but people at the gcc steering commitee and the usage of many C extensions without maintaining proper fallback to assembler source files (in kernels, hence linux) broke the chain of 'sanity' for good. Now you must have an ultra complex c++ compiler to "bootstrap" (~LFS), not to mention the required zillions of complex tools required by the "build systems".
Lately, it seems AI coding may be the salvation here... How? AI seems to assist writting c++(insert you computer language with a complex syntax here) to simple C "transpilers" (somebody pretended to have done the same with a rust->simple C transpiler, was published here on HN). I have to say I have never used AI, since they are gated with the web engines of the whatwg cartel (I cannot even get a token to use some web API), I have never tested.
The conclusion: fixing the software stack to let sane small alternatives to 'exist' and be 'real life' is probably not going to be calm and quiet.
tosti 2 days ago [-]
Re: regulation, there were antitrust laws well before the Internet, but they haven't been properly enforced wrt big tech. I see no need for new laws (especially laws that cover technical details because politicians always screw those up), but it would be about time to invoke them. Else I hope they enshittify their way to collapse. The way things are going I think that's likely although it could take until 2038
Re: bootstrapping, your computer, your OS, your choice. When I power on my laptop it starts grub, linux, a shell script, sysvinit, at the moment openrc then kicks in (I want to replace that one), and all that's left running is init, sysklogd, chronyd, cronie, and agetty.
And I don't think vibe coding is going to help much at all unless you want another templeos. I think it could do that.
sylware 2 days ago [-]
Here, "regulation" is more about a "minimal platform for interop" than anti-trust.
That "minimal platform for interop" would be made of simple but able to do a good job enough and stable in time file formats and protocols. This minimal platform must be reasonably implemented with "Small Tech" (excluding de facto the whatwg cartel web engine and computer languages with ultra-complex languages or heavy runtime this is common sense).
That "minimal platform" should probably be made with subsets of current file formats and protocols. As I said, for instance a subset of PDF (with validation tools), mandatory handling of basic UTF-8 text files, no script/basic HTML for the web, brutally simple SMTP support (aka self-hosted, not paying for DNS, or email addresses with IPs literals, only the commands to send actually emails without fideling around), IRC bridge for chat, etc.
BTW, on the "assembly to save us", I was talking about very high level languages with interpreters/JITs coded directly in assembly (aka binary specifications), then Mr. Bellard quickjs, but also obviously python (but it seems its syntax is going amok which is bad omens)/lua/etc.
This "platform" should slow down a lot the endless enshitification cycle we are into.
If AI coding is that powerfull (cannot test it as its access is gated by the whatwg cartel web engines), it can probably help: like I said, since we are not alone, look at what the others like me did: they are using it to write transpilers from ultra-complex computer language syntaxes, I saw on HN this norvegian guy who is using AI coding to help write directly in 'human readable' assembly (here x86_64) the binary specifications of its own everyday software.
This plaform must be very rigid, but not completely, namely rational removal/restructuring could happen. Basically, implementation "from scratch" by "Small Tech" must always be reasonable.
Aside of all that, there is the ultimate hard truth: for much software developement, but not all, it is extremely hard to justify a permanent income and that honestly. Making all that very complicated to fit in any economy.
tosti 5 hours ago [-]
Politicians don't understand the Internet, never mind its protocols. That's why they use silly terms such as "cybercrime". "Cyber" means "the Internet and I don't understand any of it"
Code written in assembly is more error prone, more difficult to debug and harder to understand than higher level languages. After years of reading and writing code I know being able to reason with others about the source code of a given program is more important than what the actual language is, or any of the other purities programmers like to keep. Without readable source, the program either dies a slow death or becomes some kind of minefield. And besides, throwing out decades of development is such a waste of effort.
I don't understand your comment on permanent income and the economy. Sorry.
shevy-java 7 days ago [-]
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.
blablabla123 7 days ago [-]
> 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.
shevy-java 7 days ago [-]
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).
blablabla123 6 days ago [-]
Well as mentioned it was in the 2000s. Compiling KDE alone took several days. Also there was no automation/script, so you really had to go to ftp.gnu.org and look in which folder the coreutils package is ;) I realize there's now a list of packages with checksums
IslandRebel 6 days ago [-]
I did it in a VM took me 20 hours. Most of that time was waiting for things to compile and fixing mistakes I made because I didn't read the instructions properly.
r3trohack3r 7 days ago [-]
I liked KISS for this
It was like automated LFS from git
FreeBSD’s Makefile system is also in this ballpark
nullify88 7 days ago [-]
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.
HarlequinHair 6 days ago [-]
Except you can write bootloader only if you have something to boot.
Bootloaders as we know them came after OSes, because the need of a bootloader is to boot something.
Following your logic of building a piece only if needed, a bootloader should come after.
I like the recipe analogy and I actually think adding things only if needed will help cutting unuseful features and possibly to have different implementations for solutions you need.
No point in reinvent the whole thing, tho.
Following your analogy, if all cakes need egg, there must be a reason even if we don't know it.
robotresearcher 6 days ago [-]
You probably want to use a working bootloader to see if your ‘hello world’ OS-fragment works at all. No one is writing much OS without running it, surely.
HarlequinHair 6 days ago [-]
"Linux from scratch" involves Linux, not Libreboot, not Grub (just to mention instances of BIOS/UEFI and bootloader).
We already have means to test the new OS.
There is real point in writing a new one until the OS is complete, is there?
robotresearcher 6 days ago [-]
If you’re satisfied using a third party bootloader, and one exists, there’s no point writing one ever.
convolvatron 6 days ago [-]
in the bad olden times you definitely started to write your operating system for your new computer from the first instruction executed upwards. it wasn't at all common to have a comprehensive virtualization/simulation environment.
HarlequinHair 6 days ago [-]
I can't understand what is the point you are trying to make
convolvatron 6 days ago [-]
until very recently you couldn't even do OS development without a boot loader, so asserting that that would be the last thing you would write is just nonsensical
HarlequinHair 6 days ago [-]
Let me rephrase.
We already have a bootloader.
"Linux from scratch" involves Linux, not Libreboot, not Grub (just to mention instances of BIOS/UEFI and bootloader).
We already have means to test the new OS.
What I meant with my previous post is "newer" bootloader (which are actually pretty old, like grub), came after OSes passed a certain complexity.
Previously we technically had bootloaders, but they were interactive, mostly.
Am I misremembering?
convolvatron 6 days ago [-]
oh. I'm talking about authoring OS and boot loaders from an absolute blank slate. like starting from the world where you toggled them in from switches, and later by burning proms
kaashmonee 7 days ago [-]
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.
ngriffiths 6 days ago [-]
> only adding new things once you’ve discovered a need for them.
Agree! imo this is the guiding principle that makes great tutorials great.
wolfi1 7 days ago [-]
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
gigatexal 7 days ago [-]
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
self_awareness 7 days ago [-]
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?
lukeify 7 days ago [-]
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.
austy69 6 days ago [-]
Idk what to tell you if the “welcome to Linux from scratch” header wasn’t enough of a hint
fourside 6 days ago [-]
I thought the parent comment was missing something obvious too but if you click the top link in that section, it’s a page describing LFS but without linking to its content. Then I clicked the “Read online” link on the menu on the left, but the top links are errata and security advisories and then the main link. Not the worst navigation I’ve seen but the parent comment does have a point.
myaccountonhn 7 days ago [-]
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.
partyficial 7 days ago [-]
it's like their brain is unaware of the concept of a timeline
mrleinad 7 days ago [-]
So Linux users are by definition, eternal.
voxelghost 7 days ago [-]
It is indeed glorious.
esseph 7 days ago [-]
... At the top? You're expected to read all of it! :)
khantto 7 days ago [-]
[dead]
boomlinde 7 days ago [-]
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."
lukeify 7 days ago [-]
You mean the link to a page which _also_ doesn't have the main book?
bbg2401 6 days ago [-]
It's a link to the project page for the main book and it does a good job of explaining itself and the available resources. I guess the biggest issue is it's not immediately obvious the left navigation menu changes between the project and subproject landing pages.
phlipski 6 days ago [-]
About 4 years after beating my head against the wall trying to learn all about embedded linux builds and reading through yocto docs, I found a course on Udemy titled, "Embedded Linux Step by Step Using Beaglebone Black" It was perfect for walking me through the kernel, file-systems, boot-loaders, etc... It was a bit dated even then and thus required a little leg work to find the proper source versions of linux for the beagle board but I got it all working and cross-compiled a linux distro from scratch for the beagle board, flashed it, booted it and talked to it via serial port. I highly recommend the course.
bmenrigh 7 days ago [-]
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.
rntksi 7 days ago [-]
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)
dirkc 7 days ago [-]
LFS prepared me for Gentoo :)
halyconWays 7 days ago [-]
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
Celeo 7 days ago [-]
From the news page:
> Bruce Dubbs - 2026/09/01
> The Linux From Scratch community announces the release of LFS Version 13.1.
lioeters 7 days ago [-]
List of (not all Linux) distributions that can be bootstrapped from source:
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)
timw4mail 6 days ago [-]
In my experience with Gentoo, the hard stuff is well beyond the base setup: it's getting sound, bluetooth, auto-mounting, etc. setup the way it is in the bigger distros.
That was a weekend project once, absolutely grueling but you learn so much about the OS internals.
Marchant_hq 6 days ago [-]
Still remember the first time LFS booted. Felt like a true wizard, even if it was just a shell.
j117noai 5 days ago [-]
First time hearing about LFS. Decided to give it a shot as a learning journey. So far it's been fun, I learned about a bunch of stuff, like what ld-linux-x86-64.so.2 does and why you should not delete it on your host machine when trying to create the cross-toolchain
shevy-java 7 days ago [-]
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?
7 days ago [-]
aboardRat4 7 days ago [-]
What's the news? This manual has been with us since forever.
steve-atx-7600 7 days ago [-]
I'm glad to see its still being maintained after more than 25 years since I last used it.
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.
nobleach 6 days ago [-]
For me, BSD and Portage was my intro to "you're gonna need to learn how to compile stuff". But Gentoo Stage 1 was my real intro into how to bootstrap Linux. I had been using it for about 6 years at that point. (RedHat/Mandrake/TurboLinux/Caldera/Slackware/Debian-based stuff) Starting at nothing but a partitioned disk felt crazy. But I learned so much that not much in the Linux realm scares me these days. It made installing Arch back in 2011 a walk in the park.
B4st144n 7 days ago [-]
I m very happy I started years ago with Gentoo which is also from scratch but with a package manager ones your system is up ( couple of days). You learn so much just starting from zero and understand choices you can make on that journey. In the end I stopped using it though, way later when the Gentoo hype was over though. Getting stuck into dependency loops wasn't productive anymore.
ammmir 7 days ago [-]
I remember using LFS’ predecessors to build 1.44MB “rescue” floppy disks with Linux 2.0 in the 1990s. Tweak the config so it could fit on there along with a small userland. I don’t even remember if busybox was around back then.
It used to be a teenager’s rite of passage to build your kernel config, figure out LILO (remember that, pre-grub!), ipchains.. talk about feeling old!
Interesting project. Why does it use LLVM toolchain when it already builds gcc in an earlier stage?
lrvick 6 days ago [-]
LLVM is a much more mature and modern compiler by basically every measure, and importantly, a native cross compiler unlike GCC.
One copy of LLVM can build for many architectures vs needing one GCC toolchain for every architecture you wish to target.
Also modern languages like rust require LLVM so we need it anyway, and the kernel has rust now, so why not make the most mature compiler stack the global default? Using two different compilers for the kernel would be begging for problems.
I am most optimistic for the Fil-C fork of LLVM being a default some day where we get compile time memory safety too.
We do maintain gcc in tree for legacy languages like Fortran though.
lioeters 6 days ago [-]
If I understand correctly, I think they build an older version of gcc using tcc (Tiny C Compiler by Bellard); then using that to build newer versions incrementally until they get to the modern stack with LLVM.
i_am_a_peasant 6 days ago [-]
I kind of gained all the benefits of LFS by just maintaining a yocto embedded linux distribution at my first job for a couple of years.
Yocto is basically automated LFS, it will compile a cross toolchain then use that cross toolchain to compile everything for your target system.
LFS is worth doing if you are interested in learning how Linux distro is put together. There is a fair bit of reading involved. I did the entire thing in a Debian VM.
utopiah 7 days ago [-]
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?
nandanadileep29 7 days ago [-]
The best way to learn linux !
aa-jv 7 days ago [-]
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.
dat999zx 7 days ago [-]
Confirmed Linux user with the good ol 2000 web style. Great job!
cientifico 7 days ago [-]
The fastest way to learn and remember what Linux is about
L4XB 7 days ago [-]
Very cool; good Job!
_superposition_ 7 days ago [-]
The OG
bellowsgulch 7 days ago [-]
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.
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)
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 certainly do not miss compiling X11!
All this for running on embedded Linux with 32MB flash drive running from read-only volume powering two kiosk displays.
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.
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.
Fundamental things like how processes are scheduled are not explained by LFS.
Again I disagree. Way too much time is spent building software than actual practical OS development.
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!
How would it compare, in your experience, to other (modern) cooking books with a similar scope?
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.
If I installed the bootloader first, I'd have to remember to run dracut after the system was installed. Or I install it last, create the init at the same time and make a habit of it.
And you dont need to boot anything, just a busy loop after a log "Hello World" is enough, if you feel fancy, maybe make a simple shell ?
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.
If you like the idea of everything being purpose built for your computer, then after you do LFS you should switch to gentoo.
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.
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.
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.
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...
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'.
Exactly my experience. Back in the day when all I knew was Windows and a couple of BSDs I wanted to get into Linux, because it seemed like it was going to become very relevant in the next decades. After years of slacking I thought LFS would probably be the ideal choice. Turned out it wasn't, at least for me. I ended up "learning Linux" with distros like Gentoo, Arch and later even Ubuntu, and by just replacing my production systems with Linux, which were still running on OpenBSD mostly. I have revisited LFS a couple of years ago and honestly didn't take much from it. I get the appeal, but it's not for everyone.
Bare LFS is not enough (I run my own): you need a kind of userland (above glibc) multi-version system which some kind of "atomic-ish" switching (always have a stable SSH running in case something goes wrong, better than unplugging the system disk and fix it on another computer).
For linux, same thing, with a kind of flip-flop-ing for updates/fix/etc.
The insight that gives you will probably scare you: the current "open source" stack is an abomination (the worst is the SDKs I think).
That's why we need _LEAN_ open source, and that includes the SDKs.
I promised myself not to work for any of those anymore :)
Modifications and changes must be weighted very carefully. For instance "removing" (including in the SDK) is usually a less worse modifications than the others and it decreases the global technical size and complexity/number of layers of the stack/SDK (which is top priority in "security"), namely most of the time but not everytime a good thing.
Because, on most complex software (open source or not), a "believed" benign modification can be disastrous. It is even worse if close to bare metal involving complex hardware (even with massive QA[testing]).
That said, port trees usually have devel-* sections. Does that count?
You'll see also a good amount of more than questionable code generators. And when you will have a look at some _GNU_ makefiles of big corner-stone projects, you will question the sanity of their authors (the "makefile" itself is often, but not all the time, very questionable too nowdays). Everything was with a good intent, turned sour and painful on the long run.
On our modern computers, we should have "one-compilation-units" for most, if not all binary products (exes or shared libs) anyways. "Same language" binary static linking in the open source world should not be a thing anymore (have a look at those 'header-only' projects).
The invisible backdoor injectors (namely compilers) are a problem, for many reasons that most know here (barrier to implementation of real-life alternatives, [open source] developer lock-in, etc). The more complex is the syntax of a computer language, the worst it is (on c++ syntax complexity scale, or with a heavy/intrusive required runtime like many "new" languages do shove down your throat).
If you don't see any issue, get cproc/qbe C compiler (and the binutils gas assembler), then you compile linux (with a brutal and linear shell script, let's say for a real life x86_64 desktop) and we'll talk again after, ok? And once you succeed, we'll see how it holds in 7-10 years (the time ISO takes to break in a non pertinent way many things).
If I'd want to roll my own distro again, I'll have a look at an old dir with lots of scripts and patches where I tried doing just that. (I bet almost none of it works with current tarball versions.)
I think I'll retire with NetBSD. Keep up the good work though, someone ought to highlight the insanity of build tools building build tools.
For this major reason, computer languages with a "simple" syntax and "alternative" real-life compilers should be favored (or you know it is reasonable to build one from scratch). The current _LESS WORSE_ alternative is C and similar. But this is far from a silver bullet. I think our only way out, namely getting rid of all this toxicity is assembly without abuse of any macro-preprocessor, that's why worldwide non-IP locked ISA standard like RISC-V are so much important.
If you really want to start over from scratch, some form of assembly is indeed required :) And the first assembler would have to be assembled by hand. I'm not sure if riscv is useful for that, I'd try finding the oldest m68k still serviceable. And the sooner you get to C, the better. Starting from scratch is one thing, doing it all in asm takes more than a lifetime. And from C to various interpreters, of course. Most programs can be written in a scripting language and have fewer bugs than if they were written in more verbose languages.
But where I do agree: I presented the "assembly saving the world from big tech toxicity" would come with very high level scripting languages (probably a mess... but less toxic than what we have today), but with their interpreters/JIT "compilers" written is such assembly without abuse of any macro pre-processor.
I gave some thoughts about porting Bellard quickjs to pure hand written/tool assisted RISC-V assembly.
What I described is an example of build bootstrapping. There's a website about it, https://www.bootstrappable.org/
Some of Big Tech hates "small is beautiful" and stability in time then will fight hard with their $ for that not to happen (administration "corruption"). Complexity and size (including the SDK then the computer language syntax complexity) is their bread and butter to keep "control" and keep alternatives away.
For the "bootstrappable", it is the starting point of building from 'small and simple' toward big and complex, aka the SDK 'binary seed'. At the time anybody would expect a 'simple C compiler' with a simple linker and assembler buildable with that simple C compiler... but people at the gcc steering commitee and the usage of many C extensions without maintaining proper fallback to assembler source files (in kernels, hence linux) broke the chain of 'sanity' for good. Now you must have an ultra complex c++ compiler to "bootstrap" (~LFS), not to mention the required zillions of complex tools required by the "build systems". Lately, it seems AI coding may be the salvation here... How? AI seems to assist writting c++(insert you computer language with a complex syntax here) to simple C "transpilers" (somebody pretended to have done the same with a rust->simple C transpiler, was published here on HN). I have to say I have never used AI, since they are gated with the web engines of the whatwg cartel (I cannot even get a token to use some web API), I have never tested.
The conclusion: fixing the software stack to let sane small alternatives to 'exist' and be 'real life' is probably not going to be calm and quiet.
Re: bootstrapping, your computer, your OS, your choice. When I power on my laptop it starts grub, linux, a shell script, sysvinit, at the moment openrc then kicks in (I want to replace that one), and all that's left running is init, sysklogd, chronyd, cronie, and agetty.
And I don't think vibe coding is going to help much at all unless you want another templeos. I think it could do that.
That "minimal platform for interop" would be made of simple but able to do a good job enough and stable in time file formats and protocols. This minimal platform must be reasonably implemented with "Small Tech" (excluding de facto the whatwg cartel web engine and computer languages with ultra-complex languages or heavy runtime this is common sense).
That "minimal platform" should probably be made with subsets of current file formats and protocols. As I said, for instance a subset of PDF (with validation tools), mandatory handling of basic UTF-8 text files, no script/basic HTML for the web, brutally simple SMTP support (aka self-hosted, not paying for DNS, or email addresses with IPs literals, only the commands to send actually emails without fideling around), IRC bridge for chat, etc.
BTW, on the "assembly to save us", I was talking about very high level languages with interpreters/JITs coded directly in assembly (aka binary specifications), then Mr. Bellard quickjs, but also obviously python (but it seems its syntax is going amok which is bad omens)/lua/etc.
This "platform" should slow down a lot the endless enshitification cycle we are into.
If AI coding is that powerfull (cannot test it as its access is gated by the whatwg cartel web engines), it can probably help: like I said, since we are not alone, look at what the others like me did: they are using it to write transpilers from ultra-complex computer language syntaxes, I saw on HN this norvegian guy who is using AI coding to help write directly in 'human readable' assembly (here x86_64) the binary specifications of its own everyday software.
This plaform must be very rigid, but not completely, namely rational removal/restructuring could happen. Basically, implementation "from scratch" by "Small Tech" must always be reasonable.
Aside of all that, there is the ultimate hard truth: for much software developement, but not all, it is extremely hard to justify a permanent income and that honestly. Making all that very complicated to fit in any economy.
Code written in assembly is more error prone, more difficult to debug and harder to understand than higher level languages. After years of reading and writing code I know being able to reason with others about the source code of a given program is more important than what the actual language is, or any of the other purities programmers like to keep. Without readable source, the program either dies a slow death or becomes some kind of minefield. And besides, throwing out decades of development is such a waste of effort.
I don't understand your comment on permanent income and the economy. Sorry.
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.
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).
It was like automated LFS from git
FreeBSD’s Makefile system is also in this ballpark
Bootloaders as we know them came after OSes, because the need of a bootloader is to boot something. Following your logic of building a piece only if needed, a bootloader should come after.
I like the recipe analogy and I actually think adding things only if needed will help cutting unuseful features and possibly to have different implementations for solutions you need.
No point in reinvent the whole thing, tho. Following your analogy, if all cakes need egg, there must be a reason even if we don't know it.
We already have means to test the new OS.
There is real point in writing a new one until the OS is complete, is there?
We already have a bootloader.
"Linux from scratch" involves Linux, not Libreboot, not Grub (just to mention instances of BIOS/UEFI and bootloader).
We already have means to test the new OS.
What I meant with my previous post is "newer" bootloader (which are actually pretty old, like grub), came after OSes passed a certain complexity.
Previously we technically had bootloaders, but they were interactive, mostly.
Am I misremembering?
Agree! imo this is the guiding principle that makes great tutorials great.
It’s on my list of things to do when I have some free time
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?
> Bruce Dubbs - 2026/09/01
> The Linux From Scratch community announces the release of LFS Version 13.1.
https://github.com/vasi/bootstrappable-distros
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?
It used to be a teenager’s rite of passage to build your kernel config, figure out LILO (remember that, pre-grub!), ipchains.. talk about feeling old!
One copy of LLVM can build for many architectures vs needing one GCC toolchain for every architecture you wish to target.
Also modern languages like rust require LLVM so we need it anyway, and the kernel has rust now, so why not make the most mature compiler stack the global default? Using two different compilers for the kernel would be begging for problems.
I am most optimistic for the Fil-C fork of LLVM being a default some day where we get compile time memory safety too.
We do maintain gcc in tree for legacy languages like Fortran though.
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)
Is there a Web version running in a VM/container in the browser?