I did this once before and it was instructional and fun (for a certain definition of fun). If you like hacking around on your system, this is a great way to understand a lot of the moving parts in Linux.
I still like the idea of a minimally patched system built and configured from the ground up. Building everything from source takes a long time, so I didn't do Linux-From-Scratch more than once and instead most of my linux machines are now running ArchLinux, which has a similar philosophy about systems except that they distribute compiled binaries.
Anyways, if you haven't built many programs from source before, this is a great way to get a curated introduction. Worth it in many ways.
Can you elaborate? Part of my everyday life as a coder is downloading packages and building them, so I'm curious how this brings more to the table. I flipped through the book (http://www.linuxfromscratch.org/lfs/view/7.1/) and couldn't tell..
You still need to do some research, but it helped me focus on what I wanted to learn. Why was I using that command? What does that package do? Crap, I typed that wrong - why did I get that error message?
Before I built LFS, I had only a rough idea of the internals of the C build system and Linux runtime. Basically, I just knew that I had a recent GCC and some surface-visible tools like make, autoconf etc. and most software built just fine when I needed it to. The process of bootstrapping a clean GCC that operates in a chroot-jail and then using that to construct build a system from the ground up -- kernel, glibc and all -- gives great insight into the dependencies and build process of each of these basic packages.
It's great that the Linux world has become so sugar-coated, and typical build instructions for source packages nowadays can be as simple as a list of apt-get packages to install followed by "./configure && make && sudo make install" but this glosses over an awful lot, and turns your build and runtime dependencies into a black box.
If you're not aiming to build a complete system for every day use, the book still teaches how to bootstrap Linux.
So if you know how to build and install regular software, you might still be interested in cross-compiling and creating a tiny Linux kernel and rootfs you can boot in an emulator like qemu. You can either use glibc and GNU userspace or use ucLibc and busybox, or perhaps glibc+busybox.
If you already know how to bootstrap a Linux system, then you can go through the book and build a few dozen packages by hand and sooner or later you will learn to appreciate the efforts of Debian (and other) package maintainers go through.
I gave an old version of this a go a long time ago. It was really very time consuming. I would be interested in doing it again though now that I have more of an idea about compiling from source.. I was still very new to it then. I felt that you have to be pretty switched on to this before you start.
My ideal distribution would be somewhat of a meta distribution allowing from source (meaning git, svn) control as well as binary installation. These are a few idea's I've had regarding this:
* Parse build systems such as configure.in, Tupfile.. for options and dependencies and use simple machine learning for classification of options
* Use some sort of locality sensitive hashing to sort packages thus easy to categorize without arbitrary naming
* Meta framework allowing for building different package formats such as rpm, deb..etc.
* Quality control as well as PGO and such via rspec (or something as malleable).
Gentoo or Exherbo do all by hand and in shell which becomes time consuming and incredibly brittle. All this could easily be broken down into individual parts.
As an aside, on recent hardware it's not as long as it used to be, you certainly can compile the base system (kernel, glibc, udev, and most base commands) in a single 8 hours day.
I did this once before and it was instructional and fun (for a certain definition of fun). If you like hacking around on your system, this is a great way to understand a lot of the moving parts in Linux.
I still like the idea of a minimally patched system built and configured from the ground up. Building everything from source takes a long time, so I didn't do Linux-From-Scratch more than once and instead most of my linux machines are now running ArchLinux, which has a similar philosophy about systems except that they distribute compiled binaries.
Anyways, if you haven't built many programs from source before, this is a great way to get a curated introduction. Worth it in many ways.
Great Snakes! This was almost exactly my experience with LFS, and I just installed Arch on my laptop, after running it on servers for a while.
> Worth it in many ways.
Can you elaborate? Part of my everyday life as a coder is downloading packages and building them, so I'm curious how this brings more to the table. I flipped through the book (http://www.linuxfromscratch.org/lfs/view/7.1/) and couldn't tell..
You still need to do some research, but it helped me focus on what I wanted to learn. Why was I using that command? What does that package do? Crap, I typed that wrong - why did I get that error message?
Before I built LFS, I had only a rough idea of the internals of the C build system and Linux runtime. Basically, I just knew that I had a recent GCC and some surface-visible tools like make, autoconf etc. and most software built just fine when I needed it to. The process of bootstrapping a clean GCC that operates in a chroot-jail and then using that to construct build a system from the ground up -- kernel, glibc and all -- gives great insight into the dependencies and build process of each of these basic packages.
It's great that the Linux world has become so sugar-coated, and typical build instructions for source packages nowadays can be as simple as a list of apt-get packages to install followed by "./configure && make && sudo make install" but this glosses over an awful lot, and turns your build and runtime dependencies into a black box.
> ./configure && make && sudo make install
When I used Ubuntu, I'm not sure I ever even needed that.
If you're not aiming to build a complete system for every day use, the book still teaches how to bootstrap Linux.
So if you know how to build and install regular software, you might still be interested in cross-compiling and creating a tiny Linux kernel and rootfs you can boot in an emulator like qemu. You can either use glibc and GNU userspace or use ucLibc and busybox, or perhaps glibc+busybox.
If you already know how to bootstrap a Linux system, then you can go through the book and build a few dozen packages by hand and sooner or later you will learn to appreciate the efforts of Debian (and other) package maintainers go through.
I gave an old version of this a go a long time ago. It was really very time consuming. I would be interested in doing it again though now that I have more of an idea about compiling from source.. I was still very new to it then. I felt that you have to be pretty switched on to this before you start.
My ideal distribution would be somewhat of a meta distribution allowing from source (meaning git, svn) control as well as binary installation. These are a few idea's I've had regarding this:
* Parse build systems such as configure.in, Tupfile.. for options and dependencies and use simple machine learning for classification of options
* Use some sort of locality sensitive hashing to sort packages thus easy to categorize without arbitrary naming
* Meta framework allowing for building different package formats such as rpm, deb..etc.
* Quality control as well as PGO and such via rspec (or something as malleable).
Gentoo or Exherbo do all by hand and in shell which becomes time consuming and incredibly brittle. All this could easily be broken down into individual parts.
Call me crazy, but somehow LFS+(Puppet|Chef) makes a lot of sense... :|
If you're thinking of heading down this road, there is also Automated Linux From Scratch.
http://www.linuxfromscratch.org/alfs/
As an aside, on recent hardware it's not as long as it used to be, you certainly can compile the base system (kernel, glibc, udev, and most base commands) in a single 8 hours day.
I built my first LFS inside Virtualbox, it was slow. Fun starts at Beyond LFS (BLFS). Never finished it, installed Ubuntu instead and be productive.