Slashdot Mirror
Beyond Linux From Scratch 1.0 Released
An anonymous reader writes "DistroWatch reports about the 1.0 release of Beyond Linux From Scratch (BLFS), a subproject of Linux From Scratch: 'The BLFS Development team is proud to announce the release of BLFS 1.0. With this release, you can take your LFS 4.1 base beyond a development system. It can be a desktop, a firewall, a multimedia player/editor, an Apache web server or all of the above. You install only what you need. Your Distro. Your Rules. Enjoy.'" Choose the closest mirror...
... to learn a lot about linux.
Thx to all the guys (and girls) who contributed to LFS
Grtz
is that it is a good learning experiance.
When I first started using Linux I did the usual, RedHat, SuSE, Mandrake, blah blah blah. I ran the nice little installer, opened my desktop, ran a few programs, but I couldn't tell you what was where or how to effectively fix broke things.
Then I tried Gentoo and now I feel like I have learned something about Linux. I found out where configuration files went because I had to. I learned how to compile the kernal because I had to. I learned how to install freaking network cards because I had to.
I don't know if my machine is "leaner and meaner" but you know, I had a lot more fun doing building it.
RTFM? FTFM!!
BTW, if you want to do the LFS part, I'd expect it to take a few weeks for a novice linux user (that's about what I averaged all three times.)
LFS. Have you built your system today?
Linux from scratch is critical to the future of GNU/linux. It stops the corporates from stealing all the limelight (yes I mean SuSE, Redhat et al) and is the ultimate counter measure to the "Linux will fragment like UNIX did" naysayers.
For all Linux users, building from scratch is like the Muslim pilgrimage to Mecca, it is something that you should do at least once in your life. I for one support this and will do my bit to ensure continuing freedom.
i have been part of the LFS community for a few years now, just helping out on the lists and writing a few hints. The sad thing is not that BLFS exists, but that it has become more of a 'copy and paste the commands' textbook for building a system. the hints were more of a walkthrough which taught you what you were doing at each step and explained in some detail setups for larger programs. dont get me wrong, i love BLFS, but i think it has lost some of what the hints had.
another sad thing about LFS is that the punters seem to WANT copy and paste instructions... lately i have unsubscribed from the lists because new posters are always asking FAQ questions or not checking the archives. a while ago, only those keen to learn GNU/Linux in more detail (and were not afraid of the `man` command) used LFS; nowadays we just get a bunch of kids wanting us to hold their hand while they build their own distro to increase their geek factor. and new hint subissions are all silly GNU style (configure ; make install) stuff which doesnt need documented. i personally think if you want to run LFS, you have to be prepared to write a few patch files yourself for dodgy programs, involving some level of programming experience.
for the record, i still use LFS, i think it kicks ass, and the speed difference with any distro is VERY noticable (i have had others confirm this, its not just propoganda). but then, it is an addiction; you have to reach a stage where you say "ok, this is stable, i am not going to upgrade it anymore!" or you lose your real life.
There are no packages. You download the official Tarball or gzip and extract, compile with your options, and install. It is probably the absolutely most vanilla linux their is. I have to second that it is very educational. I have built LFS twice, once about 2 years ago, and once about 4 months ago. The first time a system boots where you understand every little daemon and startup script and program and it's usefullness is very rewarding. LFS is basically an instruction book on how to build all the differant programs and libraries in the right order. At first, the GNU tool chain is built statically from a differant distro, then a jailed root is used to rebuild everything dynamically with the static toolchain, so the system is self-hosted. The book explains everything very well, and only minimal knowledge is needed. I can't emphasize enough how educational it is on Linux and Unix in general.
-- the computer doesn't want any beer, no matter how much you think it does. NEVER, EVER feed your computer beer.
Anyway, I don't understand how anyone has trouble installing packages from source. You just need to partition them appropriately. I wish distributions used a similar method so they could keep parallel versions of programs and libraries installed.
Take openssh, for example:
My typical build of openssh requires: zlib, openssl, and tcp_wrappers.
I use a structure I call /mfs ("My File System"). I could use /usr/local for the same thing, but a customized directory will prevent collisions in /usr/local (the usual default prefix for configure scripts).
Under /mfs I have directories "dist" (the tarballs), "src" (where I untar and build each package), and "pkg" where I install packages.
So I start with zlib: "./configure --prefix=/mfs/pkg/zlib/1.1.4 ; make ; make test ; make install".
I repeat with tcp_wrappers, openssl, and finally openssh. So now I have the most current versions:
It should go without saying that I configure openssh to use the zlib, openssl, and wrappers libraries under /mfs, rather than the default system libraries. To the anal purists out there, I don't do this with all libraries (such as glibc), as it would drive me insane -- but it could theoretically be done.
Here's where it gets elegant (or convoluted, depending on your tolerance for complexity). Under each package's directory, I use a symlink from the version I wish to use on a regular basis to "std".
So, under /mfs/pkg/openssh, I may have directories 3.6.1p1, 3.0.1p1, and 2.9.9p1. Let's say that I want to use the latest sshd, so I run "cd /mfs/pkg/openssh ; ln -s 3.6.1p1 std". I then cd back up to /mfs. I then issue "lndir pkg/openssh/std". Actually, I have a script in /mfs that automatically removes all existing links under /mfs (avoiding the "pkg" dir, for obvious reasons) then re-linking every package with a "std" link. (Note I don't use a "std" link -- and thus don't lndir -- for libraries without runable binaries). If you don't know how lndir works, check it out (it's from the XFree86 distribution, though that might not be where it originated.).
After running lndir (or my script), I now have /mfs/{bin,etc,var,lib,sbin}. I point my sshd startup script to always use /mfs/sbin/sshd, which is actually a link to /mfs/pkg/openssh/std/sbin/sshd. Since std is a symlink to the version I wish to use, I can change to a newer or older version by simply stopping sshd, changing the "std" link to point to another version, and restarting sshd.
The beauty is that still have other versions available to me. Say the scp provided in 3.6.1p1 has an irritating bug (not the case, but just imagine). If my normal PATH has /mfs/bin, I'll get scp v3.6.1p1, but I can fall back to running /mfs/pkg/openssh/3.0.1p1/bin/scp.
This technique is especially valuable in multi-user systems, where libraries and applications of different versions (think compilers, for example) have dedicated users who aren't ready to upgrade.
Sorry for the really long post, but this idea works extremely well, IMHO, and I'm surprised that no distros use a similar technique for maintaining parallel versions. If RPM used this technique, you'd never run into the case where a new app needs a newer library version, but upgrading that library isn't possible since other major applications require that specific version (such as KDE needing a specific version of libpng and libcrypt).
Method of processing duck feet