ALFS == build world?

Jesse Tie Ten Quee highos at highos.com
Sat Dec 2 15:03:38 PST 2000


Yo,

On Sat, Dec 02, 2000 at 10:27:25PM +0100, Stefan Hoffmeister wrote:
> Yeeeees, but in order to install an LFS from scratch system... As much as
> I like the approach taken by SuSE, Mandrake, or RedHat, when installing a
> "native" LFS system I'd rather not install one of these *first* in order
> to be able to switch over.

Whomever said this can't be done? :)

I know for a fact that Remenic (#LFS at irc.linuxfromscratch.org) has done
it like that, he didn't feel like installing a distro on his IBM
Thinkpad so he downloading my LFS-2.3.6 i386 static build from
http://quasar.highos.com/ALFS/ (note: most of the stuff here is a couple
of months old, but still usefull....)

He kept that archive on his windows partition, then rebooted and
partitioned+formatted with PartitionMagic, then booted up with Toms'
Bootdisk, got networking going, mounted his new partition, unpacked that
archive and chroot'ed and started the process of installed the rest of
LFS after Chapter 5 (started at Chapter6 instead i mean)

Ok, a bit of hacking in there you have todo, but it's not impossible ;)

> IMHO, there should be a very minimal base system that allows for
> installation of an ALFS system that then builds an LFS system from
> scratch.
 
Now, for ALFS, there is not going to be a need to have a distro
installed, that's one of the main points.
 
> I am not too familiar with the BSD family (my tinkering with FreeBSD
> doesn't really count) - I wonder whether there are any provisions for
> patching the kernel as part of the build process?

Dunno, i'm not that familiar with BSD.

> Interesting.
> 
> [BTW: IE 5.0 complains about an XML error. Yeah, I know, don't use IE.]
 
Yeah..IE can read XML documents and the profile doesn't have a DTD
(reason it's bitching ;) to parse.

> How would this accommodate for my (actual) desire of having IBM's Dynamic
> Probes and support for the Linux Trace Toolkit patched into the kernel? 
> 
> I'd rather start with a "clean" kernel, then add patches (reiserfs, LTT,
> etc) on top. I see this having been taken into account for glibc - start
> with the "raw" distribution, then add the optional add-ins, then patches.

See, bdumm's post (which will problably arrive before mine ;)

> KISS - Keep it Simple ... . Adding real-time tinkering will add *major*
> synchronisation problems and, with that, reliability problems. Once
> something is in progress, it may be aborted, but never, ever play with
> something life, as the outcome *will* be unpredictable.

I'm talking waywayway in the future here (i was having fun one day on
the mailing lists, just saying how easy it would be todo that on the
fly, without breaking anything when it comes to synchronsation or
reliabitlity)

You haven't heard how the ALFS IPC system will be in place (well this
hasn't been talked about much, minus a few threads on the mailing lists
and what we talked about on IRC between myself, Gerard and Bryan) which
would make synchronisation on the fly like so, very easy.

The first version i doubt will have much of an interface ;)

> I take it that security updates will be patched in the same way? 

Yup.
 
> Has it been taken into account that currently there is a divergence
> between the preferable kernel C compiler (egcs 1.1.2) and the preferable
> "user mode C(++) compiler" - gcc 2.95.2 - and that this divergence will
> increase the moment gcc 3.0 will be out?

Yup.

> I think I'll have to understand what *I* want much better before I can
> talk intelligently about ALFS (and LFS). I am still waiting for my target
> experimental machine (notebook, P133) to be "given up" (for a PIII 500
> notebook) before I can actually try LFS and look at the details :->

It's usually a good idea..

> Right *now*, when looking at current Linux distributions, it just looks
> like a "whole mess", difficult to configure because of a lack of
> uniformity in config options, because of the sheer amount of "stuff" that
> is being delivered by default. This all could be avoided with a lean
> flexible system, with consistent config options - and LFS (with ALFS on
> top) currently seems to be the one and only choice AFA Linux is concerned.

Yup.

> I can imagine that (A)LFS allows building a Linux system that can do
> everything - from being a Beowulf master, to a dial-in router, to a
> starting point for embedded devices.

Yup.

> My (professional) focus currently is on "simplicity", "maintainability",
> and "flexibility" - in my experience everything that doesn't follow these
> attributes is prone to errors, and hence very expensive. In that respect,
> that SuSE 7.0 install that I am working with on one of my machines, taking
> gigabytes of hard disk space, is just horrible. RedHat 7.0 isn't better at
> all, taking 700 MB or so (pretty default, too). *I* don't have the time
> and energy to tinker with that mess. I cannot believe that "normal" users
> (in contrast to geeks) will ever want to have that mess. This is somewhat
> backed up by what I currently use:

A clean LFS build (with the kernel source tree unpacked in
/usr/src/linux) is just under 200MB, that includes all development stuff
(or aka full LFS build :)

-
Jesse Tie Ten Quee - highos at highos dot com

-- 
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message




More information about the alfs-discuss mailing list