27 January 2012
Le 27 January 2012 à 17:33:12
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.
Le 27 January 2012 à 17:05:56
Le 27 January 2012 à 13:05:19
Cette année, une petite nouvelle est arrivée dans le monde des licences de logiciel libre : la seconde version de la licence publique Mozilla (MPL 2.0). Elle n’est pas totalement nouvelle, car elle garde l’esprit général de la première version puisqu’il s’agit d’une licence de faible copyleft. C’est-à-dire que cette licence permet dans une certaine mesure — assez large — de combiner du code régi par la MPL avec du code sous une autre licence (y compris propriétaire). Pour autant, des modifications apportées aux fichiers du code MPL doivent être régies par les mêmes obligations : mise à disposition du code source, notifications des droits des utilisateurs (droits d’utiliser, de partager, d’étudier le fonctionnement et de publier des modifications — la définition d’un logiciel libre).
Ainsi, la MPL est un bon compromis, entre d’un côté les licences « académiques » (BSD, MIT) et de l’autre, les licences copyleft¹ fortes comme la licence publique générale GNU. Mais comme tout compromis, la MPL souffre des inconvénients incombant à chacun des deux modèles de licence.
Il y a cependant des qualités indéniables à la MPL 2.0, que j’ai voulues résumer ici :
La certitude d’une approche technique du copyleft plutôt que juridique
C’est la principale qualité du copyleft à la sauce Mozilla : la portée de celui-ci se limite aux « Modifications » telles que définies par la MPL 2.0, c’est-à-dire tout fichier originellement sous MPL qui a été modifié, et tout nouveau fichier qui contient du code originellement sous MPL. Pour faire simple : tant qu’on ne touche pas à un fichier du code sous MPL, on est en dehors du cadre d’application de son copyleft.
Cette façon de procéder contraste largement avec le fonctionnement des licences GNU dont la portée du copyleft s’apprécie juridiquement, car celui-ci s’applique aux œuvres dérivées (derivative works en copyright). Or pour déterminer s’il s’agit d’une œuvre dérivée ou non, il faut à la fois solliciter des approches juridiques et techniques. Ça ne veut pas dire pour autant que cette solution est plus compliquée, ni moins sûre (il y a consensus) mais il reste des zones à clarifier (on peut voir un essai de catégorisation de plusieurs cas de figure où le copyleft s’applique ou ne s’appliquerait pas).
Compatibilité avec les autres licences libres importantes.
- Licence Apache 2.0 : les conditions de respect des obligations de la MPL 2.0 relatives aux brevets ont été calquées sur celles de la licence Apache, de telle façon que la satisfaction des conditions de la MPL 2.0 satisfait celles de la licence Apache 2.0. En d’autres termes : incorporez du code Apache 2.0 dans du code MPL 2.0, tenez-vous aux obligations de la MPL 2.0 et vous aurez de facto respecté celles de l’Apache 2.0.
- Licences GNU GPL, AGPL, LGPL versions 2 ou ultérieures : cette compatibilité est rendue difficile par les différences d’appréciations de la portée du copyleft. Auparavant, Mozilla avait recours pour cela au double-licenciement; les logiciels étaient à la fois publiés sous les termes de la MPL 1.1 et de la GNU GPL par exemple. Cela menait à des bifurcations, puis à des incompatibilités.
La MPL 2.0 a adopté une meilleure solution, qui déclare explicitement la compatibilité avec les licences GNU². On peut donc incorporer du code MPL 2.0 à du code GPL 3.0 par exemple, et distribuer le tout sous licence GPL 3.0 — tout en donnant la possibilité à celui qui reçoit l’ensemble de continuer à bénéficier de la portion du code MPL 2.0 sous cette licence.
Du côté des projets et des distributeurs de logiciels en aval, cette compatibilité simplifie grandement l’analyse du jeu de licences et leur travail de documentation, etc.
Changement de la clause de défense contre les brevets.
À l’heure où la guerre nucléaire sur les brevets est déclarée, on sait l’importance de ces clauses anti-brevets dans les licences de logiciels libres qui se sont développées depuis la version 1.1 de la MPL (1998). On peut dire en quelque sorte que ces clauses sont à la guerre des brevets, ce que les traités SALT sont aux armes nucléaires : des accords mutuels de non-agression.
Le licencié d’un logiciel sous MPL bénéficie de droits accordés par ses contributeurs. Si celui-ci engage des poursuites contre quiconque pour violation de brevets par le logiciel sous MPL, alors il perd tous les droits (droits d’auteur et droits sur les brevets des contributeurs) dont il avait bénéficié jusqu’alors grâce à la MPL.
Cette clause de défense contre les attaques pour violation de brevets (attaques souvent abusives, sur des brevets parfois invalides ou fantasques) est une avancée majeure par rapport à la version 1.1 de la MPL — laquelle avait une clause à la fois bien trop large puisqu’elle se déclenchait pour toutes poursuites de violation de brevets, y compris les brevets qui n’avaient rien à voir avec le logiciel sous MPL ; et à la fois bien trop restreinte puisqu’elle ne concernait que la poursuite d’ayant-droits du logiciel sous MPL, laissant les autres sans protections.
Dans l’ensemble, il faut saluer le travail de Mozilla qui a conduit la rédaction de cette version de la MPL. Il s’agit sensiblement d’une amélioration, qui a su garder les qualités inhérentes à la MPL tout en corrigeant les problèmes pratiques et en s’adaptant aux problématiques d’aujourd’hui notamment dans cette lutte contre les brevets qui, chaque jour, menacent les développeurs de logiciel.
En anglais : Articles de Luis Villa, qui a mené ce travail de rédaction de la MPL 2.0 ; Un article de Richard Fontana (RedHat) ; Communiqué de la FSF ; et enfin, le texte de la licence.
Notes :
Le 27 January 2012 à 10:04:55
La plupart des paquets Debian sont gérés grâce à un logiciel de gestion de versions (VCS – Version Control System) tel que git, subversion, bazaar ou mercurial. Les particularités du format « 3.0 (quilt) » ne sont pas sans conséquences sur la gestion des paquets dans un VCS, et cet article va vous présenter quelques astuces afin d’en rendre l’usage plus agréable.
(Tous les exemples présentés ci-dessous s’appuient sur l’utilisation de git comme VCS).
1. Exclusion du répertoire .pc
Le répertoire .pc est utilisé par quilt afin de stocker ses données internes (liste des patchs appliqués, sauvegarde des fichiers modifiés). Il est également créé par dpkg-source de telle sorte que quilt « sache » que les patchs sont situés dans debian/patches (et non dans patches, qui est le répertoire que quilt utilise par défaut). À ce titre, le répertoire est conservé même lorsque plus aucun patch n’est actuellemement appliqué.
Vous ne tenez cependant pas à conserver ce répertoire dans votre dépôt : il doit donc être mentionné dans la liste des fichiers exclus. Avec git, il suffit d’indiquer :
$ echo ".pc" >>.gitignore
$ git add .gitignore
$ git commit -m "Ignore quilt dir"
Le fichier .gitignore n’étant pas pris en compte par dpkg-source, le paquet source généré par ce dernier ne sera pas « pollué ».
2. Retirer les patchs après la compilation
Si vous stockez vos sources « amont » avec les patchs non appliqués (ce que font la plupart des gens) et que vous ne compilez pas vos paquets dans un répertoire temporaire prévu à cet effet, alors vous souhaitez probablement « désappliquer » les patchs après la compilation, de sorte à retrouver un dépôt dans un état « propre ».
C’est désormais le comportement par défaut de dpkg-source. S’il a dû appliquer les patchs, il les enlèvera automatiquement également.
Mais on peut tout de même forcer ce comportement en ajoutant « unapply-patches » à debian/source/local-options :
$ echo "unapply-patches" >>debian/source/local-options
$ git add debian/source/local-options
$ git commit -m "Unapply patches after build"
svn-buildpackage compilant systématiquement dans un répertoire temporaire, le dépôt est laissé exactement dans le même état qu’avant la compilation : cette option est inutile dans ce cas. Ce comportement peut également être demandé à git-buildpackage grâce à l’option --git-export-dir=../build-area/ (../build-area/ étant le répertoire utilisé par svn-buildpackage, cette option force git-buildpackage à se comporter comme svn-buildpackage).
3. Gérer vos patchs quilt comme une branche git
Plutôt que de gérer les patchs spécifiques à Debian via quilt, il est possible d’utiliser git lui-même. Avec git-buildpackage vient l’outil gbp-pq (Git-BuildPackage Patch Queue – File des patchs de git-buildpackage). gbp-pq permet l’export d’une série quilt dans une branche git, que vous pouvez alors manipuler comme vous le souhaitez. Chaque commit représentant un patch, vous devez « rebaser » cette branche afin d’éditer les commits intermédiaires. Jetez un oeil à la documentation de gbp-pq pour appronfondir le sujet.
Alternative à gbp-pq, l’utilisation de git-dpm est plus compliquée, mais présente l’avantage de conserver l’historique de toutes les branches utilisées pour générer les séries quilt de toutes les publications Debian. Son principe de fonctionnement est très bien expliqué sur son site, et vous pouvez également souhaiter lire la revue qu’en a fait Sam Hartman, qui en présente les limites.
4. Documenter la manière de passer en revue les modifications
L’un des principaux bénéfices liés à l’utilisation du nouveau format source tient au fait qu’il est dorénavant simple de passer en revue les modifications amont : celles-ci sont conservées en autant de patchs distincts proprement documentés (et, idéalement, en utilisant le format DEP-3). En utilisant les outils décrits précédemment, le message de commit devient l’en-tête du patch. Il devient donc important de saisir des messages de commit explicites.
Cette méthode fonctionne bien tant que votre méthode de travail prend appui sur les patchs Debian, regroupés dans une branche que vous rebasez sur les sources amont à chaque publication. Certains mainteneurs n’aiment pas cette méthode de travail et préfèrent voir appliquer les modifications propres à Debian directement sur la branche d’empaquetage. Ils sautent alors vers une nouvelle version amont en la fusionnant dans cette dernière. Il est difficile dans ce cas de générer une série quilt à partir du système de suivi de versions. Il faut à la place indiquer à dpkg-source de stocker toutes les modifications dans un seul patch (qui devient alors équivalent au bon vieux .diff.gz), et documenter dans son en-tête comment mieux passer en revue les modifications, par exemple dans l’interface Web du VCS.
Le premier comportement est obtenu en passant l’option --single-debian-patch, et le second en écrivant l’en-tête dans debian/source/patch-header :
$ echo "single-debian-patch" >> debian/source/local-options
$ cat >debian/source/patch-header <<END
This patch contains all the Debian-specific
changes mixed together. To review them
separately, please inspect the VCS history
at http://git.debian.org/?=collab-maint/foo.git
<Put more details here>
END
Ceci est une traduction de mon article 4 tips to maintain a “3.0 (quilt)” Debian source package in a VCS contribuée par Weierstrass01. Vous voulez d’autres tutoriels comme celui-ci ? Cliquez ici pour vous abonner à ma newsletter et recevoir les nouveaux articles par email.
Aucun commentaire pour le moment | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.
Le 27 January 2012 à 02:31:40
L’UE a voté hier, à Tokyo, ACTA, l’accord commercial anti-contrefaçon. C’est fait. Mais le combat continue, tout n’est pas fini. La ratification finale n’aura pas lieu avant juin, il faut donc rester mobilisé, la lutte continue ! Toujours sur La Quadrature du Net, il y a des conseils pour lutter, alors, mobilisez-vous, c’est important ! [...]
26 January 2012
Le 26 January 2012 à 18:00:29
Munin est un logiciel de supervision permettant de centraliser la gestion des graphes de données RRDTools. Il permet en quelques commandes que nous allons détailler dans ce billet de générer des graphes complexes pour surveiller vous machines et les processus qui tournent dessus.
Voici un exemple de graphe sur les statistiques remontées par un serveur utilisant Varnish:
Introduction
Munin est proposé sous la forme de deux packages complémentaires: munin et munin-node.
Le premier (munin) est à installer sur votre serveur de supervision (appelé maître). Son objectif principal est de récupérer les données venant des machines à surveiller puis de générer des graphes qui seront présentés aux utilisateurs via une interface Web.
Le second (munin-node) est à installer sur toutes les machines à superviser (appelées noeuds). Son objectif est de collecter les informations systèmes en utilisant des plugins (présent dans le package munin-node et dans munin-plugins-extra).
La communication entre le serveur maître et les machines noeuds utilise, par défaut le protocole TCP/4949 (initialisation de la connexion TCP de la part du serveur maître).
Installation de Munin
Pour la suite de ce billet (et sauf mention spécifique), je partirai sur le principe ou vous utilisez des machines sous Debian/Ubuntu.
Installation de Munin sur le serveur maître
Le serveur maître doit disposer d'un serveur Web (voir ce billet pour installer simplement NGinx sur votre système) configuré avec le répertoire root par défaut: /var/www.
Comme Munin est présent dans les dépôts officiels, il suffit de saisir la commande suivant qui va installer le package maître ainsi que le package esclave histoire de pouvoir superviser son serveur de supervision...:
sudo apt-get install munin munin-node munin-plugins-extra
sudo ln -s /var/cache/munin/www /var/www/munin
sudo /etc/init.d/munin-node restart
En faisant pointer un navigateur Web vers l'URL:
http://votreserveurdesupervision/munin
Vous devriez voir s'afficher les statistiques de votre serveur. Il faut attendre quelques minutes avant de voir les premiers graphes, le temps que les bases de données soient renseignées.
Installation de Munin sur les machines noeuds
Installation des noeuds sous GNU/Linux
Là encore c'est assez simple:
sudo apt-get install munin-node munin-plugins-extra
La configuration de Muni sur les machines noeuds est centralisée dans le fichier /etc/munin/munin-node.conf. Il faut éditer ce fichier pour y configurer l'adresse IP de votre serveur maître à la ligne suivante:
# A list of addresses that are allowed to connect. This must be a
# regular expression, since Net::Server does not understand CIDR-style
# network notation unless the perl module Net::CIDR is installed. You
# may repeat the allow line as many times as you'd like
allow ^192\.168\.1\.200$
Cette configuration (à adapter à votre besoin) va autoriser la machine maître d'adresse IP 192.168.1.200 à se connecter sur cette machine noeud pour y récupérer les données à superviser.
Il faut ensuite relancer le service Munin-node pour faire prendre en compte la nouvelle configuration:
sudo /etc/init.d/munin-node restart
Installation des noeuds sous Windows
Le projet Munin ne fourni pas de "node" pour WIndows, il faut donc se retourner du coté de la communauté pour trouver notre bonheur. En l’occurrence du coté du logiciel Munin-Node-Win32 disponible au téléchargement sur cette page. Il suffit de lancer l'installer pour que l'installation et le lancement du processus en tache de fond soit effectué (procédure testé sous Windows 7).
Installation des noeuds sous MacOS
Si vous avez à surveiller des machines sous Mac OS X, il va falloir mettre un peu plus les mains dans le cambouis. En effet, il faut obligatoire passer par l'installation des gestionnaires de paquets Fink ou MacPorts. Je vous conseille la lecture du Wiki officiel.
Configuration des plugins sur les machines noeuds
Nous allons voir dans cette sections comment configurer ce que l'on souhaite superviser sur les machines noeuds. Munin utilise le fichier /etc/munin/plugin-conf.d/munin-node (ainsi que tous les fichiers se trouvant dans le même répertoire) pour configurer les paramètres des plugins (bien souvent de simples script Perl).
Le répertoire /etc/munin/plugins/ contient la liste des plugins utilisables par la machine noeud et le répertoire /usr/share/munin/plugins/ l'ensemble des plugins. En y regardant de plus prêt, le répertoire /etc/munin/plugins/ fait des liens symboliques vers le répertoire /usr/share/munin/plugins/.
Pour voir la liste des plugins disponibles sur le noeud, on peut utiliser:
# sudo munin-node-configure
Exemple de l'ajout des plugins NGinx (permettant de surveiller un serveur Web NGinx) sur un noeud:
Pour faire prendre en compte un nouveau plugin sur un noeud (node) il faut faire un lien symbolique entre le fichier en question dans ce répertoire et /etc/munin/plugins/. Par exemple pour accéder aux stats de mon serveur NGinx:
sudo ln -s /usr/share/munin/plugins/nginx_status /etc/munin/plugins/nginx_status
sudo ln -s /usr/share/munin/plugins/nginx_request /etc/munin/plugins/nginx_request
Il est quelquefois necessaire d'installer des dependances pour que le plugin fonctionne.
Pour voir les dépendances nécessaire il suffit de saisir la commande:
sudo munin-node-configure --suggest | grep nginx
nginx_request | yes | no [LWP::UserAgent not found]
nginx_status | yes | no [LWP::UserAgent not found]
Il faut donc installer la librairie perl contenant le module LWP qui est présente dans le package libwww-perl sur Debian/Ubuntu:
sudo apt-get install libwww-perl
Cela a l'air OK:
sudo munin-node-configure --suggest
nginx_request | yes | yes
nginx_status | yes | yes
On peut faire prendre en compte la configuration par Munin-node:
sudo /etc/init.d/munin-node restart
Configuration du maître pour prendre en compte les machines noeuds
Une fois toutes vos machines noeuds configurés (voir le chapitre précédant), il faut maintenant modifier la configuration du serveur maître pour les prendre en compte. Là encore, fidèle à la philosophie Unix, la configuration est centralisé dans le fichier /etc/munin/munin.conf.
En plus des répertoires systèmes en début de fichier:
# The next three variables specifies where the location of the RRD
# databases, the HTML output, logs and the lock/pid files. They all
# must be writable by the user running munin-cron. They are all
# defaulted to the values you see here.
#
dbdir /var/lib/munin
htmldir /var/cache/munin/www/
logdir /var/log/munin
rundir /var/run/munin
Il faut configurer la liste des noeuds de la manière suivante:
# A simple host tree for mondomaine.com
[maitre.mondomaine.com]
address 127.0.0.1
[noeud1.mondomaine.com]
address noeud1.mondomaine.com
[noeud2.mondomaine.com]
address noeud2.mondomaine
Reste à relancer le serveur Munin pour prendre en compte la configuration:
sudo /etc/init.d/munin restart
En faisant pointer un navigateur Web vers l'URL:
http://votreserveurdesupervision/munin
Puis par exemple les graphes sur l'occupation mémoire:
Pour voir une démonstration en ligne des capacités de Munin, vous pouvez consulter ce serveur maître qui est en accès libre.
Plus de plugins ?
Un des gros avantage de Munin est le fait de pouvoir simplement
écrire de nouveaux plugins en utilisant votre langage favori (nous reviendrons bientôt sur ce sujet dans un prochain billet). Pas mal d'exemples sont proposés dans
le dépôt GitHub suivant (vous devriez trouver votre bonheur).
Le 26 January 2012 à 16:40:37
Dans une vie précédente, j’ai utilisé KDE 4.3, ce qui remonte à environ 2 ans et demi. J’avoue que je n’ai pas eu envie de me plonger dans KDE entre temps, mais la sortie de la version de KDE SC 4.8 m’a donné envie de le faire. J’ai donc installé dans une machine virtuelle Qemu-KVM, une distribution archlinux 64 bits.
Au moment où je rédige cet article, KDE SC 4.8.0 est encore dans le dépot [testing] de la distribution, et donc demande l’activation de ce dernier. Pour l’installation, je n’ai pas cherché la finesse : bien qu’il existe un découpage en méta-paquets, j’ai demandé l’installation de la totalité de l’environnement, ce qui a demandé quelque chose comme 2 Go ? 
L’installation s’est résumé à faire un :
yaourt -S kde
La traduction française ?
yaourt -S kde-l10n-fr
J’ai ensuite rajouter une extension qui permet d’utiliser le moteur webkit en lieu et place de khtml dans konqueror.
yaourt -S kwebkitpart
Une fois l’ensemble lancé, est on surpris par la légèreté de l’affichage. La barre des tâches qui contient le menu K est joliment stylisé. Le bouton qui permet de gérer les gadgets est simple, loin du clinquant de l’époque KDE 4.2 / 4.3.
Introduit à l’époque de KDE 4.7, le gestionnaire d’activité est sympathique et permet de lancer de manière plus intuitive – c’est un avis personnel – les logiciels sans passer par les méandres du menu K. Je peux me tromper, mais j’ai comme l’impression que ce dernier va finir par perdre de l’importance au fil des versions.
Je me pose une question : pourquoi ne pas donner l’extrème onction au moteur de rendu khtml ? Bien qu’étant à l’origine du moteur webkit il est maintenant vraiment dépassé. Même s’il a un score honorable au test Acid3, son score est vraiment faible, dépassé de près de 50 points par Microsoft Internet Explorer 9 – sur le html5test.
J’ai fait une rapide présentation de KDE SC 4.8 dans la vidéo ci-jointe :
<iframe frameborder="0" height="315" src="http://www.youtube.com/embed/3N539c0Mo-M?rel=0" width="420"></iframe>
Et je dois dire que j’ai été agréablement surpris par la vitesse de l’ensemble, spécialement pour les effets d’affichages qui normalement sont largement plus saccadés.
Cependant, je reste un fan de gnome au plus profond de mes tripes, ce qui ne m’empêche pas de reconnaitre que cette mouture de KDE est très bonne.
Le 26 January 2012 à 15:20:21
Le 26 January 2012 à 11:20:31
Le 26 January 2012 à 10:55:00
A l’occasion de la journée du Domaine Public, nous vous proposons d’évoquer la licence Creative Commons Zero ( CC-0 )
La licence CC-Zero : une licence en faveur du domaine public.
Utilisée telle une déclaration d’intention sur les ouvrages Un monde sans copyright… et sans monopole (ed. Framabook) et Piratons la démocratie (ed. ILV)), la licence Creative Commons Zero (CC-0) est un contrat qui traduit la volonté des auteurs d"une œuvre (scientifiques, enseignants, artistes, créateurs) souhaitant renoncer à leurs droits au profit du domaine public (ou, lorsque la loi ne leur permet pas, de les céder très largement). Toute personne est ainsi invitée à réutiliser librement leur création, quelque soit le but et sans aucune restriction de droit.
Cette licence découle du positionnement en faveur du domaine public initié par Sciences Commons en 2007. Elle concède très largement les droits sur les données (et les bases de données) dans le but de permettre leur combinaison et diffusion sans entrave. Le projet communautaire Personal Genome ainsi que la région italienne du Piémont figurent ainsi parmi les premiers utilisateurs.
Le travail de traduction fut réalisé courant 2010 par les associations VeniVidiLibri et Framasoft, dans leur objectif de vulgarisation et de promotion des licences libres (notamment au travers des licences GNU GPL, ODbL, Art Libre et Creative Commons).
La problématique
Déposer des travaux dans le domaine public est difficile, pour ne pas dire impossible, pour les personnes qui souhaitent contribuer à l’usage public avant l’expiration de leurs droits. Peu de juridictions offrent une telle possibilité et les législations varient d’une juridiction à l’autre (cession, date d’expiration, renoncement ).
Aucun texte et aucune jurisprudence ne permettent à ce jour de donner de réponse certaine à la question de la validité d’un tel « domaine public » consenti. Néanmoins, la validité d’une mise volontaire dans le domaine public d’une œuvre par son auteur reste très critiquée au regard du parallélisme des formes : seule la loi pouvant reprendre ce qu’elle a donné (à ce sujet, voir Jean (Benjamin), Option Libre. Du bon usage des licences libres, Paris, Framabook, déc. 2011, p26). Par ailleurs, certains droits (notamment celui d’être cité comme auteur droit de paternité) sont inaliénables et seront maintenus — même à l’égard d’ œuvre du domaine public ou en situation de cession très large.
La solution CC0
Ainsi, la licence Creative Commons Zero (CC-0) agit en deux temps et traduit l’intention des créateurs d’abandonner tous leurs droits de copie et droits associés dans la limite offerte par la loi ou, lorsqu’un tel acte est impossible, d’opérer une cession non exclusive très large. De cette façon le domaine public et le domaine du libre se rejoignent pour ne faire qu’un.
Conforme à l’esprit d’internet et du numérique, la licence Creative Commons Zero (CC-0) est un instrument universel et sans frontière. Au final, et bien que sa réception differera selon les législations en vigueur, cette licence est destinée à fournir le moyen le plus complet pour contribuer au domaine public quelque soit le pays concerné.
Licence CC0 ( fr )
Résumé de la CC0 ( fr )
Licence CC0 ( en )
Résumé de la CC0 ( en )
Faq CC0 ( en )
Option Libre : Du bon usage des licences libres ( fr )
Propostion de traduction de Framasoft
Ce texte est sous licence CC-By-SA et est inspiré fortement de ce texte
http://fr.issuepedia.org/index.php?title=Licence_CC0&printable=yes
Le 26 January 2012 à 10:20:57
Récémment, la blogosphère liée au logiciel libre a parlé du dernier projet ergonomique en date sortie des laboratoires de Canonical : HUD, un projet pour remplacer les menus déroulant par un système de saisie intuitive.
Le Libriste propose un article avec la vidéo d’une préversion en test. Je n’ai personnellement pas encore testé cette technologie, potentiellement intéressante mais qui me fait poser quelques questions : comment faire avec des logiciels qui ont des options à foisons, comme un outil de traitement de texte ou un logiciel de retouche vidéo ?
Est-il plus rapide de faire un clic sur le menu Editer puis un autre sur annuler au lieu de taper « annuler » ? Evidemment le projet n’en est qu’à son balbutiement et sera surement amélioré pour une intégration par la suite. Même si je pense que viser la version 12.04 serait un peu court, vu le bouleversement ergonomique que cela entraine.
Et il est évident que ce genre d’interface se dédie plus à une tablette qu’à un ordinateur classique, et c’est une vision qui peut s’envisager.
Cependant, cette technologie n’est pas la première à vouloir faire disparaître le menu déroulant. Ce bon vieux menu déroulant fondement même des premières interfaces graphiques…
Pour voir une des attaques les plus connus contre un des fondements des interfaces graphiques des 30 dernières années, il faut remonter 5 ans en arrière, avec la sortie d’un petit logiciel du nom de… Microsoft Office 2007. C’est à cette époque que sort la première version de la suite bureautique de Microsoft rompant avec les menus déroulants, à savoir l’interface ruban.
Au lieu des menus et de leurs listes d’options, des icones et un ruban qui s’adapte à la demande de l’utilisateur. D’ailleurs, sauf erreur de ma part, l’explorateur de MS-Windows Vista, puis de MS-Windows 7, certains outils comme Windows Live Messenger ont fait disparaître le bon vieux menu déroulant, qui est toujours disponible si l’on appuie la touche alt soit dit en passant.
Mais Microsoft et Canonical ne sont pas les seuls à avoir attaqué le menu déroulant. Mozilla Firefox depuis sa version 4.0 et Opera depuis sa version 11.50 (ou un peu avant ?) propose un bouton qui permet ensuite d’avoir les options dans un menu plus condensé.
Google Chrome a aussi utilisé cette option, remplaçant le bouton nominatif par un bouton ressemblant à une clé à molette.
Donc, c’est un mouvement de fond qui s’est enclenché depuis des années, pour repenser l’interface graphique. Avec à la clé une question : à trop vouloir simplifier l’interface graphique, ne va-t-on pas la rendre plus inaccessible ? Quid des fonctionnalités qu’on ignore ? Et comment se repérer quand on sait visuellement où se trouve une option dans un menu donné ?
Le 26 January 2012 à 09:00:00
Dans le folklore Lyonnais, à part le gras double, les quenelles, les coussins, la cervelle de canut, les lumignons et les traboules, il y a plein d'autres trucs sympas comme les JDLL. Mais oui, les Journées du Logiciel Libre !
Alors comme ça parle de logiciel libre, l'April y est bien évidemment dès qu'elle peut. Voici donc une vue de notre stand en 2006, avec DJ Estelle et MC Eva aux platines !
Le 26 January 2012 à 08:14:50
25 January 2012
Le 25 January 2012 à 16:28:06
Le 25 January 2012 à 09:00:09
Un petit billet "flash express" pour protéger son site (ou un répertoire de son site) avec une authentification simple (type login/password) sur un serveur NGinx.
Pré-requis
Il faut disposer d'un serveur NGinx bien configuré (par exemple en utilisant ce script d'auto-installation pour Debian ou Ubuntu) puis du logiciel htpasswd que l'on peut installer sous Debian/Ubuntu avec la commande suivante:
sudo apt-get install apache2-utils
Création du fichier .htpasswd
Ce fichier va contenir, de manière chiffré, le mot de passe associé à l'utilisateur. La commande à utiliser pour créer ce fichier est la suivante:
sudo htpasswd -c /var/www/.htpasswd nicolargo
New password:
Re-type new password:
Adding password for user nicolargo
Ou:
- -c est une option pour créer le fichier (sans cette option, le couple login/password est ajouté)
- /var/www/ est l'emplacement du fichier .htpasswd. Le contenu du répertoire /var/www/ (donc la racine de mon site Web) sera donc protégée par le couple login/password
- nicolargo est le nom de l'utilisateur (login)
- ilfaut sasir deux fois le mot de passe (password)
Configuration de NGinx
Pour que NGinx puisse gérer les fichiers .htpasswd, il faut ajouter modifier la configuration de son site (à adapter selon votre configuration):
server {
listen 80;
server_name localhost;
root /var/www;
# Static
location / {
index index.html index.htm;
auth_basic "Login";
auth_basic_user_file /var/www/.htpasswd;
}
# Protect hidden file to read/write access
location ~ /\. {
deny all;
}
}
Après avoir rechargé la configuration:
sudo /etc/init.d/nginx restart
Il ne reste plus qu'à...
Tester
En pointant un navigateur sur le site en question, une bannière d'authentification va apparaitre:
Note sur la sécurité
Attention de ne PAS utiliser se mécanisme pour protéger des informations sensibles. En effet il n'y a pas de chiffrement des données lors de la transmission en HTTP entre le navigateur et le serveur et le fichier .htpasswd peut être récupéré en cas de corruption de votre serveur...
24 January 2012
Le 24 January 2012 à 16:34:49
Le 24 January 2012 à 11:11:42
…Ou n’aiment pas le « one size fits all » ? Un fidèle lecteur m’a écrit il y a quelques jours pour me suggérer de parler d’un problème inhérent selon lui aux distributions linux : leur rejet de la simplicité.
Je ne reproduirais pas le message en question, mais tout ce que je peux dire, c’est que cette personne a une dent contre les interfaces qui se démultiplient, spécialement les interfaces nouvelles générations qui ont fait leurs premières armes l’année dernière.
Un reproche que l’on fait souvent aux interfaces graphiques utilisateurs des distributions linux, c’est leur foisonnement. Contrairement au duopole Microsoft-Apple où chacun des adversaires impose sa vision de l’interface graphique comme étant ce que recherche l’utilisateur (en lui imposant au passage sa vision des choses), le monde du logiciel libre est celui qui refuse l’idée de la taille unique, en clair imposer à l’utilisateur débutant comme à l’habitué la même interface, avec les mêmes icones, les mêmes raccourcis claviers, etc…
D’un coté on impose l’interface, et l’utilisateur fait son choix souvent en fonction de ses besoins ou de ses finances, de l’autre, on laisse l’utilisateur choisir ce qui lui convient le mieux à l’utilisation.
C’est pour cela que l’on a 3 grands noms dans les environnements de bureau, Gnome, KDE SC et Xfce, mais aussi un nombre conséquent de gestionnaires de fenêtres plus ou moins complet, allant d’Openbox à RatPoison, en passant par fluxbox, windowmaker ou encore wmfs.
Ce n’est pas que les distributions refusent la simplicité, elle préfère promouvoir un ou plusieurs choix (en fonction de la cible d’utilisateurs qu’elles visent), car tout le monde n’a pas les mêmes besoins, ni les mêmes envies.
Dans ce cas, les distributions les plus ouvertes sont, par ordre alphabétique : Archlinux, Crux Debian, Fedora, Frugalware, Funtoo, Gentoo.
Car soit elles ne mettent en avant aucune interface, soit elles proposent les principales individuellement.
Choisir pour l’utilisateur ou laisser l’utilisateur choisir, à vous de voir la voie que vous préférez !
Le 24 January 2012 à 07:41:05
Le 24 January 2012 à 07:40:59
Le 24 January 2012 à 07:38:00
Powered by Planet!
Mise à jour: Le 28 January 2012 à 08:05:26
18h30-18h45 : Présentation des organisateurs (Wikimédia France, Communia, Creative Commons et l'Open Knowlegde Foundations) et du domaine public
![[RSS 1.0 Feed]](images/rss10.png){kind=small}
![[RSS 2.0 Feed]](images/rss20.png){kind=small}
![[FOAF Subscriptions]](images/foaf.png){kind=small}
![[OPML Subscriptions]](images/opml.png){kind=small}
![[Planet]](images/planet.png){kind=small}
