Laurent HOAREAU wrote:
> Jeremy Huntwork a écrit :
>
>> Jeremy Huntwork wrote:
>>
>>
>>> * Does the community still want the LiveCD project?
>>>
> (Consider that a
>
>>> couple of the arguments above imply that the LFS
>>>
> LiveCD by its nature is
>
>>> degrading the quality of LFS)
>>>
>>> * If so, is the community prepared to lend help in
>>>
> keeping it alive?
>
>>>
>>>
>> Thank you all for your comments and consideration. I
>>
> ran through the
>
>> lists quickly this morning and came up with the
>>
> following:
>
>> 20 people expressed their appreciation for the CD,
>>
> more than half voting
>
>> to keep the project around. Also, several either
>>
> offered to contribute
>
>> or suggested ways in which the project may be
>>
> improved.
>
>> 2 people explicitly voted to drop the project.
>>
>> I could let this thread continue for some more time,
>>
> but I get the
>
>> impression that the ratio of votes will continue
>>
> approximately the same.
>
>> So the real question now becomes, where do we go
>>
> from here? There have
>
>> been a few suggestions put forward as to what may
>>
> help future
>
>> development and what will alleviate the original
>>
> concerns brought up. I
>
>> will try to lay down what I recall:
>>
>> * Go back to the drawing board, so to speak. Start a
>>
> new CD from scratch
>
>> that is minimal (and minimal means minimal, not just
>>
> 'without X') and
>
>> re-define core concepts that the CD will adhere
>>
> closely to. (For
>
>> example, as proof of the soundness of LFS, the CD
>>
> should strictly adhere
>
>> to LFS. If we adopt this one aspect, we should also
>>
> be able to make use
>
>> of ALFS development to produce the CD, instead of
>>
> maintaining a full set
>
>> of separate scripts.)
>>
>>
> Hum, if you choose to build the cd without X, we loose
> the advantage of
> multi windows (impossible then to see the LFS book and
> the terminal used
> to build LFS in the same time for example). In a world
> where most people
> come from graphical environment, it could be a
> problem... But the use of
> alfs could reduce the problem...
>
>> * As has been suggested from a long time ago, make
>>
> use of package
>
>> management in the build process, especially for BLFS
>>
> packages. This
>
>> would allow at least two benefits: an easier
>>
> development process, and
>
>> greater extensibility/customization.
>>
>>
> Very good idea, but have you enough time to make that.
> I'm very
> interesting by this idea and if you want help in this
> way, I'm could be
> ok...
>
>> * Add an LFS-style document to the project that
>>
> teaches how to create a
>
>> LiveCD from scratch.
>>
>> * Devise methods for users to more easily provide
>>
> feedback and make it
>
>> easier to contribute as a whole.
>>
>> What are your thoughts on the above? And are there
>>
> any other
>
>> suggestions, either new ones or ones that I missed?
>>
>> --
>> JH
>>
>>
>
>
>
>
>
>
> _____________________________________________________________________________
> Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
> http://mail.yahoo.fr
>
>
Multiple 'windows' don't require X, personally i logon to 2 or 3 virtual
terminals, carry out the lfs build work in terminal 1 and have a copy of
the book open via lynx in terminal 2, then i can simply select with the
mouse to highlight and right click in VT1 to paste. To open another
session press ALT+F# where # is a number, then you can rattle between
them in much the same way as you'd use gui desktop windows.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
