Il est très de trouver un utilisateur de Windows qui ne connaît pas l’utilitaire CCleaner. Je me souviens encore que quand j’étais sous Windows, c’était un des premiers logiciels que j’installai juste après Firefox et VLC. Cependant CCleaner à deux grands défauts insurmontables, le premier c’est qu’il est pas intéropérable, c’est à dire qu’il est impossible de le faire fonctionner sur un système d’exploitation autre que Windows. Son deuxième défaut, qui à mes yeux est plus important que le premier point, c’est qu’il est pas libre.

C’est pourquoi il m’a fallu trouver un équivalent libre à CCleaner il y a quelques semaines, quand j’ai dû aller à la rescousse d’un ami windowsien (un windows XP, je n’ai pas eu la (mal)chance de toucher à windows 7). Heureusement pour moi, deux petites minutes de recherche sur Duckduckgo.com m’ont suffu pour trouver BleachBit.

BleachBit permet de nettoyer le disque dur (Dans mon cas, j’ai gagné plus de 400 Mo, quant au pc de mon pote sous windows, c’était 1.4 Go d’espace disque libéré). Mais aussi protéger votre vie privée en effaçant toutes vos traces numériques. Pour ça, BleachBit va vider le cache, les cookies, fichiers temporaires, logs, historique de navigation… tous passe à la trappe, ainsi que quelques fonctions avancées. En tout, BleachBit permet de faire le ménage dans 90 applications. Pour une liste complète de toutes ses fonctionnalités, visitez cette page.

En plus de sa version pour Windows, BleachBit est disponible pour toutes les distributions majeurs (Debian GNU/Linux, Fedora, Ubuntu, Mandriva, OpenSUSE…). Rendez vous sur la page de téléchargement et récupérez le paquet qui corresepend à votre distribution.

Pour l’installer par exemple sous Ubuntu, lancez une console, puis placez vous dans le répertoire de téléchargement, enfin, tapez cette ligne de commande :

sudo dpkg -i bleachbit_0.9.1-1_all_ubuntu1110.deb

Enjoy it

Related posts:

1. DNS alternatifs : optimiser votre connexion
2. Transférer musique et vidéo vers votre iPhone et iPod depuis GNU/Linux
3. Prey : un antivol pour votre laptop et smartphone

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.

Disponible en pré-commande, la Pandora Handheld (littéralement : « qui tient dans la main ») est une sorte d’hybride entre Nintendo DS et EEE-PC… Gadget inutile ou concept innovant? On peut se poser la question.

Notre description se base sur les données du site, sans avoir pu tester un modèle en vrai.

Le format est très semblable à la DS, avec un seul écran (tactile) et un clavier sur la partie basse. Ça ressemble à un mini netbook, sans touchpad. Le clavier semble prévu pour être utilisé avec les pouces, les touches ressemblent plus à un clavier de téléphone portable qu’à celui d’un ordinateur. La partie haute comporte des « pads » comme sur les manettes de jeu vidéo.

Connectique

- 2 ports SDHC
- 1 sortie JACK 3,5mm (réglage du son par un bouton rotatif, difficile de dire s’il s’agit d’un vrai potentiomètre ou d’un système à impulsions)
- 1 port USB host pour brancher une clé usb ou tout autre périphérique
- 1 port USB On-The-Go qui peut servir à charger l’appareil
- une sortie TV Composite + S-video, et c’est vraiment dommage que le connecteur soit un format propriétaire

Composants

- 512 Mo de SD-Ram
- 512 Mo de mémoire interne NAND
- Processeur ARM Cortex A8
- chipset vidéo+son IVA2 de Texas Instruments
- écran tactile 800×480
- carte sans fil WIFI + Bluetooth

Utilisation

L’utilisation principale avancée par le constructeur est le jeu vidéo. Suivent la programmation et la navigation Internet.

Comme console de jeu, on devine une bonne prise en main de l’appareil. Les jeux montrés sur les captures d’écran suggèrent une orientation vers le rétro-gaming via des émulateurs ou des adaptations de vieux jeux. On imagine d’ailleurs mal des éditeurs sortir des productions adaptées à la Pandora, déjà que c’est plus que rare sous GNU/Linux ! Cette machine se destine donc principalement aux geeks nostalgiques.

Pour l’utilisation en tant qu’ordinateur, elle est livrée avec un GNU/Linux customisé. On peut ensuite booter sur d’autres systèmes à noyau Linux depuis les ports SDHC. Attention toutefois : c’est un processeur ARM, qui exige donc un système compilé pour cette architecture.

Personnellement, j’aurais aimé y voir un port Ethernet pour pouvoir être utilisé comme appareil nomade de paramétrage de switches, routeurs… Cela dit la place manque un peu pour loger le port, et on peut très bien utiliser le port USB soit par un cordon USB/RS232 soit un adaptateur USB/Ethernet.

Voici une petite vidéo de illustrant quelques possibilités de la Pandora :

Dispositif de pointage

Il n’est pas dit si les pads « analogiques » peuvent servir de dispositif de pointage. Un stylet est livré avec la Pandora, mais difficile de savoir si on peut utiliser d’autres objets non revêtus d’une matière spéciale. La mention « LCD with resistive touch screen » laisse supposer que ça serait possible car les écrans résisitifs sont composés de deux feuilles transparentes qui se mettent en contact quand on touche la surface.

À noter au passage que les les écrans résistifs sont une technologie un peu dépassée, à l’heure actuelle la plupart des équipements utilisent des écrans capacitifs qui requièrent des pressions moins fortes mais ne sont sensibles qu’à certains matériaux conducteurs (comme la peau).

Conclusion

En résumé, c’est plus une console de jeu « bidouillable » et un mini pc d’appoint plutôt qu’un ordinateur portable. À l’heure où les smartphones offrent des caractéristiques très semblables, on se demande un peu où est l’intérêt. À titre d’exemple, le Nokia E7 est quasiment aussi puissant, dispose également d’un clavier physique, d’un port USB host et d’une sortie micro-hdmi… Le seul intérêt de la Pandora Handheld est donc de pouvoir booter nativement sur le GNU/Linux de notre choix, mais à 445€ ça fait cher les deux ports SD et le clavier/pad. Ça aurait pu être intéressant à un prix 3 fois moindre.

Souhaitons que cette machine ait du succès, mais ça paraît délicat au vu du peu de public visé et des caractéristiques.

Si vous voulez placer votre pré-commande, il faut faire un dépôt de 10€ (remboursables en cas d’annulation) et la somme ne sera débitée que lorsque votre machine sera prête. Formulaire à remplir sur cette page, en anglais uniquement.

Source : http://openpandora.org

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 :

PHP aussi moche soit-il est beaucoup utilisé et on n'a parfois d'autre choix que faire ce qu'on nous dit. L'un des problèmes qu'on rencontre est le manque d'un shell interactif pour tester un concept vite fait bien fait.

Heureusement, j'ai trouvé un projet (libre) qui permet d'obtenir un shell et de tester ce qu'on veut dedans.

Pour l'installer, assurez-vous d'avoir PEAR et faites comme suit:

$ wget http://jan.kneschke.de/assets/2007/2/17/PHP_Shell-0.3.1.tgz
$ sudo pear install PHP_Shell-0.3.1.tgz

et lancez avec

$ php-shell.sh
PHP-Shell - Version 0.3.1, with readline() support
(c) 2006, Jan Kneschke <jan@kneschke.de>

>> use '?' to open the inline help 

>> 

Et maintenant vous pouvez faire ce que vous voulez. Consultez le site officiel pour plus d'informations

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.

(Bon, j’espère que le titre de cet article est grammaticalement exact)

Cela fait plusieurs semaines que je n’ai rien publié sur ce site et je n’y publierai plus rien.

Je travaille depuis plusieurs semaines sur un autre projet, toujours web, et je compte bien utiliser les différentes choses apprises grâce à ce blog pour atteindre mes objectifs.

Je suis reconnaissant à ceux qui ont pris le temps de lire (20 000 personnes en 2011, 11 000 en 2010) et quelques fois de commenter le contenu de ce site.

Les articles les plus consultés sont les suivants :

Brice Delmotte d’Ordissimo : « nous allons lancer notre tablette »

Ubuntu Netbook Edition 10.10 face à Jolicloud 1.0

Un mois avec Ubuntu Netbook Edition 10.04

OS pour netbook : il y a encore du boulot

GNU/LINUX et les seniors :  un rendez-vous manqué?

Les articles les plus commentés :

Les licences libres : une synthèse pour mieux comprendre

Ubuntu 10.10 : et après?

GNU/LINUX est-il viral?

Les grands paradoxes de GNU/LINUX

Ubuntu : la boite à outil du débutant

Je suis également très content d’avoir découvert la communauté du logiciel libre et d’y avoir contribué (modestement).

Allez, bon vent à tous et …bonne année 2012

J’ai assisté cette semaine à une rencontre avec Chris Di Bona, gourou de l’Open Source chez Google. Cette rencontre était animé par le très bilingue (quel bel accent) Tristan Nitot que je ne présenterais pas en vous disant qu’il est le fondateur de Mozilla Europe…

Je partage donc mes notes avec vous, non exhaustives, et j’espère, fidèles à ce qui a été dit.

Mais d’abord, me direz-vous, ô généreux blogueur au style si lyrique même en temps de crise,  c’est qui donc ce Chris Dibona?

Donc en résumé, c’est le gourou de l’open source chez Google, il est « Open Source Programm Manager ». Visiblement dans les murs depuis assez longtemps et créateur des summer of code (lui ou son équipe, j’ai pas bien compris).

enfin bon, en vrac, voici mes notes :

Google a scanné plus de 30 millions de fichiers et voici les principales licences sous lesquelles ces fichiers sont publiés:

• GPL
• LGPL
• DSB

Ce trio de tête représente plus de 80% des fichiers. C’est énorme et cela laisse assez peu de place aux licences propriétaires.

Pourquoi les rédacteurs de ces lignes de code mettent-il à disposition leur code?

• par curiosité intellectuelle
• Pour améliorer leur compétence
• Besoin de faire travailler son cerveau

Donc, les programmeurs open source sont assez philanthropes. Mais ça, on le savait.

Google utilise aujourd’hui encore des serveurs très proches des PC grand public. Et utilise bien naturellement des logiciel open source (notamment GNU/Linux).

Pourquoi?

Contrôle total & flexibilité font partie des avantages (et non des moindres) que met en avant Chris DiBona.

Comment Google participe à l’open source?

« Reliable scalable clean project hosting

Version control

Issue tracking

Wikis

Over 600 projects! »

Conclusion, n’importe quelle appli’ open source utilise du code Google selon DiBona.

Mais Google crée également de nouveau format pour améliorer l’interopérabilité et l’expérience globale du web :

« WebM pour éviter les formats proprio type HD264

WebP

Webrtc

Omaha

Ganeti

Adk android robot world« 

Enfin, Chris DiBona appuie sur le fait que Google organise le Summer Of Code. Fin de la première partie.

Tristan Nitot revient sur scène, nous voilà lancé dans un phase de question/réponse qui, je l’avoue, m’a plus passionné que la première partie de cette rencontre.

Plusieurs message assez forts, venant notamment de Nitot :

« Le cloud enlève à l’utilisateur le contrôle du logiciel. Ce n’est pas bien. Plusieurs solutions sont possibles. Notamment une solution moins disante qui serait de dire qu’il est acceptable de perdre ce contrôle si le formats des données stockées est ouvert. Ce n’est pas suffisant selon nous. Mozilla essaie de faire des choses comme la synchronisation des favoris etc… Cependant, nous n’avons pas encore trouvé d’autres solutions. La centralisation n’est jamais bénéfique et c’est une vraie question. »

« Mozilla se devait de réagir à Chrome OS. C’est le projet Boot to Gecko. Nous ne l’aurions pas fait sans l’arrivée d’Android et de Chrome OS ».

Je finirais ce compte-rendu approximatif avec cette belle réflexion de Tristan Nitot sur le manque de design supposé et d’ergonomie dans les interfaces des logiciels Open Source :

«  Il y a une gué-guerre presque inévitable entre les designers qui veulent simplifier les interfaces et les développeurs qui souhaitent offrir le plus de fonctionnalités possibles…car ils les ont développées, c’est leur bébés et les designer qui ont en général une approche plus minimaliste. Il est assez dur pour un designer de se faire accepter dans ce monde là.

Firefox a bénéficié justement de son approche minimaliste en terme de fonctionnalités.

En effet, le code est voulu le plus léger possible. Si l’on veut développer une nouvelle fonctionnalité pour Firefox, on doit créer une extension. Cela permet de ne pas alourdir l’expérience globale et que chacun puisse avoir le navigateur qui convient à ses besoins »

Enfin, je vous invite à suivre l’actualité des rencontres organisées par la Cantine.

Sur le même sujet:

• créer son app sur le chrome web store
• les territoires du logiciel libre envahis par Google

Wbfs-manager est un utilitaire permettant de gérer les sauvegardes de ces jeux wii stockées sur disque dur. Il utilise pour cela, la librairie libwfs (WFS pour Wii Backup File).

Avec cette application vous pouvez gérer les isos des jeux Wii depuis votre Fedora !

Installation en ligne de commande : yum install wbfs-manager

Installation avec l'interface graphique : Autres > A WBFS manager for Linux using GTK+

Localisation dans le menu : Applications > Outils Système > WBFS Manager

Lancement en ligne de commande : /usr/bin/wbfs_gtk

Site web : http://code.google.com/p/linux-wbfs-manager/

Un petit billet inhabituel pour changer, mais toujours en rapport avec le logiciel malgré tout.

Il est des machines qui sont un un point tournant dans l'histoire. La machine à vapeur, l'ordinateur, l'iPad... ah non pas celui-ci. Bref, je vais m'intéresser à LA machine emblèmatique des premiers hackers et fondatrice du logiciel libre, puisque Richard Stallman a programmé les premiers morceaux de GNU dessus (EMACS et GCC). Je veux bien entendu parler du PDP de DEC.

Le labo d'intelligence artificielle du MIT où RMS travaillait avait tout d'abord un PDP-8 avant de passer au PDP-10. Ces ordinateurs sont des mainframes, dédiés à êtres des ordinateurs centraux avec de nombreux terminaux. Ces engins prédatent Unix, et ils étaient souvent accompagnés d'un système d'exploitation nommé CTS, pour "Compatible Time-sharing System", ou Système Compatible à Temps partagé en langue de Molière. Les hackers du MIT quant à eux avaient conçu leur propre système d'exploitation multi-utilisateur qu'ils avaient appelé parodiquement ITS pour "Incompatible Time-sharing System"; bon nombre des fonctionnalités de ce système étaient très en avance sur leur temps comme le support de système de fichiers en réseau, noyau supportant opérations temps réel et partagés, partage des cycles asynchrones pour les tâches utilisateur et débugueur intégré à l'OS (permettant d'arrêter l'exécution de n'importe quel programme et d'en analyser l'état, avec reprise d'exécution sans conséquence).

On peut toujours trouver ITS et l'installer sur un émulateur de PDP, voire un vrai PDP si on a assez de place chez soi. Mais pour commencer, j'ai préféré jouer avec quelque chose qui nous est plus familier: UNIX6. Cette version d'UNIX est sortie en 1975, et beaucoup d'eau a coulé sous les ponts depuis. J'ai installé l'émulateur simh, présent dans beaucoup de distributions, puis suivi les instructions de gunkies.org afin de pouvoir l'installer. Je vais vous traduire le modus operandi et tenter d'expliquer ce qu'on fait.

Pour la suite, il est intéressant de noter que simh reproduit le fonctionnement de l'appareil. Les boutons roses en dans l'image de l'article étaient en fait utilisés pour programmer le PDP. Un sélecteur permettait de sélectionner un registre ou la mémoire et on chargeait un mot avant de l'envoyer à l'adresse désirée. Vous en verrez l'usage lorsque nous booterons UNIX (le PDP n'avait pas de bios, donc il faut initialiser le boot à la main).

Tout d'abord, récupérez l'image de bande d'UNIX, puis renommez le fichier en dist.tap (faites en une copie de sauvegarde au cas où) démarrons simh, sur Fedora, la commande est:

simh-pdp11

Maintenant, nous allons charger le bootloader d'UNIX dans le disque du PDP comme suit:

set cpu 11/40
set tm0 locked
attach tm0 dist.tap
attach rk0 rk0
attach rk1 rk1
attach rk2 rk2
d cpu 100000 012700 
d cpu 100002 172526
d cpu 100004 010040 
d cpu 100006 012740
d cpu 100010 060003
d cpu 100012 000777
g 100000

Toute la série avant les d cpu sont particulières à l'émulateur; on décrit le matériel qu'on souhaite avoir. Notez la partie attach tm0 dist.tap, dans laquelle nous connectons un lecteur de bande avec la bande d'UNIX. Ensuite on passe des instructions en langage machine afin d'initialiser le lecteur de bande et enfin on exécute du code sur la bande.

Le simulateur va se verrouiller à ce moment-ci. Débloquez le en appuyant sur ctrl+e. Puis entrez l'instruction:

g 0

Le PDP va booter et afficher un signe "=". Tapez les instructions comme suit pour formater les bandes:

=tmrk
disk offset
0
tape offset
100
count
1
=tmrk
disk offset
1
tape offset
101
count
3999
=

Enfin appuyez sur ctrl+e, puis entrez q pour quitter l'émulateur. Nous avons maintenant notre disque de boot tout prêt et le lecteur de bande est formaté pour UNIX.

Il est temps maintenant de booter en mode utilisateur seul afin d'installer UNIX à proprement parler. Avant de commencer, quelques avertissements. Le terminal ne se comporte pas de la même manière que d'habitude. Essentiellement car il émule un télétype et qu'on ne peut pas effacer sur le papier, donc pas de touche backspace. La touche backspace marche, mais elle efface toute la ligne sans afficher l'effacement. Le mieux est de relire plusieurs fois ce qu'on tape et de prendre son temps. Sinon effacez avec backspace, puis tapez sur entrée et retapez toute la ligne (ou profitez des terminaux modernes en copiant-collant ;)). Allons-y:

set cpu 11/40
set tto 7b
set tm0 locked
attach tm0 dist.tap
attach rk0 rk0
attach rk1 rk1
attach rk2 rk2
dep system sr 173030
boot rk0

Maintenant vous devriez voir affiché un symbole "@". Démarrez UNIX en mode seul en tapant rkunix. Ensuite on nettoiera le terminal en passant la commande:

STTY -LCASE

Première chose à faire maintenant, recompiler le noyau d'UNIX.

chdir /usr/sys/conf
cc mkconf.c
mv a.out mkconf

Lancez mkconf (pour configurer le futur kernel) et entrez les infos suivantes:

# ./mkconf
rk
tm
tc
8dc
lp
done
#

Maintenant on va compiler la configuration et y lier le reste du noyau comme suit:

as m40.s
mv a.out m40.o
cc -c c.c
as l.s
ld -x a.out m40.o c.o ../lib1 ../lib2
mv a.out /unix

On peut vérifier que le noyau est bien installé et fait 30kb (on est loin des noyaux modernes hein!):

# ls -l /unix
-rwxrwxrwx  1 root    30346 Oct 10 12:43 /unix

Pas d'udev!!! Donc pas de fichiers de périphériques dans /dev. Heureusement, on peut le faire à la main (on n'a pas le choix d'ailleurs). Je vous conseille de copier/coller cette partie là.

/etc/mknod /dev/rk0 b 0 0
/etc/mknod /dev/rk1 b 0 1
/etc/mknod /dev/rk2 b 0 2
/etc/mknod /dev/mt0 b 3 0
/etc/mknod /dev/tap0 b 4 0
/etc/mknod /dev/rrk0 c 9 0
/etc/mknod /dev/rrk1 c 9 1
/etc/mknod /dev/rrk2 c 9 2
/etc/mknod /dev/rmt0 c 12 0
/etc/mknod /dev/lp0 c 2 0
/etc/mknod /dev/tty0 c 3 0
/etc/mknod /dev/tty1 c 3 1
/etc/mknod /dev/tty2 c 3 2
/etc/mknod /dev/tty3 c 3 3
/etc/mknod /dev/tty4 c 3 4
/etc/mknod /dev/tty5 c 3 5
/etc/mknod /dev/tty6 c 3 6
/etc/mknod /dev/tty7 c 3 7
chmod 640 /dev/*rk*
chmod 640 /dev/*mt*
chmod 640 /dev/*tap*

Et maintenant on va copier le reste d'UNIX sur les disques du PDP. Attention aux commandes dd, surnommé à juste titre "disk destroyer". Prenez votre temps ou copiez/collez.

dd if=/dev/mt0 of=/dev/rk1 count=4000 skip=4100
/etc/mount /dev/rk1 /usr/source
dd if=/dev/mt0 of=/dev/rk2 count=4000 skip=8100
mkdir /usr/doc

On va monter le reste du système et configurer les montages automatiques (très lointain ancètre du système d'init et fstab, vous allez voir...)

/etc/mount /dev/rk1 /usr/source
/etc/mount /dev/rk2 /usr/doc

# cat >> /etc/rc
/etc/mount /dev/rk1 /usr/source
/etc/mount /dev/rk2 /usr/doc

Entrez la combinaison de touche ctrl+D pour en finir avec cette dernière commande. Nous allons maintenant nous occuper de la commande df qui ne savait pas deviner où étaient les disques, donc on doit lui indiquer leurs emplacements dans le code et recompiler. Pour cela nous allons devoir utiliser l'éditeur texte ed. Gardez bien la tête froide et prenez votre temps. Si vous trouviez VI ou EMACS hardcore, ed va vous ôter ce qui vous reste de cheveux.

# chdir /usr/source/s1
# cp df.c df.c.bak
# ed df.c
/rp0/d
.-2a
  "/dev/rk0",
  "/dev/rk1",
.
w
q
# cc df.c
# cp a.out > /bin/df

Notez que j'ai fait une copie de sauvegarde au cas où. À présent nous allons vérifier les systèmes de fichiers (pas de fsck non plus à l'époque):

icheck /dev/rrk0
dcheck /dev/rrk0
icheck /dev/rrk1
dcheck /dev/rrk1
icheck /dev/rrk2
dcheck /dev/rrk2

Enfin nous allons activer le mode multi-utilisateur et rebooter. Enfin rebooter... Disons qu'on sync les disques plusieurs fois avant d'éteindre violemment l'appareil (ctrl+e puis q).

# ed /etc/ttys
1,8s/^0/1/p
w
q
#
# sync
# sync
# sync
# sync

Maintenant on peut utiliser UNIX normalement, en multi-utilisateur. Vous pouvez d'ailleurs vous y connecter en telnet sur le port 5555. Copiez le code qui suit dans un fichier boot.ini, puis lancez avec la commande simh-pdp11 boot.ini:

set cpu 11/40
set cpu idle
set tto 7b
set tm0 locked
attach rk0 rk0
attach rk1 rk1
attach rk2 rk2
attach lpt printer.txt
set dci en
set dci lines=8
set dco 7b
att dci 5555
boot rk0

Le lancement ressemble à:

PDP-11 simulator V3.8-1
Disabling XQ
Listening on port 5555 (socket 108)
@unix

login: root
#

Connectez-vous en tant que root, sans mot de passe.

Bon il n'y a pas tellement à faire, mais c'est intéressant de voir ce qui a changé (assez peu en fait) en 37 ans. Je suis en train de voir si je pourrais éventuellement porter la toute première version de VI (appelé ex) de 1BSD vers UNIX6, mais ça n'est pas tâche facile. Je vous tiendrais au courant!