Tuesday, 21 January 2014

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. :)

Friday, 13 December 2013

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.

Tuesday, 29 October 2013

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 :)

Friday, 6 September 2013

Implementing MTP on Ubuntu Touch

Some of the fun parts of working at Canonical is how you get to work on so many different things.

I've spent the last few days working on an implementation of the MTP protocol for Ubuntu Touch, based on some amazing initial work from Thomas Voß to port the Android MTP libraries to C++.

I hadn't touched C++ in just about ten years. Last time was for school stuff, and it seems like things have changed a fair amount since, so I first had to get back in touch with the quirks of C++, learning Qt (which I used for my initial work), and learning Boost; in particular Boost::Filesystem, and some of the most fun pieces of Boost like BOOST_FOREACH, range adaptors, etc.

But MTP has been progressing very nicely, with code surely ready to land pretty soon in the Touch images. It was initially only exposing image files in /home/phablet/Pictures, but the latest code (still at lp:~mathieu-tl/mtp/images) now exposes all files in /home/phablet.

Not everything is implemented yet: for instance, you won't really have access to see or change permissions, copy or move files around the exposed filesystem, or delete files, but you can already browse and retrieve files, just like you can use the current MTP code to push files to an Ubuntu Touch device.


I'm thrilled at what's to come on that front, this is going to be a lot of fun.
If you're interested in testing this, feel free to take a copy of my bzr branch and experiment. You can build mtp simply:

cd mtp/
sudo apt-get install bzr bzr-builddeb debhelper build-essential cmake libboost-dev libboost-filesystem-dev
bzr bd

Let's keep working on making Ubuntu and the Touch images rock!

Saturday, 4 May 2013

Protocol stacks on Ubuntu Touch

We're working really hard to get the Ubuntu Touch images into a state where the UI is really polished, the experience rocks, and just to make it a truly amazing product that reflects the core principles of Ubuntu.

One of the aspects of this work is to get to a really good story with protocol stacks in general -- that is to say, bluetooth, WiFi, and the fun things behind connectivity on a mobile device. How can I get my files on the device? How can I copy the pictures that I've just taken back to my computer?

On the way back home from Oakland I've had quite a lot of time to reflect on what we've done so far. I've seen really cool demos of things you could get done on Touch and how things are going to look like in the near future. It makes me very proud to be part of getting Ubuntu to a large number of people through a solid Desktop system, but also stellar mobile devices support.

So, we did get bluetooth to work pretty okay so far on Touch. It seems like the current baddest issue is really just UI, but fortunately people are already hard at work fixing that, too. Keyboards can be discovered, and so can mice (I've uploaded a video to YouTube about that before). Bluetooth headsets should follow soon, but when I last tried I was running into issues with pulseaudio on the Nexus 7... If you're interested in bluetooth and know a little about BlueZ and the command line, by all means, let me know on IRC and let's get this to be really awesome.

For WiFi, we also have indicator-network in the archive, all rewritten, received tons of love, and soon to be ready to shine on both the desktop and mobile phones or tablets. Don't get me wrong, there's still a long way to go, but it feels to me like one thing we can pretty quickly ramp up to converge and essentially be the same experience no matter what form factor it is running on.

That covers WiFi -- but what about mobile data? (3G / 4G, but I rather speak of it in the most general terms) Well, that's being actively worked on as well. We're not too far off from having working 3G data  on the "officially supported" devices (Galaxy Nexus, Nexus 4, Nexus 7); and from there it seems like it may not be too much trouble for people to ramp up that support for other devices. Sure, it's complicated work because of how technical it is, but I think it's still approachable.

For mobile data, I've lately been working on teaching NetworkManager to speak to oFono; which are the two stacks we're decided, at UDS, to use to handle networking and telephony. The code itself isn't too pretty yet, but I'll add just a bit more meat to it and provide it as a test bzr branch for people to experiment with, until it's stable enough to make it into the archive altogether.

All this to mention that I'm really excited about the current progress for Touch, and although my progress on my own work items wasn't exactly stellar, I'm thrilled about what's to come. So thrilled I'll contact my cell provider to get the right SIM card size to start using Touch on a Nexus 4 as my main phone next week.

See you all at virtual UDS, looking forward to lots of constructive discussions about networking and connectivity!

Monday, 6 August 2012

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.

Tuesday, 22 May 2012

Here's a quarter, go buy yourself a clue

"Don't hate the media, become the media~Jello Biafra

TL;DR: Ôtez-vous de mon chemin. Je suis pour la hausse. Pas de raison de manifester, pour l'instant.

Je ne veux rien savoir des manifs, de la loi 78, de l'autre loi à Montréal, des hausses des frais de scolarité ou alors si vous êtes pour au contre. Je n'en ai rien à faire. Y'a tellement d'autres chats à fouetter. Je "recommence" l'école pour la session d'automne à l'UQAM en informatique (de soir, temps partiel). Arrangez vous pour pas me faire chier et pas être dans mes pattes à ce moment là.

Pour ceux qui se questionnent; mes opinions sont simples:
  • Je peux payer mes cours sans problème, alors la hausse, ça ne me touche pas, tant que c'est raisonnable. Ça l'est pour l'instant, à mon avis.
  • L'éducation doit être accessible à qui le veut bien, mais ca veut pas dire qu'une hausse va véritablement dramatiquement changer les choses.
  • Le gouvernement se doit de bonifier les prêts et bourses de toute façon, pour aider les gens qui ont du talent ou du potentiel à faire valoir ce potentiel et leur droit à l'éducation.
  • L'éducation est un droit, certes, mais il n'est pas indispensables. Si on a que des doctorants, qui va être plombier, ramasser les vidanges, etc? Ca en prend de tous les niveaux, de toutes les cultures et de tous les niveaux d'éducation, il n'y a pas de sous-emploi.
  • Suivant cette ligne de pensée, travailler risque d'aider fortement à pouvoir se payer les frais de scolarité. Pas oubligé d'aller directement à l'université après le CEGEP, pas oubligé d'y aller à temps plein. Je serai le cobaye de ce que j'avance, mais je serais fort surpris d'apprendre que j'aie tort... (ce que d'autres personnes de mon entourage ont déjà fait également avec succès).
  • Encore sur le même train: /there is no such thing as a free lunch/. Tout se paye, y'a des emplois en jeu, des salaires à payer. Ca doit venir des poches de quelqu'un.
  • Et plus: si ca vient pas directement de l'utilisateur, ca vient forcément des poches de quelqu'un d'autre. Si ce "quelqu'un" d'autre est le gouvernement, c'est qu'implicitement ca vient globalement des poches de la population au complet.
  • Pour terminer, toujours sur la même pensée: je ne devrait pas devoir payer pour donner un meilleur salaire potentiel, pour ouvrir des portes à quiconque, sauf moi-même (et mes enfants, mais alors voir plus haut, ils paieraient eux-mêmes avec aide, et potentiellement bourses, etc.)
  • Je suis totalement pour le fait de donner une chance égale à tous, et une éducation convenable à l'ensemble de la population, de façon à partir sur un pied d'égalité. En ce sens, la "gratuité scolaire" est tout à fait sensée au niveau primaire et secondaire, et même au niveau collégial. Il en va d'une compréhension correcte des maths, du français, de l'anglais, etc., ainsi que d'apprendre à apprendre/développer un sens critique. On veut pas des moutons qui suivent ce qu'on leur dit, mais des personnes sensées qui ont leurs propres idées. Cela ne veut pas pour autant dire que l'enseignement universitaire devrait être cette "base commune", où on apprend d'avantage des concepts plus pointus, où on se spécialise, etc.
  • Le point ci-haut implique un changement de mentalité radical des entreprises. Doit-on vraiment rendre indispensable un papier signé pour signifier une compréhension d'une matière (et attention, il y a des exceptions, la médecine, le droit, l'enseignement, etc.)? En informatique, je ne suis pas du tout convaincu de sa nécessité. Je préférerais engager des postulants qui prouvent leur compréhension technique et *active*, *dans le vrai monde*, basée sur expérience ou sur un potentiel clair (test d'aptitudes, entrevues poussées), qu'un postulant fraîchement sorti de l'université avec son diplôme.
  • Je ne considère pas la loi 78 antidémocratique. Interdire les manifestations, les restreindre, etc., le serait. Demander de bien vouloir annoncer les quand, comment, pourquoi, c'est simplement donner un outil aux policiers pour pouvoir assurer la sécurité des manifestants et du reste de la population. Imaginez si ça devait tourner à un affrontement entre différents groupes de citoyens? (oh wait...) Ça donne au moins un indice sur le fait que quelque chose ne fonctionne peut-être pas correctement si les détails (voir précédemment) venaient à changer.
  • Dans le même sens: cette loi sur les masques, dissimulation du visage, etc.; je crois que c'est une bonne chose. Vous n'en avez pas besoin pour mener à bien une manifestation. Sinon, si vous avez quelque chose à cacher, on est en droit de se demander ce que vous faites là, et en droit de penser devoir intervenir. Je ne me servirai pas de ce billet comme d'une tribune pour d'autres instances où la dissimulation du visage est entrave à la vie publique.
Oui, j'y vais à l'UQAM, faire mon certificat, pour mon édification personnelle. Parce que des sujets comme le développement agile et le droit de l'informatique m'intéressent vraiment (pour ne donner que deux exemples). Je suis peut-être fou comme ça, mais je crois que c'est bien ce genre de questionnement, de soif de savoir et ce genre de personnes dont j'aimerais voir le Québec composé. Pas des grognards prêts à tout arracher à la moindre lueur d'un peu de complexité dans leur vie coussinée.

Pour en passer aux manifs; j'aime avoir la PAIX. Pouvoir marcher à Montréal, "ma ville" (erm.. vous comprenez...) sans devoir me demander si je vais être bloqué par des manifestants, par la police, ou par un blocage du métro ou des ponts pour revenir chez moi. Ne pas avoir à me demander si je pourrai passer une soirée tranquille sur une terrasse, ou voir mon auto brûlée par un émeutier ou me faire poivrer par un policier...

Bien sûr, certains peuvent avoir mauvaise attitude, bousculer et tout -- mais ces agents devront répondre de leurs actes et ne sont pas majorité. La police est là pour garder tout le monde en sécurité, ça vient avec beaucoup de stress et de responsabilités, donnons-leur donc un peu de chances. Pas besoin de se mettre en travers de leur travail non plus. Je connais des policiers. Ce ne sont pas que des mauvaises personnes...

Et les manifestants. Sérieusement? Peut-on toujours parler de manifestation si ça tourne à l'émeute (ou presque), une fois sur deux? Du moment où on voit des actes de violence, il me semble que le gros bon sens est de se dissocier du groupe, le plus radicalement et de la façon la plus permanente possible. Déjà après trente jours de manifestations consécutives, on peut comprendre qu'il y ait grogne et mécontentement, mais il me semble que le bon sens me dit, à moi, de "crisser" mon camps et de plus rien avoir à faire avec ces personnes, que ça va tourner mal, que ce n'est qu'une question de temps. En plus, je suis certain qu'il existe d'autres méthodes pour faire des moyens de pression, pour signifier son mécontentement. De bien meilleures méthode qui ne seront pas, d'autant plus, n'empêcheront pas à d'autres de finalement bien pouvoir terminer leur dernière session. De pouvoir enfin travailler (voir plus haut, exceptions aux requis de diplômes).

Finalement, le gouvernement. Bah. À ce point c'en est que triste. Que croyez-vous vraiment qu'ils feront? Pensez-vous sérieusement qu'on arrive à l'orée d'un état policier? Je serais bien le premier à m'insurger. Vous avez, généralement, voté pour le gouvernement qui a été mis en poste. Possiblement comme alternative "la moins pire", mais quand même. Ils sont là pour trouver des solutions et tenter d'arriver à un compromis pour le bien de la population en général. Le fait est qu'en prenant des décisions on arrive tôt ou tard à déplaire à quelqu'un. Je sens que je m'en attire moi-même tout plein, des commentaires sur ce blogue... J'aime quand même mieux faire payer ceux qui étudie pour leurs études que la population globale, qui n'a pas besoin de plus de taxes ou d'impôts, ou de détourner l'argent de d'autres domaines (*toussote* la santé *toussote*) qui en ont bien besoin.

Ce qui m'insulte et me révolte le plus de tout ça, c'est la mésinformation. Si j'ai écris des conneries ici, répondez-moi et j'éditerai. Ou alors j'expliquerai mon raisonnement. Mais le fait que des journalistes construisent des nouvelles, les modifient (donnent leur opinion, ce qui me choque déjà depuis longtemps... en général, à la télé, c'est pas éditorialiste mais journaliste ta job!!! À moins que tu t'appelles Mongrain, Martineau, Lévesque ou même Poirier jusqu'à un certain point, on veut pas connaître ton opinion, juste avoir les faits. (et comme ça, pour les opinions on peut éviter de les regarder)), c'est totalement inacceptable. Mais encore, pas une raison d'aller dans la rue retourner des voitures. D'un autre côté, j'ai vu beaucoup de spéculations sur le sujet. N'oublions pas que les journalistes doivent incorporer un grand nombre de détails disparates pour relater les faits d'un événement comme une émeute. Tout plein d'informations venant de toutes parts, des réseaux sociaux, de la police, de leurs expériences. Des erreurs, on en fait tous. Je préfère donner le bénéfice du doute.

Mais pour terminer, je suis tout simplement amusé par tout ce que je vois, dans les médias, les discussions avec collègues, étudiants ou non, etc. Trop d'opinions (et moi qui en rajoute!), trop peu de faits purs et durs, trop de violence inutile et de grogne mal canalisée. Un nombre impossible d'opiniâtres mal informés... J'en suis peut-être un, même si j'ose croire que tout ce que j'ai écris ici vient de ma propre analyse, colorée par mes propres expériences de toute une vie, et basée sur les faits que j'ai pu trouver et colliger. Avec un peu de chance, il s'agit d'une synthèse pas trop folle d'un situation qui elle, l'est.

Le plus ridicule, c'est maintenant les masques de Guy Fawkes. Anonymous. Y'en a qui ont trop regardé V pour Vendetta... Mais ca me fait penser à une citation du film, justement:
People should not be afraid of their governments. Governments should be afraid of their people.

N'empêche, on est pas encore rendu à 1984, ni au Londres d'Alan Moore. Quand ce sera le cas, vous me verrez dans la rue moi aussi. En attendant, ôtez-vous de mon chemin et laissez-moi vivre en paix.

Thoughtful discussion and criticism is welcomed, but please send all flames to /dev/null.