On Tue, 26 Feb 2008 15:00:01 -0700 Gerard Beekmans <[EMAIL PROTECTED]> 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. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
