LWN: Comments on "Debian opens a can of username worms"

Doesn't the GECOS field already cover some of this use case?

taladar — Mon, 23 Dec 2024 09:25:50 +0000

Optimistically you could consider the problem "solved" by Unicode two decades ago, pessimistically it isn't even fully there yet today (e.g. some popular database products still do or only recently switched to full UTF-8 encodings as the default and did not support anything outside the Unicode BMP in their previous default encoding).

I wouldn't call that "solved it many decades ago".

Doesn't the GECOS field already cover some of this use case?

zdzichu — Sun, 22 Dec 2024 13:55:39 +0000

> surprised when the British clerk managed to produce a proper ó for the birth certificate

I wouldn't be surprised, given the number of Polish people in the UK.

Doesn't the GECOS field already cover some of this use case?

NAR — Sun, 22 Dec 2024 12:26:53 +0000

One of the restrictions I set when we chose our children's name was to avoid accented characters - for the very same reason, to avoid possible problems during travel. For various reasons I lifted this restriction for our third child - of course he was the one born abroad :-) I was very (and pleasantly) surprised when the British clerk managed to produce a proper ó for the birth certificate - I think she saved us quite a headache.

we really expect children today to learn a 1950s (!) encoding

What they need to know is the English alphabet. And as English is the international language nowadays, we can expect them to learn this while they learn English. Besides, we're using lot of stuff "hardcoded" in the previous centuries, from the metric system to normal gauge, the Latin alphabet itself, etc. the list of characters in the original ASCII charset is just one of them.

Doesn't the GECOS field already cover some of this use case?

steffen780 — Sat, 21 Dec 2024 21:18:11 +0000

I used to have a non-ASCII character in my surname, an "ö". After spending many hours of travel mentally preparing for the possibility of a heavily armed but dumb border guard making trouble for me because the UK travel company's software supplier apparently didn't realise that travellers on international journeys might have non-ASCII names (turned the "ö" into like 5 random characters) I started booking tickets with "o" instead. I figured that the kind of ignoranus who wrote the ticketing software above wouldn't notice the missing dots - and anyone who does notice will understand my explanation why I gave a false name. And this wasn't in 1960, this was ca 2001 or later. Remember, this was with a travel company. Not a local bus company, these people did substantial international travel. In fact the brand was "Eurolines" - but they couldn't even handle German names.

Similarly, until 2010 or so I would not use äöüß in filenames. Ever. To this day I still only use my native languages properly for low-risk "user-only" files - so I might use it for a LibreOffice file or a video, but I would not use it for a login username, anything in /etc, and so on. I just don't want the extra hassle. But I'm fairly advanced with IT - how is a typical user supposed to know that some software still can't handle such things, many DECADES after the problem was partially solved with Unicode? Do we really expect children today to learn a 1950s (!) encoding just so they know what characters they can use in a username? Surely there's more useful things that can be taught instead. E.g. pretty much anything else ;)

That being said: I wouldn't hold my breath for non-ASCII login usernames to become reliably usable with the infamous "long tail" of software. But huge progress has been made, and I think it's important to keep going.

French people who believe É does not exist

marcH — Sat, 21 Dec 2024 18:00:48 +0000

> E.g. pressing the "2" key will do the same with our without caps lock, but shift will change that to a double quote or @ symbol or whatever.

With a France keyboard, it depends whether you use mac or Windows.

> I don't ever use windows, but I'd like to see if the "é" key does the same thing with shift as with caps lock, or something different.

On Windows it does the same thing. That's the problem and one of the reasons why É is so hard to get on Windows.

> My (possibly optimistic) guess is that caps lock would give you the Élusive character :-P

Instead of wrongly guessing, you could just search the internet or open one of the references already mentioned above.

Dead keys

rschroev — Sat, 21 Dec 2024 16:42:51 +0000

Exactly. Each dead key on a typewriter has two accents: one when you press the key normally, another one when you press the key in combination with shift.

French people who believe É does not exist

Wol — Sat, 21 Dec 2024 15:10:36 +0000

And iirc typewriters didn't have caps-lock, they had shift-lock. (Ie they mechanically locked the shift key down, hence the name.)

I seem to remember one computer layout that had both, certainly shift-lock can be damn useful and its (apparent) lack on modern keyboards could be a pain. I don't feel that any more, it's been too long ago, but if I had it back I'd probably find a use for it :-)

Cheers,
Wol

Dead keys

johill — Sat, 21 Dec 2024 12:05:30 +0000

IIRC (but I haven't used one in probably about two decades) that's simply how you get the other (another) accent, e.g. for é vs è. I think we still have one somewhere, so I guess I could check.

French people who believe É does not exist

sammythesnake — Fri, 20 Dec 2024 22:05:35 +0000

"caps lock" and "shift" don't usually do the same thing - caps lock is for capitals only, but shift *also* changes lots of other keys, mostly punctuation.

E.g. pressing the "2" key will do the same with our without caps lock, but shift will change that to a double quote or @ symbol or whatever.

I don't ever use windows, but I'd like to see if the "é" key does the same thing with shift as with caps lock, or something different. My (possibly optimistic) guess is that caps lock would give you the Élusive character :-P

Dead keys

sammythesnake — Fri, 20 Dec 2024 21:55:59 +0000

> On those mechanical typewriters the vertical position of the dead key accents is fixed obviously, on the correct height for lowercase letters but not high enough for uppercase letters. The typewriter won't stop you (and can't stop you) from using a dead key in combination with uppercase letters, but the result will not be satisfactory.

I imagine it would be optimistic to expect you to have such a typewriter on hand to experiment with, but the first thing I'd try would be to use the SHIFT key while pressing the accent key...

Doesn't the GECOS field already cover some of this use case?

ssmith32 — Wed, 18 Dec 2024 21:34:02 +0000

>for them to lean 1 (one) English world

Yes, what a shame they can't just lean one world. Or just learn to live in one English world.
Or just lean on one word to avoid learning English.
Or something.

(yeah, cheap shot, but come on, if you're gonna get on a soapbox about folks learning to spell one word, you really should double check that you spelled *word" correctly, and avoid inadvertently proclaiming that there is one English World - it's the kind of thing that could end up really getting under a Scot's skin).

Is this a real problem?

tao — Tue, 17 Dec 2024 14:11:46 +0000

Isn't it enough to be able to use UTF-8 in the full name field? In most larger multi-user systems you'll inevitably end up with name collisions anyway, so even with UTF-8 support in the username your friend would probably end up named something like bjørn3 (or, more likely, bj<5letters of last name>3).

Is this a real problem?

taladar — Mon, 16 Dec 2024 10:33:00 +0000

The real question is how many admins and users would be much more than just slightly annoyed that they can't ban someone because that person performing some harmful action uses a UTF-8 username they can neither pronounce nor type.

Damages i18n has done?

taladar — Mon, 16 Dec 2024 10:28:30 +0000

Oh, I would absolutely be for machine-readable output for all of those situations.

Unfortunately as long as you have some sort of output that isn't fully pre-specified (like an enum) but a free form value you would then soon get the feature request to translate those parts of the output too because someone wants to build some sort of user-facing UI based on the machine-readable output.

My argument is more that certain messages should not be translated because translations are literally hurting communication when compared to the use of a single language.

Is this a real problem?

MortenSickel — Thu, 12 Dec 2024 13:43:38 +0000

The question is rather,

How many people are each and every day annoied that there is a limit on allowable characters in your username?

Since usernames usually are closely connected to your given name, for my (Norwegian) friend Bjørn, the name bjorn is not his real name, and although bjoern to a certain degree is a correct spelling, it feels wrong, and for people using completely other character sets as cyrillic, arabic or ... it is even worse.

So the answer is clearly, the usernames should allow UTF-8, but as this article has clearly shown, it is not an easy part to get there, but hopefully one day. The way it is today is more or less a user name standard saying "ascii ought to be enough for anybody"

Anything but POSIX portable filename set with a conservative length restriction is dangerous

NRArnot — Thu, 12 Dec 2024 12:29:41 +0000

On old systems this was a valid command

$ chown user.group somefile

OK, somewhere along the Red Hat line, chown started being more picky and insisting on user:group, but even so, might there be legacy boxes out there sharing usernames via some centralized system?

How to enter weird characters under X11

yaap — Thu, 12 Dec 2024 11:20:12 +0000

Compose works on Wayland for me, with KDE Plasma 6. Just tried your second option, got it in color on konsole ;)

French people who believe É does not exist

MortenSickel — Thu, 12 Dec 2024 09:06:02 +0000

àÀ öôÔÖÈè typed by pressing the accent dead key (some needing shift or AltGr) and then the relevant key (typing on a Norwegian keyboard having æøåÆØÅ as separate keys, but no other accented letters) I happend to learn about the dead keys since I am often typing German.

But I have no idea if the first lettes in the comments comes out as an accented letter or as a accent+letter combo.

French people who believe É does not exist

marcH — Thu, 12 Dec 2024 05:23:39 +0000

>Haven't they accents always been available as dead keys on Windows?

Not for é (extremely common character) with the default Windows layout in France. é has its own key. It becomes É with caps lock on a mac but it becomes a number on Windows. There are some dead keys available but not for the acute accent.

There are apps that let you visualize any keyboard layout.

How to enter weird characters under X11

geuder — Thu, 12 Dec 2024 00:16:41 +0000

The compose aka multi key is truly amazing, someone must have had too much time...


$ grep -c '^<Multi'  /usr/share/X11/locale/en_US.UTF-8/Compose

3580

I don't even use en_US locale, but somehow the definitions seem to get included anyway. Some of the more useless examples:


<Multi_key> <C> <C> <C> <P>             : "☭"   U262D # HAMMER AND SICKLE

<Multi_key> <p> <o> <o>                     : "💩"  U1F4A9 # PILE OF POO

Not sure whether all of this is available under Wayland or is it another reason to postpone upgrading ☺

(the last character was typed as <Multi_key> <colon> <parenright>)

Dead keys

rschroev — Wed, 11 Dec 2024 23:10:43 +0000

Dead keys come from mechanical typewriters: a dead key prints an accent, but does not advance the carriage like normal keys do; that's why it's called "dead". Therefore the next character is printed in the same position, resulting in a letter with an accent above it.

On those mechanical typewriters the vertical position of the dead key accents is fixed obviously, on the correct height for lowercase letters but not high enough for uppercase letters. The typewriter won't stop you (and can't stop you) from using a dead key in combination with uppercase letters, but the result will not be satisfactory.

Computers are smarter than mechanical typewriters and can produce the correct glyph, with the correct vertical position of the accent to match the letter it's combined with. On computers the user experience is different though: when you press a dead key, nothing seems to happen. No output appears. Only on the next key press is output generated. What that output looks like depends on the combination. For example, if I press ´ followed by a, I get á. But if I press ´ followed by space I simply get ´, and combined with z it gives me ´z (because z with an acute accent doesn't exist, I guess).

Belgian azerty has a number of dedicated keys for the most common letters with accents, so you don't need to use dead keys for those (though you could, if you wanted to): é è à ù (ù doesn't seem all that common to me though; I would think ê is more common). All other accented characters require the use of one of the dead keys (^ ¨ ´ ` ~). ^ is a special case in that it appears twice on the keyboard: once as a dead key to produce e.g. ê , and once as a normal key to produce ^ (which I can also produce by first pressing the dead key ^ followed by space, just as I can with all the other dead keys). I don't know why ^ is special enough to get two appearances.

Side note: "Dedicated" is not entirely the correct term here: all those keys produce other letters when combined with Shift, and often also with AltGr. For example, é is on the same key as 2 (Shift) and @ (AltGr) (yes, azerty keyboards require Shift to type digits, which is why people using azerty have a somewhat higher tendency to use the numerical keypad for numerical entry).

Second side note: The term "dead key" is not exactly correct either, since being dead or not is not a feature of the key itself anymore like it was on mechanical typewriters. For example the key with ^ produces a very normal non-dead [ when used with AltGr. There are no fully dead keys anymore (on Belgian azerty, at least).

(That's probably more than you wanted to know about dead keys and accents on azerty keyboards)

Damages i18n has done?

raven667 — Wed, 11 Dec 2024 18:42:39 +0000

I've seen this standard in various vendor software, eg Cisco IOS and variants use a similar kind of system

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/16_xe/s...
https://www.cisco.com/c/en/us/td/docs/ios/12_2/sem2/syste...

found an example from some IBM system that is this style where every log is numbered

https://publibz.boulder.ibm.com/epubs/pdf/ispzmc90.pdf

grabbing one at random ISRB0001 is searchable and leads to further docs https://www.ibm.com/docs/en/zos/2.4.0?topic=codes-ispf-me... which would be a searchable tag even if the text of the message was localized or changed between versions

Damages i18n has done?

mbunkus — Wed, 11 Dec 2024 16:50:21 +0000

> Please note that I was specifically talking about error messages and auto-switching of output to another language on relatively low level interfaces

You're trying to enforce permanence on human language here. Error messages may change for a number of reasons, including them being unclear or even plain wrong, having to be extended to include additional information, include examples to the user how to fix the error/use the program correctly, or just stylistic changes. Even error messages written in English might contain non-ASCII characters if they include user-generated content, and that might not even be validly encoded (e.g. a file name). Note that all of those can happen with English as well.

If you want "I don't want to have to change my things, ever", then you're in well-trotten territory of e.g. REST APIs & similar. Argue for your low-level tools to implement best practices from those APIs, including:

- structured, versioned output
- a status indicator
- machine-parseable, stable error codes (that don't change) alongside human-readable error messages (that are subject to change & translation)
- one imposed language on all identifiers, most likely English (e.g. hash keys, status strings etc.)

That gets you everything you want while also allowing the tools to be translated, their messages changed in whatever way, to be easier to use by more people. This is something that I would very much like to see as well.

As for two examples, the "ip" tool & the "restic" backup command have JSON output in addition to the well-known, default human-readable one. It's easy to handle. Unfortunately in both cases error messages (and in the case of Restic certain verbose status messages) are still printed as human-readable messages instead of using JSON for it as well, falling short of what I'd like to see.

French people who believe É does not exist

farnz — Wed, 11 Dec 2024 13:06:40 +0000

Exactly, and it results in a different set of tradeoffs. A compose key is strictly more flexible than dead keys, since I can type things like Compose o c, and get ©, and both Compose , c and Compose c , get me ç. A dead key is clearer to the user - you type accent, base character, and always get the combination of the accent with the base character.

French people who believe É does not exist

Wol — Wed, 11 Dec 2024 12:55:17 +0000

Ah. So a "dead key" is basically like a normal key, except it displays a particular accent, so it can't display until the following key is pressed and they display together. In other words, a dead key is "compose", "accent" combined into one?

Cheers,
Wol

French people who believe É does not exist

farnz — Wed, 11 Dec 2024 12:49:32 +0000

Compose is different to a dead key. A dead key is a key you can press that appears to do nothing, but where the next keypress is modified by the dead key - for example, if you have a dead key for `, then pressing it does nothing, but pressing ` followed by e gets you è.

A compose key is a mode switch for the keyboard; the next few (at least two) keypresses are combined into a single character. I've configured Shift-CapsLock as a compose key, so I typed è as Shift-CapsLock, e, `.

French people who believe É does not exist

Wol — Wed, 11 Dec 2024 12:30:54 +0000

> Or is the issue here that people often don't know how to use dead keys these days?

That's almost certainly true for the Anglo-Saxon world. There's nothing on my (105-key UK keyboard) that looks like a "compose" key, and I wouldn't know where to start. I used to have a Cyrillic keyboard, but that had the old DIN connector, so is long gone ...

Cheers,
Wol

Damages i18n has done?

Wol — Wed, 11 Dec 2024 12:20:06 +0000

> Similarly, even in entertainment media, once I learned English I noticed how many of the German dubs contain English idioms that do not exist in German and were just translated word for word (presumably to make the lip-sync work).

This! As someone who's German is passable, and who's French has mostly been forgotten (plus ancient smatterings of Russian and Khmer), so much information is passed *by reference* in conversation, that if you're not a native speaker it's extremely easy to miss what is actually being said. Or (as has happened to me) the "meaning as written" can be very different to the "meaning as understood", so you end up saying something completely different from what you thought you had said!

Cheers,
Wol

Damages i18n has done?

Wol — Wed, 11 Dec 2024 12:13:16 +0000

That sounds exactly like what I was thinking of - of course, using a database, there was a MESSAGES file which the error function searched - keyed on message id and language, then it printed the appropriate error message for the locale. Prefixed by the message id, to make it easy to search for / report a problem. If you're dealing with a support team who speak a different language, the message id makes much more sense than the error message.

Cheers,
Wol

Damages i18n has done?

farnz — Wed, 11 Dec 2024 10:50:16 +0000

The UNIX world never went this way; I encountered it interacting with mainframes and minicomputers, back 30-odd years ago.

French people who believe É does not exist

taladar — Wed, 11 Dec 2024 09:58:42 +0000

Not sure if it does make a difference for those two particular layouts but which dead keys exist and behave as dead keys is absolutely part of the keyboard layout.

Damages i18n has done?

taladar — Wed, 11 Dec 2024 09:57:14 +0000

Please note that I was specifically talking about error messages and auto-switching of output to another language on relatively low level interfaces, the kind most likely used directly only by relatively skilled computer users.

I am absolutely in favor of translating interfaces used by laymen (but only those parts they want skip over anyway like error messages) and documentation.

I have the opposite experience to yours though, when i was younger, in the 1990s, a lot of computer books were translated by clueless translators so every publishing house had a different German version of the standardized English IT terminology and some of the coding examples in programming books were broken because the translators didn't understand how to translate e.g. a regex replacing part of a string.

Similarly, even in entertainment media, once I learned English I noticed how many of the German dubs contain English idioms that do not exist in German and were just translated word for word (presumably to make the lip-sync work).

I am also not talking about the cost to business here, I am talking to the cost i18n has to the communication itself by making that worse, not the financial cost.

Damages i18n has done?

taladar — Wed, 11 Dec 2024 09:45:38 +0000

While that does seem like a good solution to the issue I can't say I have ever encountered a program using that in 20+ years of professional Linux administration.

Damages i18n has done?

Cyberax — Wed, 11 Dec 2024 06:33:17 +0000

Again, realistically ChatGPT and Google will provide you enough context. And it's not like error messages are James Joyce's poems, they are typically very formulaic.

I maintain a couple of small projects, and I actually communicated with Arabic speakers via a translator.

French people who believe É does not exist

rschroev — Tue, 10 Dec 2024 20:42:44 +0000

Haven't they accents always been available as dead keys on Windows? I can't be sure but I seem to remember I've always been able to type accented letters on Windows, even those that don't have a dedicated key (on Belgian azerty, not French, but I don't think that makes a difference in this case). Or maybe that only worked for lowercase letters, not for uppercase?

Or is the issue here that people often don't know how to use dead keys these days?

Damages i18n has done?

mbunkus — Tue, 10 Dec 2024 17:23:26 +0000

It's not just about error messages, though. If you don't speak any of the languages a tool is available in (including its help output, man page etc.), then that tool is most likely completely unusable for them.

It's kind of hard to know how many people across the world do not speak English. There are several statistics out there that say that up to 1.45 billion people do speak English[1], but there are 8.2 billion people across the globe (or something like that). For whatever reason. Lack of education (or even educational possibilities), too young, too old, learning disabilities, socio-economic pressure & limitations etc. etc. "Just learn English" is not going to cut it just yet, maybe never.

For example, I started using computers when I was eight, I think. I was able to learn to program in it because the manual it came with was in German, even though the software itself was in English. I could not speak English at that point, but having documentation in my native language enabled me to at least associate several English words (PRINT, IF…) & short phrases (SYNTAX ERROR IN…) with their German counterparts, but only because I had the German stuff to learn from. If that hadn't been available, I might only have started doing stuff with computers years later if ever at the scale I'm doing it now. Having stuff available in your own language enables you to learn, to use, to create. Saying things like "everyone needs to learn English in our field" and "i18n has cost businesses a lot" is really thinking from inside a certain bubble, and it's really excluding & limiting.

All I'm asking for here is to be more open to make software, especially Open Source software, available and usable to all, not just the English-speaking system admin clique.

[1] https://www.statista.com/statistics/266808/the-most-spoke...

It's the human

mbunkus — Tue, 10 Dec 2024 17:09:34 +0000

> With that said, I don't understand why some people want their *name* as a user name.

Easier to remember. Emotional attachment. The fact that outside of computers you usually do use your name & not some arbitrarily restricted identifier to refer to yourself. Far less understanding for technical quirks & anachronisms in the general, not-too-tech-savvy public.

When I see some of my relatives having problems remembering their PINs for their EC cards which they use several times a week, I'm sure they're not keen on having to remember arbitrary identifiers for websites on end.

There are plenty of reasons. I guess you wouldn't consider them valid or important enough. Others may disagree.

It's the human

wtarreau — Tue, 10 Dec 2024 13:13:03 +0000

You can let users choose within certain limits. Others use tri/quadri/pentagrams. I used to have "tarw" when I was a student for example. I've also had 2 different numeric accounts as a student. Nobody complained, the account was there for the whole year, plenty of time to remind it. Also for a very long time you were limited to 8 chars. Many valid names wouldn't fit so that was another good justification to use a short name different from your real one. Actually it's only at home and on my work laptop that I'm using my first name since I'm not creative and it's short. People I know with long or composed names (for example "jean-françois") just use a short variation such as "jf" or "jeff" to avoid conflicts. On the few machines I am/have been managing with up to ~20 persons, often short names are used, with roughly 50% matching the user's first name, indicating that it's more like "I don't know what to use" than "I want my name".

BTW, just look here on LWN: most logins are short (including yours which is among the shortest). When I registered I tried "willy" and it was already taken by Matthew so I switched back to something simple. In any case I needed to note it somewhere, so I could have used anything else, like people have on gmail for example.

Is this a real problem?

alx.manpages — Tue, 10 Dec 2024 13:08:44 +0000

Is this a real discussion? Or are we discussing about the sex of the angels?

- How many people are currently using --badname (or the equivalent in the wrapper programs)?

I suspect the number is low.

Those that understand computers most likely avoid it,
knowing that it can trigger bugs in so many places.
I would say the number is exactly 0,
except maybe for a few cases just for fun testing a system.

Even more so if they have ever used different keyboards for input.
Restricting oneself to [a-z] for passwords is a good recommendation for similar reasons.
You might get locked out of your own system if you can't type the symbol.

There might be some people that do use UTF8 symbols in their usernames,
and I expect it's people that have no clue of how that works. So:

- How many of the people already using it would continue using it if you explain them the possible consequences?

Then, can we justify discussing support for one feature that has been available for a very long time (in Debian) with close to 0 users --especially those informed--, where we suspect it's quite dangerous?

Have we learnt something from allowing \n in file names?

Damages i18n has done?

farnz — Tue, 10 Dec 2024 11:46:44 +0000

The well-worn solution has messages that look like %FOO-PLORT-12345:"filename","example.com","2001:db8:1::42/64"%. The idea is that you look up %FOO-PLORT-12345 in your catalogue of possible messages, and get told that it's "could not download {1} over HTTP from https://{2}/ (resolved IP {3})". You can then fill in the parameters (by hand, back in the day, computer can do it now), and discover what the error meant.