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 . 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
Description: This is a digitally signed message part.