What next? [Was: Re: LiveCD or No LiveCD?]
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:
> 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.
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?
> 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.
> 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
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
> 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
> 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
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.
More information about the lfs-dev