Re: UTF-8 practically vs. theoretically in the VFS API (was: Re: JFS default behavior)

[Jamie Lokier <jamie@shareable.org>]

Alex Belits wrote:
>   UTF-8 is dependent on Unicode, that is cumbersome, not user-expandable,

Ah, Alex, welcome back. :)

> This means, it's quite possible that this standard will be replaced
> by something better in the future

You mean like Unicode 4 will be replaced by Unicode 5 or something? :)

Seriously, if there was another standard encompassing all languages
and characters, why would they call it something different?

> and this is why poor design of Unicode is tolerated by users, and
> this is also why many people use non-Unicode-based charsets.

You've said this many times before, without explanation.

As far as I know, Unicode is a superset of all pre-existing computer
charsets used anywhere - but do feel free to correct me.

Unicode does have its problems - but what possible advantage does
_any_ known non-Unicode charset have over Unicode, apart from space saving?

You mention that Unicode doesn't well support language identification.
This is true - but the non-Unicode charsets (koi8-r etc.) don't
support that either!  Or do they?

>   And this is perfectly fine. Displaying and editing multilingual text is
> a user interface issue, that kernel should not be involved in.

Actually the kernel does have a line editor which needs to know a little.

>   I can point at the example of this "solution" that happened years ago
> when UCS-2 was all the rage, and it got hardcoded and enforced by NTFS
> and everything that handles it. Who is laughing about that decision now?

We are all laughing ;)

-- Jamie