What next? [Was: Re: LiveCD or No LiveCD?]
TheOldFellow
theoldfellow at gmail.com
Wed Feb 27 00:07:36 MST 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