On Tuesday 02 June 2009, Christian Perrier wrote:
> One of the release goals of Debian Installer for squeeze is dropping
> the use of console-data keyboard mappings, to replace them by
> console-setup [1].
Here are (finally) the results of my tests. Sorry for the delay; I will
explain the reason for that in a separate mail after people have had a
chance to read this.
I still haven't tested c-s in depth: all issues in this mail were "found"
in about 15 minutes of testing and by doing some general checks.
My conclusion is that a switch from kbd-chooser to c-s-udeb *in its
current form* would mean serious a serious reduction of the quality of
the installer. The issues reduce the technical quality, functionality
*and* usability of the installer.
As a user I'll take kbd-chooser over c-s in its current form any day.
> The main rationale for this is that console keyboard mappings provided
> with console-setup are the same than X keyboard mappings.
Please note that I am not against c-s. I fully accept that sharing the
X.Org keymap definitions is better than having separate console keymaps.
My only problem is with the way things are currently implemented *for the
installer*, although some comments also affect the regular package.
IMO most if not all of the issues are fixable, but that will require a
serious effort.
I am just reporting the issues here. IMO it's up to the people who've been
pushing c-s for D-I to follow up on them: to discuss them with the
package maintainer (AFAIK he's not subscribed) and to somehow get them
fixed.
I'll try to structure the issues in a logical way, but it's impossible to
prevent that this will be a long and complex mail. Please respect the
fact that will have taken me multiple hours to write it.
All data is based on Christian's test mini.iso; comparisons were done
against a daily built mini.iso from the same date.
TECHNICAL ISSUES
================
1. Package size - impact on initrd size and memory usage
--------------------------------------------------------
In general I think it is necessary to be very alert on this, especially
for udebs that are included in initrds.
.iso size free mem after boot
mini.iso: 8,916,992B 230,884kB
mini-cs-i386.iso 9,267,200B 229,608kB
Christian did forget to drop console-keymaps-at from his iso, so the
actual numbers should be a bit lower. If I correct for that, I get:
- a ~250Kb (2.8%) initrd size increase
- an extra memory usage of just under 1Mb (!)
But do remember that translations for c-s are far from complete, so both
initrd size and memory loss are quite likely to end up bigger than that!
Can someone please explain why we're bothering to switch away from
dhcp3-client if they're willing to accept such a crazy increase?
Can someone also please explain what major functionality gains c-s has
that would justify such a huge cost?
Also, any chance to ever produce installation floppies again (admittedly
already unlikely) has gone right out of the window here.
But the main problem here is that most of the increase is IMO not needed.
It is largely a result of suboptimal implementation and inclusion of
functionality that does not belong in an installation system. Various
suggestions that will reduce the size of c-s in D-I can be found below.
2. The totally insane /usr/share/c-s-mini/c-s.config file
---------------------------------------------------------
With no disrespect intended to Anton or Samuel, but reading strings and
translations from a sourced script is very simply not an acceptable
technical solution. It violates the design principles of (c)debconf and
will be a maintenance nightmare for the future.
It also contributes significantly to the size problem as all original
strings (or keys) are endlessly duplicated in the file, which they would
not be in the debconf database.
I also don't see why the strings cannot be in the debconf database. For
example localechooser and choose-mirror also has a number of dialogs that
are built dynamically and they all use standard debconf functionality.
I have not looked deeply, but I don't see why c-s could not do this in
debconf, using for example Choices-C, variables and 'register'.
The current solution seems to me to be a case of "we didn't know how to do
it correctly, so we just took an easy way out". But maybe Samuel can
explain the actual issues in some detail.
3. Offers keymaps that not available?
-------------------------------------
In expert mode I see keyboard models for Amiga, Sun, Macintosh etc. But
only the c-s-pc-ekmap udeb is included. How is that supposed to work?
4. Other technical issues
-------------------------
In general I feel that the decision to keep the c-s udeb identical in
functionality to the regular c-s package is a bad choice: the installer
has different requirements than an installed system.
Separating that properly would also allow the removal of the D-I menu
description template from the regular package.
* Does not respect selected choices: on <Go Back> from "layout" to
"origin" the default origin is selected, not the choice I previously
selected.
* Has the implementation been checked for idempotency?
* Are previous choices respected when c-s is run a second time?
* Coding style: scripts are for example not tab-indented, again wasting
memory.
* Huge (copyright) comments should be stripped out of scripts.
* A script that gets sourced should not have a shebang.
* A coordinated effort should be made at some point to get c-s tested on
arches other than x86.
* The number of options in some dialogs make c-s COMPLETELY unusable with
the text frontend.
FUNCTIONALITY ISSUES
====================
1. Preseeding
-------------
Does not work at all AFAICT.
Has preseeding been tested or even given any thought at all? I hope you'll
agree that it is part of the core functionality of the installer...
Currently a user can configure his keyboard with two simple choices:
d-i console-keymaps-at/keymap select us
#d-i console-keymaps-usb/keymap select mac-usb-us
And in practice only the first of those is ever needed.
IMO c-s should be smart enough to skip the "origin" question if a layout
is provided (but of course only if the "seen" flag is set; otherwise it
should ideally default to the corresponding origin).
2. Keyboard detection
---------------------
Does c-s detect if a keyboard is connected at all and what type it is?
Does it change defaults based on that? Or does it just leave everything to
the user? The last could be considered a regression.
I'm not really sure how relevant this is anymore given that kernel
behavior changed and all keyboards are technically managed as PC.
But wouldn't it be nice if the correct keyboard layout could be
autodetected? AFAIK a lot of keyboards, especially USB and maybe also SUN
keyboards do advertise their layout.
3. Other functional issues
-------------------------
* Should skip keyboard configuration for serial console and UML installs
(listed on status wiki page).
* In expert mode kbd-chooser also offers an option to skip kbd config.
* Compose key does not work in D-I (already reported as bug); it fails
both in debconf and the debug shells, but in slightly different ways.
In debconf it seems like it is recognized, but I don't get a composed
character; in the shell it does not seem to work at all.
USABILITY ISSUES
================
Although a lot of the issues above are important and some should IMO even
be blocking a switch to c-s, this is where the real pain is.
Note again that most of my comments are limited to the D-I context,
although some are general and also affect the regular package.
Dialogs are far from intuitive. In expert mode I completely and utterly
lost my way during c-s and even during normal installation there are
simply way too many keymaps to choose from.
What happened to the design principle of D-I that we aim for a solid but
*basic* system installation and that if users want bells and whistles
they should configure them after system installation?
Note that IMO a component has to be usable in *both* normal and expert
mode. Too many users choose expert mode (even if they don't need it and
should really be running a default install) that we can just throw
anything at them.
Please remember that most users will only see these dialogs *once*. We
should aim (and always have) to make it possible for users to get it
right the first time. In an installed system you can go back and try
something else; in the installer you should not have to!
Especially as the first time a user will actually use the keyboard is when
he's prompted for a host name, or even when asked to enter a user name.
1. Number of questions
----------------------
kbd-chooser has exactly *two* questions, only one of which is shown during
normal installs and that has a fairly intuitive selection; the expert
mode question is the very elementary choice between kbd architectures
with only a few choices.
c-s has a staggering *ten* questions. IMNSHO most of these questions have
absolutely NO business being asked in D-I.
Let's have a look (I hope I counted correctly):
1) keyboard model, ~150 options ... WTF?
2) keyboard origin, ~90 options
3) keyboard layout
4) altgr key
5) compose key
6) encoding (shouldn't that just take what was selected in localechooser?)
7) character set (can't we just set a default based on selected language?)
8) console font (bell)
9) font size (whistle)
10) virtual consoles (this should IMO not even be a debconf question, but
just be configurable through the config file)
Hey, look there, we can drop at least 5 whole questions *and all their
strings* for the installer! That will help with the size :-)
Note that you could opt to keep the bare templates as "internal, can be
preseeded" templates without strings. That would be a way to offer
flexibility for experts for automated installs without any of the cost.
2. Way too many obscure choices resulting only to confuse users
---------------------------------------------------------------
kbd-chooser has, for x86, a single list of ~45 keyboard layouts, a mix of
"origin" and "layout". IIRC that is a careful selection (thanks Christian)
out of the total number available in console-data.
And it seems to be more than enough as I cannot remember ever seeing any
report that said something was missing.
I realize that for a graphical environment (or maybe desktop use) it is
more important for users to select the exact correct keymap than purely
for console use.
But do we really need to offer the total range from 150 models, 90 origins
and multiple layouts within that *during installation*?
Again, reducing this to more sane proportions would also help solve the
size problem.
That size of the lists causes a problem in itselves. Take the model
question (first question in expert mode).
Pretend you've never done a Debian install before and that you're an
average user, not a hacker.
The list is displayed and I see there are loads of choices. You browse up
and down out of curiosity and because you want to select the right one,
but see nothing that exactly corresponds to your keyboard. So you decide
to choose the default. Ehhhhh, what was the default again? Oops.
This is partly a problem of debconf and is maybe a bit less of a problem
in the graphical installer than with the newt frontend (because you can
scroll through the list with the mouse without changing the current
selection), but it *is* something that needs to be allowed for.
IMO we should just only offer the generic models (plus arch-specific
models). We can always mention in the dialog (and the manual) that a more
detailed selection is possible post-installation.
But even if we do want to offer the full list, this question absolutely
needs to be split into various categories, for example by manufacturer.
Not simple though as some manufacturers are really "to small" for that.
Same goes for the origin question. Do we really need to support all of
them (Maldives has a special layout? Crazy.)?
3. Questions are asked in such a way that they invite *wrong* answers
---------------------------------------------------------------------
Note that some of the problems I mention here are really upstream issues
and can probably not be solved. However, they do affect our usability and
we need at least to make sure our interface is clear for users.
In the next bit I'm going to use Dutch as an example as it is a bit
special: most computers sold in NL have a keyboard with a plain US
keymap, often with only a Euro key added on '5' or 'E'.
Here is how kbd-chooser asks which layout to use:
Keymap to use:
American English <--- default
Brazilian (ABNT2 layout)
Brazilian (EUA layout)
Canadian French
Canadian Multilingual
Dutch
This is very consistent and clear. Most people will know that real Dutch
keyboards are weird and thus accept the default.
Now let's try c-s (ignoring the model question):
Origin or the keyboard:
Braille (WTF is that doing in this list and how is it an "origin"?)
Brazil
Canada
Netherlands
USA <--- default
United Kingdom
Uh, what? Origin of the keyboard? Well, I bought the computer at the local
computer store, so in the Netherlands. Oops, wrong choice.
The main problem is that country names are used instead of adjectives.
Compare:
* Do you use a Dutch or an English American keyboard layout?
* Is your keyboard from the Netherlands or the USA?
Which is more likely to be answered correctly?
And which idiot decided to use "USA" in this list? First of all it should
be "U.S.A.", but even then it is inconsistent as hell. Why not
just "United States of America"?
If the country names are unavoidable then we need a *lot* better
description for this question than "Origin of the keyboard"!
And it would really be nice if the country names were at least consistent
with localechooser...
If "Netherlands" is selected I get the layout question with:
Netherlands
Netherlands - Macintosh
Netherlands - Standard
Netherlands - Sun dead keys
OK, the last 3 should probably not be there, but "Netherlands"
and "Netherlands - standard"? Is "Netherlands" not standard enough?
Possibly "Standard" should be "Sun Standard" instead?
And why the repetition in this dialog? Couldn't the origin be mentioned in
the description with only the variants in the choices list?
4. The AltGr and Compose dialogs
--------------------------------
I'd very much prefer if these questions could be avoided altogether in
D-I. It will be completely unclear to most users what they mean.
We should just make sure that correct defaults are selected based on the
selected keyboard layout and possibly the country selected in
localechooser (I'd really like it if we could set Right Alt to compose by
default if country is NL and keymap is us).
5. Character set dialog
-----------------------
Typo in "western Europe and Turkic languages": s/Turkic/Turkish/
The # versus . indicators in the character set dialog are very
non-intuitive. The dialog should really _only_ mark the choices that
result in lang reduction (and preferably use the TAB feature in D-I).
The # indicators are redundant.
Some of the choices are rather long and likely to cause problems for
translators.
Well, that's it. Kind of weird to have to spend most of the day to write
down what was found in 15 minutes of testing...
Cheers,
FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.