C'est le début de l'année et pourtant déjà des conférences sympas. La dernière en date Linux.conf.au. J'ai une tendresse particulière pour celle-ci car c'est une des interventions donnée là-bas qui m'a donné envie de m'intéresser à wayland.
Au gré de balades sur l'internet mondial, une intervention repérée au GUADEC 2013,
et au titre provocateur: more security with less security.
C'est là qu'on mesure la difficulté de mettre en oeuvre de la sécurité.
Je suis tombé sur ce petit article très intéressant: pour aider au debugging,
on peut activer la protection renforcée de la pile, une capacité disponible avec les derniers gcc.
J'ai vu quelques conférences intéressantes du CCC (c'était comme toujours entre noël et le premier de l'an):
Note: j'alimenterais cet article au gré de mes découvertes intéressantes.
Une petite vidéo très sympa sur la sécurité dans Xorg. Ça se passait au CCC.
Une raison de plus de passer à wayland ;)
J'ai posté récemment
une première version d'un backend FreeRds pour weston, le compositeur de référence de wayland.
Dans cette article, je vais détailler un peu le fonctionnement de ce nouveau compositeur. Ceux qui ont déjà lu mon article sur le compositeur FreeRdp ne seront pas perdu.
FreeRds est un projet en cours, son but est de fournir un serveur RDP en se servant de la librairie FreeRdp. Xrdp était basé sur le code de rdesktop, on peut voir FreeRds est son successeur mais basé sur FreeRdp.
Voilà un schéma simplifié d'architecture de couplage FreeRds / weston, avec weston qui crée le contenu à afficher:
Dans le cadre du projet FreeRDS, j'ai eu à créer un petit programme bouchon faisant office de SessionManager pour tester des développements. La communication entre FreeRDS et le SessionManager se fait en protocol buffer, j'ai donc regardé du coté du binding python.
Rien de magique dans protobuf, il s'agit juste d'une (nième?) manière standardisée de sérializer des données. Je vais faire mon vieux de la vieille mais ça ressemble quand même furieusement à du CORBA sans la partie réseau (ce qui est d'ailleurs un peu embêtant, nous verrons ça plus tard). On décrit des messages dans un fichier .proto, on passe un compilateur dessus qui va générer du code pour lire et écrire les messages. Le truc bien c'est que le compilateur propose plein de langages de sortie.
C'est bien beau de pouvoir écrire des messages mais si vous êtes sur ce blog, vous vous doutez bien que c'est pour transporter des paquets sur le réseau. Voici donc quelques extraits de code python
Ce lien m'a fait économiser beaucoup de temps pour faire cette "simple" action (en même temps quand on fait quelque chose de pas standard avec qmake ce n'est jamais simple). En espérant que ça pourra aider quelqu'un d'autre...
Un petit article que je trouve très drôle sur l'estimation des temps des projets.
J'ai été récemment confronté à un problème qui m'a occupé un peu. J'avais une classe abstraite pure qui servait d'interface. Elle devait servir à faire le lien entre une application et l'implémentation qui resterait cachée (et qui évite aussi de linker avec l'implémentation). Jusque là rien de méchant, c'est du C++ avec Qt5.
L'implémentation fait des choses et je voulais qu'elle puisse émettre des signaux et que le code externe puisse s'abonner aux signaux.
Donc quelque chose dans le genre:
// myinterface.h #include <QObject> class MyInterface : public QObject { Q_OBJECT public: virtual void myfunction() = 0; signals: void onSomethingHappened(); };
// myimplementation.cpp #include <QObject> class MyImplementation : public MyInterface { Q_OBJECT public: virtual void myfunction(); };
Ce serait bien si ça marchait, mais le moc (Meta Object Compiler) ne veut pas compiler ça et dés qu'on veut faire un connect() sur le signal ça coince.