A. No, not at all. The projects have very different goals. The primary goal of LFS is to teach. The goals of DIY Linux are clearly documented on the Project Goals and Guidelines page. But yes, there is a fair amount of overlap as both projects provide a recipe to build a GNU/Linux system from source.
Q 2. You (Greg Schafer) used to work on LFS, right? What happened?
A. Yes. Unfortunately, some ungrateful folks there didn't appreciate the work I was doing. It seems the LFS IRC channels breed some very anti-social behavior which surfaces on the mailing lists from time to time. But it was time for me to move on anyway.
Q 3. So are you competing with LFS or what?
A. No, certainly not. As per Q1, we have very different goals. LFS is focused on a "book" (well, an enormous howto really) and aims to teach by taking the user on a "walk through" in an interactive shell environment. DIY Linux is focused on:
- A Robust Build Method (Bootstrapability)
- Technical Correctness
- Testing
- Document Centric Automation
- Package Management
Q 4. How does the DIY Linux build differ from LFS?
A. There are too many differences to list here. But it's worth noting we have improved upon and fixed many issues prevalent in the current LFS build. We continue to monitor the LFS build and record our views on what we perceive as technical errors or inconsistencies as we see fit. Please keep in mind that DIY Linux does some things differently because of a) Package Management and b) our focus on scripting means we don't have to be concerned with users making typos on the interactive shell command line. (Update: September 2006 - I'm pleased to report that many improvements developed here are now finding there way back into LFS).
Q 5. Is it acceptable to you if the LFS project (or anyone else for that matter) copies, borrows, steals or adopts some of your ideas and work?
A. Yes, of course. This is the open source world after all. But please do the ethical thing and give proper attribution.
Q 6. What's this `ICA' thing I've seen you mention in various places?
A. It stands for "Iterative Comparison Analysis" and is essentially about reproducibility. It's really just a simple, but time consuming, technique to measure the effectiveness of the 2 phase build method we use to bootstrap a Linux system. Over time, it has proved to be a good way of finding bugs in the overall build method. Check out the gsbuild scripts to see how it works.
