You are currently browsing the category archive for the ‘Contribution’ category.
Au détour de quelques questions que je me posais que la détection de forme, j’ai découvert les transformations de Hough. Ces transformations permettent, en jouant avec la géométrie de détecter par exemple des droites ou des cercles dans des images. Le principe est basé sur un accumulateur construit dans un espace réciproque à l’image dont les maxima marquent les formes probablement existantes dans l’image binarisée.
En quelques mots, pour des droites, l’idée est de balayer toutes les pentes et toutes ordonnées à l’origine et de compter le nombre de pixels matchant la droite de test avec l’image.
Scikit-image est une bibliothèque sous licence libre pour Python spécialisée dans la traitement d’image trouvant son socle technologique dans numpy et scipy. La transformation de Hough pour les lignes existait déjà, mais pas pour les cercles.
J’ai donc implémenté cette détection dont l’image ci-dessous illustre le résultat sur une photographie d’une série de pièces de monnaie. Dans l’exemple, on fait une tentative en précisant 2 rayons et en récupérant deux possibilités par rayon. Un des intérêts que je vois dans cette méthode est l’estimation de la position du centre de cercle qui peuvent être importants pour d’autres traitements postérieurs.
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
from skimage import data, filter
from skimage.transform import hough_circle
from skimage.feature import peak_local_max
# Load picture and detect edges
image = data.coins()[0:95, 70:370]
edges = filter.canny(filter.sobel(image), sigma=2.8)
fig, ax = plt.subplots(ncols=1, nrows=1, figsize=(6, 6))
ax.imshow(image, cmap=plt.cm.gray)
# Detect two radii
radii = np.array([21, 25])
hough_res = hough_circle(edges, radii)
for radius, h in zip(radii, hough_res):
# For each radius, keep two circles
maxima = peak_local_max(h, num_peaks=2)
for maximum in maxima:
center_x, center_y = maximum - radii.max()
circ = mpatches.Circle((center_y, center_x), radius,
fill=False, edgecolor='red', linewidth=2)
ax.add_patch(circ)
plt.show()
Petite remarque. J’ai appris aussi à cet occasion l’algorithme permettant de dessiner des cercles ou des lignes (Bresenham) et que celui-ci présentait le défaut ne pouvoir faire des cercles concentriques formant un disque plein. L’algorithme d’Andres est alors la solution pour ça (il supporte mieux la rotation aussi). Le premier était implémenté dans Scikit, pas le second, ce que j’ai corrigé. A noté que j’utilise Bresenham pour Hough car il me semble plus approprié (moins de redondances locales)
Au sein de l’April, nous utilisons deux outils complémentaires pour rédiger des notes : mediawiki et etherpad-lite que beaucoup auto-hébergent (lqdn, framapad ou le pad de l’april). Au cours d’un échange de courriel avec Marianne, j’ai appris qu’elle avait dû utiliser l’export DokuWiki de framapad pour déposer son texte sur le wiki de l’April. On a été vite convaincu de l’intérêt d’avoir un export pour mediawiki, surtout que c’est un moteur de wiki plutôt répandu.
Un rapide coup d’oeil au code m’a indiqué que c’était du javascript — que je ne connais pas — mais que ca semblait simple d’adapter l’export dokuwiki en export mediawiki. En deux bonnes heures, j’ai fait tourner le code en local et j’ai réussi à la modifier afin d’avoir un premier export. Quelques peau-finages plus tard, j’ai fait un pull-request dont l’enthousiasme du premier commentaire fait extrêmement plaisir 
[Edit : le pull request a été repris ici]
Il manque un coup de graphisme pour y mettre la bonne icone (j’ai utilisé pour le moment celle de dokuwiki, je suis mauvais dans ce genre de gimperie)
Il y a donc de bonnes chances de voir un export mediawiki dans le futur 
Situation
J’utilise zim tous les jours, notamment afin de conserver ma veille. Cette veille est issue du traitement de mes flux RSS. Lorsqu’une page contient une information intéressante sur un sujet, j’ajoute le lien dans la page zim qui correspond. J’y ajoute parfois des commentaires. Je fais de même lorsque je navigue (recherche d’astuces, comparatif pour achats…). Je pense que la majorité des personnes utilisent des marques pages dans leurs navigateurs. Je ne trouve pas cela pratique car il est difficile de les ranger, de les manipuler, de les commenter. Zim m’enlève cette difficulté.
Problématique
Cependant, chacun sait que le web bouge sans cesse. Le problème vient lorsque vous décidez de vous pencher sur un sujet. Vous ouvrez la page zim en relation afin de retrouver toutes les informations accumulées aux fils des mois ou des années. Vous retrouvez vos liens mais certains sont morts. Plusieurs raisons à cela : le site peut être inaccessible, avoir changé de CMS (liens cassés), de domaine ou simplement avoir disparu, voir le contenu retiré… dommage le lien était intéressant.
Première tentative
Nous ne sommes pas les premiers à faire ce constat, d’autres ont anticipé en créant des archives du web. La plus connue est sans doute archive.org. D’ailleurs, je vous conseille le module resurrect pages pour firefox.
Il y a toujours un mais… La solution n’est pas idéale, car nous sommes dépendant d’un service qui peut ne pas avoir archivé la page souhaitée : le crawler n’est pas passé au bon moment, le crawler n’est pas parvenu jusqu’à la page ou le site n’a jamais été visité…
Seconde tentative
L’idée est de mettre en place sa propre archive. On n’est jamais mieux servi que par soi-même, pas vrai ? Les outils utilisés par ces sites d’archives me semblent démesurés pour mes besoins. Un wget de la page me suffirait amplement dans 95% des cas. Bien sûr, on ne va pas faire ça à la main, ce serait trop long, et rapidement on ne le ferait plus.
Un script python va donc nous sauver la mise. En scannant à la recherche d’url toutes nos pages zim, il va récupérer la page avec le module urllib.request. Cette page est sauvée dans l’endroit de son choix. On ajoute un lien (comme le fait wikipedia dans les références via wikiwix) vers notre fichier téléchargé. Zim gère l’ouverture des fichiers avec xdg-open, chez moi c’est géré dans
~/.local/share/applications/mimeapps.list
Un simple clic sur l’archive ouvre la page dans le navigateur.
Le script peut être automatisé à l’aide d’une tâche cron ou via la fonctionnalité "outil personnalisé" de zim.
Quelques remarques
Comme je l’ai spécifié, j’utilise urllib.request. Je n’ai pas trouvé mieux dans la récupération de page. Si vous connaissez une bibliothèque plus performantes, je suis toujours preneur.
J’ai du changer le user-agent. Pour ceux qui ne connaissent pas, c’est la façon dont est identifié le visiteur du site. Par défaut, c’est python, je l’ai changé pour Firefox car des sites comme wikipedia me jetais. Sans doute parce qu’ils préfèrent qu’on utilise l’API.
La solution est implémentée pour zim, mais l’idée est générique pour ceux qui utiliseraient d’autres solutions de prise de note.
Idées d’amélioration
Il serait peut être pertinent de rafraîchir les archives tous les mois en conservant les versions anciennes (au cas où). Typiquement, certains commentaires sont très utiles et il peut être bon de les avoir. Une autre bonne chose serait d’avoir la possibilité d’empêcher délibérément l’archivage. Parfois, j’ai des liens vers des dépôts pour lesquels il n’y a aucun intérêt à avoir une copie ! Si vous avez d’autres propositions…
Code
C’est sous GPLv3, nécessite python3. J’ai déposé le code ici, plus pour information que pour production pour le moment, le code est relativement chaud. Si des gens sont intéressés par des versions stables dans le futur, je les proposerai.
L’April possède un wiki de travail permettant aux membres et aux non-membres de participer à l’élaboration de divers travaux. Ce wiki fonctionne grâce à mediawiki.
Récemment, j’ai mis en place un sélecteur de licence permettant à un contributeur d’apposer facilement une licence parmi une sélection (ou de mettre une licence ‘custom’ si aucune n’est satisfaisante). Ceci se fait très facilement en modifier la page spéciale MediaWiki:Licenses. Il suffit d’y faire une liste de modèles et ces modèles insère le texte adéquat de la licence (ou un lien y référant). La question de la licence est bien évidemment centrale dans ce type d’outil de travail, il en va de la possibilité de diffuser et de réutiliser les productions des contributeurs.
Ceci étant fait, il s’est posé la question des fichiers ayant été envoyés par le passé pour lesquels il n’y avait pas eu de licence précisée (environ 1200 fichiers). Pour palier ce manque, j’ai écris quelques lignes de code afin de mettre à jour automatiquement ces fichiers en question.
J’avais pour point de départ un fichier csv que j’ai parsé à l’aide d’un premier code perl pour créer des fichiers dont la syntaxe est de type ini, facile à manipuler. Je produit un fichier par utilisateur concerné. Chaque entrée concernant un fichier dont la licence est à préciser.
Un courriel est envoyé à chaque personne pour demander de compléter le champ licence, puis, à la réception de celui-ci, il est lu par un deuxième script via la bibliothèque Config::IniFiles. Les informations sont ajoutées à la page mediawiki idoine, comme l’aurait fait le sélecteur de licence, via la bibliothèque WWW::Mechanize.
Le choix de perl s’est fait lorsque j’ai appris (merci VX et Tangui) que la bibliothèque perl mechanize était bien mieux documentée que la bibliothèque python (devinette inside via 3 exemples). C’est tout de même plus rassurant…
Ca se code tout seul… si on n’oublie pas les deux lignes pour se loguer à mediawiki avant (certains comprendront ). En espérant que cela serve ou donne des idées à quelqu’un.
Chacun sait qu’il est bon de protéger son serveur d’attaque brute-force. Pour cela, j’utilise le célèbre fail2ban. Mon serveur ayant une configuration relativement modeste, j’ai choisi d’utiliser lighttpd (lighty) comme serveur web. Ce serveur web fait notamment tourner depuis peu un gitweb dont le seul but est de me permettre d’accéder à mon contenu synchronisé sur mon dépôt git depuis une autre machine. Autrement dit, en cas d’urgence, je veux pouvoir consulter mes notes.
Ces notes doivent rester privées. Pour cela, j’ai utilisé le mode mod_auth de lighttpd permettant de mettre en place un mot de passe sur le dossier. L’une des principales menaces dans la mise en place de ce type de protection est l’attaque par brute-force. Alors que lighttpd a été patché en mai 2010 pour que le log contienne l’IP lors d’un échec d’authentification, aucune règle pour fail2ban n’existait. Je l’ai donc créée.
Les modifications que j’ai apporté ont été commité dans un fork git du projet. J’ai effectué une demande de merge auprès de la communauté de fail2ban, leur laissant le soin d’améliorer si besoin est.
PS : encore une preuve de la simplicité de contribuer au logiciel libre, l’écriture du billet a été plus longue que la contribution elle-même.
Je vous présente le logiciel que je code en ce moment à l’occasion de la sortie de sa version 0.2. Ce logiciel, codé en python, est distribué sous licence libre GNU GPL v2.
Qu’est ce qu’inforevealer ?
La bonne question est sans doute pourquoi un nouveau logiciel ? Avant tout pour le fun. J’avais envie de me faire la main, et j’ai déjà appris plein de choses. Mais outre cela, je voulais coder quelque chose qui aurait une petite chance d’être utile à quelques uns.
Ceux qui ont déjà effectué de l’aide à un tout jeune débutant qui rencontre des problèmes avec sa distribution sait qu’il est parfois pénible d’obtenir les informations pertinentes. En effet, avec le temps, on acquière de l’aisance sous notre OS préféré et donner le résultat d’une commande ou le contenu d’un fichier (même accessible que par root) ne nous est plus difficile. Mais aux débutants, on va passer la moitié du temps d’entraide à lui expliquer comment taper une commande, comment se logguer en root, ou nous donner le résultat d’un fichier. Sans compter les command not found parce que la personne ne sait pas recopier une ligne, ça finit par lasser.
L’idée est donc de se débarrasser de ces soucis de base pour s’attaquer au réel problème rencontré par l’utilisateur. L’idée est fort simple. Un logiciel va produire un log, ciblé sur une catégorie "type", regroupant divers commandes et contenus de fichiers. La manipulation du log produit devra être aisée.
Et il fait quoi ce inforevealer ?
Inforevealer n’est disponible qu’en ligne de commande pour le moment. On peut spécifier une catégorie selon la panne comme par exemple : disk (relatifs aux partitions etc), display (pour les problèmes d’affichage…), package (soucis de paquets), bootloader, sound et j’en passe.
A partir de là, un log est généré en local. un unique fichier que l’utilisateur peut récupérer. (le chemin est précisable, par défaut /tmp/inforevealer)
Le log peut aussi être envoyé sur un pastebin de son choix (parmis ceux supportés). L’url apparait directement dans le terminal à l’image de pasteinit. Ca tombe bien, j’ai réutilisé une partie du code dispo en GPLv2 pour cela. Je dirai que cette méthode de pastebin est encore plus facile pour le débutant.
Certaines commandes/fichiers sont spécifiques à la distribution (packages). Le logiciel est prévu pour s’en accommoder en détectant automatiquement la distribution. Ce logiciel a donc pour vocation d’aider toutes les distributions (dans la limite de la configuration existante… là, toute aide est appréciée )
Certains fichiers/commandes ne sont accessibles que par root. Si des droits privilégiés sont nécessaires, on demandera à l’utilisateur s’il veut effectivement augmenter ses droits pour générer un log le plus complet possible. su et sudo sont supportés.
Et le futur ?
Les fonctionnalités futures reposent surtout sur l’interface graphique. L’interface CLI (ligne de commande) ne sera pas abandonné (on serait bien mal en cas de plantage de X…), mais fréquemment on a quand même une interface graphique qui tourne, et un débutant préfèrera cliquer, donc il faut lui donner cette possibilité. Je dirai que c’est le dernier gros morceau en codage que je vois (outre un souci pour traduire les descriptions qui pointe son nez).
Une autre chose majeure, et chacun peut contribuer en donnant ses idées, concerne la configuration des catégories. Toutes les idées de commandes plus performantes, de fichiers pertinents seront ajoutés. J’utilise un fichier de conf pour cela, ce qui permet aussi aux packagers de ne pas attendre mon retour upstream pour effectuer des adaptations à leurs distributions.
Enfin, tout cela se fera si des gens y voient un réel intérêt Toutes autres idées géniales (ou pas) sont les bienvenues.
Le dépôt du projet est sur github (tant que gitorious ne gère pas les tickets) Rendez-vous dans la section téléchargement.
Bien que j’ai quelques idées à réaliser en programmation et notamment l’apprentissage du langage python à faire (j’y reviendrai probablement dans un futur article), je me consacre beaucoup à mon autre passion qu’est la physique en ce moment. Il faut dire que je suis dans une période (depuis quelques semaines) où je défriche des terrains de connaissance encore vierge ou parcellaire en vue de ma thèse et c’est très plaisant.
Mon implication récente dans wikipédia n’est sans doute pas anodine avec cet état de fait. J’avais, il y a un moment déjà, désiré apprendre d’avantage sur la rhéologie via wikipédia et de fût bien déçu de l’état des articles. Trop peu d’entrées existaient en français, et les articles, même en anglais, sont souvent très très incomplets. Je me suis donc lancé à corps perdu dans cette tâche d’améliorer un peu les choses.
J’applique donc désormais la même méthode qui m’avait permis de progresser rapidement sous GNU/Linux, la doc, la doc et encore la doc en comparant, confrontant les sources, en étendant ses lectures pour compléter les articles… c’est un moyen formidable pour se poser des questions et progresser… et en plus on contribue au libre !
Voilà de quoi rassurer ceux qui penseraient que je m’ennuie.
Protéger grub, pourquoi ?
Il est possible de protéger grub de l’édition en ajoutant un mot de passe. L’objectif est d’améliorer la sécurité en empêchant l’édition de grub et donc d’un accès root. Bien sûr, une telle protection est inutile si on peut démarrer sur un média externe comme une clef USB ou un lecteur optique. Un liveCD/USB permettrait de se donner un accès root. Il convient donc de protéger le bios également et de supprimer le démarrage sur média externe. Les puristes iront jusqu’à poser un cadenas sur la machine, protéger l’entrée de la salle par biométrie… 
bref, je m’égare.
Protéger grub, comment ?
Dans une console, on peut utiliser grub-md5-crypt :
grub-md5-crypt
Password:
Retype password:
$1$AvIeV/$e6WXVU5ubnIIZDgwuQ9iF.
Il suffit alors d'ajouter la ligne suivante password --md5 $1$AvIeV/$e6WXVU5ubnIIZDgwuQ9iF. dans le fichier /boot/grub/menu.lst et c'est tout
Et pour les anti-consoles ?
Mandriva propose bien sûr une alternative à la console pour protéger son grub. Si vous démarrez la version actuelle du centre de contrôle Mandriva et allez dans l’onglet approprié, vous verrez cette interface.
Il y a en fait trois problèmes :
Premièrement, je ne trouve pas la présentation astucieuse. Comme vous pouvez le voir, il faut aller dans "avancé" pour activer la protection dont le mot de passe se trouve dans la fenêtre principale.
Deuxièmement, la case protection se retrouve être décoché si vous revenez plus tard dans cette interface alors que la protection est active et fonctionnelle.
Troisièmement, il est impossible de désactiver la protection…
Autant de soucis méritent un patch
J’ai donc ajouté plutôt une case à cocher dans l’interface principale, case qui va (dé)griser les champs pour le mot de passe selon qu’elle est active ou non. Le fait que la case précédente était toujours décochée venait simplement d’un oubli et la désactivation de la fonctionnalité était aussi un cas oublié. Tout ceci se retrouve donc dans le patch que j’ai proposé. La nouvelle interface deviendra (si mon patch est accepté) :
Peut-on faire encore mieux ?
Je pense que oui En effet, il faut garder en tête que lorsqu’on souhaitera éditer le grub (en pressant p), il faudra entrer son mot de passe en clavier qwerty (donc en aveugle si vous avez tout autre clavier). Mon idée serait de vérifier le clavier utilisé lorsque l’utilisateur a activé la fonctionnalité et afficher un petit message informatif dans les cas nécessaires.
Certains le savent, je veux m’investir au plus près du code source. Je fouine donc à travers les projets à la recherche d’une correction que je peux apporter. Mes connaissances en programmation ne sont pas encyclopédique, mais je me débrouille. Je profite de ce billet pour lancer un appel (cf partie sur Tilda)
Manque de traduction dans drakxservices (Mandriva)
Le premier patch concerne un bug que j’ai ouvert lorsque je me suis mis pour la première fois au test de distributions en développement. Ouvert fin 2008, le bug n’avait pas été corrigé, notamment à cause d’un flottement sur la personne responsable. Il était temps de prendre le taureau par les cornes et de faire un coup de perl.
Ce qui semblait à première vue un simple manque de traduction était en fait des chaines inexistantes dans les .po. Il s’avère qu’en fait, certaines chaines étaient connues et pour cause, elles apparaissent dans un hash. Mais pour les services n’apparaissant pas dans le hash, la description était directement recherché dans /etc. J’en ai donc profité pour compléter la table.
Tilda : erreur de segmentation
Un problème que j’avais remarqué sur la 2010.0, mais j’avais oublié d’ouvrir un rapport… le logiciel tilda déjà discuté ici ne se lançait pas à cause d’une erreur de segmentation. Ce n’était pas le cas sous mandriva 2009.1 bien que la version du logiciel n’ai pas changé. Je suis parvenu à corriger l’erreur de segmentation. Si vous lisez le rapport vous verrez que j’ai supprimé l’appel à
gdk_x11_window_set_user_time ()
Selon moi, il n’y a pas d’intérêt, mais je connais très mal les API utilisé dans tilda. Si quelqu’un sait… De plus, je vais reporter le patch upstream, mais le projet semble abandonné à mon plus grand regret, j’aurai vraiment bien aimé le reprendre, mais mes compétences ne me le permettent pas encore.
Imageshack-uploader : corrections de warnings en partie dus à des changements chez ffmpeg
J’ai eu l’occasion d’aider une personne sur la mailing liste francophone d’entraide à la création de RPM pour mandriva. Le résultat se trouve là. Le patch a permis de compiler correctement le logiciel. il n’y a pas vraiment de commentaire particulier à faire si ce n’est le warning
httprequest.cpp: In member function ‘QNetworkProxy&
HTTPRequest::getProxy()’:
httprequest.cpp:37: attention : reference to local variable ‘p’ returned
où il manque visiblement une donnée membre du type QNetworkProxy. Je n’ai pas remonté ce point. Ce soucis de ce projet est l’organisation, il n’y a pas sur leur gestionnaire de version les codes des différentes versions. On est ainsi obligé de prendre le code sur le dépôt à moins de démanteler le .deb founit. 
Adhérer April
CC-BY-SA
La Quadrature du Net
Planet-libre
Wikio
