LFS Write up -- Part 2 -- RFC

Doumbeck1 at aol.com Doumbeck1 at aol.com
Wed Nov 21 14:30:16 PST 2001

Know what your system settings need to be before you begin, especially 
settings for routing and eth0 or ttyS0 or whatever. This will save 
frustration. If you need to refer to your Base System's settings, then go for 

    Keep Notes. If you build LFS following the book to the letter, then to 
book is your notebook. If you diverge even a tinsy bit, write it down and 
keep it handy. Keep notes on how you install all software, you will need it 
if you need to remove something or need to remember where you installed it, 
because some other package doesn't seem to find it on its own. Don't loose 
your notes...This is important. You could end up installing a library in two 
locations by accident and that can cause all kinds of hell in the future.

    The first thing you should install after LFS is GPM, including before you 
start LFSing the second time...trust me...read the hint to get it compiled 
otherwise you won't get it compiled.

    Hints are found at http://hints.Linuxfromscratch.org go there, download 
them all and read them...read GPM first.

    Learn to like the console...it has much better, more stable software than 
X. I use X sometimes when I really want graphics support, but console really 
is better for functionality, it uses less resources and the software almost 
always much faster ... 9 out of 10 Linux gurus agree. Ok that's more 
generally Linux oriented and not LFS oriented, so I will stop there.

Pros and Cons

    Here is the part you Linux advocacy die-hards should appreciate. You 
should notice the similarity between what is said here, and what is said in 
the MS vs. Linux war.


    The very first and foremost pro for using LFS is Education. Flat out, 
this beats any other advantage that LFS has to offer. By the time you have 
learned how to compile your own Linux system using only the book for tips and 
hints, you have become a system developer and not just user...Don't get me 
wrong, you'll still have lots to learn about system administration and other 
stuff before you are a guru, but you are more guru now than ever before. You 
will learn how to modify and maintain source code. You will learn how your 
computer works, and right down to low level CPU functions if you go the hard 
core optimization route.

    Stability. This is the second most important reason for building LFS. 
When you take the time to regression test your system and fix any minor bugs 
that do occur occasionally, you'll have arguably the most stable system you 
could find. In essence this is by the way, what distribution developers do. 
In their own fashion they build their own specific LFS and test rebuild test 
patch rebuild and test and package.

    Performance. LFS is native. That means it was built on the system it is 
running on. If you allow gcc to discover the sort of system hardware and 
software you are using, you'll have a pretty good optimized system that by 
default will outperform any distribution on the market, guaranteed. There is 
a reason for this. Distributions need to build Linux systems for the widest 
set of platforms. Within an architecture family, this means compiling their 
distribution for the lowest common denominator (i.e. the Intel 80386 in the 
case of the Intel family and its compatibles). The exception being Mandrake, 
which targets the Pentium Classic as the lowest platform. Essentially this 
makes your Athlon1.2 GHz computer a 1.2 GHz 80386. None of the advantages are 
the newer architectures are used, because they can't be if the software must 
also run on an i386. So you gain a great deal of performance, up to 30% for 
just the default compile time options in some cases.

    Lean-ness. LFS will be very small compared to similar installations from 
Distributions. You can strip RedHat down to the very same files that you 
would find on a finished LFS system. RedHat would still be a much larger 
installation. This is due in part to the same reasons why you see a gain in 
performance with LFS. As well, instead of having to hunt down files that 
aren't going to be used, you instead are faced with the joy of only 
installing that which you absolutely want or need. I have a fully featured 
GNOME workstation loaded with software. The installation is big, but it's 
much smaller than a RedHat GNOME workstation, having only the components I 
use. It also is very stable and doesn't crash. I have only installed software 
as needed and so I know there is nothing superficial or superfluous about my 

    Customizability. This could really be put anywhere in the ranking of 
pros. It might be your first priority or your last. This is also very easily 
the most used argument for why people might select Linux over MS Windows, and 
it also the most used argument for building LFS. You can do anything you want 
with LFS. You can put together a fat desktop and multimedia workstation with 
GNOME, KDE and GNUStep. Configure it to automatically boot into runlevel 5. 
Use xmms to play your favorite music and watch your favorite DVD movie with 
mplayer. If you don't like using /usr/local in the traditional manner and 
want to install all user software in /usr/local/PACKAGENAME go for it. Your 
PATH and ld.so.conf will be huge, but hey it can make software removal a 
breeze (rm -rf /usr/local/PACKAGENAME). Alternatively, you could fashion a 
DOS-like filesystem structure if you really want. Yes you could customize 
RedHat to that extent, but go ahead and try...Its a much bigger head-ache 
than customizing LFS. Here's the kicker and paradox argument for anti-LFSers, 
I'll be done long before you. LFS just lends itself to customization since 
its very basis is being compiled entirely from sources.

    Compartmentalization. This is really a combination of the last two above. 
With the lean-ness and customizability inherent in LFS, LFS is well suited 
for singular tasks that are best suited for older hardware freeing up newer 
hardware for hard-core tasks. Everyone knows about using an i[3,4,5]86 as a 
firewall, but how about using an i586 for a firewall and moving dhcp, WINS 
resolution and DNS and your other seldom used services to an i486. The i486 
would perform very well, and perhaps better than your heavily hit i586 
firewall running the additional services. You can leave the firewall alone to 
do its job as a router/NAT/firewall and so it performs better too. Ok, I am 
getting into that general Linux territory again. Stop.

    Experimenting. You can play all you want, and if you break something you 
probably now have the wherewithal to figure out what you broke.

    Understandability. When you are finished building your complete Linux 
system with all the junk you could want on it and tweaked it to the brim, I 
want you to compare your system with a RedHat or Debian or any other 
distribution system. Look at /etc  ...  geez what the heck is all that crap? 
Compare your ~/.bash_profile ~/.bashrc and ~/.bash_logout with RedHat's ... 
See any difference? A huge one I will wager.

    Support. LFS builders are some of the MOST knowledgeable Linux users in 
the world. If you hop onto irc.Linuxfromscratch.org friendly faces, people 
who are MORE than willing to help out a fellow LFSer will greet you. If they 
can't help you directly on irc, then you will likely be directed to the 
mailing lists or the news server (which is a mirror of the lists.) You can 
also search the mailing list archives to see if someone has already 
encountered and solved your problem. It's very likely. On a not so rare 
occasion a fellow LFSer might even try and duplicate the problem on their end 
to see if they can solve the problem. LFSers are by definition Linux problem 


    Education. You will be forced to learn how to do this, and it does take 
some time to become accustomed to this new method of system building. Gone 
are the days of just sticking in a CD and booting. You will have to make 
intelligent choices, scrap ideas and start anew when an idea doesn't pan out. 
Notice this is also listed in PROS.

    Time. It does take time to develop a system. As you become more familiar 
with compiling a system completely from scratch, compile time diminishes. 
Again my first time it took 3 weeks (with legit excuses), and now it takes me 
3-4 hours. Before you think of this as too much of a disadvantage, how many 
times have you sat in front of a Linux installation screen and labored over 
what to install and how. And how many more times have you spent 4 hours 
installing Linux only to say to yourself...Oh man I wish I hadn't done that. 
It's the same deal; with familiarity it doesn't really take much more time to 
build Linux than it does to install it (of course I AM talking about on 
faster computers, an i386 can take days to compile LFS where a CD will take 
maybe 5 hours.)

    Frustration, Bruising and Headaches. Sometime when you are trying to 
install some software, you'll have one heck of a time. You'll bang your head 
on the desk (hence the bruises) and you kill anyone that comes within arms 
length. This isn't the norm, but it does happen sometimes. Usually it will be 
due to some earlier installed, and required software not being recognized 
properly or source code that isn't up to the current state of Unix/Linux. 
Before you beat yourself silly, just hop onto irc.linuxfromscratch.org. 
Someone is likely to have run into the same problem, or something like it and 
can give you a hand, within minutes usually.

    Proprietary. As much as customization is an advantage, it also becomes a 
disadvantage. You have no choice but to customize, or work very hard to 
adhere to a set of standards such as the File Hierarchy Standard, and others. 
You will never find RPMs for your system or deb files. Occasionally a tgz or 
tar.gz file will work as packaged. You pretty much are destined to compile 

    Experimenting. You will have to do it. Experimenting is how you get much 
software to work, but once you do get it to work, it really works.

    Package Management. Once again...No RPM, No Deb, the occasional tgz file 
works. There are people who have installed RPM or dpkg and apt-get, and they 
build their own packages for their own future use, but unless you follow the 
same standards as the people who made the packages, you can't use them. Most 
people make them for their own use so they can add and remove less often used 
software at will.

    Support. If it doesn't work, you don't have a vendor to blame and fix 
things for you. It's all on your shoulders. You can get on many irc channels 
that support developers, such as irc.openprojects.org. The developers of your 
software can often be found there.

    Configuration. You have to hand code almost every aspect of your Linux 
system. Although there are some provided rc scripts and /etc configuration 
files that can be downloaded from ftp.LFS.org, you will probably want to 
change them to suit your needs...In addition any software you install above 
and beyond the LFS system will not have pre-made configuration files. You 
will have to learn how to do that yourself.

    Man Pages. This is really a PRO but I add it here for a reason. There are 
no manuals for LFS, no QUE no UNLEASHED or other overview manuals such as 
those you can get for distributed Linux. Man Pages will become your friends, 
and application specific manuals (such as O'Reilly's) will become the meat 
and potatoes of your IT library. In fact you might want to throw out your old 
Linux manuals, because they ARE vendor specific and won't be much help at all 
with LFS, they may even confuse you.


    Linux From Scratch isn't for the faint of heart. It is meant as a 
launching platform from which you can build systems to do your bidding as you 
wish it. Go now, young Jedi. And remember, "Use the source" (Someone else 
gets credit for that quote, but I can't remember which LFSer said that to me)

Copyright Nov. 2001


Gerard Beekman - Owner, Project Leader, Author and Principle Developer and 
Principle Tester of "Linux From Scratch Project" and Friend
Beverly Beekman - Mrs. Gerard, gracious supporter of the Linux From Scratch 
Jesse Tetanka (HIghOS) - IRC OP, Developer, Tester and Friend. We miss you 
Jeremy Jones (mca) & roryo - Testers and Co-Authors of Gnome.txt, the GNOME 
hint (much better than my hint) and Friends, sometimes
The list goes on and on, all the way down to minor contributors and just 
people we (and some we don't), and then at the bottom of the list is me.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list