From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Sun Nov 27 2005 - 17:58:09 CST
From: "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>
>> If there must exist several encodings depending on the user's
>> locale, then the user's locale setting must be accessible to the OS
>> itself (so the locale system must become part of it, part of its
>> kernel services, instead of being outside in a application library).
>
> Doesn't matter whether it should, because it isn't. I'm not designing
> an operating system now. I'm designing a language which runs on
> existing OSes and must play by their rules.
Then play with it. There are different needs in anapplication that is
supposed to backup all files found in a filesystem (whatever their name or
content, the only thing relevant being their location or selected type), and
an application that exposes a user to a choice of filenames to work with. If
filenames have a meaning for those users, it must be a valid string, and
thus be correctly encoded. And the system should take the preventive
measures to ensure that users will continue to have accessto their files and
collaborate with other users, even if they use a different locale in their
profiles.
Personnally I amnot shocked by the fact that I can't access within some
account to allfiles in a system. the system-widerole that allows this is
"root" under Unix/Linux, and it is not madeto be interactive. Its locale
configuration can remain technical, and this is the place where full
backups, or filesystem checks will occur. If "root" wants that its
filesystems are encoded with UTF-8 it canenforceit on allthe system, and
even configure alluser accounts to use it, or it can uninstall the support
for locales that don't work with it.
Now if that "root" wantsto accessto aremote system, it will act as a
non-root regular user for the other system which has its own restrictions.
But if the job is correctly madeby the local admin managing "root", it
should be able to configure a remote filesystem link to match the expected
encoding used andwanted in that remote filesystem. Which Unixsupported
encoding will allow interacting with all remote filesystems? No other reply
than UTF-8. So install UTF-8 locally and forget the nightmare : users will
thank you. There's in fact little or no benefit in continuing to support
other 8-bit encodings on Linux/Unix. It's time to switch and convert your
filesystems to Unicode.
This archive was generated by hypermail 2.1.5 : Tue Nov 29 2005 - 09:29:58 CST