Site original : Framablog
C’est un Geektionnerd très spécial que nous propose Gee cette semaine (cliquez sur l’image pour l’agrandir).
Vous pouvez également lire les traductions de quelques uns de ses articles que nous avons publié cette semaine, ainsi que ce Manifeste Hacker qui lui va si bien.
Crédit : Simon Gee Giraudot (Creative Commons By-Sa)
Le Framablog a pris l’habitude de suivre les travaux de Bernard Stiegler au sein d’Ars Industrialis. Il faut dire que ça n’est pas tous les jours qu’un philosophe affirme que « le logiciel libre peut redonner sens à nos vies » !
Nous vous proposons ci-dessous le réplication d’une vidéo de Simon Lincelles intitulée « Introduction à l’économie contributive » et co-écrit par Bernard Stiegler.
Malgré quelques inexactitudes, nous partageons l’hypothèse que le logiciel libre (et Wikipédia) représentent un espoir et un modèle pour l’avenir de notre économie.
Remarque : cette vidéo (lien direct Vimeo) est le troisième épisode d’une série initiée ici.
Au delà de l’émotion des circonstances, voici la traduction d’une note d’Aaron Swartz qui pose la question du devenir de nos données après notre mort.
Et pour ce qui concerne le code, le léguer à la FSF est une bonne idée ;)
Cet article est rangé dans le répertoire « 2002 » de son site. Il avait alors 16 ans !
Aaron Swartz - 2002 - Site personnel
(Traduction : Moosh, lgodard, zozio nocture (aka brandelune), aKa, Sky)
Si je me fais renverser par un camion… lisez cette page.
Il y a une vieille blague chez les programmeurs sur qui va gérer le code si son auteur se fait renverser par un camion. Cette page est ici pour assurer que tout le monde sache quoi faire si, pour une raison donnée, je ne suis plus en mesure de conserver mes services Web en fonctionnement.
Je désigne Sean B. Palmer comme mon exécuteur testamentaire virtuel pour l’organisation de ces choses (et Sean, si tu effaces quoi que ce soit, je te hanterai de ma tombe !)
Je demande que le contenu de tous mes disques durs soit rendu public sur aaronsw.com.
Web.Resource.org Sean (ou la personne qu’il désignera) deviendra le nouveau webmaster. Continue de mettre à jour le site et la liste des miroirs, et garantis la persistance des URLs. (Ceci implique que rien de controversé ou d’illégal ne doive être ajouté, à part pour Cryptome.)
Code Source Le copyright pour mon code source sous GPL doit être transféré à la Free Software Foundation. Elle semble avoir une politique raisonnable concernant la mise à disposition du code.
Sites Web Merci de laisser les sites Web opérationnels quand c’est possible, sans modifier les contenus que j’ai écrit quand approprié. Des pages dédiées (par exemple sur aaronsw.com) pourront contenir une note sur ce qui m’est arrivé avec un lien vers des plus d’information. La page d’accueil sur aaronsw.com devra être modifiée avec un lien vers l’ancienne page.
Tombe Je voudrais reposer dans un endroit qui ne me tuera pas. Ce qui veut dire avoir un accès à de l’oxygène (bien qu’un accès direct serait probablement une mauvaise chose), et ne pas avoir à traverser 6 pieds de saleté.
Pour le reste, envoyez un e-mail à Sean. Je suis certain qu’il fera quelque chose de raisonnable.
Si quelque chose m’arrive, merci de mettre à jour le pied de page de cette note avec un lien. Envoyez également un e-mail aux listes concernées et mettez en place une réponse automatique pour mon adresse e-mail afin d’informer les personnes qui m’écrivent. N’hésitez pas à publier les choses que les gens disent à mon propos sur le site. Tout ceci est probablement évident, et je suis certain que vous vous en sortirez.
Oh, et au fait, vous me manquerez tous.
Crédit photo : Doc Searls (Creative Commons By)
Un certain nombre de textes tournent actuellement sur le Net suite au décès d’Aaron Swartz. Parmi eux on trouve « La Conscience d’un hacker » (ou « Le Manifeste du hacker ») datant de… 1986 et que d’aucuns trouvent particulièrement adapté aux circonstances. Et pour cause…
Nous vous le proposons traduit ci-dessous[1]. Il a été rédigé par Loyd Blankenship, (alias The Mentor) juste après son arrestation.
« Oui, je suis un criminel. Mon crime est celui de la curiosité. »
Remarque : Nous sommes en 1986 et c’est par le téléphone que passe le réseau. Un téléphone qui se retrouve alors bloqué par ces « sales gosses » pour la communication classique.
The Mentor - 8 janvier 1986 - Phrack.org
(Traduction : NeurAlien, Moosh, ga3lig, goofy, zozio nocture (aka brandelune), Slystone, KoS, aKa, Martin, lamessen, Sky)
Ce qui suit a été écrit peu de temps après mon arrestation…
Un autre s’est fait prendre aujourd’hui, c’est partout dans les journaux.
« Scandale : Un adolescent arrêté pour crime informatique », « Arrestation d’un hacker après le piratage d’une banque »…
Satanés gosses, tous les mêmes.
Mais vous, dans votre psychologie de costume trois pièces et votre conscience technologique des années 50, avez-vous un jour pensé à regarder le monde avec les yeux d’un hacker ?
Ne vous êtes-vous jamais demandé ce qui l’avait fait agir et quelles forces l’avaient animé ?
Je suis un hacker, entrez dans mon monde…
Mon monde, il commence avec l’école… Je suis plus éveillé que la plupart des autres enfants et les nullités qu’on nous enseigne m’ennuient…
Satanés gamins, ce sont tous les mêmes.
Je suis au collège ou au lycée. J’ai écouté les professeurs expliquer pour la quinzième fois comment réduire une fraction.
J’ai bien compris. « Non Mme Dubois, je n’ai pas montré mon travail. Je l’ai fait dans ma tête ».
Satané gosse. Il a certainement copié. Ce sont tous les mêmes.
J’ai fait une découverte aujourd’hui. J’ai trouvé un ordinateur.
Attends une minute, c’est cool. Ça fait ce que je veux. Si ça fait une erreur, c’est parce que je me suis planté.
Pas parce qu’il ne m’aime pas…
Ni parce qu’il se sent menacé par moi…
Ni parce qu’il pense que je suis un petit malin…
Ni parce qu’il n’aime pas enseigner et qu’il ne devrait pas être là…
Satané gosse. Tout ce qu’il fait c’est jouer. Ce sont tous les mêmes.
Et c’est alors que ça arrive. Une porte s’ouvre…
Les impulsions électroniques déferlent sur la ligne téléphonique comme l’héroïne dans les veines d’un drogué.
Pour trouver dans un Forum le refuge contre la stupidité quotidienne.
« C’est ça… C’est ici que je dois être…»
Ici, je connais tout le monde… Même si je n’ai jamais rencontré personne. Je ne leur ai jamais parlé, et je n’entendrai peut-être plus parler d’eux un jour… Je vous connais tous.
Satané gosse. Encore pendu au téléphone. Ce sont tous les mêmes.
A l’école, on nous a donné des pots de bébé alors qu’on avait les crocs pour un steak…
Les morceaux de viande que vous avez bien voulu nous tendre étaient pré-mâchés et sans goût.
On a été dominé par des sadiques ou ignoré par des apathiques.
Les seuls qui avaient des choses à nous apprendre trouvèrent en nous des élèves de bonne volonté, mais ceux-ci étaient comme des gouttes d’eau dans le désert.
C’est notre monde maintenant… Le monde de l’électron et des commutateurs, la beauté du baud. Nous utilisons un service déjà existant, sans payer ce qui pourrait être bon marché si ce n’était pas géré par des profiteurs avides, et c’est nous que vous appelez criminels.
Nous explorons… et vous nous appelez criminels.
Nous recherchons la connaissance… et vous nous appelez criminels.
Nous existons sans couleur de peau, sans nationalité, sans dogme religieux… et vous nous appelez criminels.
Vous construisez des bombes atomiques, vous financez les guerres, vous assassinez et trichez, vous manipulez et vous nous mentez en essayant de nous faire croire que c’est pour notre propre bien… et pourtant c’est nous qui sommes les criminels.
Oui, je suis un criminel. Mon crime est celui de la curiosité.
Mon crime est celui de juger les gens selon ce qu’ils pensent et disent, pas selon leur apparence.
Mon crime est d’être plus malin que vous, quelque chose que vous ne me pardonnerez jamais.
Je suis un hacker, et ceci est mon manifeste.
Vous pouvez arrêter un individu, mais vous ne pouvez pas tous nous arrêter…
Après tout, nous sommes tous les mêmes.
The Mentor
Crédit photo : Elizabeth Brossa (Creative Commons By-Nc-Sa)
[1] Il en existait une première traduction mais elle était « perfectible ».
Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.
Traduction Framalang : , , , , , , , , , , , , , + Cédric Corazza
Kai Blin
Kai Blin est un bio-informaticien qui mène des recherches sur les antibiotiques dans le cadre de ses activités quotidiennes, tant sur ordinateur qu’au labo. Il est très heureux de pouvoir diffuser le logiciel développé dans le cadre de ses activités professionnelles sous licence open source. Vivant dans la charmante ville de Tübingen, dans le sud de l’Allemagne, Kai passe une partie de ses soirées sur l’ordinateur, à programmer pour le projet Samba. Il consacre la majorité de son temps libre restant au théâtre, où il participe aussi bien à la performance scénique qu’à la construction d’accessoires et à la régie technique dans les coulisses.
Écrire des correctifs et les proposer est souvent la première interaction concrète que vous pouvez avoir avec un projet open source. C’est la première impression que vous donnez aux développeurs présents. Proposer de « bons » premiers correctifs, ou tout du moins jugés comme tels par le projet auquel vous contribuez, vous rendra la vie plus facile. Les règles précises d’écriture du correctif, de la façon de le soumettre au projet et tous les autres détails nécessaires vont sans doute varier selon les divers projets auxquels vous voulez contribuer. Mais j’ai trouvé quelques règles générales que l’on retrouve presque à chaque fois. Et c’est ce dont traite cet article.
Le fil rouge de ce livre est « ce que j’aurais aimé savoir avant de commencer », aussi permettez-moi de commencer par l’histoire de mes premiers correctifs. J’ai été impliqué sérieusement dans l’écriture de code pour la première fois pendant le Google Summer of Code™ de 2005. Le projet Wine avait accepté que j’implémente un chiffrement NTLM basé sur des outils connexes à Samba. Wine est un projet à committer unique, ce qui signifie que seul le développeur principal, Alexandre Julliard, possède les autorisations de commit sur le dépôt principal. En 2005, Wine utilisait encore CVS comme système de gestion de versions. Quand le projet a démarré et que j’ai reçu le courriel me disant que j’étais accepté, j’ai contacté mon mentor sur IRC et me suis mis au travail.
J’alignais joyeusement les lignes de code et bientôt j’ai pu implémenter les premières fonctionnalités. J’ai produit un correctif et l’ai soumis à mon mentor pour qu’il fasse une relecture. Au temps du CVS, il fallait renseigner toutes les options de diff(1) manuellement, mais je m’étais particulièrement documenté sur la partie cvs diff -N -u > ntlm.patch. De cette façon, j’avais le fichier que je pouvais envoyer à mon mentor. En fait, c’est quelque chose que j’ai bien fait. Et c’est la première chose que vous devriez prendre en compte quand vous préparez un correctif. Le résultat classique de la commande diff est sans doute plus facile à lire pour un ordinateur, mais je n’ai jamais rencontré un humain préférant le résultat classique au résultat d’un diff unifié. Grâce à l’option -u , diff utilise les notations + + + et - - -
Par exemple, le diff qui suit est le résultat de la réécriture de « Hello, World! » en Python, version suédoise.
diff —git a/hello.py b/hello.py index 59dbef8..6334aa2 100644 --- a/hello.py +++ b/hello.py @@ -1,4 +1,4 @@ #!/usr/bin/env python # vim: set fileencoding=utf-8 -print "Hello, world!" +print "Halla, varlden!"
La ligne qui commence par « - » est la ligne supprimée, celle qui commence par « + » est celle qui va être ajoutée. Les autres lignes permettent à l’outil de correction de faire son travail.
J’ai envoyé le diff unifié que je venais de créer à mon mentor qui m’en a fait une review(2) en me signalant beaucoup d’éléments à modifier. J’ai effectué les corrections et lui ai renvoyé un nouveau diff peu de temps après. Le cycle d’analyse du code a continué durant toute la durée du GSoC et mon correctif ne cessait de grossir. Quand la date de livraison est arrivée, je me suis retrouvé avec un correctif monstrueux dans lequel étaient inclus tous mes changements. Naturellement, j’ai eu beaucoup de mal à obtenir une review de mon correctif, sans parler de le faire accepter. Pour finir, Alexandre refusa de regarder plus avant le correctif tant que je ne l’aurais pas scindé. Les règles en usage chez Wine exigent que les correctifs soient de petites étapes logiques ajoutant une fonctionnalité. Chaque correctif doit faire quelque chose d’utile et pouvoir être compilé.
De fait, scinder un énorme correctif existant en différentes parties cohérentes individuellement et qui peuvent être compilées représente beaucoup de travail. C’était même d’autant plus de travail que je ne connaissais qu’une seule manière de le faire : écrire un petit correctif, créer le diff, le proposer à la validation, mettre à jour ma contribution locale et écrire alors le correctif suivant. Peu de temps après que j’ai commencé à envoyer mes premiers petits correctifs, Wine est entré dans une phase de gel des fonctionnalités d’un mois menant à la version 0.9.0 bêta. Je suis resté sur le correctif suivant pendant un mois avant de pouvoir continuer et j’ai finalement envoyé mon dernier correctif en novembre. Complètement frustré par cette expérience, j’ai décidé que je ne voulais plus jamais avoir à faire avec la communauté Wine.
Ma frustration perdura jusqu’à ce que des personnes qui utilisaient réellement mon code commencent à me poser des questions sur celui-ci en février 2006. Mon code était vraiment utile ! Ils voulaient également davantage de fonctionnalités. Quand Google annonça qu’il reconduirait le GSoC en 2006, mes projets pour l’été étaient clairs. Maintenant que Wine avait basculé de diff à git en décembre 2005, je savais que je ne serais pas ennuyé par des gels de fonctionnalités, puisque je pouvais finalement créer tous mes petits correctifs localement. La vie était belle.
Ce n’est que lorsque je suis tombé sur une interface de git (appelée porcelaine dans le langage git) qui émulait le comportement de Quilt que j’ai appris qu’il y avait des outils qui auraient pu rendre ma vie plus facile, même en 2005.
Maintenant que je vous ai raconté comment j’ai réussi à me planter avec l’envoi de correctifs, permettez-moi de poursuivre avec quelques conseils pour éviter les pièges.
Mon premier conseil est de lire attentivement toutes les directives de soumission de correctifs que peut avoir le projet auquel vous voulez contribuer. Celles-ci, ainsi que les normes de style de codage, doivent être consultées avant même de commencer à coder.
Même si ce n’est pas explicitement indiqué dans les directives de soumission des correctifs, vous devez vraiment, vraiment envoyer le résultat d’un diff unifié. Je n’ai encore rencontré aucun projet qui préfère la sortie non unifiée du diff. Les diffs unifiés rendent la révision du correctif beaucoup plus facile. Ce n’est pas par hasard que les programmes de gestion de version modernes utilisent automatiquement ce format dans leurs commandes diff par défaut.
En ce qui concerne la gestion de versions moderne, vous devriez vraiment utiliser un système de gestion de versions distribué (DVCS) pour travailler localement sur le code. Git et Mercurial sont les choix les plus populaires de nos jours, quoique Bazaar puisse aussi très bien faire l’affaire. Même si le projet auquel vous voulez contribuer utilise toujours un système de gestion de version centralisé, être en mesure d’envoyer vos changements de manière itérative est une très bonne chose. Tous les outils de gestion de versions distribués mentionnés ci-dessus devraient être capables d’importer des changements depuis un SVN ou un CVS. Vous pourrez y aller et apprendre doucement Quilt mais, sérieusement, le futur passe par les systèmes de gestion de versions distribués.
Quand je dois examiner des correctifs, les plus ennuyeux à traiter sont ceux qui sont trop gros ou qui tentent de faire de nombreuses choses en même temps. Les correctifs qui ne font qu’une chose à la fois sont plus faciles à traiter. Au final, ils vous faciliteront la vie quand vous devrez déboguer les erreurs qu’auront manquées à la fois l’auteur et le vérificateur.
Après avoir proposé votre correctif, gardez un œil sur les canaux de communication du projet et sur votre correctif. Si vous n’avez eu aucun retour au bout d’une semaine, vous devriez poliment en demander un. En fonction de la façon dont le projet gère les propositions de correctif, celui-ci pourrait être noyé dans le bruit. N’espérez pas voir votre correctif retenu du premier coup. Il faut, en général, quelques essais pour s’habituer au style d’un nouveau projet. En tant que contributeur néophyte, personne ne vous en voudra pour ça, à condition d’avoir presque tout bon. Assurez-vous seulement de corriger ce que les développeurs vous ont indiqué et envoyez une seconde version du correctif.
Écrire de bons correctifs n’est pas difficile. Il y a deux ou trois choses à prendre en considération. Mais après en avoir écrit quelques-uns vous devriez être au point sur celles-ci. Un système moderne de contrôle de version (distribué) et le workflow (Ndt : flux de production) qui en résulte gèreront de fait la plupart des choses que j’ai mentionnées. Si vous n’avez qu’une chose à retenir, c’est ceci :
Les quelques lignes directrices ci-dessus devraient vous aider à bien faire la plupart des choses, sinon toutes, quand vous soumettrez vos premiers correctifs. Bon codage.
(1) Un diff (abréviation de différence) est un fichier qui affiche le résultat d’une comparaison entre deux éléments (en général, des lignes de code). Pour en savoir plus : http://fr.wikipedia.org/wiki/Diff
(2) Review : révision minutieuse http://fr.wiktionary.org/wiki/review