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

Jeremy Huntwork jhuntwork at linuxfromscratch.org
Tue Feb 26 08:47:57 PST 2008

Alexander E. Patrakov wrote:
> Please subtract the number that want to use the LiveCD to cover LFS bugs, don't 
> realize the inherent incompatibility of LFS with 64-bit hosts (IMHO, the fact 
> that LFS doesn't mention it counts as a bug), or don't know how to apt-get 
> install build-essential.

How in the world am I supposed to do that? Do you know the skill-level 
of every individual that commented in every list? Even if I add your 
vote to bring the 'drop it party' up to 3 (I could also add mine in 
favor of keeping the project, which I don't need to) and I stick to only 
people whose skill level I know, the majority are still voting to keep 
the project.

As an aside, I fully disagree with your inflexible stance on who is 
'allowed' to use either LFS or the LiveCD, or whose opinion on either 
product counts. The prerequisites stated in LFS are _suggested 
guidelines_. Nowhere does it say that people that don't meet those 
prerequisites are not free to use LFS or the CD, or that their 
experience with it is invalid.

If someone who had just encountered a PC 2 weeks ago stumbled onto LFS, 
managed to work their way through it and came out the other end 
successful, I'd applaud them! Sure, they wouldn't have approached LFS 
the way it was intended, but if they learned something, the main goal 
has been reached. Obviously they are intelligent and determined enough, 
and very likely they will continue to learn and grow. Therefore, their 
opinion and feedback is just as valuable.

And think of the reasons why those guidelines exist in the first place! 
First and foremost, isn't it because we want the reader to be successful 
in their experience? After that objective, IMHO, comes the secondary 
purpose that we as developers can't be responsible for the experience of 
every person who decides to start down the LFS path. There is nothing 
that requires us to provide more support to those who should have read 
more first. Far better for you to ignore them then to make judgment 
calls on who is 'allowed' to use the product or express their opinion 
about it.

> Then we need a procedure to deal with feature requests ("reject outright" also 
> counts as a procedure). Also we need a procedure to determine what counts as a 
> feature request and what doesn't (e.g., what to do with net-firmware, 
> scsi-firmware and the numerous kernel patches and extra drivers for new hardware?)


> This is incompatible with the "strictly adhere to LFS" goal, because LFS has no 
> package management except "rebuild everything once a day". Note that I make no 
> statement about the relative merit of these two incompatible goals.

I suppose so. Although, the way I was perceiving it:

  * The configure and make arguments do not change so there is no 
difference in the binaries produced
  * The install arguments do not change so the binary locations are the same
  * All we really do is package up and log

Isn't it still adhering strictly enough to LFS to count? Granted, this 
may not meet what is truly considered package management in a distro 
sense, but it would still ease development, and help in allowing further 

>> * Add an LFS-style document to the project that teaches how to create a 
>> LiveCD from scratch.
> IMHO, this would line up with the rest of the project nicely, and doesn't 
> exclude actually providing some binary CD.

Yes, this is turning out to be a good suggestion, I believe.

>> * Devise methods for users to more easily provide feedback and make it 
>> easier to contribute as a whole.
> This also should include stating what kind of feedback is needed. So far, there 
> were only "please add this package" requests, borderline cases like "old laptops 
> with the OnTrack disk manager doen't see the partitions with libata" (solved by 
> adding kpartx) and a few bug reports.



More information about the lfs-dev mailing list