What next? [Was: Re: LiveCD or No LiveCD?]

TheOldFellow theoldfellow at gmail.com
Tue Feb 26 23:07:36 PST 2008


On Tue, 26 Feb 2008 15:00:01 -0700
Gerard Beekmans <gerard at linuxfromscratch.org> wrote:

<snip>
> The premise is simple actually. It's not a paradigm shift. We've all 
> talked about it over and over again, rehashed it to death why it can't 
> be done: combine our various projects.
<snip>

Great idea, makes best use of available person-power too.  Are YOU going
to ride shotgun on it?  This is why we broke up in the first place: one
camp wanted apps, the other a fancy toolchain.  If building LFS isn't a
self-justifying hobby - which I admit it was for me - then the apps
have to be there somehow, or the toolchain's not worth getting right.

> Package management has been brought up by various people. It's a simple 
> requirement if you plan to use the system for a while, besides just 
> learning. ALFS would be able to tackle that problem as well.

and without PM the system isn't maintainable for production use.  I
just can't avoid the thought that a chosen PM must be mandatory if...

> What if ALFS became the main way to do an LFS system?
<snip>
 
> The book can still provide all the educational value it does today. But 
> concentrate less on how to run a configure script.<snip>

This is what makes it an education project and not a simple distro.  I
don't have a problem with it becoming a distro (Your Distro!) provided
the educational stuff is retained.
 
<snip>
> We could provide a lot more useful information for just about every 
> package we currently install. It would be more useful than the list of 
> short descriptions. For those, if ALFS came into play, you can just look 
> up the man pages when you obtain a list of installed files. The space 
> used in the book can be better spent.
> 
> The book will essentially become less of an installation script 
> interspersed with some text and more of an actual book teaching 
> concepts, decisions, justifications, etc that make for a working Linux 
> system.

I wrote something like a commentary on LFS once, called 'The LFS
Reference' that goes a little way towards this.  It's probably in the
archives somewhere.

> As a closing remark - we offer this while LFS teaching endeavor with a 
> set of tools to get the job done that target a variety of people. A 
> bootable CD that can be used on a system without Linux pre-installed 
> would be one of those tools (aka what started this thread). Whether it's 
> a LiveCD complete with an Xorg system or not is immaterial. The basic 
> idea is that we have a boot CD that can double as a Rescue CD as well 
> when we mess up Grub. Why not use an LFS CD to repair/install an LFS 
> system rather than use somebody else's distribution CD to repair/install 
> our own LFS.
> 
> LFS started out as more of an LFS+BLFS combined (read the 1.x series). 
> Then it was decided to split the core of LFS from the optional parts as 
> the optional parts are too user specific. Not everybody likes a chosen 
> email program, web browser, etc.

There is a world of difference between mandating an MUA and mandating a
PM.  One is infrastructure, the other is just the app I happen to like
today.

> I don't know that we want to merge LFS and BLFS in its entirety but 
> maybe ALFS can become the "official" glue between the two. If nothing 
> else, to take away the manual burden of trying to install all the needed 
> packages.

It the PM that will be the glue between all three projects, and even
CLFS if they want to play with us.
 
> I groan when it comes time to install something like KDE and Gnome. 
> That's a week project to get it all just right unless you can spend 
> hours upon hours for a few days on it. Shouldn't have to be.

Fluxbox :)  Unfortunately many nice apps want Groan-vfs these days and
D-Bus and Hal, and...

> I'll leave it at that. Some food for thought where I believe we must 
> improve in order to move forward.

Good to have your brain back  :)

Without a new target, LFS is dead.

> Gerard


Richard.




More information about the lfs-dev mailing list