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...
I've recently been impressed by Gentoo Linux which lets you build your system from a BSD-style ports system: the whole thing held together by a bunch of Python scripts, but otherwise your build options, tools and so on are your own choice. If that's not Linux From Scratch I'm not sure what is :-)
Having said that, I'm not always convinced that the way to a reliable server setup is to build everything yourself, but both LFS and Gentoo look good for the desktop.
Matthew @ Bytemark Hosting
Linux From Scratch [linuxfromscratch.org] is not a disto, but a set of instructions for building a GNU/Linux system from little more than an existing distro. The Beyond Linux From Scratch [linuxfromscratch.org] project builds on this tradition, providing instructions for installing a number of other packages.
:-)
Having said that, I would recommend that anyone serious about furthering their knowledge of Linux, and at least 750MB of free hard disk space should give it a go. I got into Linux back in '93, and knew quite a lot. Then I stumbled across Linux From Scratch (LFS) - I didn't realise how much I didn't know until finishing my first complete build.
I now run an number of LFS-based systems at home and at work, and have never looked back.
BTW, I am typing this on my Gentoo [gentoo.org], 1.4_rc4 build.
Any fool can talk, but it takes a wise man to listen.
LFS, for example, does not tell you how to install X windows from the source.
BLFS tells you about major packages and their dependencies.
I've installed LFS before. LFS is just the instructions on how to install Linux from scratch (hence the name, Linux From Scratch). They supply a few pieces of software conveniently in one place so you don't have to spend hours finding it on your own and figuring out what version goes with what. It is just enough to get an OS that works, but not enough to do much except put more software on it.
BLFS is a collection of instructions for installing various bits of popular software like Gnome, KDE, Mozilla, and more.
I would like to point out that LFS is not Gentoo. LFS is literally Linux From Scratch. There are no installation scripts. There are no system management tools. There is no pretty interface, or simple instructions. It is a book, not a piece of software.
You literally go through each piece of software and configure, compile, and install it. It is pretty cool because they describe what each piece of software is for, and you can see how one piece builds on another. You'll certainly never look at your system the same again, because you'll know what each bit does.
I wouldn't suggest trying LFS unless you are interested in what exactly goes on under the hood, or you are building your own distro from scratch.
The radical sect of Islam would either see you dead or "reverted" to Islam.
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.
Beond Linux From Scratch is a great resource for expanding an LFS system, but don't forget about the LFS hints! http://hints.linuxfromscratch.org
There is lots of valuable information in the form of hints that is not available in BLFS
Sigh... /. editors, I love you for causing an absurd amount of trouble for me. I thank you for promoting our projects, I just wish you guys would have contacted us before linking to the main websites.
;p)
:)
We've had hosting issues ever since our main server was taken off the VA network last October, and since then things have been hosted on my personal server. Anyways, I just wanted to rant little, considering i'm at the other end of this slashdotting.. (not like it's my first time, more like 8th now
At least use the mirrors guys.. please
Where exactly? In chapter 9 (hint: this is the last chapter in the book), "What now" it states:
If I seem short sighted, it is because I stand on the shoulders of midgets
Here are some suggestions for your distro-crafting efforts (no implied priorities):
- There should be a way to say "fetch documentation for x" where x is a path name to any non-user file (and a few user files). man is the "right place" to do this, although if you wanted to take the time to re-engineer info so that it could take any program name or path name as an argument and find the right documentation AND had an initial dir.info that wasn't so geard toward "so you've installed EMACS and the GNU tools on an existing UNIX" then it might be a useable replacement for man (and info has the benefit of being a bit easier to convert into other forms like GUI-viewer, print and HTML-based representations because it's based on a more generalized markup language (texi) which is in turn based on a more powerful typesetter (\TeX). I'm a long time (15ish years) user of UNIX and UNIX-like systems, and I still want this!
- A set of management tools for pam that runs the spectrum from adding a user to choosing a password hashing format to setting up an LDAP server based on an existing source (local files, an external database, etc). In the UNIX tradition (and for good and valid reasons that you can find by searching USENET, and I won't go into here) it should be command-line driven, but I would not complain at all about a GUI tool
- A heirarchical installation model that allows for a
/usr, /opt and /usr/local which are applied to all system paths and configurations in reverse order (e.g. default paths all start with /usr/local/bin) and which package maintainers have well defined conventions for using according to historical precident (/usr is for distribution-native packages, /opt is for third-party packages and /usr/local is for site-local items that are created and installed by the maintainer of the system). If I put GNOME3.0pre-alpha97 into my /etc/apt/sources or whatever the equivalent is, and install it, it should go into /opt so that un-installing it puts my system back where it started. If I hack my own copy of Perl and install it, it should go into /usr/local so that it's clear that this is my hacked version and not something installed from the official distribution. - sudo, ssh, and pam all have different views on what it means to authenticate. These views need to be merged at the distribution level into a single means of authenticating. This is a hairy problem, and may involve feeding back into all three projects, but if I don't have a password because I use a pam-based smart card and ssh-agent for remote key exchange then I can't use sudo (which requires a password). sudo is well within its rights to require periodic re-authentication, but that needs a mechansism (through support in it and the infrastructure of the os including pam and ssh) to feed that re-authentication request all the way back to my smart-card interface....
So, if distributions are seeking to solve problems like these, great. If they're not, and they're just another way to customize Red Hat or Debian or install from source or put your files on an FTP server, then I have to ask if the authors of these tools are even scratching their own itch?!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.
I don't consider myself a guru, but 'I would say I know enough'. I've done the whole LFS/source based distro thing for a while now so here's my take on things.
I think it's important to make a distinction between LFS and Gentoo/SGL/Sourcemage/Lunar/uPM. LFS is a book that describes the process of producing a minimal linux installation that is capable of building software. The source based distros provide scripts/tools that automate the build process for you. Which you choose is largly dependent on your needs.
It seems from your post that you are interested in learning what makes GNU/Linux tick: what files do what, what software is required and what's bloat, and generally what goes on under the hood. For this I found that there is no substitute for LFS, it took me from Mandrake newbie to power-user in a couple of months. This was a good few years ago and at the time there was no BLFS, I feel that that actually helped me with learning the stuff. LFS held my hand through the installation of the base system, but after that I was forced to RTFM, making my own mistakes and learning from them. After 2 or 3 months I had a fully functional system with KDE, apache and a bunch of other stuff. I also had learned many times more than I did in over a year of using mandrake.
My new shiney LFS system was a joy to behold, but it became a real pain to maintain. I found that an unacceptable portion of my time was spent updating software manually and it was effecting my productivity. This was around the same time that SGL first appeared on freshmeat. I had tinkered for a while with LFSmake but found that it wasn't flexible enough. SGL was wonderful, I traded a small amount of the total control that LFS gave me for a system that saved me 80% of the time I was spending on keeping my system up to date.
Unfortunatley there was a bit of a storm in the SGL teacup which resulted in SGL going offline for a while and 2 forks appearing (Sourcemage and Lunar). Initially I went with Sourcemage but I found that after a while it became too unstable and as I was using it for work I couldn't have that (it may well be better now, I've not checked it out in a while). I switched to Lunar and am still using it now. It doesn't provide the same education as LFS, but once that knowledge is aquired it provides a much more efficient means of installing/maintaining your system.
I should say that I did once try gentoo but I was put off by the complete lack of an installer. You have to jump through too many hoops (and triangles, hexagons and other polyhedra) to get the thing up and running. uPM also looks interesting but is still in a relativly eary stage of development.
To sum it all up: LFS cannot be beaten for it's educational value, but for day-to-day use Lunar suits me best.
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