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

DJ Lucas dj at linuxfromscratch.org
Tue Feb 26 23:19:22 PST 2008


Gerard Beekmans wrote:

> I'm still at the office so I'll elaborate on this later, but to keep the 
> momentum going I can at least summarize my thoughts. They are not 
> finished concrete thoughts yet, just possibilities. They aren't even 
> viable yet with our current resources. Call them pipe dreams for now, 
> but that's how LFS once started - a pipe dream. With determination and a 
> clear plan they *can* become reality if everybody rallies behind it and 
> help out.

Judging by the lack of responses, it definitely needs to be clarified. 
I really need a painted picture here, because the one I had earlier was 
pretty grave.  See below...

> 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.
> 
> LFS in itself is a great exercise. Without parts of BLFS that end result 
> isn't very usable for a system that you actually plan to use on a daily 
> basis; server or workstation wise.
> 

Agreed.

> Without a better ALFS integration, people are going to find themselves 
> unable to use LFS in production on more than one computer. I could not 
> see myself running vanilla LFS on the servers I maintain at work. One is 
> doable but not even full time when you have other duties. When you end 
> up with a dozen or more systems, you either get ALFS working, or you 
> give up and go back to a distribution.
> 
> 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.
> 

Again agreed, though you make it sound as if to 'get ALFS working' is a 
difficult task, and it's just not anymore.

> What if ALFS became the main way to do an LFS system? 

Ouch.  That's a pretty tough pill to swallow, but it is inevitable.  My 
concern:  We'll have each other's build 'recipes' tailored for a 
specific end, just floating around in our ~/public_html/.  At that 
point, what makes us different than gentoo or sourcemage?

> You might argue 
> the fact that it takes away from the LFS methodologies. There is great 
> benefit to be had from doing it all manually. But let's be honest - the 
> majority of the book is running configure, make, make install. Does that 
> really provide much educational value? It's not like you can actually 
> read the output fly by on modern machines. In years past you could 
> sometimes read along and get an idea of what it was doing. Not so much 
> anymore. And not really important unless you're a programmer too and 
> have an interest in knowing those details.
> 
> The book can still provide all the educational value it does today. But 
> concentrate less on how to run a configure script. It's far more 
> valuable to know how Glibc works internally, and how it interacts with 
> every part of the system and what it provides beyond just a C library, 
> than how a configure script figures out where "gawk" lives.

Very interesting point.  I'd have disagreed in the past though.  Who 
still remembers the reboot in Chapter 7? There was no copy and paste 
back then and that's where I learned a ton about fixing my mistakes. 
Due entirely to my LFS/BLFS work,
'./configure --prefix=/usr && make && make install' will forever be a 
thoughtless flicking and flopping of fingers. :-) Now with today's book, 
everyone does CnP, so if the ideas in the rest of this message are 
implemented properly, I guess we don't even loose finger memory, and a 
lot could be gained.  I like the ideas, but the presentation of the book 
text is going to be so much more important if the users aren't forced to 
read it in order to get to the final result owing to ALFS.

Maybe I'm just paranoid.  I mean, I really don't want to overshadow the 
good points (below) of this thread by my vision, but I've got to throw 
it out there so that we don't become just another distro.  I wonder if 
anyone else had the same vision?  The one I had was not that much 
different than an installation of Windows XP, except it's on a text 
console, with it's endless loop of messages about how much better it is 
than previous versions of Windows. Those messages replaced by the text 
of the LFS book, and all the while, jhalfs is just chugging along in the 
background.

"jhalfs will complete in 4 hours and 26 minutes" it says.  Of course 
that might be closer to 12 hours, or maybe only 26 minutes.  ;-)  OK, 
yeah, that's pushing it, SBUs are way better an estimate than any of 
Microsoft's best guesses.  But seriously, that's just not anything even 
close to LFS.  Presentation of the book's text and *interaction* *with*, 
rather than full automation of the ALFS tool will have to be the main 
focus for a while.  Can the semi-automated way be done where it actually 
requires that you read the book?

> 
> The actual installation process is the boring part of setting up LFS. 
> After so many packages you lose focus and just wait for it to do its 
> thing. We're better off talking about what exactly this package is going 
> to be used for during the installation (automated installation or 
> otherwise). You have to wait anyways. Use the time constructive and 
> spend less time typing commands you already know.
> 
> Take Glibc as an example. Throughout the book we learn a bit about it, 
> but it's very limited. I am not suggesting providing the manual or info 
> pages from each package in the book, but we can definitely expand on 
> what's there. Sometimes a mini-tutorial style explanation could be 
> beneficial for some packages.
> 
> Take Perl as another example. Unless you already know what Perl is, you 
> wouldn't be much wiser by reading the Perl installation page in Chapter 
> 6. The most you get out of it is that it's some kind of programming 
> language (though seeing it's called the Report Language you may not even 
> clue in to the fact).
> 
> 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.
> 
> 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.

Was still that way when I started, and that was in the 2.x books.  2.2 
comes to mind but I have no idea what my first LFS was.

> 
> 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.
> 
> 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.
> 
> I'll leave it at that. Some food for thought where I believe we must 
> improve in order to move forward.
> 
> Gerard

While I do agree for the most part with everything you've said, I still 
have a big hesitation towards automating anything for fear that we will 
loose sight of the original HOW-TO goal.

-- DJ Lucas




More information about the lfs-dev mailing list