4 ms·

My issue with LFS (and I've attempted it several times, and always ran out of time to complete it) is that most of the time is spent compiling all the source co

My issue with LFS (and I've attempted it several times, and always ran out of time to complete it) is that most of the time is spent compiling all the source code. 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.

agumonkey 5y ago
Did LFS twice, I left with a broken system I couldn't understand but many hours of sed patch [vaguely] useful syntax mastery (I tried not copy paste the commands and typed them on my own) 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.
cxr 5y ago
Alternatively, and a lot more "real", would be if the system compiler available during the step-by-step phase cared foremost about getting functioning binaries out quickly. Bootstrap your way throughout the day with "slow" binaries built with the fast compiler and keep a log of this activity, then you feed this spec into a batch tool that runs overnight and uses the industrial strength compiler to recompile whatever it can before you wake up, interrupt it, and proceed with your work the next day. 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.

agumonkey 5y ago

Did LFS twice, I left with a broken system I couldn't understand but many hours of sed patch [vaguely] useful syntax mastery (I tried not copy paste the commands and typed them on my own) 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.

cxr 5y ago

Alternatively, and a lot more "real", would be if the system compiler available during the step-by-step phase cared foremost about getting functioning binaries out quickly. Bootstrap your way throughout the day with "slow" binaries built with the fast compiler and keep a log of this activity, then you feed this spec into a batch tool that runs overnight and uses the industrial strength compiler to recompile whatever it can before you wake up, interrupt it, and proceed with your work the next day. 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.