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