Lowlife -- a Linux floppy from scratch
[A floppy with which you can turn even old computers to thin clients]

,,A civilizáció túltesz az életen...''
[URH]

The original location of this html file is http://www.creo.hu/~csaba/lowlife/.
Current version: 0.5.1

I named this bootfloppy-cookbook project Lowlife. It's not yet another recursive acronym, neither a non-recursive acronym; it's just refers to the "native" circumstances of usage and the circumstances of producing it. Anyway, if you find an appropriate acronym, tell me, I may canonize it. Now some information I might find useful for you :)

LFS (Linux From Scratch) is a project devoted to making Linux systems by compiling everything from source. It's a paradise for "diehardhobbyist" (as someone told once) Linux fans, who want every every bit of object code on their box being compiled by themselves, according to their personal tastes.

But the LFS project has more importance for the Linux community than having a nice cage of weirdos in its zoo which can be shown to visitors for their bigger fun.

To make it understand, consider the Windows installer. Any program you get on the Windows platform nowadays ships as an installer exe. After fetching that exe, you just click on it, and the program populates your system after answering some configuration questions, and it's just waiting for you to use it (after you've rebooted; but that's another story :). It's a comfortable way of installing the programs.

On the contrary, in Linux binaries were always a pain in the arse. This is a consequence of diversity: each distribution has its own way of treating binaries, which might be just as comfortable as the Windows installer 'till the distro actively maintains a package of the given program. Fairly soon you can find programs, which has no package for your distro, or there is a package but obsolete and it does not run with your present kit of libs or there is a package but configured in a way that does not suit your needs. The way to dependency hell is paved with pre-compiled binaries. Then you die on organizing your system in a consistent way, such that each depency is fulfilled.

Compiling from source seems to be the exit from dependency hell: installing programs by custom-compiling them to your system. But compiling from source can as well be a hell, when you just get a flux of error messages and you are unable to figure out what went wrong; or the program compiles nicely but when you run it, it does not do anything more than segfaulting. After the third such program you meditate about typing "rm -rf /"...

LFS is the way out of compilation hell. Here the certain programs are examined carefully by certain people, and they find out how can one get that beast compile properly. This produces a big knowledge base which can be for the use of anybody who wants install a program on his/her Linux system. (It's a great advantage of LFS related to other source-based distros: you can make use of LFS without building a whole Linux system from scratch. But you cannot make use of source distros if you run another distro, as they have their own special package installing system.) Of course (just like a binary distro lacks a package for some program), it may occur that the compilation of the one program you want to get installed is not documented in LFS. But if you really need that thing, you can figure out the tricks -- you can do it with one, it would be just the third one where you scream for "rm -rf /". And then you can submit your explorations to the LFS knowledgebase. If you are not a developer of some LFS-related project, you still have the possibility of making an LFS-hint.

I think this evolution-friendly nature of LFS (and that's it old enough now to show some sings of being matured) makes LFS an information source of importance similar to TLDP (The Linux Documentation Project). For me, LFS is primarily a genious concept for developing a knowledgebase, and not a distro-like thing.

I would be glad if more and more people realized this within the Linux community and didn't think of LFS as a bunch of radicals but put the LFS site to their bookmarks in the same folder as TLDP, Sourceforge and Freshmeat.

In this page you can find my humble commit to the LFS project: the description of the procedure of making a Linux bootfloppy from scratch, enhanced with the svga vncviewer. With such a floppy you can turn even old computers to useable thin clienst (by and large equivalent with X terminals. Eg., see my 486 latop displaying the X desktop of my PC (thus making it possible that two of us can use computer simultaneously, without having to invest in a new PC):

So what do I have here to spare? Here are the hints themselves: And some auxiliary stuff (you will see what these are if you read the hints):
Hints attempt to conform the LFS hints format.

Patches attempt to conform the LFS patch format.

Lowlife is licensed under The MIT License.

Update, 2005/03/25

The current instructions won't work out of the box, because the toolchain wrappers has been removed from the Uclibc distribution.

I always plan to update Lowlife properly, but it seems that I don't get there. Anyway, what I can do with minimal effort is to quote here a mail which tells you how to get around this problem. 

On Fri, 9 Apr 2004, Bhaskar wrote:

> Hi
>
> i was reading through and following  you instructions on making a lite linux boot floppy.
>
> The problem i am running into is with uClibc.
> i am have the 09.26 version of uClibc. I follow your instructions as written in your txt file.uClibc doesn't  show any compile errors and says done compiling and then after "make install" says done installing. Then i try to compile busybox with these uClibc libraries, but i doesn't work saying that
>
> /usr/i386-linux-uclibc/bin/i386-uclibc-gcc : No such file or directory.
>
> Infact the bin directory in /usr/i386-linux-uclibc/ is not present.
>
>
> Can you tell me what i am doing wrong?

Uh-oh... That's my fault, the hint is dated, I always plan to update but I
didn't yet get there. So the situation is as follows: between 0.9.21 and
0.9.22 the uClibc guys made up their mind and said: the gcc wrapper works
only in 99% of all cases, and they don't want to maintain a non-100% proof
solution -- so they removed the wrappers from the uClibc distribution,
saying that one should use a native uClibc toolchain if wants to play with
uClibc. But making such a toolchain is certainly an overkill for a
bootdisk...

So you can:

* either downgrade to uClibc 0.9.21 and follow my instructions
letter-by-letter;

* or you can dowload the wrapper from their CVS Attic:

http://www.uclibc.org/cgi-bin/cvsweb/*checkout*/uClibc/extra/gcc-uClibc/Attic/Makefile
http://www.uclibc.org/cgi-bin/cvsweb/*checkout*/uClibc/extra/gcc-uClibc/Attic/gcc-uClibc.c

(d'load it directly or you can use the equivalent cvs command, which I
couldn't figure out). After you've compiled uClibc, create
extra/gcc-uClibc/ in your uClibc source tree, put these there, hack the
Makefile a bit (IIRC I had to, but I don't remember exactly how), compile
the wrapper and enjoy! (recommended way, should be pretty
straightforward).

Yours,
Csaba
Finally, a simple request: I spent quite a bunch of time of putting this stuff together, and my girlfriend thinks that this time went directly to /dev/null (as I remember, she used a different wording :), as noone will ever read or use this stuff. So if you found here something you consider useful, please drop me a mail for helping me in convincing her that it's more than an attempt of assasination against her :) [you can access me by sending your mail to the server math-inst.hu, addressed to user ekho](though I think the best I can do is not answering to such mails (at least, not answering to each) -- I guess you might have a high email load anyway --, I do appreciate the feedback).

[Go to my main page]