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...

Comments

I think I'm missing something

[Anonymous Coward]

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.

And that's different from LFS how?

Re:I think I'm missing something

[kinnell]

Yes it does. It's right there in the documentation

Where exactly? In chapter 9 (hint: this is the last chapter in the book), "What now" it states:

Now that you have finished installing your LFS system, you may be wondering "What now?". In order to answer that question, we have composed a list of resources for you.

Beyond Linux From Scratch
The Beyond Linux From Scratch book covers installation procedures for a wide range of software beyond the scope of the LFS Book. The BLFS project can be found at http://beyond.linuxfromscratch.org/.

...From which I conclude that you are a troll, and the person who modded you "insightful" is an idiot.

How different from Gentoo?

[mattbee]

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.

Re:How different from Gentoo?

[kinnell]

The difference is that with gentoo, you don't learn much because most things are automated. Yes, gentoo is probably a much better option for someone who just wants a customised linux distribution. LFS, though, is an outstanding educational tool, for one thing, and an invaluable resource if you want to produce a linux distribution which is radically different from the norm in any way.

If you want to learn about how and why a linux distribution is put together, LFS is the way.

Re:How different from Gentoo?

[Rasta Prefect]

Linux from Scratch is actually quite a bit different from Gentoo. Gentoo provides you with executable code, you answer some questions and you have a new install, although the process takes longer and is more configurable than say, downloading pre-built packages. Linux from Scratch, last time I checked, provides you with a document. Thats it. No packages. First you create and format your partitions (by hand, using fdsck and mkfs). Then you create your filesystem, (mkdir /usr /var /etc.....), then compile statically linked versions of them minimum utilities needed to boot and compile, then reboot, recompile libraries and dynamically linked versions, then start compiling the rest of your system software. All by hand. And you have to create your own init scripts (although examples are provided).

Why would you want to do this? It's an excellent way to learn about Linux. You learn exactly what components make up your system, get a pretty good idea how they interact, etc.

Would you want to run this on a system you actually use? Probably not. It's a pain in the ass. Everything has to be compiled from scratch. No package system to minimize cruft build-up. Every security patch has to be downloaded and applied by hand. It's very time consuming.

Re:How different from Gentoo?

[Anonymous Coward]

So, in other words, you only use this if you want to claim to be l33ter than thou...anyone with an actual life uses Gentoo.

People with actual lives use Mandrake or Red Hat. People with l33t tendancies but an aversion to work use Gentoo. People who want to learn stuff use LFS.

Re:How different from Gentoo?

[jdavidb]

Gentoo Linux is a distro. LFS is a "Make your own distro" HOWTO.

Suppose there were no Gentoo, and you wanted to make your own distro with the design goals of Gentoo. You'd install some other distro like RedHat or Debian (or perhaps even a completely different OS; anyone ever bootstrap Linux from FreeDOS?) and slowly compile your own packages. You might choose to use rpm, dpkg, your own, or no packaging system. You'd have a bit of dependency hell while trying to figure out what order to compile everything in (and make sure that you didn't wind up with library dependencies on the original distro). Finally, you'd want to repeat the process from within your new distro; after all, you want it to be self-hosting rather than having to install RedHat each time you build a new version.

Mastering LFS trains you to do all this. Does everyone need to know how to do this? No. Do we really need any new distros? Probably not. But people who have said, "Yes we do" have often brought us much better systems (like your beloved Gentoo). Plus, I found learning this material to be intensely interesting and right up my alley.

Gentoo / Slackware instead

[ajalics]

For labs/installations of many machines, or people who are dolts - um I mean newbies, I always recommend whatever the local flavour of Redhat/Suse/Mandrake/whatever.

However, for a few choice machines, machines that you spend more time with then should be legally allowed, I always recommend slackware (for a non high bandwidth connection) or gentoo (with high bandwidth). The flexibility of these last too is very rewarding for anyone who wants an uber customized Linux box.

And especially with slackware, you gain a lot of knowledge and familiarity with how things works, and how to fix things. This knowledge pays off it's debt quickly. For example, you might have a redhat buddy that has some problems with configuration GUI X, and you just go and fix it by hand.

LFS is interesting, but what's the big difference between it and gentoo? Just an extra step that's not very practical unless you're making your own distro.

Excellent News!

[rice_burners_suck]

This is excellent news. Linux has enjoyed widespread publicity and use, but unfortunately, I think that most people who use Linux (and are new to "alternative" operating systems) are using Red Hat or one of the larger distros and don't really understand its ins-and-outs. For many people, this is perfectly acceptable because all they care about is reading their email and word processing anyway. For them, DOS 2.0 with some kind of quick GUI would be more than enough, let alone Windows XP LX SE 2010. Putting together your own distribution with step-by-step instructions will probably make anybody a better user, admin, developer, etc. And with a book to show you how to build a usable distro, you simply can't go wrong. I think I'm going to dig some junk out of my computer graveyard and try this one out tonight... it'll be a long night!

my kinda EULA

[b17bmbr]

You install only what you need. Your Distro. Your Rules. Enjoy

Can we please shift PRIORITIES?!

[ajs]

Instead of inventing YET ANOTHER WEB SERVER DISTRO (yes, I've been tempted too), can we please focus our efforts on the things that are wrong, broken and unusuable in EVERY DISTRO ON THE PLANET?

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?!

Re:Can we please shift PRIORITIES?!

[ajs]

surely man already does this? my man pages are valid for any command, library call or setup file on my system

Not mine. I've tried every variant of Linux I can get my hands on. Here's an example from my system, just trying a few of the "/etc/p*" files:

man pam_smb.conf
man pine.conf
man printconf.local
man profile
man protocols

How do I find out what program "profile" is documented under? Granted, that's an easy one, and I already know the answer, but many people don't know what a borne shell is, much less that bash IS one.

FreeBSD actually made a point of thise, and they were doing a good job for a while. I have no idea how that's doing at this point, though.

You make the point that paths can be edited... well, yes, but the WHOLE system needs to know that you can have files in multiple locations. For decades now, /opt has been the correct place for third party software, and still I see distribution vendors all inventing their own ideas (Red Hat just wants everyone to install in /usr, debian made some noises in the /opt direction and then gave up in favor of the Red Hat model, the other distributions don't appear to have even thought this far ahead. It *is* a distribution's job to worry about how sofware can be added to the system in a sane way and impose those standards.

You claim that a distribution cannot manage user authentication, but then who exactly DOES? The sudo folks say it's pam's job. The pam folks say it's ssh's job. ssh says it's sudo's job....

In the end, it's GOT to be the distribution that sets their foot down and says "here is the way you will authenticate a user, and here is the way that you will pass authentication data around." The fact that SSH had to roll it's own was a sad result of the state of user authentication at the time, not a desirable situation. Should MY remote access program use SSH's keys or create it's own? Should I maybe have an API for that? Should that API be part of the standard suite of getpw* API calls? WHOAH NOW! That's the glibc folks!

Packaging a distribution is about creating a working system out of the parts provided and any other glue that needs to be added, not about typing "make install" and walking away.

On the point of what to call the system, I've never understood why people put the name of the kernel in the distribution name. It's kind of like calling a computer an IBM PC Clone....why? Why not be your own thing and put your acknowledgements in the documentation where they belong? Eh, I guess most folks don't agree with me here, so oh well....

Re:Can we please shift PRIORITIES?!

[rifter]

Your documentation problem is an interesting one, and I have to say I agree this is something useful. (I think it is rather obvious the other answerers are blinded, as many Linux contributers/users seem to be, by "what is" and "how you do it now" and are not seeing the benefit of how it could be done.

A major problem here is the ragmentation of documentation even for a given command. A little bit in the man page, a bit in the info file, a bit in some randoom PDF, some random text files, a HOWTO, a mini-HOWTO, an Oreilly book, and some random web pages, besides a few archived emails from a list and some usenet articles, and maybe by the time you have gone through all that you will know what to do sometimes. (If not, you need to email a list).

Of course it would be much easier to RTFM if the FM was easier to read, or get to. It would be nice if one or a couple of these places was fairly complete. To be fair, many packages do this, and it is the package's job to provide docs, but this f course leads to an inconsistency, such that some package maintainers like info, others man, and others want you to read their web site, etc. I agree wholeheartedly that it is the distro's job to fill in the cracks. And there are some examples.

For instance, OpenBSD (yes not a Linux Distro, but everyone starts on the same foot on most packages) has decided that they will provide adequate man pages, and they will have everything documented in man pages such that you can actually use those pages, and only those pages, and get things to work. And they do it. Compare the man page for some random package/command on OpenBSD to the *very same one* on Linux (same version even) and you will see what I mean. Someone in the OpenBSD team is fixing the bloody man pages. So why can't Linux distros do it?

Of course the extreme where every file is documented on the system is a very good one to hope for, and something to think about. Also a better doc system than man (though so far I like man best) might be helpful in this task.

The naysayers to your problems are ignoring the fact that distributions change things all the time. It is their job to fill in the cracks and make a useable system. To their credit, I think most have done a lot of work getting things to happen their way. But as usual, there is more that could be done...