Jeremy Huntwork wrote:
On Thu, Feb 09, 2006 at 10:50:44AM -0600, Bruce Dubbs wrote:
My only problem with LFS on the issue is that LFS traditionally has not
offered choices. That is, there is only "one true path" through the
book. This makes users who do not need or want UTF-8 proceed on their
own. IMO, this is not desireable.
And to further clarify, an LFS machine as it currently is does *not*
automatically use UTF-8. The changes to the LFS book are so that the
LFS system *can* use UTF-8 properly if a user requires it. IMO, this is
more important than some other packages that aren't really necessary,
and yet are (and have been) in the LFS book, such as vim and readline.
You may not need UTF-8, but that doesn't mean that the programs we
install in LFS shouldn't properly support this excellent means of
standardization.
I still haven't seen the additions quantified (did I miss it?). What is
the difference in size of the new UTF-8 LFS vs a previous by-the-book
build? Seeing those figures might help aversions to UTF-8.
--
JH
I'm a non english speaker so utf-8 support, is a very welcome, like J.H.
said, it's not that i *need* utf-8, i can live well enough with
[EMAIL PROTECTED], but having a lfs build support utf-8, is a good thing,
not only for me but to help making linux and lfs less of a iso8859-1*
thing and more of everybody thing, as we known support for some
languages in the current lfs book is not optimal, it's not that utf-8
will solve the issues, but it will help, as for the overhead added by
utf-8, i don't think it's for that reason utf-8 should not be included,
as a typical build of lfs, even with all the striping done, is not what
a consider very small, it's trimed, but not small, so it's not for size
that utf-8 should not be included, as for memory size, linux itself
needs more than 64mbs of ram, less than 256 in a decent desktop
environment is not very good (and yes, i could *crawl* a desktop
environment on a 166MMX with 16mbs of ram, i'm building lfs to primarily
be a desktop not a server, but even servers live better with more ram),
and by the looks of some comparisons on other threads the overhead of
utf-8 is not much, and can probably be lowered through better
optimizations.
So go for utf-8 support, even if it's not by default active, and for the
no-utf supporters, what about just divide the book if needed, on a per
package basis, for a build with and without utf-8 support?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
