[lfs-dev] kbd

Qrux qrux.qed at gmail.com
Fri May 18 02:22:22 PDT 2012


On May 17, 2012, at 7:06 PM, Bruce Dubbs wrote:

> Since you are using Applemail, I think the problem is that it is using \r for 
> newlines instead of \n.  I see your mail wrapped, but when replying, it doesn't 
> wrap automatically.  It's easy enough fo rme to to edit->rewrap though.

That's a pre-Darwin Mac thing.  Mail inserts no \r's or \n's.
I'll insert some manually for now.

It expects that the receiving end can wrap if necessary.
This is a known non-feature in Mac OS X Mail (and some other
Mac OS X mail clients).  I don't have any ideas off the top
of my head.  Happy to hear advice.

BTW, which mail client(s) are folks using that don't wrap
automatically?

>> I'm asking if kbd serves a useful purpose.
> 
> Short answer: yes.
> 
> Longer answer: International keyboards need it and there are some useful 
> functions for US keyboards.

@Markku...I meant no offense.  I've always just assumed that
devs work on the console in English, with a US keyboard layout.
A lot of devs have to do that, since i18n isn't always a top
prio for bleeding edge stuff (e.g., Xen).  I just figured devs
would choose the path of fewest dependencies, especially for
something as infrequently used as the console, and when you
have the required language proficiencies (which obviously
you do).

>> This doesn't answer why LFS includes kbd.
> 
> Because Xorg isn't needed on all systems and some don't have the needed HW.

I think you're saying that there are some keyboards that generate
keycodes that make their HW unusable without kbd.  I didn't realize
that there were such keyboards; i.e., ones that would refuse to
generate standard US QWERTY keycodes if one opted to use the US
layout.

>> That is an artifact of (bad) product design.
> 
> Yea.  Let's redesign all the non-us keybords in the world.

Hardly my point.  I'm asking, like in Markku's case, if he can take
his Finnish keyboard and use it in US QWERTY layout to output the US
layout keys?  If so, why not just use it that way ON THE CONSOLE, and
simply wait until you're in X to get i18n in xterm (or whatever)?

Also...I'm not saying non-US keyboards are bad.  I'm saying that I've
been to Asia, and I've bought keyboards while I was there.  Those
keyboards can generates standard QWERTY keycodes that correspond
with a standard US keyboard, regardless of what's printed on the key
cap.  I figured that's how the devs would use the console.  In fact,
I know several Asian devs that couldn't care less about seeing CKJV
on the console, and use their keyboards--while ON THE CONSOLE--as
a US keyboard.

I'm not sure why it attracts so much ire to ask this question in the
context of LFS, which is quite a bit leaner than the commercial distro
these Asian devs were using.  Since everyone here appears to speak
English quite well (certainly far and away above the bar needed for
using a US-layout/English console), I just assumed they also wouldn't
care.

Obviously other languages need custom keyboards.  I was just surprised
that there are folks who want THE CONSOLE internationalized.
I'm used to folks who deal with i18n on the "client side".  I also
assume this is how most people use their LFS box--either as an SSH
server or run X.  I simply don't think many people run a Linux box
and work mostly from the console.  I suppose all the noise means I
might be mistaken on this (or a related) assumption.

But, let's not make it a crime to clarify.  If Ken would rather assert
that I'm not "new" to the community, then to the extent that his
assertion is valid I'd say that I see a lot of GroupThink(TM) in LFS.
Most is probably good.  But there are often ruffled feathers when
long-held assumptions from time immemorial are questioned.  I figure
decisions about LFS aren't usually proofs.  It stands to reason, then
that those decisions can be questioned.

	Q




More information about the lfs-dev mailing list