On May 17, 2012, at 5:25 PM, Ken Moffat wrote:
> On Thu, May 17, 2012 at 04:37:24PM -0700, Qrux wrote:
>>
>> Console fonts (and asking people to build FB support in kernels) seem like a
>> waste of effort when most people probably spend 99% of their time SSH'ed in
>> to their LFS box or running X (both BLFS considerations).
>>
> As well as adding better support for some glyphs, different console
> fonts can be different sizes: larger, and therefore hopefully more
> legible if your eyesight is not 100%, or smaller to allow more text
> on a screen.
[Hard to trim? I don't understand. Your mail client doesn't word-wrap?
I'll try to be mindful, and insert a bunch of '\n's all over the place.]
I'm trying to reduce the back and forth.
That's why I ask several questions at a time.
The original question doesn't get answered.
That's why I keep asking.
I'm asking if kbd serves a useful purpose.
You're saying I can make the font bigger.
You also say I should have a FB kernel if I use X.
So...1) How is X related to this discussion about LFS?
And, 2) "Bigger fonts and better glyphs" at the expense of higher complexity
seems
to warrant a "Hey--sanity check--is this machinery necessary?"
That's why I keep asking if it provides anything necessary.
> Anyone running Xorg on ati (radeon), intel, or the
> nouveau-supported graphics cards, with a modern kernel, should be
> using KMS and therefore gets a framebuffer.
This doesn't answer why LFS includes kbd.
Can you see how this type of answer ("If you use X, you get a FB") doesn't
answer the question
("Why does LFS need kbd?")? Can you see how it raises other questions?
I realize that may not have been the topic of the resizecons thread.
But I don't think asking the question should provoke so much ire (or confusion).
It seems unnecessary that LFS assumes (or asks) the user to build a kernel with
FB support.
>> Does the vanilla kernel & userland require kbd to exist in order to use the
>> console? If not, why does it exist as a part of LFS? Are there people with
>> keyboards such that the default kernel driver (i.e., without kdb) cannot
>> interpret certain keypresses?
>>
> If you had a French or German keyboard, the results from pressing
> the keys would be very different from what is shown on the key caps.
That is an artifact of (bad) product design.
Keyboards sold for use with other languages that have characters outside of the
English alphabet
are sold with the presumption about the OS is going to "display" the character
that's pressed.
That's not something wrong with the kernel.
That's an issue for keyboard manufacturers to deal with.
You could try to solve it in LFS...
But, is it necessary to solve glyph issues at the console?
Can you tell me which are the critical sysadmin tasks that use Cyrillic,
accented, or ideographic
characters--i.e.; can you explain why non-ASCII glyphs are necessary on the
console? Are there lots
of people with /dev/sd<thorn> and eth<eth>0 devices?
>> Even if so...Why does that even matter? Login as root, and pick passwords
>> based on some intersection between your keyboard and the default set of
>> recognized (ASCII) keycodes. You only need enough functionality at the
>> console to get userland network connectivity or X.
>>
>> Is kbd necessary even to drive a standard QWERTY keyboard with a vanilla
>> kernel/userland?
>>
>> Q
>>
> I have to say that you are good at asking streams of questions, but
> not at taking note of replies that don't suit you (e.g. you still
> reply with very-long lines which make it much harder to trim your
> replies).
Suitability implies purpose. The purpose of a reply, in general, is to answer
a question. In reply.
If it doesn't answer the question, then it's not suitable for that purpose.
It's not about personal
suitability. Please don't personalize it.
So...answers that don't answer the question don't suit me. Answers that do, do.
I respect it when you say I asked the wrong question earlier.
Can you afford me the same respect when I'm asking a related--but different
question?
Irrelevant "answers" are why I keep asking.
> In general, you give the impression of being someone who has only
> recently arrived here
I'm sure compared to many, I have "recently arrived here"
> but who thinks that the book should match his
> own prejudices for how little should be built.
No. I'm trying to reconcile all the answers I've gotten about what determines
what should be in LFS.
I have also sought inclusion of bits, but was told that it was unnecessary.
I'm trying to understand
if these decisions come from consistent reasoning, or if they are...somewhat
arbitrary.
> This thread is not about removing the kbd package from LFS - start
> your own thread(s) for the packages you don't want to build, or
> better still, just drop them from your own builds.
Ok--Title changed...
...and, I do drop things I don't use...
But, I'm hopeful we agree that that's different than the discussion about
whether
or not they need to be there in the first place.
Q
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
