Older blog entries for simosx (starting at number 4)

Quite often you see people supporting a view and makes you wonder how they can do it with a straight face.

Mark MacGann from EICTA issued a press release expressing his dissapointment that the legislation on software patents did not pass during a European Union Agricultural(sic) Council meeting on December 21, 2004.

Karl-Friedrich Lenz has a diary entry on his blog questioning the EICTA reaction and motivation.

At another part of the world, BSA (Asia) and GOH Seow Hiong have been quite active against open-source software since his appointment of the latter as Director of Software Policy in Asia (BSA).

BSA is the company that normally uses questionable methods to identify and collect license fees for pirated software belonging to the set of companies it is funded by. It is quite confusing to understand their role by visiting their Website, as you will read things like "Promoting a safe and legal digital world", "BSA educates consumers on software management and copyright protection, cyber security, trade, e-commerce and other Internet-related issues."

To state the obvious, not following the license of the software you are using is illegal; that's the same for products based on either proprietary or open-source software. However, you should choose products based on open-source software as it offers you a safer legal digital world.

BSA (Asia) has surpassed the role of just doing the essential money collection job for the companies it represents and now attacks open-source software efforts in South-East Asia.

BSA (Asia) and GOH Seow Hiong use misleadingly (page 23) the term commercial software to describe proprietary source code. One can have commercial software products based on proprietary software but also commercial software products based on open-source software. A third option is that one also has the freedom to be self-sufficient by choosing directly open-source software.

The open-source policy in Malaysia says [GoogleCache] that "in situations where advantages and disadvantages of OSS and proprietary software are equal, preference shall be given to OSS". It looks quite modest to me, as the preference clause is invoked only in the extreme case of equality of advantages and disadvantages between the two. However, BSA (Asia) and GOH Seow Hiong issue a polemic [GoogleCache] against "OSS procurement preference".

BSA (Asia) and GOH Seow Hiong maintain that "any preference for any model of software, open source or proprietary, could disturb the balance in the industry". The current balance in the industry is that proprietary software is used almost exclusively in any aspect of the industry. My idea of a balance is something towards 50-50.

BSA (Asia) and GOH Seow Hiong are unhappy with the work that IOSN is doing in South-East Asia on advocating about open-source software to developing countries. IOSN has been producing a set of Primers to help developing countries on open-source software. BSA sent a letter showing their discomfort. Perhaps the BSA line does not work well in South-East Asia anymore? In this letter, they include editorial comments for some of the primers although the public feedback period has already passed on each of them.

In addition, on the subject of security, BSA (Asia) tries to add that proprietary vendors offer "source code sharing initiatives", probably as a plug to the Shared Source program by Microsoft. It is quite interesting to see that what you get with Shared Source is not even close to being enough to conduct a security review. Once you sign up to the special Government Security Program, you only get to view and search the source code through your Web browser. The Windows XP source code consists of around 40 million lines of code. Assume this gets printed to 60 lines per page, binded to one thousand page volumes, and you get in total around 666 huge volumes. If this was a story book, you might be able to follow the first few volumes. However, it's not a linear story; it's source code, interconnected in a complex mesh structure. With open-source, you get the full source code files, you are able to compile, run visualisation and analysis tools, debug, test, verify, compare. With Shared-source, you can only peak through your Web browser; no chance to analyse, compile, run visualisation tools, test, verify... Initiatives such as "Shared Source" are a gimmick.

Furthermore, BSA cannot see why teaching proprietary tools/software quite often results to piracy, as each student is unable to pay for the license. BSA says that since a student buys the hardware, they should be able financially to shell out money for any expensive proprietary software, for their homework and assignments.

Finally, BSA appears to firmly believe that software patents are good for developing countries (the primary audience of IOSN is developing countries).

In another article, BSA (Asia) and GOH Seow Hiong claim that software patents not bad. In particular, "software patents do not necessarily benefit bigger players" (perhaps in the same way that BSA wants primarily to educate consumers). Also, "software patents benefit start-ups or small companies more because it encourages innovation". Does this make sense? Is this the education the developing countries of Asia should receive?

You should voice your concerns on all these.

You cannot write characters with accents on Linux console while in Unicode mode?

The dead keys functionality for Unicode mode needs some more love.

A workaround is to convert the console keymaps so that they do not require dead keys. For example, with dead keys, to put an accent on "a", you would normally type ";", then "a". You can convert the keymap so that, e.g. Alt+a will print the "a" with an accent.

To sum up on current support on Linux Console (that's not xterm but what you get with Ctrl-Alt-F1 :), you can view documents in Unicode from a wide range of character sets as long as combining characters are not required (Hindi no, Vietnamese yes). You can input (write) in Unicode mode as long as no dead keys are involved.

A dead key is a key that when you press it nothing happens. You press a second key and the character prints (for example, ";"+"a" for ά).

I tried the patch of Chris Heath on Fedora Core 2 and here is my take, from the user's point of view.

The patch works, surprisingly very well. It can be easily intergrated to the various distributions simply by modifying the /etc/sysconfig/i18n and /etc/sysconfig/keyboard configuration files.

The system scripts essentially call the following two commands (assuming we are already in Unicode mode):

% setfont <font-name> -m <console-screen-map>
% loadkeys <keymap>

For example, For Spanish:

% setfont latarcyrheb-sun16 -m 8859-1
% loadkeys es

For Finish:

% setfont latarcyrheb-sun16 -m 8859-1
% loadkeys fi

For Greek:

% setfont iso07u-16 -m 8859-7
% loadkeys gr

The character and key maps used are the "old" 8-bit versions. setfonts loads a Unicode map with the "-u" options instead of "-m". Also, the key maps for a few languages have been updates (for example, "gr-utf" for Greek). The new files (very few) cannot be used here. No need to update them ;-).

I tried a few languages and what follows shows characters produced from the console with composing. I used "vim" as my editor.

gr: Greek ά έ ί ό ύ ώ ϊ ϋ ϊ Ά Έ Ί Ή Ύ Ϋ
es: Spanish ñ á é í ý ú ü ï ÿ ä ë
nl: Dutch á é í ó ú ý à è ì ò ù
cz: Czech ä ë ö
us-ascentos: á é í ó ú ý ä ë ï ö ü ÿ
cf: french-canadian à è ì ò ù
fi: Finish ä ë ï ö ü â ê î ô û
fr French â ê î ô û ä ë ï ö ü ÿ

Therefore, from the user's point of view the patch works.

Iñtërnâtiônàlizætiøn

Interesting name, isn't it? It started as an entry of the blog of Sam Ruby with a recommendation to try the specific string in individual blog software to test if they can process properly Unicode.

If you google for Iñtërnâtiônàlizætiøn, you will get around a thousand results. Plus one.

While the Linux Desktop has been fully converted to Unicode and UTF-8, the console is still lacking in one significant area. Before going into details, let's start from the basics.

Most mainstream Linux distributions already put the console in Unicode mode. In addition, they load a suitable font for the console to display common languages. For example, the font latarcyrheb-sun16 covers Latin-based alphabets, Arabic, Cyrillic and Hebrew. If a filename uses those characters, they show correctly. The font files have been updated to include information about what is their unique Unicode ID. If the character is not found, a generic character will appear in its place. You may have noticed it; it says "LF" in one character cell.

Suppose you want to view Greek? Replace the font with the corresponding Greek console font.

The file /etc/sysconfig/i18n contains information about I18n for the console (but not limited). Only this file needs to be edited to accomodate other languages. By default it looks like

LANG="en_US.UTF-8"
SUPPORTED="en_US.UTF-8:en_US:en"
SYSFONT="latarcyrheb-sun16"

To configure to display, for example, Greek, the file should look like

LANG="en_US.UTF-8"
SUPPORTED="en_US.UTF-8:en_US:en"
SYSFONTORIGINAL="latarcyrheb-sun16"
SYSFONT="iso07u-16"

The font files are located in /lib/kbd/consolefonts/ and you need to use the variation that has the u character in the filename, denoting a file that for each character it lists the Unicode code point.

I am not sure if there is a tool to edit the i18n file, simply by selecting the system language. This would be the best.

The program script /sbin/setsysfont uses /etc/sysconfig/i18n to do all the dirty work. Read the script for the details.

Up to now we dealt with displaying. How do we write? We write thanks to /bin/loadkeys. The kernel comes with a default keymap so you can write common English in any case.

Both /sbin/setsysfont and /bin/loadkeys are invoked by /etc/rc.d/rc.sysinit, during system startup.

Now, what's the problem? Well, the writing part is not done in "full utf-8" but rather in 8-bit, making it impossible to add accents making it difficult to write crafts such as Iñtërnâtiônàlizætiøn.

There are some patches to enable support, see below.

I have just sent an e-mail to linux-kernel and I am waiting to see the response. I hope something happens.

X fingers!