Linux from Scratch 10.0
linuxfromscratch.org
linuxfromscratch.org
and a month before that here: https://news.ycombinator.com/item?id=23787526.
If curious see also:
2019 https://news.ycombinator.com/item?id=20149111
2016 https://news.ycombinator.com/item?id=11829373
2012 https://news.ycombinator.com/item?id=4488162
2012 https://news.ycombinator.com/item?id=3677350
Posts about new releases by well-known projects are something of a grey area, but if you want to read a long explanation of how we treat them, one is here: https://news.ycombinator.com/item?id=23071428.
Did this years ago and learned a ton, that said I'd probably never do it again. Once you know, you know. And sometimes you wish you knew less.
This is how I felt when learning Go, coming from a background of OOP languages. But it was worth it.
Parent has answered the first part of your question. As for why Go was worth the trouble, is because of its Utility nature, it has been the perfect replacement for Python as it doesn't have performance limitations(no need to find C extensions) and I'm rolling out production applications faster than ever before with Go.
If you don't do it reflectively, and simply copy and paste command lines, then I agree, you're not going to get anything out of it.
As it was, I had to debug a few build issues here and there, with version drift; that too was educational.
The biggest thing to come out of it for me, apart from understanding the Linux boot process better and a greater appreciation for chroot, was getting comfortable with ./configure [options] && make && make install for installing software from source.
Is my understanding correct that these are the things that you definitely have to work through with LFS?
As for bootstrapping, it's been a while since I did it, but that was mostly just setting up grub and pointing it at your newly minted kernel. Grub handles all the "where is this on the disk" issues for you.
I would suggest anybody thinking seriously about Linux (if you want to call yourself devops or SRE) to go through a full build at least once.
I would appreciate some thoughts on whether to go by the systemd route or the non-systemd route. The pros and cons.
I did the systemd one a few weeks ago and I think that besides a few small affordances for some systemd quirk, the main issue was installing all the prereqs for building systemd (namely meson, ninja, which openrc probably doesn't require).
They give a nifty tar command to snapshot the disk, which could help create a "fork point" for the setup. `pixz` is very helpful addition in this case (e.g. `tar -cp $LFS | pixz -9 > my_backup.tar.xz`)
In any case, I would only go the systemd route if it is what you want to learn. Otherwise just use runit -- much simpler and probably a bit easier to bootstrap. That leaves you time and energy to spend on other areas.
I'm inclined to go the systemd route because I use it myself regularly, but I also understand that systemd is a bit of a monolithic piece within Linux. I suspected that it might hide a lot of things that used to be more discrete and manual (but more unix-y).
I introduced the idea of using quilt for applying all the patches. I've noticed more recently that OpenEmbedded and Yocto do the same thing.
Probably easiest to start with ubuntu.
LFS walks through isolation when you are building the system, so it doesn't really matter what you start with.
The biggest issue with doing it is the time it takes. Some of the compiling can take ages, and you tend to forget you are waiting for it, and get busy with something else, only to come back 3 days later with no idea what stage you got to!
My advice is to use the fastest machine you have as the host for the LFS build process - it'll take a lot of the pain away.