Le problème fondamental de notre système électoral

Permettez-moi de résumer le problème fondamental de notre système électoral (le scrutin uninominal majoritaire à 1 tour) avec un simple diagramme que j’ai créé à partir des résultats de l’élection québécoise de 2014:

2014-03-07

La barre du haut correspond à ce pour quoi le peuple a voté. La barre du bas représente comment ces votes sont transformés en sièges à l’Assemblée. Résultat: on est de nouveau coincés pour quatre ans avec un gouvernement «tout puissant» dont la majorité de l’électorat ne voulait pas.

Comme si ce n’était pas déjà assez problématique en soi, ce système mène inévitablement au vote tactique (communément connu sous l’adage «Tout vote pour quiconque autre que le top 2 des candidats est en fait un vote pour le candidat #1»).

Outre le Canada, le même problème affecte les États-Unis, le Royaume Uni et autres pays sous-développés.

Et c’est pourquoi, tant qu’il n’y aura pas un mode de scrutin proportionnel, le Québec ne sera jamais un pays.

Call for testing: urfkill / Getting flight mode to rock on Ubuntu and Ubuntu Touch

Last month, I blogged about urfkill, and what it's meant to be used for.

The truth is, flight mode and proper killswitch (read: disabling radios on devices) handling is something that needs to happen on any device that deems itself "mobile". As such, it's one thing we need to look into for Ubuntu Touch.

I spent the last month or so working on improving urfkill. I've implemented better logging, a way to get debugging logs, flight mode (with patches from my friend Tony Espy), persistence, ...

At this point, urfkill seems to be in the proper state to make it, with the latest changes from the upstream git repository, into the distro. There is no formal release yet, but this is likely to happen very soon. So, I uploaded a git snapshot from the urfkill upstream repository into Trusty. It's now time to ask people to try it out, see how well it works on their systems, and just generally get to know how solid it is, and whether it's time to enable it on the desktop.

In time, it would be nice to replace the current implementation we have of killswitch persistence (saving and restoring the state of the "soft" killswitches) currently in two upstart jobs — rfkill-store and rfkill-restore — with urfkill as a first step, for the 14.04 release (and to handle flight mode on Touch, of course). In the end, my goal would be to achieve convergence on this particular aspect of the operating system sooner than later, since it's a relatively small part of the overall communications/networking picture.

So I call on everyone running Trusty to try to install the urfkill package, and file bugs or otherwise get me feedback on the software. :)

urfkill : a daemon to centrally control RF killswitches

Here's another project of the u-daemon variety. The latest addition to upower, udev, etc. Meet urfkill.

urfkill is meant to be a daemon that centralizes killswitch handling, rather than having all kind of different applications and daemon handle Wi-Fi, Bluetooth, WWAN and whatnot separately, and potentially fighting over them, you can have just one system that tracks the states and makes it possible to switch just one type of killswitch on all at one, or turn everything off should you so desire...

One reason I've taken an interest in urfkill in Ubuntu is that as we build a phone, we have to keep thinking about how users of the devices will be mobile. That's even more the case when you think about a phone or tablet than a laptop: on a laptop, you may have to think of WiFi and Bluetooth, but you're just about as likely to have your laptop off or not have it at all; whereas phones and tablets have become ubiquitous in our way of life.

Like anyone, thinking mobile I'd first think of walking around, driving, or other methods of travel. Granted, nobody needs to turn off Wi-Fi when getting in their car, but what about on planes?

This is the first thing everything brings up when talking about killswitches. Planes. Alright, you really do need to turn the device off on take off and landing, but some airlines do now allow wifi to be on and offer in-flight service. They still require you to keep cellular and bluetooth off. Also, while I sometimes do take my laptop out of my bag on long flights, it's just cramped. Space is at a premium on a flight (hey, I fly economy...), you'll likely want to have a drink, people besides you may need to get up, spillage could occur if there is turbulence...

I don't really enjoy using my laptop on a flight, even though it's quite small. It's just so much trouble and not very comfortable.

However, I do love to watch saved movies, listen to music, and play games on a tablet. That tablet will most likely need to have radios turned off. My phone will typically just stay off and stowed far enough, since I don't really change SIM cards until I can do so safely without risking to lose the thing.

But then, one can also think of how you should avoid using transmitting equipment in a hospital. They have similar rules about radios as planes to avoid interfering with cardiac stimulators, MRI equipment, etc.

Having all kind of different applications handle each type of killswitches separately is quite risky and complicated. How are you certain that things have been turned off? How do you check in the UI whether it's the case? Can you see it quickly by scanning the screen?

What about the actual process of switching things off? Do you need to go through three different interfaces to toggle everything? What do you need to do if you don't have a physical switch to use?

What about persistence after a reboot?

urfkill is meant to, in time, address all such questions. At the moment, it still needs a lot of work though.

I've spent the last day fixing bugs I could find while testing urfkill on my laptop, as well as porting it to logind (still in progress). In time, we should be able to use it efficiently in Ubuntu to handle all the killswitches. With some more work, we will also be able to use it to manage the modem and other systems on Touch.

For the time being, urfkill is available in the archive, for those who want to start experimenting with it.

Hacking with a Samsung ARM Chromebook on Trusty

So I decided it was about time to update / reinstall my Samsung Chromebook (the ARM one...) to Trusty, or at least to use Saucy. Turns out it's not that simple.

First, you need to know where to get the right stuff. I installed straight on the device, so chrUbuntu was the obvious choice. It's a pretty nice script that allows you to do just about anything necessary.

1) Bring your Chromebook to developer mode.

I'm not going to give the details. It's findable on the Internet, and unsafe enough that you should only do this if you know what you're doing... That counts double for running Trusty on the Samsung Chromebook.

From there, get into crosh (Ctrl+Alt+T), in shell mode (type shell at the crosh prompt).

2) Download the script:

cd ~/Downloads
wget http://goo.gl/s9ryd

3) Run the script:

sudo bash s9ryd xubuntu-desktop dev

This will do the gory install step, partition your device and format the new partition, download the ubuntu core tarball, and from there install the metapackage you've asked for as a first argument.

Be aware that if you have never repartitioned the device, you'll likely notice the system rebooting during the process -- if that happens, just re-run the same command to pick this back up where they ended. It's clear when the process is done and the system installed -- the script requires you to press Enter to reboot.

This was where things got fun.

Turns out my device booted fine into Trusty, but it would only show a black screen with the mouse cursor. If you moved the mouse, you could see the cursor changing but still nothing else. Switching to another VT (Ctrl-Alt-arrow (F1) or whatnot) would work to get you a text-mode login, but only if you switched early enough while X was getting ready to load... otherwise, you'd just get a pretty garbled display.

I hacked at the whole thing for a good while. I already know xf86-video-armsoc was involved in ChromeOS at some point, so I tried to install that.

Still no love. Tried to copy the libs from ChromeOS to the device, in case it was some libmali or EGL/GLES issue... Still nothing better.

I even touched /etc/X11/xorg.conf with some black magic, looking up the details using w3m in a text console...

Turns out the problem was with xf86-video-armsoc itself. I initially clued in when I looked at the dates for upload of the X packages and xf86-video-armsoc itself -- it didn't seem quite right: X was newer by a bit. I knew there could be some issue with the ABI in some cases; but after more careful investigation, that's probably fine too -- armsoc properly depends on -abi-14.

After much more work and trial and error, I updated xf86-video-armsoc to 0.6.0 from the Linaro git tree and also reverted one commit changing flags and it's not mostly working. X runs, I get lightdm, I can run apps -- "compositing" in Xubuntu works too, to get transparency and gradients... all with some minimal display corruption of the window decorations.

So the end of the line is -- if you want to run Trusty on your Chromebook and run into similar black screen issues, and you feel daring, feel free to try my newly-built xf86-video-armsoc package in my PPA:

https://launchpad.net/~mathieu-tl/+archive/ppa/+sourcepub/3627079/+listing-archive-extra

It's simple; once you're in a text console on the machine (login as user/user):

nmcli dev wifi connect <your wifi network> password <your wifi password>
sudo add-apt-repository ppa:mathieu-tl/ppa
sudo apt-get update
sudo apt-get install xserver-xorg-video-armsoc-exynos
sudo reboot

These updated packages, or at least some kind of permanent fix, should make it into Trusty soon. Stay tuned :)

La route vers le multimédia libre sur Android avec GStreamer

Comme plusieurs d’entre vous le savez déjà, Android est un écosystème au code source ouvert, mais pas tellement ouvert d’esprit ou de culture. Pour décrire succintement le phénomène, je qualifie typiquement Android de « read-only open-source » (du libre en « lecture seule »). Bien qu’une réussite incontestée dans l’industrie, cette plateforme n’a généralement presque rien en commun avec une distribution Linux conventionnelle (mais ça c’est une discussion pour un autre jour).

Ce qui change aujourd’hui, c’est que notre cher GStreamer supporte maintenant Android, grâce à la nouvelle version du SDK GStreamer. Naturellement, cette trousse de développement est non seulement gratuite et documentée, elle est entièrement libre!

C’est qu’un premier coup de hache dans les ronces qui fragmentent l’écosystème du libre: il est maintenant possible de développer des applications multimédia sur toutes les plateformes majeures (Linux, Windows, Mac OS, Android) sans s’arracher les cheveux, sans devoir tout réapprendre et réinventer à chaque fois.

Un jour vous verrez, nous verrons sûrement le dernier bastion des « jardins privés », iOS, succomber au charme de GStreamer.

The new GStreamer SDK is out, with Android support

Time flies! It’s been only a few months since the first release, and yet my pals at Collabora and Fluendo have just announced the availability of another major release of the GStreamer Software Development Kit.

Following up on the 2012.9 “Amazon” release, this SDK release, codenamed “Brahmaputra”, reveals a natural pattern: akin to the river of the same name, it streams down from the Himalayas, brings the coolness downstream, keeps flowing and breathes life onto the lands.

Evening on the Brahmaputra River, by Vikramjit Kakati

A particularly interesting piece of land that now gets irrigated by the flow of GStreamer is the Android plateau (some say platform, but that’s less geographically-fitting!).

Yep, you heard that right, pioneers of the open world! The land of Android is now fertile, free and wide open to rapid development of multimedia applications with GStreamer. Go ahead and try it out today, let us know how it helps you Get Things Done—and how GStreamer can be made even better!

The SDK currently supports a bunch of Linux distributions, Windows (from XP to 8), Mac OS, and Android 2.3.1 and newer (some features such as hardware acceleration will require Android 4.1 or newer). It is fully documented, free as in both, and has a sexy website (what more could you ask for?).

Getting Things GNOME 0.3: retour vers le futur

J’aimerais tout simplement saluer le travail de l’équipe de développement derrière GTG, mon logiciel favori (si si, logiciel favori, point final ! Il est essentiel à ma survie).

Pour vous donner le contexte, j’écrivais cette note personnelle dans Tomboy en 2006, suite à la lecture de Getting Things Done:

Nostalgie? Tout à fait. Maintenant, retour vers le futur, où ce problème est résolu par GTG.

Avec la version 0.3, GTG vient de se sortir de la pire crise de development de son existence. En effet, la version 0.2.4 datait de 2010 (faisons fi de la version intermédiaire 0.2.9 qui n’a pas vraiment eu le temps d’être reprise par plusieurs distributions Linux). Un très long cycle de réingéniérie—pas qu’un simple réusinage, non mossieur !—s’est effectué entre 0.2.4 et 0.3. Le résultat est une application qui performe mieux, est plus facile à développer et lave plus blanc. Je vous laisse constater les prouesses de la nouvelle mouture. La liste de bugs réglés par la série 0.3 (incluant les améliorations de 0.2.9) est tellement longue qu’elle fait planter Launchpad. Selon mes estimations, le total se situe à environ 400 bugs résolus (excluant les doublons, invalides, etc).

Puisque je suis maintenant un vieux crouton après toutes ces années d’utilisation intensive de 0.2.4 (malgré ses petits défauts), je ne suis pas encore passé à 0.3 sur ma machine principale—j’attends que ça vienne avec ma distribution Linux. Toutefois, selon mes quelques tests, le tout me semble solide. Je vous invite donc, jeunes chenapans, à utiliser cette nouvelle version de toute urgence, et m’en donner des nouvelles.

Évidemment, je vous invite également à contribuer au projet. Ploum et ses comparses vous aideront certainement à vaincre les monstres de l’espace qui pourraient croiser votre chemin.

Bug 1010724: Why doesn't dnsmasq listen on both IPv4 and IPv6?

Dnsmasq currently only listens on 127.0.0.1; that's done on purpose. If the only nameserver you have is 127.0.0.1, both IPv4 and IPv6 queries will go through it. It doesn't listen on an IPv6 address. We'll likely change the actual address to '127.0.1.1' as soon as this is possible with dnsmasq, there are changes coming up upstream that should support this.

Letting dnsmasq listen on IPv6 is definitely something I wouldn't mind to see working; but it's unfortunately not as simple as adding '--listen-address=::1' to the parameters passed to dnsmasq by NetworkManager. (Actually, it could be, see below)

I understand some may want to disable all IPv4 on their systems, but that's not advisable, at least for the time being and for the loopback interface and dnsmasq specifically. You absolutely can have an IPv6-only system with no IPv4 addresses on any of the physical interfaces, yet retain the use of 127.0.0.1 on the loopback interface for dnsmasq and others -- DNS resolution will still work for both IPv4 and IPv6 without issues, and you will simply not be able to access IPv4 addresses (since it would be an IPv6-only system for the physical interfaces).

The reason just '--listen-address' can't be used is because we've already had reports about dnsmasq listening on 127.0.0.1 being an issue. It's one we want to address. When installed from the 'dnsmasq' package on Ubuntu/Debian; dnsmasq ships an init script that listens on that loopback IPv4 address as well; causing issues for those who genuinely want to run a system-wide instance of dnsmasq that can be interrogated via loopback (thus serving the local machine), or users who haven't changed any of the default configuration for dnsmasq.

In the case of 127.0.0.1, the fix is relatively simple because we can switch to using 127.0.0.2 or 127.0.1.1; but for IPv6, there doesn't seem to be any such thing other than ::1 specifically meant to be used as a loopback address. In IPv4, it's actually a whole subnet that is available to the loopback interface; while in IPv6 you only have one address (::1/128) (see http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-00).

I'm very open to suggestions; at this point I'm looking for great ideas on how to best fix this and avoid concurrency issues with other applications; but given the rather minimal return of enabling it vs. the impact on other software running on the machine, and because we ran into precisely this kind of issue (multiple applications listening on the same address on port 53) already, I'd be inclined to have a real good alternative before changing things.

Consider the following two strace outputs for 'ping6 www.google.com'. The first one was run with dnsmasq started (manually, for testing purposes, but with the same parameters as NetworkManager uses) to listen on IPv4:

read(3, "# Dynamic resolv.conf(5) file fo"..., 4096) = 183
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x7f45cba80000, 4096)            = 0
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])
sendto(3, "\r\347\1\0\0\1\0\0\0\0\0\0\3www\6google\3com\0\0\34\0\1", 32, MSG_NOSIGNAL, NULL, 0) = 32
poll([{fd=3, events=POLLIN}], 1, 5000)  = 1 ([{fd=3, revents=POLLIN}])
ioctl(3, FIONREAD, [90])                = 0
recvfrom(3, "\r\347\201\200\0\1\0\2\0\0\0\0\3www\6google\3com\0\0\34\0\1"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, [16]) = 90
close(3)                                = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(1025), inet_pton(AF_INET6, "2001:4860:800a::93", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)


The network is unreachable only because I didn't have IPv6 access at the time. You can see that the request was sent and the address was properly discovered as "2001:4860:800a::93". The most important part is the first connect() using AF_INET as family, and "127.0.0.1" as the address -- that was libc trying to reach the nameserver defined in /etc/resolv.conf.

Now consider the following strace output, which is for the same request sent while dnsmasq was configured to listen only on ::1; and with ::1 defined as the nameserver in /etc/resolv.conf:

socket(PF_INET6, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(53), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])
sendto(3, "\220]\1\0\0\1\0\0\0\0\0\0\3www\6google\3com\0\0\34\0\1", 32, MSG_NOSIGNAL, NULL, 0) = 32
poll([{fd=3, events=POLLIN}], 1, 5000)  = 1 ([{fd=3, revents=POLLIN}])
ioctl(3, FIONREAD, [90])                = 0
recvfrom(3, "\220]\201\200\0\1\0\2\0\0\0\0\3www\6google\3com\0\0\34\0\1"..., 1024, 0, {sa_family=AF_INET6, sin6_port=htons(53), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 90
close(3)                                = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(1025), inet_pton(AF_INET6, "2001:4860:800a::93", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)


Very much the same behavior as above. This time, the entry in /etc/resolv.conf was ::1, so that's what was used for the first connect(); and because that's an IPv6 address, AF_INET6 was used as sa_family.

Both IPv4 and IPv6 queries were the first to run, and returned pretty much instantly.

One alternative to allow dnsmasq to listen on both IPv4 and IPv6 could be adding a loopback interface (or a tap interface) and using a limited scope IPv6 address, but there remains gotchas with this particular course of action -- for instance, dnsmasq currently appears to bind to *both* the specified link-local address added to lo as well as the "primary" IPv6 address defined for lo (::1/128).

Furthermore, it seems rather clumsy to me to include both the IPv4 and IPv6 addresses in /etc/resolv.conf when they refer to the same software instance. It's not going to bring much.

If you don't care at all about these details, whether ::1 shows up in /etc/resolv.conf automatically, don't run other instances of dnsmasq and want to experiment with custom configurations; in Quantal you'll be able to add configuration settings to files in /etc/NetworkManager/dnsmasq.d and tweak the settings as required.

Enabling IPv6 Privacy Addresses

At the last UDS, we once again discussed the state of IPv6 support in Ubuntu. We're in the process of making Ubuntu really rock with IPv6, and this comes with decisions and hard work.

One of these decisions was to enable IPv6 Privacy Extensions by default. In other words, rather than having an IPv6 address that is derived directly from your network device's MAC address, you'll now have that, but supplemented with time-based temporary addresses, randomly created, used to establish outgoing connections to systems. This leads to higher privacy; because it makes it harder for an eavesdropper to identify whether different addresses really refer to the same node (that's because the *prefix*, which network you come from, would change, but never the last part of the address, unless using privext). How all of this works is described in more details in RFC 4941.


And leading to this, the hard work. We've recently enabled IPv6 privacy extensions through a new file shipped by procps: /etc/sysctl.d/10-ipv6-privacy.conf. Sysctls are parsed early on in the boot process, but perhaps not early enough; which lead to an issue: on some systems, one would see some interfaces with privext enabled, and some others without. This appears to be because some interfaces (eth0 on my system) are initialized early enough in the boot process that it comes up before the sysctl settings are applied.

With this, another issue: there are three types of sysctl settings for ipv6: default, all, and per-interface entries. According to kernel documentation and help strings; default is meant as the ... default for future interfaces that would get created. At least, that's how I get it. Per-interface entries are obvious: you're just changing the setting for that particular interface. But what about all?

Well, it turns out net.ipv6.conf.all.anything doesn't really do anything, except for forwarding and disable_ipv6. These two options are already handled specially by kernel code. The particular setting that interested me was use_tempaddr though, and isn't being propagated (to the per-interface entries) or use globally to enable privacy addresses on all interfaces; which is something you'll likely want if you are looking to enable privacy extensions at all. Take this example: if you're using a mobile system, you might have wired and wireless connected at the same time, and may want to get up, unplug wired, and move around to a different spot, with or without suspending. While NetworkManager will in time allow toggling privacy extensions per connection, you shouldn't need to manually change this for a default install, on a typical, mobile worker day.

So I started writing my first ever kernel patch: having the net.ipv6.conf.all.use_tempaddr sysctl propagate its value to all the other interfaces already present on the system when the value is changed. It's currently being reviewed before I work towards having it included in the kernel proper. Reviews for that patch are welcome on the kernel-team mailing list.

I've now tested that this solves the issue of applying that particular sysctl at boot time; much like it appears to be expected to work by just about everyone if I'm to believe research I've done on the web on that subject. If there are brave souls wanting to test this, head over to my NM PPA. You'll need to be running Precise, and the package you'll want is linux 3.2.0-4.11~mtrudel2. Since this is a custom hacked up kernel package (but I tried hard to follow the Kernel Team's procedures), standard warnings of caution and the usual "if your system gets broken you get to keep both pieces" apply... but I'm running that package too ;)


GNOME Women: work on PiTiVi!

Do you love Python (or C)? Interested in video editing? Then you should definitely consider working on PiTiVi as part of the GNOME Outreach Programme for Women! Feel free to email me or Thibault about it, or catch us on IRC (some details about the program and how to get in touch with us are on this page)

Wait, let me give you an even better incentive. If you feel like email or IRC is too dry to carry complex discussions/questions, and would like a more personalized approach, I (and/or Thibault) will be glad to make an appointment with you for a live audio/video call over Empathy (through Jabber/XMPP/GTalk), Google Plus or even Skype. Just ask and we’ll make sure to be available to discuss every concern you may have.

PiTiVi is currently in a heavy state of flux and it is a bit tricky to list out the exact features that you could work on for the time being. This is one of the reasons why I’m offering an audio call. In the meantime you could take a quick look at the roadmap, pitivi love, but keep in mind that some of these items may be outdated or blocked by the transition to GES. The feature that we probably need the most right now is completing the implementation of the user interface for editing text/titles in PiTiVi: the work is partly done, your mission (if you accept it) would be to finish the UI and integrate it with our new GES backend.

Get in touch with us ASAP, there’s loads of stuff to be done and you only have until Halloween to apply for the GNOME Outreach Programme for Women!

Note that you will have to make a small patch/fix as part of your application, but we’ll gladly help you with it.