Ok let's start
bdumm at bobby.bcpub.com
Fri Jun 23 12:16:29 PDT 2000
Just got back from yapc, had to leave early, but I
got to see larry talk and met a few folks that author
alot of books I read, and met dick hardt, talked about
visual perl. Sorry for the OT content, just had a good
time, wanted to share it....
> >you need Glibc to compile programs dynamically. CDROM system has no
> >Glibc so the only way to get your root file system to contain Glibc
> >files is to make $LFSby using root - chroot.
> Well, personally I would like the choice on whether or not you want to
> copy over the static binaries. Once I have the scripts up and running,
> I don't want to have the system slow down because it is loading
> programs from cdrom. I'd rather copy all of the static binaries to the
> partition first (do something for 10 minutes while this is going on)
> and then start the scripts so that my system is a bit more responsive.
> And just so that there is no confusion, I would recompile those
> binaries and get rid of the static ones after everything is finished.
well I was going to save this for the "next idea" but here goes...
We seperate "choice" from "process". In doing so we can build
a "profile" on what the person wants, optimizations, copying static
binaries, different "methods"(interactive, semi, auto, etc.), and I
am sure there are plenty others. I know I got a few which I'll save
at the moment cause if "choice" equals a "profile" we can take
the bits of scripts/howtos, etc. that we already have, to get the
"process" of ALFS working.
I think that we should decide on a couple basic "profiles" to get
the "process" running and start building a framework to allow
that "choice" in ALFS.
I know for instance that I want to eventually use the network for
installations with ALFS. Most of our network is setup to pull everything
off an archive server, and cdroms don't do much for me. But I
understand their purpose. If you think about it quite a few networks
run in a way similiar to ours, not everyone uses cds....
Imagine building say several xml "profiles" and putting it on a
server with ALFS. Then I could go to a machine, choose a profile,
have it d/l the profile and parse it, and away I go.... Installations
across the net would be alot of fun. I can d/l everything in the time
it takes to compile a full LFS. And it might be interesting from
the remote perspective. Imagine someone who has a bad net
connection using some sort of interface to interact with an ALFS
at a place with a good net connection. Might be a hit with
I'll stop rambling, but I still believe that we should seperate choice
from process because choice is going to be what drives ALFS IMHO.
We though need a reliable dependable "process" that integrates the
book, ftp archive, cdrom, whatever else we come up with and someway
to make sure it all works....
Mail archive: http://www.pcrdallas.com/mail-archives/alfs-discuss
IRC access: server: irc.linuxfromscratch.org port: 6667 channel: #LFS
Unsubscribe: email alfs-discuss-request at linuxfromscratch.org and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)
More information about the alfs-discuss