5 ms·

I did LFS back when I was a pre-teen/teen. So late 90s, early 00s. And while I agree to an extent that it doesn't give you much day-to-day stuff, it really make

I did LFS back when I was a pre-teen/teen. So late 90s, early 00s. And while I agree to an extent that it doesn't give you much day-to-day stuff, it really makes you more comfortable with operating systems and linux especially. Nowadays, I am a devops/infrastructure engineer, and I can say LFS is a core foundational experience that has let me be better at my job. I know deeper inner workings of a Linux distro and that strong foundation helps. Yes there is so much more to learn but having LFS in your back pocket of lifetime experiences is great. I also think its a 1 and done kind of thing. I don't see a huge benefit of doing it again. Maybe for fun, in a VM while waiting for other things to finish. It is also much faster nowadays. Back when I did it, I had a 1ghz, 256gb ram machine, it took me days. I could probably go through it in a day casually with modern computing, and especially since I have a threadripper machine, sending 64 threads at the make commands im sure will get my 1 BU to be a very small number. If you have a child that is interested in computers, tech, programming, etc. I highly encourage this activity. Could be a fun bonding activity too.

organsnyder 3y ago
I had the same experience around the same time (though I'm a bit older). LFS really helped me understand the relationship between the bootloader, kernel, init system, and all of the various daemons and tools that make up a complete system. From there I moved to Gentoo, and then eventually to Ubuntu and other batteries-included distros. But the knowledge I gained from LFS is still a foundational part of my skillset, even though my roles have been more dev-focused than ops/infra.
- jonhohle 3y ago
  Until I moved to FreeBSD in the mid 2000s I ran Gentoo primarily. Even though it had a bit more hand holding than LFS, it still taught me a lot and getting to choose implementations allowed consideration of design choices (cron, mail, syslog, etc.). I’ve tried to return a few times but it’s a bit different now and I’m happy enough with FreeBSD that I don’t have much place for it. I do wish more embedded distros would have started with Gentoo (specifically ARM SBCs).
  - bombcar 3y ago
    I think one of the advantages of Gentoo or LFS is you get an “introduction” to a bunch of the various parts, so that when you need to change something in the future you know where to start looking.
- agumonkey 3y ago
  Somehow LFS didn't help me understand the various subsystems... all I remember is long sed patches and compilation logs It did teach me how subtle a running stable OS is underneath though, as, after my first standalone boot, I could enjoy a partially working TCP stack: elinks could browser, curl couldn't, irssi sometimes, all of this with random terminal display codes being inserted.
lrvick 3y ago
IMO a secure server is an immutable appliance. I still build Linux from scratch most weeks as a core part of my job. Bare bones hardened kernel + shim init + target application are all you need, and will be your highest security/reliability systems. And yeah, threadrippers are a must.
- englishrookie 3y ago
  I assume you compile the source code because you want to be sure you don't use any compromised binaries? But how can you be sure the source code wasn't compromised with some obfuscated C code? (Honest question, I'm just a humble application developer.)
  - sneed_chucker 3y ago
    You can never be 100% sure. Even the compiler, firmware, or hardware could be compromised. Security comes down to reducing attack surface, ideally to an infinitesimal degree.
  - musicnarcoman 3y ago
    While I do not build LFS regularly or for production use, the security improvement typically comes from the fact that the end system is _super_small_ and focused. Less software means less attack surface. Sure, compromised binaries are nasty but personally I do place quite a lot of trust with the distribution repos. (PS, if you are reading this and contribute packages to distribution repos: Thank you!)
  - lrvick 3y ago
    It is dramatically easier to hide malware in a compiled artifact than in public source code, not to imply that the latter does not happen. In security focused orgs though you review all code yourself with the exception of things with extensive third party signed review such as the Linux kernel itself. Even then I review codepaths in the kernel critical for my use case such as random.c From there, if I -alone- compile containers, kernels, or binaries, someone could coerce me to tamper with them to compromise all downstream users. Same if there was a central build system I can access. To mitigate this I ensure my artifact builds are deterministic, sign my changes, and have team members review my changes, reproduce my artifacts bit for bit, then counter-sign the results. It is never wise to be in a position where there is possibility of you yourself tampering with things that control anything of value, or else someone will coerce you to help them steal said value. As a security engineer it is my job to ensure no one ever has to trust anyone, including me.
m463 3y ago
Sounds like a valuable formative experience. Sort of like launching a spaceship in factorio.
coldpie 3y ago
Same, though a bit later, circa 2007. It's great for software developers too. It's a good quick intro to many different build systems & philosophies, and shows you how the different pieces of software connect together by standard paths and package management tools like pkgconfig. Being able to quickly dive into a new project, understand how to build it and hook other software into it, debug build problems, and make quick hack changes is extremely valuable for developers.
- lathiat 3y ago
  Yep me as well sometime in that era. It was very interesting and informative. I'd never use it for an everyday system obviously but was a good excercise. And I did this on my real machine before VMs were really a thing :-)
tutfbhuf 3y ago
How does it compare to install Arch linux without an installer? I remember that it took me a day or two of tinkering, when I did it for the first time (circa 2009) and I learned a lot. As of today, Arch remains my distro of choice.
- imiric 3y ago
  It's very different. With LFS you build your own distro. You bootstrap the filesystem, build your kernel and everything else from source, and there's no package manager. That means manually managing dependencies, which is a nightmare in and of itself, and something we take for granted with Linux distros. The LFS book is quite thorough, so you technically only need to copy/paste commands, but you learn _a lot_ about Linux in the process. I highly recommend it to anyone interested in Linux. I did it once in college, and parts of BLFS IIRC, and it's one of the few memorable projects I got from my degree.
abdullahkhalids 3y ago
I almost did it in 2008ish. Back then my country had a severe electricity crises, and in the summer we would get alternately one hour of electricity and one hour of blackout. So I had to try and break the LFS build into one hour chunks. Though I got through quite a bit, unfortunately, there were some multihour build steps and I never got lucky enough with multihour electricity, till I finally lost interest. I did learn quite a bit from reading the manual though.
noiseman 3y ago
> I had a 1ghz, 256gb ram machine You had a 256gb ram machine???
- Daegalus 3y ago
  Ha, I wish, good catch on the typo, I can't edit, but should have been "mb" It's been so long that thinking of ram in anything other than GB is weird.

organsnyder 3y ago

I had the same experience around the same time (though I'm a bit older). LFS really helped me understand the relationship between the bootloader, kernel, init system, and all of the various daemons and tools that make up a complete system. From there I moved to Gentoo, and then eventually to Ubuntu and other batteries-included distros. But the knowledge I gained from LFS is still a foundational part of my skillset, even though my roles have been more dev-focused than ops/infra.

jonhohle 3y ago
Until I moved to FreeBSD in the mid 2000s I ran Gentoo primarily. Even though it had a bit more hand holding than LFS, it still taught me a lot and getting to choose implementations allowed consideration of design choices (cron, mail, syslog, etc.). I’ve tried to return a few times but it’s a bit different now and I’m happy enough with FreeBSD that I don’t have much place for it. I do wish more embedded distros would have started with Gentoo (specifically ARM SBCs).
- bombcar 3y ago
  I think one of the advantages of Gentoo or LFS is you get an “introduction” to a bunch of the various parts, so that when you need to change something in the future you know where to start looking.
agumonkey 3y ago
Somehow LFS didn't help me understand the various subsystems... all I remember is long sed patches and compilation logs It did teach me how subtle a running stable OS is underneath though, as, after my first standalone boot, I could enjoy a partially working TCP stack: elinks could browser, curl couldn't, irssi sometimes, all of this with random terminal display codes being inserted.

lrvick 3y ago

IMO a secure server is an immutable appliance. I still build Linux from scratch most weeks as a core part of my job. Bare bones hardened kernel + shim init + target application are all you need, and will be your highest security/reliability systems. And yeah, threadrippers are a must.

englishrookie 3y ago
I assume you compile the source code because you want to be sure you don't use any compromised binaries? But how can you be sure the source code wasn't compromised with some obfuscated C code? (Honest question, I'm just a humble application developer.)
- sneed_chucker 3y ago
  You can never be 100% sure. Even the compiler, firmware, or hardware could be compromised. Security comes down to reducing attack surface, ideally to an infinitesimal degree.
- musicnarcoman 3y ago
  While I do not build LFS regularly or for production use, the security improvement typically comes from the fact that the end system is _super_small_ and focused. Less software means less attack surface. Sure, compromised binaries are nasty but personally I do place quite a lot of trust with the distribution repos. (PS, if you are reading this and contribute packages to distribution repos: Thank you!)
- lrvick 3y ago
  It is dramatically easier to hide malware in a compiled artifact than in public source code, not to imply that the latter does not happen. In security focused orgs though you review all code yourself with the exception of things with extensive third party signed review such as the Linux kernel itself. Even then I review codepaths in the kernel critical for my use case such as random.c From there, if I -alone- compile containers, kernels, or binaries, someone could coerce me to tamper with them to compromise all downstream users. Same if there was a central build system I can access. To mitigate this I ensure my artifact builds are deterministic, sign my changes, and have team members review my changes, reproduce my artifacts bit for bit, then counter-sign the results. It is never wise to be in a position where there is possibility of you yourself tampering with things that control anything of value, or else someone will coerce you to help them steal said value. As a security engineer it is my job to ensure no one ever has to trust anyone, including me.

m463 3y ago

Sounds like a valuable formative experience. Sort of like launching a spaceship in factorio.

coldpie 3y ago

Same, though a bit later, circa 2007. It's great for software developers too. It's a good quick intro to many different build systems & philosophies, and shows you how the different pieces of software connect together by standard paths and package management tools like pkgconfig. Being able to quickly dive into a new project, understand how to build it and hook other software into it, debug build problems, and make quick hack changes is extremely valuable for developers.

lathiat 3y ago
Yep me as well sometime in that era. It was very interesting and informative. I'd never use it for an everyday system obviously but was a good excercise. And I did this on my real machine before VMs were really a thing :-)

tutfbhuf 3y ago

How does it compare to install Arch linux without an installer? I remember that it took me a day or two of tinkering, when I did it for the first time (circa 2009) and I learned a lot. As of today, Arch remains my distro of choice.

imiric 3y ago
It's very different. With LFS you build your own distro. You bootstrap the filesystem, build your kernel and everything else from source, and there's no package manager. That means manually managing dependencies, which is a nightmare in and of itself, and something we take for granted with Linux distros. The LFS book is quite thorough, so you technically only need to copy/paste commands, but you learn _a lot_ about Linux in the process. I highly recommend it to anyone interested in Linux. I did it once in college, and parts of BLFS IIRC, and it's one of the few memorable projects I got from my degree.

abdullahkhalids 3y ago

I almost did it in 2008ish. Back then my country had a severe electricity crises, and in the summer we would get alternately one hour of electricity and one hour of blackout. So I had to try and break the LFS build into one hour chunks. Though I got through quite a bit, unfortunately, there were some multihour build steps and I never got lucky enough with multihour electricity, till I finally lost interest. I did learn quite a bit from reading the manual though.

noiseman 3y ago

> I had a 1ghz, 256gb ram machine You had a 256gb ram machine???

Daegalus 3y ago
Ha, I wish, good catch on the typo, I can't edit, but should have been "mb" It's been so long that thinking of ram in anything other than GB is weird.