Linux from Scratch with Training Wheels
philsyme.github.io
philsyme.github.io
On the other hand, I recommend trying to make a minimal system with only a kernel and shell and then add to it as desired. That way you'll really get an idea of what's needed to do what (and realise how bloated common distros are).
A long time ago, I went through "DOS from scratch" and "Windows from scratch" in a similar fashion.
LFS, KISS and, most recently FreeBSD were extremely educational for me. They showed me what each piece of my system was for, where to look when things went wrong, where to look when I wanted to tweak something, etc.
For a modern Linux installer, liked Debian or Ubuntu, I feel like I’m looking off a cliff face into an abyss. They say it’s “free as in freedom” - and I know it’s technically true - but I don’t feel like I’m equipped to understand the system the installer produced without a decade investment of time. The way I’d interact with those systems was a lot like “free as in free beer” - I knew I _could_ fix it if something didn’t work quite right, but frankly I didn’t know _how_ to fix it or where to start. So I just consumed it like I would proprietary software; it was a big black box I never looked inside.
On KISS, I ported the base system to a raspberry PI as my first task - the system was simple enough that I could just tackle that out the gate.
For LFS I had a lightbulb moment - understanding what all those packages that scrolled by in an “apt” install were about, how they fit together, and why a distro needed “patches.” It taught me what a distribution _was_ and the work that went into building and maintaining one. It taught me what the “base system” ecosystem consisted of.
With FreeBSD ports, by day 3, I was floating my own patch on top of my window manager because the config file didn’t have a setting I wanted.
As a sibling said, you get out what you put in.
But recently I found I am using boot camp and that blow hot air around you forced me to find a solution. On macOS side I pay for a patch … totally expect to pay but then it is just one setting (no 100% cpu max 99%, but not help much) and then a setting patch on not using turbo. That is it. It is a shock. Can you just manipulate all these without programming? And without payment? Just tinker a bit and take the risk to do a windows registry setting …
As open source has indicated, you can learn from both and try to mix them. And as free as liberty, non free beer can still carry some message.
I often feel that way about FOSS in general. The freedom is more 'theoretical' than practical, although FOSS means that such software are much less hostile to users.
I appreciate repairable laptops and electronics more than I appreciate software freedom. The freedom felt more real.
... though these days, Nix on top of Slackware may be interesting
There is slackpkg for package management, and sbopkg for “ports.” (What is “missing” is dependency management, which often turns out to be a blessing.)
(pkgsrc also supports Slackware.)
I am not really into chainloading or booting from different partitions. Keep it as simple as possible. KIASAP.
I want an OS I control. If that requires time, a one-time sunk cost to learn how to do something, like sports/hobbies require, it is worth it.
It takes too much time for compiling. Some packages compiled overnight on my machine. Now I thank my distribution, that they precompile these packages for me :)
> Not very productive though I admit.
It's called "scratching an itch". You've no idea why you've got that itch, but it sure is satisfying giving it a good scratch.
But what seems like, for the present, idle fiddling about, sticks in your memory and one day in the future some problem (or interview question) will rear it's head and you'll thank yourself for just messing around. Treat it as a positive trait.
There's no installer... the boot media just drops you into a live console, and then you're expected to follow the installation guide [1] to set up your disk, bootstrap the core system, select packages, and then do just enough manual configuration that your new machine will survive a reboot.
You'll probably spend the next week or so digging around the Arch Wiki [2] to figure out how to set up the remaining odds and ends. You're definitely not building the system from scratch, but you generally do need to understand more about where things live, how they're configured, and how to turn them on and off, which the wiki is very good at explaining. The stuff you learn here will absolutely come in handy when the same component is misbehaving on a Debian or Red Hat system.
And when you're done, not only are you left with a system that's completely usable (i.e. packages that can actually be upgraded), it'll be configured exactly the way you wanted. In my case, that "messing around" laptop is now my daily driver.
[1] https://wiki.archlinux.org/title/Installation_guide
[2] https://wiki.archlinux.org/title/Main_page (a great resource for Linux in general, not only Arch specific things)
What would be easier is a step-by-step guide to 'building' the system, via fdisk onto a spare HDD, and then manually copying over all the kernel bits , stuff for a working shell etc. and editing the init scripts with explanations of what each bit does, and why you are adding them to the system.
I've read lots of docs on the structure and boot process of Linux, but stepping through adding each element to blank disk would cement in the knowledge, without all the lost time that LFS adds.
No disrespect, but this is backward.. it was fun to see the network stack acting chaotic. IRC worked fine, HTTP did not. Terminal had color issues sometimes. Made me appreciate the intricacies but left me totally clueless about why; which I thought was the point of assembling an OS bit by bit.
In fact, this has applications beyond what's involved in bootstrapping system software for self-education. It's very interesting that all the vendors of expensive compilers reacted to the production-readiness of GCC in the 90s by choosing to wither and die instead of focusing on improving the notoriously bad developer experience of the edit-compile-test cycle for large C and C++ to justify the the purchase of their products.
(Disclaimer: 18 year Gentoo user speaking)
I was just mesmerized by the scrolling compiler messages, amazed to see something that complex transform into a working system.
And once it was done I usually found a reason to start over again, just one more flag to make it perfect.
Oddly, I can't remember ever actually using Gentoo, just compiling.
Was a lot of fun, but a huge amount of time compiling
Every time I decided to try a new window manager and update USE flags to do something like add GTK support for Gnome, or QT for KDE, and obviously remove whatever I had to start with for optimization it would recompile everything. I remember in particular doing something like a fresh Gnome install, starting to use it and realizing I'd missed a USE flag for audio and having to re-compile all the Gnome apps to have them be able to use sound.
Was fun, but brutal in terms of efficiency.
It's a time sink compared to binary distributions, but LFS is a whole order greater when it comes to time sinks. Gentoo automates almost everything that you would do by hand in LFS. Compile time doesn't count as it's not your time being used.
But as an adult.. It's just not worth the time.
If you are new to Linux (or even all Unices) and you want to get a firm understanding of the fundamentals, it may very well be worth while to go through it at least once and see all the moving parts. And see them in an order that makes their dependencies clear(er).
Once you know all that and just want to keep up with the constant churn of versions to keep that one webserver running and recent? Yeah. Not worth it. Get some distro that matches your preferred characteristics and stop worrying if you need to update libBLA to recompile Apache to fix the path traversal vulnerability. That also removes the question if that library still compiles correctly with gcc 7 or if you need to upgrade to at least gcc 9...
Edit: Doing it in a VM first, might help in getting the 99 percent working first linux installation into a usable shape to make it a good daily driver. In that sense it helps lowering the barrier to actually switching later on.
If you built a linux system from scratch, this will put you in a very good position to get the job.