Keyboard layouts could be so much simpler

My brand new laptop has a french keyboard, but I've connected to it an full size dutch keyboard. Linux is great because it can actually deal with such weird setup so that for both keyboards when you press a key you get what you would expect. To do that, I configured the french layout as the default (because it's always connected to the laptop!) and whenever I plug the dutch keyboard I've got a little script which does this:
xinput --list # to find the id of the keyboard
setxkbmap -device $kb-id nl


Now, all this troubles could be avoided if not every country had a different keyboard layout (Switzerland is special, they have several layouts). 100 years ago, this could make sense, but now that there is so much exchange between countries, this is bringing more pain than advantages. One solution would be to simply change the spelling of every language to restrain them to the good old 26 basic letters, and be happy with a US layout forever after. This could happen, the Turkish people did manage, but for sure not any time soon, and anyway the culture should not be driven by the technology. It's up to the technology to adapt.

So what I'd really like to see is a generic keyboard layout, which allows to type any latin character-based language (or at least all the official ones present in Europe). The us-international layout is not so bad, but they are lots of small adaptations needed to not make it a pain to use (especially on windows where by default the diacritics are added to the next letter). Some European peoples are at it, and I hope it goes somewhere. While at changing the layout, we could move to dvorak, so the loss of direct access for the special keys of a language would be more or less counter-balance by the increase speed provided by the dovrak layout.

Even more useful would be to have the input method follow more closely the normal behaviour of putting diacritics: you first put and the letter and then you put the diacritics. It would in addition allow to add easily diacritics while reviewing a text (put the cursor just after the letter, and press the diacritic you want to add). Today, in Xorg, a first layout providing such a mechanism appeared: "USA - International (AltGr Unicode combining)". As its name implies it uses some special features of unicode. This has the disadvantage of not yet being correctly supported in every program, but that's the way to go!

Test this new layout, and report bugs on application not correctly responding to it, and propose better versions of the layout :-)

Getting integrated

As a sign that I'm integrating to the Netherlands, I have a patch in pidgin for... the Dutch translation. Ok, it's just one word, but that's a beginning!

Annoying bug tracking systems

Bugs are extremely annoying, but unfortunately bug tracking systems are also very annoying. They are several existing systems used with open source software. Unfortunately they more or less all sports the same problems.

One which is rather known is the connection of the bugs between upstream (the original project) and downstream (the distros), and in between downstream. Each project and each distro has its own bug tracking system. As a result of this, first, bugs might end up being duplicated: in general the users report their problem in the tracking system of their distro, excepted for some advanced users who directly follow upstream and report there as well. Second, the bugs get reported to places which are not read by the authors of the project, which reduces a lot the chances to have them fixed. So far, only lauchpad has tried to answer this problem, by automatically following upstream, but this does not resolve the problems to link the bug reports in-between downstream. Of course, it doesn't seem reasonable to have only one global bug tracking system for all the projects in the world. What would be useful is a mechanism which allows to transmit a bug from downstream to upstream, just by decision of the bug triaging team. It is then up to the triage team to differentiate bugs related to packaging problems to the bugs which have to be treated upstream.

However, an even bigger problem is that the bug tracking systems are actually bug report tracking system. The main concept is not a "bug", but the "report from someone about a bug". The main description about a bug is the first description ever written about it... which is one less likely to be precise: written before anyone ask for precisions, by someone who is a simple user. Generally, valuable information about the bug (eg: why and when it happens, how it can be fixed) is only available disseminated in the comments, or, even worse, in the comments of bug reports marked as duplicates. To correct this, the main concept should be shifted from "bug report" to "bug". Each bug could have assigned to it several bug reports, and bug reproducers (people would are affected by this bug and most likely able to confirm that the bug is fixed). The main description of a bug would be much closer to a wiki page, which can be updated little by little, as more things get known. Moreover, associated to the bug, there should be test cases, which allow to reproduce the bug. Each test case can be either manual, or automatic, in which case it could be possible to run the test case regularly and automatically against the latest version of the project to detect if the bug is still present. A bug would also be associated to fixes and workarounds. The fixes are patches, which can be commented, and which eventually become a commit in the code repository of the project.

A third problem is that when someone finds a bug in a project and reports it. The reporter should first check for previous reports of the bug. However, if the bug has been corrected in the mean time (typically, in the development version), it will not be easily findable because marked as closed. That is why the bug tracker should also be more aware of the versions of the projects, usually ordered as a tree. So that for each version of the project, it is possible to know which (known) bug is present, likely present, or fixed. When someone search for a bug, he or she will also indicate the version on which the bug was seen, and the search will show bugs even now closed. Not only this avoid to create a duplicate bug report, but also allow the reporter to use a workaround if it is available, without having to update to a new version.

Lots of perspectives to improve bug tracking systems. Maybe it is possible to modify bugzilla or launchpad in this directions. Maybe first, a proof of concept should be implemented. What other important features are missing in current bug trackers?

Hello from the other side of the world

So far Microsoft as been considering Linux as if it was they were two persons living on a different side of the world. No contact. Today, they have therefore done a big leap, by releasing drivers for the kernel under the GPL. It's actually only drivers to improve the execution speed of Linux when running in their virtualization engine, much less impressive than if they had released drivers for supporting the hardware of the Xbox for instance. Nevertheless, this is still a very symbolic step, as eventually a part of the kernel might be officially maintained by Microsoft.

The code will very likely be accepted, but for now it's only in the staging tree, the part of the kernel which contains "crap code" which does not yet have the quality to be normal part of the kernel. Indeed, the code looks rather ugly, but hopefully mainly just due to the coding style... Now it's time for everybody interested to go and have a look clean it up or test it.

Probably it's just a little "hello" from Microsoft, and other friendly actions towards Linux will take a very long time to come again.

And three

There used to be two. Now there are three projects dedicated to create a subtitle editor for gnome. All of them use gtk, but they are written in different languages (C#, C++, and python). I wouldn't mind if they were not each of them crappy. Actually, if just one of them was good, it would be perfectly fine. Unfortunately, they all have flaws so big that after few minutes you give up using them. Either they crash, or they do not show the movie at the same time as the subtitle, or the interface is so much messy that it's impossible to do simple things. In my humble opinion, such a program should be based on gstreamer, and written in python, so I hope Gaupol will get better in this direction...

Opensource should exactly avoid this kind of situation of happening, because everyone can join to the cause and work on improving the existing program. It's really sad to see no such collaboration. At least with the video converters, Arista and Transmageddon seem to have agreed on sharing the forces.

Being the first

Wikipedia provides articles which are supposed to be neutral point of view. It's always funny to look at who was the first inventor of an object in the different wikipedias. One could think they are all equivalent in the content, and are just translations of each-other. It seems national pride of different points of view can easily sneak in.

For example, about a plane, in English you learn that
The first self-powered aircraft was created by an Englishman by the name of John Stringfellow while in French, you learn that Le premier homme ayant déclaré avoir volé à l'aide d'un moteur est le français Clément Ader. So in English, the first one was an Englishman who created the first model plane, while in French, it is a Frenchman who created the first plane with someone inside.

Reading about the motorcycle is also interesting. In English the first motorcycle was designed and built by the German inventors Gottlieb Daimler and Wilhelm Maybach (in 18885), while in French, after some warnings about the difficulty of defining who was the inventor, you learn about the délivrance [...] le 16 mars 1869 à Monsieur Louis-Guillaume Perreaux.

Concerning the cinema, both the English and French versions emphasize on the impossibility of clearly define an inventor. Nevertheless, for those who want a name you find that In 1878, [...] Eadweard Muybridge successfully photographed a horse named "Sallie Gardner" in fast motion using a series of 24 stereoscopic cameras and that certains ont attribué son invention aux frères Lumière, concepteurs du cinématographe en 1895.

For sure, reading in more languages will bring even more interesting point of views. As most of the objects have never suddenly been invented, but slowly evolved, it is rather easy to define the inventor of it has the first citizen having made it evolve. None of the articles is wrong, just slightly biased. So when reading an article it is worthy to have a glance at the other versions just to see how far it can be biased...

Constructive gang

A couple of months ago I was walking in the street and passed in front of me two teenagers with malicious smiles. A few seconds later the bin exploded. The explosion was quite strong, lots of garbage flew away, and with the number of people around it could have easily be hurting someone. But the boys definitely seemed to have had a good time.

It's quite usual to see these gangs of teenagers hanging around without much aim, talking a lot, and from time to time having fun by breaking something. I can somehow understand why those boys are doing this: it allows them to motivate their presence, feel they are doing something together, and change their mind.

What is interesting is that open source contributers are doing exactly the same thing... with the little twist that instead of taking the easy road of destroying things, they are creating things. They come together via internet, they chat and from time to time they add a little contribution to the edifice. No actual big aim, just because it's cool. Well, the difference is that creating is much harder than destroying but also much more gratifying!