Tweekers' Blog

Aller au contenu | Aller au menu | Aller à la recherche

AH ! Un menu indispensable pour les webmasters

Ou comment écrire un programme utile en 100 lignes de Python. AH pour Apache Helper et non Apache Helicopter est un menu et permettant de réaliser les opérations les plus courantes sur ses sites web. Le programme utilise AppIndicator ce qui fait qu'il sera directement utilisable sur une distribution récente telle que Lucid Lynx. Je laisse la migration du programme vers un plus classique gtk.StatusIcon comme exercice pour le lecteur ;)

ah Voici a quoi ressemble AH, il dispose des fonctionnalités suivantes :

  • édition de son fichier /etc/hosts
  • redémarrer Apache
  • changer le propriétaire de tous les fichiers servis par Apache à l'utilisateur www-data
  • ouvrir le répertoire d'un site dans son navigateur de fichiers
  • ouvrir un site dans son navigateur web
  • inspecter les logs d'erreur
  • nettoyer les logs d'erreur
  • éditer le fichier de configuration du vhost


Il y a quelques prérequis afin de profiter pleinement de cette application. Vous devez disposer du script permsite qui va modifier la permission des fichiers. Si ce n'est pas déjà fait, ajoutez vous au groupe www-data. Il faut aussi changer le chemin vers ce script qui est pour l'instant codé en dur dans l'application (os.system("xterm /home/strider/bin/permsite")).
Vous pouvez télécharger ah et apprécier le gain de temps pour l'administration de votre serveur de développement :)

Le programme étant sous GPL V3, vous devez évidemment me faire par des améliorations que vous apporterez au programme. Si vous n'avez pas les compétences requises en Python pour améliorer vous même le script, laissez une demande de fonctionnalité dans les commentaire et si elle est pertinente, je me ferai une joie de l'implémenter :)

Mettre a jour un paquet sur Ubuntu: Exemple avec Inkscape

Un des derniers billets publiés sur le Planet Libre explique comment compiler Inkscape sur Ubuntu. Ici nous allons voir une autre méthode qui va consister a créer un paquet avec la nouvelle version d'Inkscape. Cette méthode présente plusieurs avantages, d'une part vous pourrez partager ce paquet avec vos proches de façon à ce qu'ils n'aient pas recours a la compilation, d'autre part il sera très simple de désinstaller ce paquet pour revenir si vous le souhaitez a la version supportée par Ubuntu. Enfin, cette méthode est idéale pour apprendre les méthodes utilisées par les vrais packageurs.

La première étape consiste à récupérer la dernière version des sources. Dans notre cas, Inkscape utilise le système de gestions de versions bzr. Pour récupérer uniquement la dernière version taper :

bzr checkout –lightweight lp:inkscape

Une fois que les sources sont téléchargés compressez le répertoire inkscape et renommez l'archive en inkscape_0.48~bzr9116.orig.tar.gz
Le nom de l'archive est très important pour que les outils de packaging puissent fonctionner correctement. Cette archive est nommée <nom-du-paquet-source>_<version>.orig.tar.gz.
Vous pouvez maintenant supprimer le dossier inkscape. La partie ~bzr9116 corresponds au numéro de révision du snapshot bzr, il est utile de le préciser pour ne pas entrer en conflit avec un paquet de la version 0.48 finale.
Quelques outils seront nécessaire a la construction du paquet, installez les :

sudo apt-get install devscripts dh-make dpatch pbuilder

Nous allons aussi avoir besoin du paquet source d'origine fourni par Ubuntu, tapez dans le même dossier:

apt-get source inkscape


Placez vous dans le dossier inkscape-0.47 (ou le dossier correspondant à la version d'Ubuntu que vous utilisez) et tapez uupdate ../inkscape_0.48~bzr9116.orig.tar.gz -v 0.48~bzr9116
Comme le format du numéro de version n'est pas standard, nous devons préciser le numéro de version avec l'option -v.

Nous allons maintenant nous placer dans ../inkscape-0.48~bzr9116. Tout d'abord éditez le fichier debian/changelog et vérifiez la dernière entrée :

inkscape (0.48-0ubuntu1) karmic; urgency=low

  * New upstream release

 -- Mathieu Comandon <strycore@gmail.com>  Sat, 27 Feb 2010 16:16:48 +010

L'adresse mail doit être valide, ce sera le cas si vous avez renseigné dans le fichier .bashrc les variables suivantes :

export DEBFULLNAME="Mathieu Comandon"
export DEBEMAIL="strycore@gmail.com"

En théorie, l'opération de mise a jour du paquet est quasiment terminée. Mais si nous construisons notre paquet source dès maintenant pour compiler, pbuilder va rencontrer de nombreux problèmes. Les opérations qui suivent sont spécifique à la mise a jour d'Inkscape 0.47 vers 0.48~bzr.

Les problèmes que pbuilder rencontre concernent tous la 'recette' de compilation donnée dans le fichier debian/rules. Voici un diff de l'ancien fichier avec une version fonctionnelle :

rules.orig rules 
--- ../../rules.orig	2010-02-28 13:12:31.294522000 +0100
+++ rules	2010-02-28 13:12:27.798523967 +0100
@@ -57,10 +57,14 @@
 		    --with-gnome-vfs				  \
 		    --enable-lcms
 
+configure:
+	autoreconf -vfi
+	glib-gettextize --copy --force
+	intltoolize --copy --force --automake
 
 build:  config.status
 	dh_testdir
-	cd po; intltool-update -p
+	
 ifneq "$(wildcard /usr/share/misc/config.sub)" ""
 	cp -f /usr/share/misc/config.sub config.sub
 endif
@@ -72,6 +76,7 @@
 #	$(MAKE) -C src extension/plugin/libgimpgrad.la
 	$(MAKE) CXXFLAGS="$(CXXFLAGS) $(MIPS_CXXFLAGS) $(ALPHA_CXXFLAGS)" \
 	        CFLAGS="$(CFLAGS) $(MIPS_CFLAGS) $(ALPHA_CFLAGS)"
+	cd po; intltool-update -p
 
 clean: clean-patched unpatch
 	chmod 644 $(CURDIR)/debian/patches/*
@@ -96,6 +101,9 @@
 
 	# Add here commands to install the package into debian/inkscape.
 	$(MAKE) install DESTDIR=$(CURDIR)/debian/inkscape
+	install -d $(CURDIR)/debian/inkscape/usr/share/pixmaps 
+	install -d $(CURDIR)/debian/inkscape/usr/share/application-registry
+	install -d $(CURDIR)/debian/inkscape/etc/bash_completion.d
 	install -o root -g root -m 644 $(CURDIR)/debian/inkscape.xpm $(CURDIR)/debian/inkscape/usr/share/pixmaps/inkscape.xpm
 	install -o root -g root -m 644 $(CURDIR)/debian/inkscape.applications $(CURDIR)/debian/inkscape/usr/share/application-registry/inkscape.applications
 	install -D -o root -g root -m 644 $(CURDIR)/debian/inkscape.bash $(CURDIR)/debian/inkscape/etc/bash_completion.d/inkscape
@@ -162,7 +170,7 @@
 	dh_testroot
 	dh_installchangelogs ChangeLog
 	dh_installdocs
-	dh_desktop
+#	dh_desktop
 #	dh_installexamples
 	dh_install
 	dh_installmenu


Regardons en détail les changements apportés. Si nous regardons les sources de la version bzr, nous constatons qu'il n'y a pas de fichier "configure" mais qu'il y en à un dans la version 0.47. Une possible raison de cette différence peut être trouvée dans le fichier /usr/share/doc/autotools-dev/README.Debian.gz :

2. Tolerate the big diff size, and run the autotools stuff before you
   create the Debian source package.

   Nowadays, there is no reason to do this, please use method 1 above
   instead.  In fact, method 2 can cause problems for the quilt-style
   patching system of dpkg source v3.0 format.

Comme il est précisé dans ce document, nous allons avoir recours a une méthode alternative et générer le script configure durant la construction du paquet en ajoutant une règle "configure". Cette règle pourrait appeler le script ./autogen.sh mais hyperair m'a conseillé sur #ubuntu-motu d'utiliser le script autoreconf. J'ai rajouté les lignes "glib-gettextize --copy --force" et "intltoolize --copy --force --automake" présentes dans le script autogen.sh pour que la traduction des fichiers puissent être effectuée correctement.

Une autre différence existante entre la 0.47 et la 0.48 est qu'il manque certains fichiers utilisés par la commande intltool-update -p , ces fichiers sont générés pas la compilation, j'ai donc déplacé cette commande pour qu'elle soit exécutée après make.
Autre changement, pbuilder n'arrive pas a copier certains fichier, il a fallu rajouter la création de certains dossier avec "install -d" et enfin, changement minime, j'ai commenté la ligne dh_desktop :

dh_desktop was a debhelper program that registers .desktop files.  However, it no longer does anything, and is now deprecated.

La suppression de dh_desktop ne change rien sur le résultat mais supprime un avertissement donné par lintian (l'outil qui valide les paquets source). Il y a deux autres avertissements a supprimer :

  • Mettez a jour le numéro de la Debian Policy dans debian/control
  • Créez un fichier debian/README.sources qui est une copie du fichier /usr/share/doc/dpatch/README.source.gz


Voila, nous sommes maintenant prêt a construire notre paquet source, tapez :

debuild -S -us -uc

ou si vous avez une clé GPG opérationnelle :

debuild -S


Nous avons créer un environnement de compilation, on peut voir cela comme une installation d'Ubuntu minimale et indépendante de notre système ou un chroot pour ceux qui connaissent.

sudo pbuilder create

Cette opération peut prendre quelques minutes. Si vous aviez déjà créé un environnement pbuilder, n'oubliez pas de le mettre a jour avant de créer un nouveau paquet :

sudo pbuilder update

Et enfin nous allons lancer la compilation du paquet, attention inkscape n'est pas un petit programme, il ne se compile pas en 5 minutes ;)

sudo pbuilder build ../inkscape_0.48.0~bzr9116-0ubuntu1.dsc

Si tous se passe bien, la construction du paquet binaire devrais s'effectuer avec succès, vous pouvez le récupérer dans /var/cache/pbuilder/result. Vous pouvez maintenant installer proprement la pré release d'Inkscape 0.48 :)

P.S. : La procédure expliquée dans ce billet n'a aucune raison de ne pas fonctionner sur Debian, les outils sont strictement les mêmes.

Ubuntu Party a Montpellier le 9 Janvier

A peine quitté la ville de Montpellier pour la région Bordelaise que me voila de retour. En effet je serai présent le 9 à l'Ubuntu Party organisée par l'association Montpel'libre. Cela se passera à la médiathèque Emile Zola (arrêt de Tram Place de l'Europe) de 10h à 18h.

Venez de préférence avec votre PC ;)
Je serai a disposition pour apporter de l'aide sur Ubuntu ou Debian d'une manière générale et en particulier les points suivants :

  • Utilisation de Launchpad : création d'un compte, rapport de bugs, création de projets, utilisation de bzr, création d'un PPA.
  • Les outils Debian : apt-get, apt-cache, apt-file, comment créer un mirroir local de la distribution.
  • La programmation en Python : Configurer Eclipse ou Netbeans pour le Python, créer des interfaces graphiques en GTK, créer un projet avec Quickly
  • Créer des scripts en bash, automatiser des taches
  • Faire fonctionner un grand nombre de jeux avec des émulateurs, wine, etc...


Venez nombreux :)

Lutris fait sa première sortie

Voilà, la surprise que j'avais annoncé il y a une semaine dans le billet sur Compiz est là!
lutris logo Lutris est une plateforme de jeu vidéo sous license GPL V3 pour les systèmes GNU/Linux avec certains points communs avec PlayOnLinux ou DJL. Si PlayOnLinux se concentre sur Wine et DJL sur les jeux natifs, Lutris vise a prendre en compte la totalité des jeux vidéos qui peuvent fonctionner par un moyen ou un autre sur Linux. Cela inclus les jeux natifs bien entendu, les jeux Windows, pas forcément avec Wine, mais aussi avec Cedega et pourquoi pas dans le futur Crossover games. A cela on rajoute la totalité des émulateurs existants et on arrive a un nombre de jeux vidéos supportés par Linux assez impressionnant.
Actuellement, Lutris n'en est qu'à ses débuts et le public visé par cette release est plus les développeurs que les joueurs. Le programme est tout de même fonctionnel, j'ai voulu livrer quelque chose de présentable pour une première version. Il est possible avec cette version de lancer les jeux avec Cedega, ScummVM et UAE (émulateur Amiga).
Les motivations qui m'ont poussé a démarrer ce projet sont nombreuses :

  • Il est possible de jouer sur Linux, mais souvent on passe plus de temps à configurer correctement sa machine pour que le jeu tourne correctement qu'a jouer réellement. C'est une étape rebutante pour les joueurs.
  • J'estime que plus de 90% de la ludothèque existante de 1978 a aujourd'hui est jouable sur Linux, pourtant c'est toujours Windows qui est considéré comme système pour joueurs.
  • Les projets similaires ont tous un aspect qui me rebute. DJL est en Qt et le code est en français, Cedega est propriétaire donc je ne peux pas y participer, et PlayOnLinux ... pour rester sympa je vais juste dire que c'est pas mon type de code, à cela j'ajoute qu'ils n'ont pas de dépot svn ou bzr, ni bugtracker réellement utilisé (celui sur Launchpad est quasiment vide)
  • Des bugs très ennuyeux pourrissent la vie du joueur : les panels de Gnome qui restent affichés en plein écran, l'économiseur d'écran qui s'active quand on joue au joystick, l'impossibilité de faire Alt+Tab pour retourner sur le bureau, l'impossibilité de se servir de son contrôle de volume au clavier, les jeux qui ne supportent pas pulseaudio ou même Alsa. Le but est de pouvoir jouer sans se soucier de tout cela.
  • Aucune solution n'existe pour stocker ses sauvegardes en ligne de manière a pouvoir reprendre une partie sur une autre machine ou même de pouvoir les partager avec ses amis.
  • Les solutions actuelles sur Linux n'ont pas l'aspect communauté comme ce que l'on peut trouver sur Steam ou XFire. Dans les versions futures vous aurez des notifications du type "Robert est en train de jouer a Warsow" avec une option pour le rejoindre.
  • Wine, Cedega, PlayOnLinux et DJL stockent par défaut les jeux dans un répertoire caché, j'ai du mal a supporter cela, j'ai un répertoire pour les jeux sur une autre partition indépendante de mon disque système. Certain jeux y sont depuis des années et avec 33Go de jeux sur Steam, je n'aime pas trop qu'on m'oblige a tout réinstaller. Lutris respecte les données du joueur et le laisse libre d'organiser ses jeux comme il le souhaite.
  • Il n'y a pas de gestion satisfaisante des images iso. Lutris utilisera fuseiso pour monter automatiquement les images sans droits administrateur.


Captures d'écran


Interface principale L'interface principale de Lutris. L'import des jeux Cedega et ScummVM se fait en quelques secondes.

import des covers Les jaquettes des jeux peuvent être importés a partir de l'interface en utilisant Google Images

runners La liste des programmes supportés par Lutris (ou 'runners' dans le code) avec une option pour les installer ou les configurer.

game config L'écran de configuration de jeux. On se rends compte ici que les entrées d'un dictionnaire en Python sont renvoyé dans un ordre totalement aléatoire ;)

Contribuer ou tester


Toute aide est la bienvenue, comme je l'ai précisé au début, cette release est surtout destinée aux développeurs et testeurs. De nombreux bugs sont présent et surtout beaucoup de fonctions ne sont pas du tout implémentées. Dans certains cas, il faudra éditer des fichiers de configuration a la main (dans ~/.config/lutris ), les fichiers étant au format yaml, très simple a comprendre.
Pour récupérer la dernière version, un dépot bzr est mis a disposition sur Launchpad : https://code.launchpad.net/lutris ou vous pouvez télécharger une archive tar.gz qui sera mise a jour moins souvent sur http://lutris.net/download. Surtout n'hésitez pas à créer vos propres branches sur Launchpad avec vos propres modifications du code et de faire pleiiiin de rapports de bugs ;)

Avis aux graphistes : The Gimp et Photoshop

La non-news de ces jours ci, c'est la possibilité que Gimp soit absent de l'installation par défaut d'Ubuntu 10.04. Certaines personnes, qui ont une logique qui sort de mon domaine de compréhension, en viennent jusqu'à affirmer que les utilisateurs utiliseront F-Spot pour retoucher leur photos. Le retrait de Gimp est uniquement un effet de bord de cette limite artificielle que l'on se fixe a vouloir a tout prix conserver une installation sur un média optique que je considère depuis un moment comme obsolète. Les CD-R ou DVD-R sont lents, peu fiables et surtout peu écologiques (et vas y que je te grave un nouveau CD tous les 6 mois). J'ai acquis mes derniers CD-R et DVD-R il y a plus d'un an et j'ai bien l'intention de ne plus jamais en acheter.
Gimp a beau être indispensable pour moi, je ne le juge pas nécessaire d'être installé par défaut. Inkscape m'est tout aussi indispensable et n'a jamais été installé par défaut, je n'en ai jamais fait tout un plat.
Bref, ce n'est pas le but de ce billet. Je tiens plutôt a parler du fait que de nombreux utilisateurs ne franchissent pas le cap d'un système libre car ils utilisent Photoshop depuis des années et ne se font pas a l'idée d'utiliser Gimp.
J'ai utilisé Photoshop depuis sa version 4 (en 1997) jusqu'à la version CS2 et mon passage a Gimp ne m'a pas posé de problèmes particulier. Je dois avouer que je n'ai jamais eu a utiliser des fonctionnalités très avancées de Photoshop mais mon utilisation va tout de même au delà du redimensionnement/rotation. Toujours est-il que je ne suis pas graphiste, et que j'entends toujours des remarques sur Gimp comme quoi il est inférieur a Photoshop et que son interface est mauvaise (je ne trouve pas cela vrai mais bon ...).

Un Photoshop-like pour Gimp

Il serait très bénéfique pour Gimp et le logiciel libre en général de proposer une interface très proche de Photoshop. Cela permet aux utilisateurs venus du monde propriétaire de migrer sans perdre leurs repères. Il y a déjà eu des projets visant à copier Photoshop, je pense notamment a Gimpshop et GimPhoto. Je considère ces projets comme de très mauvais logiciels pour une simple raison : Une simple modification des préférences de Gimp ne doit pas justifier de distribuer de nouveaux binaires. Gimpshop et GimPhoto sont des forks de Gimp et rien ne justifie cela. D'ailleurs, si les développeurs de ces projets respectifs ne s'activent pas un peu, ils verront leur logiciels mourir a petit feu : Gimpshop est basé sur Gimp 2.2 et GimPhoto sur Gimp 2.4. Actuellement nous sommes sur Gimp 2.6 et en route vers Gimp 2.8.
gimp.png

Avis aux graphistes

J'ai besoin de l'avis de plusieurs graphistes très expérimentés sur Photoshop et un peu su Gimp. Quels sont les changements génants pour un habitué de Photoshop ? Quels sont les fonctionnalités qui ne sont pas activées par défaut mais qui sont accessible via un plugin ? Quelles sont les fonctionnalités qui sont impossible a avoir sur Gimp ?
Vous pouvez vous exprimer ici, ou sur le site du projet gimpshop-ng : https://launchpad.net/gimpshop-ng .
Ce projet a pour but de permettre a l'utilisateur de reproduire une interface inspirée de Photoshop, de bénéficier des même raccourcis claviers. Tout cela en se basant uniquement sur la version originale de Gimp. (sudo apt-get install gimp , je précise parce que cela ne semble pas évident pour certains qui semblent préférer F-Spot plutôt que taper cette commande ;) ) Hormis l'aspect "je copie Photoshop", ce projet pourra être utile pour l'ajout de ressources liées a Gimp comme les brosses et les plugins, un Synaptic pour Gimp en quelque sorte.

Utiliser Compiz efficacement

On entends souvent parler de compiz, souvent des commentaires enthousiastes par rapport aux effets graphiques apportés. Souvent aussi compiz est dénigré et le qualifiant de "gadget" inutile ou pire d'effet b***g b***g (je m'auto censure, je ne peux pas blairer cette expression).
Malheureusement on parle peu du fait que compiz est un excellent Window Manager, le meilleur que j'ai jamais rencontré pour être honnête (mais je n'ai pas essayé KDE 4).

Je vais présenter dans ce billet ma façon d'utiliser compiz avec les avantages que cela apporte

Pré-requis

Les opérations présentées ici nécessite l'outil de configuration Compiz configuration settings manager, abrégé ccsm. Il est disponible dans les dépôts logiciels de votre distribution favorite sous le nom compizconfig-settings-manager. Après installation, un lanceur est crée dans le menu Préférences. Pensez aussi a installer les plugins additionnels de compiz.

Cachez moi ces effets superflus

La première chose à faire, c'est de désactiver les options qui ont rendu compiz célèbre (et qui ont aussi participé a sa mauvaise réputation), j'ai nommé le "Cube du Bureau" et "Déformer les fenêtres" (les fenêtres molles ou élastiques). La majorités des plugins dans la section Effets ont eux aussi peu d'intérêt et je ne conserve que "Animations", "Décoration de la fenêtre" et "Types de fenêtres a animer". Je rappelle que le but de ce billet est d'avoir un environnement de travail efficace et pas une démo technologique.

Meilleur que le cube: le plan

A la place du cube, je choisi le bureau sur un plan et ceci pour plusieurs raisons. La première est que rien ne différencie une face du cube d'une autre, il est donc plus difficile de retrouver ses fenêtres. Sur un plan (la méthode utilisée par les bureaux virtuels ces 20 dernières années), on peut se rappeler que telle fenêtre est en haut a gauche, une autre fenêtre en bas au milieutres.. L'autre raison de ne pas utiliser le cube est que dès qu'on dépasse les 4 faces, on est encore plus perdu, et tous les bureaux sont mis des uns à coté des autres sur une seule ligne. Pour mon bureau en plan, j'ai adopté une surface de 3x3 soit 9 bureaux. Pour mon utilisation, c'est le meilleur compromis que j'ai trouvé. Je donnerais plus de détails sur le bureau en plan dans la partie où j'aborderai le positionnement des fenêtres. La surface du bureau se défini dans les "Options générales".
Deux fonctionnalités que je juge essentielles sont la fonction "Éxposé" et l'option "Bureau sur un tore" des préférences de "Bureau sur un plan". La fonction Éxposé permet d'avoir un aperçu de tous les bureaux et de pouvoir déplacer les fenêtres entre eux. C'est l'équivalent d'un widget "pager" qui se retrouve sur de nombreux bureaux Linux. Grâce a la fonction Éxposé, je ne dispose pas de pager mais j'ai l'équivalent en plein écran avec un simple raccourci clavier (Super+E par défaut). Le bureau sur un tore permet de connecter le bord droit du dernier bureau au bord gauche du premier et le bord du bas des bureaux inférieurs aux bords haut des bureaux supérieurs, ce qui est très pratique pour déplacer ses fenêtres.
Puisque je parle de déplacer les fenêtres et de bureau en plan, je rappelle des raccourcis présents sur la majorité des Window Manager : Ctrl+Alt+Flèches pour changer de bureau, Ctrl+Alt+Shift+Flèches pour déplacer la fenêtre active.

Gestion des fenêtres

Ou window management en anglais, ce qui est quand même un peu le but d'un Window Manager. Dans cette section de ccsm, il existe des tonnes d'option, certaines sont complexes a apprivoiser, d'autres sont indispensables. Dans le plugin "Actions supplémentaires du Gestionnaire de fenêtre" il est possible d'activer un raccourci pour mettre n'importe quelle fenêtre en plein écran avec la combinaison Ctrl+F11, du vrai plein écran, sans barre des tâches.
Le plugin Grille est très intéressant puisqu'il permet de redimensionner et positionner les fenêtres avec la combinaison Ctrl+Alt et les touches du pavé numérique. Par exemple Ctrl+Alt+1 va positionner la fenêtre active dans le coin en bas a gauche de l'écran. Si on appuye de nouveau sur ce raccourci, la fenêtre occupera 2/3 de l'écran au lieu de la moitié. Une autre pression et la fenêtre occupera 1/3 de l'écran. Le plugin "Redimensionner la fenêtre" reproduit une fonction déjà présente sur la majorité des Window Manager : pouvoir déplacer une fenêtre avec Alt+Bouton du milieu. D'une manière similaire, Déplacer la fenêtre permet de déplacer avec Alt+Bouton gauche. Tellement utile qu'on oublie vite qu'on a utilisé dans le passé la barre de titres pour déplacer et une zone minuscule de quelques pixels de large sur les coté pour redimensionner.
Les règles de fenêtres (ou "Window Rules" chez moi, un oubli de traduction) , sont un peu complexes a maitriser mais apportent beaucoup. Ici, on va aborder pour la première fois la notion de titre de fenètre et de classe de fenêtre. Dans le jargon de Xorg on appelle ces propriétés WM_NAME et WM_CLASS et ce sont des informations que l'on peut connaitre avec la commande xprop. Ces règles permettent de fixer certaines conditions pour des classes de fenêtres que vous aurez définies. Si vous souhaitez par exemple faire apparaitre Pidgin sur tous les bureaux, vous rajouterez class=Pidgin sur la ligne "Afficher sur tous les bureaux". Cette fonction étant déjà présente avec un clic droit sur la barre de titres cela ne présente qu'un intérêt faible, mais d'autres possibilités sont offertes comme forcer un programme en plein écran. De la même manière on pourra forcer la taille de certaines fenêtres dans l'onglet "Règles de tailles". Le plugin "Placer des fenêtres" utilise le même principe et permet d'ouvrir un programme sur un bureau que vous aurez défini. Ainsi je sais que mon terminal est a gauche au centre, firefox sur le bureau central, amarok à droite au centre, Netbeans en haut au milieu.

Compiz et le jeu vidéo

Cette partie du billet pourra surprendre certains car on a souvent transmis l'idée que pour jouer, il valait mieux couper Compiz. J'ai constaté dans les benchmarks publiés sur ce blog il y a plus d'un an que cette manipulation n'apporte (avec une carte Nvidia) qu'un gain négligeable. Ma carte est loin d'être du haut de gamme (9600 GT) et je ne me prive pas de jouer a Left4dead ou Borderlands avec Compiz activé. Peut être que la différence entre Compiz/Metacity est plus visible sur ATI / intel, je vous laisse répondre a cette question dans les commentaires.
Toujours est il que compiz apporte beaucoup pour les jeux. Il faut reconnaitre que la plupart des jeux sur Linux ont une gestion pitoyable du plein écran : Toute interaction avec le bureau est bloquée, impossibilité de changer le volume sonore, impossibilité de switcher vers un autre programme avec Alt+Tab, deuxième écran noir, bref une fois en plein écran, on est bloqué et le seul recours pour avoir la main sur sa machine sont les terminaux TTY (avec une possibilité de tout faire planter). Heureusement compiz est là, et si le jeu en question supporte le mode fenêtré alors on a toutes les chances de bénéficier d'une meilleure expérience. Jouer en mode fenêtré est surement la pire chose qui soit, et j'avoue préférer ne pas jouer plutôt que jouer dans une fenêtre. Cependant avec compiz il est simple avec les méthodes expliquées ci dessus de faire des fenêtres plein-écran, ce qui offre le meilleur des deux mondes. Cette méthode ne marchera pas avec tous les jeux, par exemple OpenArena qui insiste pour vous emprisonner dans le jeu, mais dans la grande majorité des cas c'est la fin de "Je peux pas répondre sur Pidgin, je suis en train de jouer".

Résultat

Pour finir voici un screenshot pour illustrer ce que donne cette configuration de Compiz CompizExpose
On y voit Evince, Netbeans, Thunderbird, Terminator, Firefox, Amarok 1.4, Left4Dead sur Cedega, VirtualBox, Pidgin et une application surprise ;)

Image pour VirtualBox : Ubuntu Server 9.04 x64

Pour ceux qui veulent une installation rapide d'un serveur de test je met a disposition une image pour VirtualBox d'Ubuntu Server 9.04 en 64 Bit.
Les paquets supplémentaires installés sont le serveur LAMP et OpenSSH.
L'archive fait 436 Mo (contre 593 Mo pour l'iso) et le système est a jour (ou du moins il l'était le 18/09/2009).

Téléchargez l'image

Voici les réglages choisis lors de l'installation, le reste n'a pas été touché :

distribution: Ubuntu Server 9.04
architecture: x64
hostname: vboxserver
login: ubuntu
password: ubuntu
mysql password: No password
additional packages: LAMP, OpenSSH
language: English
keyboard layout: French
system updated on: September 18th 2009


Le but étant de faire de multiples copies de cette machine virtuelle, une simple copie de fichier ne suffira pas si vous avez déjà enregistré l'image disque sur Virtual Box. Il faudra changer l'UUID (identifiant disque) au préalable :

VBoxManage internalcommands setvdiuuid ma_copie.vdi

Comment aider la communauté du Libre ?

J'étais sur le point d'écrire un long billet sur ce que je perçois comme un problème majeur dans la communauté du Logiciel Libre. Sur le fait que de nombreuses personnes sont la uniquement par la haine du logiciel propriétaire, non pas par amour du libre; sur la passivité de certains membres qui ont pourtant un potentiel plus qu'intéressant; sur la mauvaise image qui est donnée au logiciel libre a cause de quelques membres zélés; sur l'hermétisme de la contribution et du développement et ainsi de suite...
Et puis non, ça n'avance a rien mis a part gagner des ennemis et insulter des gens qui ont pourraient être de précieux atouts dans l'avancée du libre.
Cela n'empèche pas que je trouve la situation presque désespérée, que je serai presque tenté de quitter définitivement cette communauté s'il y avait quelque part une meilleure alternative.
Malgré la souffrance provoquée par la pollution du Libre, je garde toujours un certain espoir de voir les choses s'améliorer si quelques personnes arrivent a canaliser les trolleurs et autres beaux parleurs pour les pousser vers quelque chose de plus constructif.
J'ai demandé la suppression de mon compte sur les forums d'Ubuntu-fr tout en étant parfaitement conscient que cela n'arrangerais rien au problème, c'est juste histoire de dire : "Je ne veux pas être associé avec ces quelques personnes qui sont en train de détruire ce que j'aime".

Dénoncer le problème ne le résoudra pas, ce qu'il faut c'est trouver des solutions qui feront que le problème n'aura plus aucune raison d'exister. Pour cela il faut prendre plusieurs choses en considération :

  • Le Logiciel Libre n'est pas en danger, il est la pour rester, et il est protégé par des licences extrêmement bien conçues. Je perçois toute personne qui tente de protéger le libre des "griffes" de Microsoft ou d'Adobe comme quelqu'un qui n'a pas confiance dans le Libre.
  • Les sociétés de logiciels propriétaires doivent être perçues comme des concurrents, pas comme des ennemis. La concurrence est quelque chose de sain et nécessaire a l'évolution (il peut aussi y avoir de la concurrence au sein du Logiciel Libre). La concurrence ne se fait pas avec des plaintes, ou des combats pseudo politico-philosophiques, mais en construisant des produits supérieurs. La philosophie du Libre est très bonne, j'y adhère complètement, mais un logiciel est un produit technique, pas une réligion , tout ce qu'on lui demande c'est de bien faire son travail.
  • Dans beaucoup de cas, on ne se préoccupe pas assez de la liberté N°1 : celle d'étudier le programme, je dirais même que cette liberté est bafouée a l'heure actuelle. Tout logiciel libre (même un projet énorme) doit être accessible a toute personne voulant s'y intéresser. Malheureusement les logiciels libres sont trop souvent maintenus par une équipe définie (ou une seule personne dans beaucoup de cas) et les contributions, ou même la simple compréhension d'un projet est très difficile d'accès.
  • Les systèmes d'exploitation libres ne sont pas encore prêt pour le grand public, il y a encore de nombreux points ou l'ergonomie mérite d'être améliorée. Certains disent "Linux ça se mérite, il faut apprendre et ne pas être assisté", je réponds à cela : "Ayez au moins la bonne foi d'avouer que vos programmes sont mal conçus, c'est le but premier d'un ordinateur que d'assister un humain". Lorsque nous demandons a un utilisateur non informaticien de taper des commandes dans un terminal, c'est une insulte faite aux systèmes GNU/Linux modernes et montre l'incapacité de la communauté à produire de bons scripts et des interfaces intuitives.
  • Les innovations faites dans le milieu du logiciel propriétaire doivent être suivies de prêt. Si le Logiciel Libre surpasse le propriétaire dans de nombreux domaines (pour les serveurs notamment), il reste a la traine dans bien d'autres notamment l'audio, la vidéo, le jeu vidéo, etc...
  • Certaines avancées logicielles présentes dans le domaine propriétaire sont totalement hors de portée pour des développeurs seuls, ou même une petite équipe. On avance souvent l'argument que les projets ambitieux sont le fruits de grosses sociétés avec beaucoup de moyens financiers mais je ne croit pas que ce soit le point crucial a la réussite de ces projets. Ce qui permet de mener a terme ces projets, c'est la structure fournie par une grosse société. La communauté du libre pourrait représenter une formidable force de travail, mais il manque quelques éléments fédérateurs, des outils permettant une meilleure gestion. Ne jamais oublier qu'un projet, aussi gros soit il est le fruit de plusieurs êtres humains, les membres de la communauté du libre n'ont aucune raison d'être moins doués. Aujourd'hui pour concevoir un logiciel digne de ce nom, travailler seul n'est plus une option.


Si tout ces éléments sont pris en considération, alors le Logiciel Libre et sa communauté cesseront d'être la risée du monde propriétaire, et sera perçu comme un concurrent a part entière. Pour l'instant, 1% de part de marché dans le domaine du desktop reste insignifiant pour être considéré avec sérieux.

Proposition de réseau social

Comme certain ont pu le remarquer, ce blog est une annexe du site que j'ai débuté il y a quelques années et qui n'a jamais vraiment décollé: Tweekers. J'ai poussé le vice jusqu'a donner comme sous titre "Plateforme de conception et d'architecture logicielle collaborative" alors que depuis le début je suis l'unique contributeur au site. Le site est plus ou moins a l'abandon et j'y poste de temps a autre quelques trucs et astuces concernant la programmation et l'administration. J'ai ajouté il y a peu de temps une section Documentation qui vise a répertorier et classifier les nombreuses documentations de projets libres mais c'est à peu prêt tout ce qu'il y a de nouveau sur ce site (Il me semble même que les inscriptions sont impossibles suite a l'ajout d'un antispam expérimental, personne n'a relevé le problème c'est dire le succès énorme du site).
Pourtant des le départ, le but était clair : a chaque problème sa solution, et le but du site était de la trouver, qu'il s'agisse d'une simple option de configuration sur Apache jusqu'a la conception entière d'une application.
J'ai utilisé ce site comme excuse pour apprendre le PHP et j'ai parfaitement conscience qu'il est buggé, que son code est à jeter a la poubelle, il n'en reste pas moins que l'idée de départ est toujours bonne et doit être gardée.
Il faudrait reconstruire ce site mais en mettant en avant le coté social du site. Il est hors de question de refaire un outil existant, surtout après la libération du code de Launchpad, qui est a mes yeux, la meilleure forge existante. Tweekers ne doit pas être une forge, ni un wiki, ni un forum, mais un réseau social axé sur l'étude de code et la conception de projets. Ce réseau social doit permettre de regrouper les personnes par domaine d'intérêts et de compétences.
Pour donner quelques exemples :

  • Peter a un concept génial pour un nouveau jeu vidéo, il publie l'idée sur son profil, 10 personnes sont intéressées. Steven a quelques connaissances de SDL propose de contribuer et d'écrire des tutoriaux, Hugues trouve que ce projet est l'occasion pour apprendre l'OpenGL, Georges cherchais a faire de nouvelles créations sur Blender, José a déja écrit un jeu vidéo et propose de réutiliser des morceaux de code de sa création, etc...
  • Jaqueline en a assez d'un bug très irritant qui n'a pas été résolu depuis des années. Le bug est répertorié sur Launchpad mais le programme est plus ou moins maintenu. Elle fait par du problème sur son profil. Dave est un autre utilisateur du programme et propose une analyse du code, il trouve le fichier qui pose problème mais n'a pas les connaissances pour résoudre le bug. Georges est un pro du C++ mais n'a pas beaucoup de temps a passer sur ce bug, mais cela tombe bien, on lui met devant les yeux la partie du programme a corriger, quelques minutes plus tard il soumet un patch (qui est automatiquement posté sur Launchpad). Dino applique le patch sur les sources, compile et construit un paquet qu'il publie sur son PPA.


Comme je l'ai bien fait comprendre, je ne comptes pas me lancer dans la refonte de ce projet tout seul, je cherche des personnes qui pensent que ce projet peut aboutir a un résultat intéressant. Pour information je compte développer le site avec le framework Symfony, probablement avec l'ORM Doctrine (je suis au beau milieu de mon autoformation a Symfony et j'ai commencé avec Propel, toutefois Doctrine semble être plus utilisé), et la librairie jQuery . Le site sera dans déplacé chez TuxFamily dans un premier temps (n'oubliez pas d'apporter votre soutien financier a TuxFamily !). A partir du moment ou j'aurais quelques volontaires, je mettrai a disposition le plus vite possible une première version du cahier des charges et pourrais organiser une réunion sur Jabber. Je précise qu'aucune connaissance n'est exigée tant que vous êtes motivés pour apprendre.

Le débat sur Mono est clos grâce à Microsoft

Un autre billet sur Mono très peu de temps après le premier, mais la nouvelle mérite d'être annoncée. Miguel de Icaza annonce sur son blog la promesse faite par Microsoft de ne jamais attaquer toute personne qui implémente les standards ECMA 334 (C#) et 355 (CLI), qui sont au passage aussi normalisés ISO. Les termes du contrat sont ceux de la Microsoft Community Promise qui sont valable pour tout le monde, sans accord a passer auprès de Microsoft, de manière irrévocable et qui ont une réelle valeur juridique.

D'un autre coté, l'équipe de Mono prends la décision de séparer nettement les implémentations des standards ECMA/ISO des implémentations des technologies Microsoft non couvertes par cet accord (WinForms, ADO.NET et ASP.NET). Ceci ne concerne ni les distributions comme Debian ou Ubuntu qui ont fait cette séparation dès le départ, ni le projet Gnome qui n'utilise que des librairies standards et libres.

Cette nouvelle aura l'avantage de rassurer les quelques personnes qui s'inquiétaient au sujet de l'intégration de Mono a Gnome et de mettre fin de manière définitive aux trolls et aux FUDs nocifs véhiculés par certains membres de la communauté.

Et c'est reparti : pourquoi Mono n'est pas une menace.

Le billet qui va suivre n'est pas de moi, c'est une traduction d'un billet de Jo Shields lisible ici dans sa version originale. Toutefois c'est un peu le billet que j'aurais voulu écrire sur Mono. Il se trouve que Jo Shields l'a fait avant et surement mieux que moi (Jo Shields est un des packageurs de Mono chez Debian / Ubuntu).

J'ai laissé tomber pendant un moment l'idée de me battre contre les anti-mono, mais le problème est que leurs attaques sont tellement persistantes qu'elles contaminent les sources d'informations sérieuses. Le récent billet de Phillipe Scoffini en est la preuve.

Je n'ai pas vraiment d'espoir sur les retombées de cette traduction, comme le dit Jo à la fin de cet article, les gens qui ont déja forgé leur opinion ne changeront pas d'avis.

Je rajouterai quelques commentaires a la fin, pour l'instant voici le billet : 

Ce billet est une copie d'un article que j'ai envoyé a Linux Today. Le message d'origine est visible ici où ils ont invité les personnes qui ne pense pas que Mono transmet le SIDA a se justifier. J'ai répondu ici. Ceci est un copie du post, pour diffuser l'information sur différents aggrégateurs de flux. Une partie du contexte peut être perdue si on ne lit pas “l' invitation” qui a provoqué tout cela en premier lieu.

 

 

Je suis un membre du Debian Mono Group, Debian CLI Application Team et du Debian CLI Libraries Team. J'ai travaillé sur le packaging de la pile Mono et des applications qui l'utilise dans Ubuntu (et Debian) depuis un peu moins d'un an. Et étant  parfaitement au courant des “flame wars”, menaces et attaques personnelles qui en découleront, je ne prendrait pas parti a cette «invitation ». Je parle pour moi même ici, pas pour le projet Debian, ni Ubuntu, ni pour le projet Mono, ni mon employeur.

 

Votre requète était de donner «une présentation posée de pourquoi Mono est désirable, pourquoi il n'est pas une menace et pourquoi il devrait être inclus dans Ubuntu par défaut ». Je répondrai à ces questions individuellement, puis je commenterais d'une manière plus générale sur votre post, ainsi que d'une façon plus large sur le mouvement « anti-mono ». Ce message est signé par GPG pour s'assurer qu'il sera publié dans une version non éditée. Le message tel quel sera mis a disposition sur  http://retro.apebox.org/herewegoagain.txt pour permettre aux personnes de vérifier l'authenticité de la signature.

 

Pourquoi Mono est désirable

Ceci est une question qui dépends surtout de la personne à qui on la pose.

Si on demande a un utilisateur, alors la réponse est « ça ne l'est pas », pas plus qu'un compilateur SCHEME ou un interpréteur LOLCODE.

Si on demande à un développeur, alors la réponse est TRES différente. Mono apporte un framework très équilibré pour permettre au logiciels libres d'être développés rapidement et efficacement. Par équilibré, je veux dire qu'il est improbable qu'il gagne sur tous les plans sur lequel on peut juger un langage de programmation – l'empreinte mémoire, la rapidité d'execution, la disponibilité des librairies, etc...- mais il se débrouille plutôt bien dans TOUS ces domaines. Concernant la rapidité, Mono est bien plus rapide que Python – jusqu'à 100 fois plus selon certains benchmarks. Il occupe une fraction de l'empreinte mémoire d'une application Java. Il dispose de fonctionnalités modernes comme le ramasse-miettes ce qui rends le développement très facile en comparaison du malloc() du C ou C++. […]

Plusieurs applications qui existent depuis très peu de temps – comme Gnome Do – utilisent toutes les fonctionnalités offertes par Mono pour être développé facilement et rapidement, en opposition a la chasse aux SIGSEGV provoquée par les erreurs humaines inévitables dans un développement basé sur le C. Mono a été concu a l'origine comme une façon d'échapper a l'horreur absolue de maintenir une énorme base de code d'interfaces graphiques en C (Evolution).

Pour aller plus loin, Mono permet une migration plus facile – pour les développeurs comme pour les utilisateurs – des frameworks CLR comme Microsoft .NET. Les étudiants qui apprennent Visual Studio .NET a l'université peuvent utiliser leurs compétences et les mettre en application pour créer ou améliorer des Logiciels Libres sur leur installation toute fraiche d'Ubuntu, sans pour autant avoir a apprendre un nouveau langage. Les entreprises qui ont investi dans des applications basées sur le framework .NET peuvent considérer de migrer leur serveurs ou postes de travail sur du Logiciel Libre. Même si la compatibilité .NET a toujours été un but secondaire, il n'en reste pas moins extrèmement populaire, qui a donné lieu a beaucoup d'entrées et de développements dans la base de code de Mono.

Il faut noter toutefois que ce cas de figure (migration de Windows) n'est pas une raison pour inclure Mono par défaut (par plus que Wine par exemple), et qu'en fait les bibliothèques requises pour faire tourner la majorité des applications Microsoft .NET sont exclues de l'installation d'Ubuntu par simple manque de nécessité.

Pourquoi ce n'est pas une menace

Ceci est une question qui ne provoquera rien d'autre que des réactions de colère – même si cela ne fera pas de mal a votre compteur de visites et le revenu publicitaire qui en découle. Mono n'est  pas  une menace car il n'a rien de particulier d'un point de vue légal. Beaucoup de personnes ont passé des heures, si ce n'est pas des jours ou des semaines a essayer d'expliquer cela. Je vais essayer d'en faire de même une fois de plus. Il y a toute une flopée de raisons qui font que ce n'est pas un problème et qui couvre un large panel de sujets. Je présenterai ces points individuellements.

 

  • Mono n'est pas le fruit d'un accord entre Novell et Microsoft. Mono est né quatre ans avant cette malheureuse affaire. Mono n'a pas de traitement spécial sous cet accord, il n'est mentionné nulle part dans ce contrat (ni aucune autre application d'ailleurs). C'est une chose importante a noter.

  • Mono est couvert par le OIN (ndt : http://www.openinventionnetwork.com/ ), comme d'autres applications libres majeures. Des attaques sur les brevets contre Mono comportent le même risque que des attaques contre tout autre projet faisant parti du OIN. Des attaques contre Mono est un rique de provoquer une «guerre mondiale » des brevets, que Microsoft ne peux pas gagner. Une telle procédure ferait du mal a leur société et leur ferai perdre de l'argent. 

  • Mono implémente un standard international, bien qu'il soit celui d'un monopoliste reconnu. Si ceci pose un problème, alors pourquoi les gens utilisent ils le C, le standard du monopoliste AT&T ? Mono implémente un remplacement Libre et amélioré d'un produit propriétaire. Si ceci pose un problème, pourquoi les gens utilisent ils GNU (qui est un remplacement Libre et amélioré du système UNIX propriétaire )? 

  • Indépendament du fait que les des licences spécifiques de brevets sur ECMA 334 et 335 couvrent ou non l'implémentation de ces standards (La « tentaive » d'ITWire de sécuriser ces arrangements mis a part ), le fait que des déclarations on été faites en public soutenant l'idée d'une licence gratuite, ramène l'impact financier de telles infractions a zero. Si une quelconque société possède une licence pour utiliser ces brevets,  sous une licence « non discriminatoire », et n'a pas payé pour l'avoir alors il serait discriminatoire de faire payer n'importe qui d'autre pour les utiliser (et de ce fait, casser les termes du contrat qui a été signé concernant la licence des brevets), ce qui ferait que ces brevets perdraient toute valeur financière. […] 

  • Mono ne peux pas «disparaitre » suite a des changements incompatibles au Framework Microsoft.NET, pour deux raisons. Premièrement, de tels changements casseraient aussi la compatibilité avec la totalité des applications .NET existantes (et en fait si une telle chose devais se produire, la meilleure options pour les utilisateurs serait de faire foncionner leurs applications avec Mono). Secundo, la compatibilité avec Microsoft.NET est un but annexe pour Mono – si Microsoft change quelque chose dans .NET 5.0, alors quoi ? Cela n'empèche pas Banshee ou Gnome Do de compiler et d'être executés sur des systèmes comme Ubuntu.

  • L'absence de «protection sur les brevets » est une chose bien différente d'une « violation de brevet ». Si je propose a quelqu'un  de vendre une promesse de ne jamais l'attaquer en justice en utilisant un de mes brevets, le fait qu'il accepte ne garantie pas que je leur vends quelque chose de valide,mais seulement qu'il est prêt a payer pour cela. Si Jim paye pour être protégé de tout les brevets que je détiens, cela ne signifie pas que Jim enfreint quoi que ce soit, ni que Ted s'il fait la même chose sans avoir payé viole quoi que ce soit non plus. Si une police d'assurance immobilière incluse la protection contre les dégâts des eaux, cela ne signifie pas que votre maison sera inondée, et ne pas acheter de protection contre les dégâts des eaux ne signifie pas que vous serez inondés non plus.  

  • Des brevet qui couvrent un detail spécifique d'un projet ne peuvent pas le tuer, l'exemple ici est Freetype. Apple a émis des menaces sur les brevets aux développeurs de Freetype pour avoir utilisé les données propriétaires stockés dans les polices TrueType permettant d'améliorer le rendu (ndt: Hinting : http://en.wikipedia.org/wiki/Font_hinting ). Vous remarquerez que FreeType existe toujours aujourd'hui, c'est parce que la METHODE qu'Apple a réclamé a été contournée et des données auto générées ont été utilisées pour ne pas a avoir a utiliser les données d'Apple. Les menaces d'Apple se sont estompées et le projet a pu continuer. Des vendeurs de FUD ont suggéré que le noyau Linux contenait un bon nombre de violations de brevets, et si jamais ils veulent bien apporter plus de détails sur ces points alors les parties spécifiques aux violations de brevets peuvent être contournées (ndt : il ne faut jamais accorder d'importance a ces FUD tant qu'il n'y a pas un nom de fichier avec un numéro de ligne couplé a un brevet précis). Une violation de brevet dans le noyau Linux ne causerais pas la disparition de toutes les distributions GNU/Linux du jour au lendemain, et il est inapproprié de considérer que n'importe quel projet libre est différent sur ce plan. Même si un brevet fondamental est violé dans un Logiciel Libre, cela n'a aucune importance, puisqu'une modification peut être faite au coeur de ce logiciel et que les applications qui utilisaient l'ancienne méthode du logiciel en question peuvent être elle aussi modifiées pour tenir compte de la nouvelle méthode. Seuls les logiciels propriétaires ne peuvent pas être modifiés dans l'éventualité de modifications majeures, et les applications propriétaires ne nous concernent pas vraiment.

  • Les échappatoires sont nombreuses dans Mono, particulièrement Mono dans Debian/Ubuntu. En premier lieu, les bibliothèques non ISO en provenance de Microsoft comme System.Windows.Forms ne sont pas inclues par défaut, et sont très rarement utilisés dans les applications Libres (notamment parce que les WinForms ont une apparence de merde). Si quelqu'un trouve une raison valable de supprimer ces bibliothèques non-standards , alors paf, elles disparaissent, sans affecter d'applications libres. De plus, si un changement plus radical est nécessaire, alors les paquets de Mono peuvent être patchés pour supprimer la violation de brevet. Si ce genre de changement drastiques est nécessaire alors comme mentionné plus haut, les applications peuvent être patchées pour tenir compte de ces changements. Et pour aller encore plus loin, si la totalité de Mono doit être supprimé (ndt : ce qui est franchement improbable a mon avis), alors les applications peuvent être portées. Le processus de portage sera long et douloureux et impactera en mal, la vitesse de développement de l'application (bien que ce ne soit pas pire que si l'application avait été développé dans le langage cible dès le début), mais il n' y aucun développeur  qui aurais écrit une application importante qui hausserais les épaules en disant «Tant pis, ce fût amusant mais le Monsieur dit qu'il faut arrêter maintenant » 

Pourquoi Mono devrait être inclus dans Ubuntu par défaut

Il ne devrait pas l'être, ou du moins pas dans le sens qui a été développé sur les blogs, newsgroups, forums, etc... Nous ne voulons pas que Mono soit installé par défaut sur n'importe quelle distribution. Mono est une plateforme logicielle et les plateformes logicielles sont inintéressantes du point de vue de l'utilisateur. Ubuntu ne devrais pas être livré avec Java, Scheme, l'assembleur ou LISP, les frameworks non plus. Ils ne sont pas intéressants pour l'utilisateur.

Ce que nous voulons par défaut sont de BONNES APPLICATIONS. Un utilisateur doit pouvoir booter une Ubuntu, Kubuntu, Xubuntu ou n'impore quel Live CD et se dire « Wow, ce truc du Logiciel Libre est génial, je n'ai absolument plus besoin de Windows maintenant ». Toutes les dérivées d'Ubuntu et toutes les distributions qui veulent convertir les utilisateurs au logiciel libre se doivent de repérer les meilleures applications existantes. Dans le cas d'Ubuntu, une décision a été faite d'inclure une application de prise de notes et un gestionnaire de photos par la Desktop Team.

Ils ont conclu que la meilleure application a offrir a leurs utilisateurs était Tomboy. Tomboy dispose de beaucoup plus de fonctionnalités que les applets «Post-it» fourni dans Gnome ou Windows Vista, et peut être vu par les utilisateurs comme un bon remplaçant de l'application propriétaire OneNote qui est vendu pour 80 £. L'autre application comparable est Zim « un wiki pour le bureau ». Zim est un produit de haute qualité, mais la Desktop Team a décidé d'utiliser Tomboy a la place car il est plus facile d'accès pour les utilisateurs non-techiques (et c'est l'application par défaut choisie par le projet Gnome).

Ils ont aussi conclu que le meilleur gestionnaire de photos était F-Spot. F-Spot est un concurrent direct du programme propiétaire d'Apple iPhoto ou du programme propriétaire de Google Picassa. Il n'est PAS comparable a des applications de type « navigateur de fichiers » comme gThumb, car une des fonctionnalités clé des gestionnaires de photo est de permettre de tagger ses photos avec des métadonnées importantes. Gthumb fonctionne bien pour un utilisation par dossier, pas pour une collection entière de photos.

Tomboy et F-Spot requierent tout deux le compilateur JIT de Mono ainsi que des bibliothèques telles que GTK# pour fonctionner. Donc pour fournir ces Logiciels Libres de meilleure qualité aux utilisateurs (déterminés comme étant les meilleures application par l'Ubuntu Desktop Team), une partie de moteurs d'execution Libres ont du être rajoutés, de la même façon que le moniteur système de Gnome requiert GTKmm. Pour aussi longtemps que Tomboy et F-Spot seront les meilleures applications, elles devront être inclues, et avec les bibliothèques qu'elles utilisent. Si d'autres applications Libres surpassent celles ci alors elles doivent les remplacer, si une application Mono surpasse une autre application dans un autre domaine, elle doit être inclue. C'est n'est pas basé sur la préférence de tel ou tel framework, même si c'est mon avis  que des langages de haut niveau comme Python ou C# permettent de développer des applications beaucoup plus rapidement qu'en C.

L'article sur Linux Today

Votre post initial montre que vous n'êtes pas équitable sur ce sujet. Il y a des phrases spécifiques qui n'ont d'autre utilité que de trainer dans la boue, et montrent vos idées préconçues sur ces sujets dont vous souhaitez discuter. Ce sont ces idées préconçues et biaisées qui obligent les personnes avec une connaissance exhaustive de Mono a ne pas s'en faire. Ce qui laisse seulement l'impression au groupe anti-mono qu'ils sont une majorité.

 « Il y a d'autres, meilleures applications qui devraient êtres inclues » – Nommez les

« Forcer des technologies Microsoft » – Au secours ! Au secours ! Je suis oppressé !  Non, pas vraiment en fait. Une bonne technologie reste une bonne technologie, et le Not Invented Here (ndt : http://fr.wikipedia.org/wiki/Not_Invented_Here )n'a jamais aidé personne. Aucun des membres de la Desktop Team n'est un fan de Mono (la plupart sont des fans de Python) (ndt : moi aussi ;) ), et aucune décision unilatérale n'est faite sur les applications a inclure. Personne n'est « forcé » a qui que ce soit. Aucun paquet relatif a Mono n'a été marqué comme « Essential:yes »

« une alliance profane dans Ubuntu » – Démagogie. Microsoft est une corporation, pas une entité super-naturelle. Suggérer la moindre idée de profanation leur donne plus de crédit que ce qu'ils méritent. C'est une société avec un grand nombre de managers seniors idiots et une poignée de développeurs compétents. Rien de plus.

« Les fans de Mono ont crée un foutoir énorme sur les forums Ubuntu » – en fait le clan anti-mono qui est responsable de cela. Si vous vous référez à des accusations de censure, alors vous vous trompez  (ou trompez intentionnellement les autres). Ceux qui lisent les détails spécifique de ces accusations pourront trouver de la vulgarité, des menaces, des disputes et pire au coeur des anti-mono. Ce comportement infantile ne permet pas de gagner des débats, ni des amis parmi les modérateurs.

« ils n'ont pas pris la peine d'expliquer pourquoi retirer Mono du CD d'installation est inacceptable » –  A ceci je répondrais par une citation de Thomas Jefferson – « Le ridicule est la seule arme qui peut être utilisé contre des propositions inintelligibles. Les idées doivent être claires avant que la raison puisse agir dessus ». Les demandes de retirer Mono de l'installation par défaut d'Ubuntu ne sont pas basées sur des suggestions rationnelles, il n'y  a aucun packageurs qui fourni de meilleurs remplacements, seulement des personnes  qui demandent ceci parce que d'après leur opinion mal renseignée, tout le monde va se faire trainer en justice jusqu'à la mort et que les applications Mono doivent être purgées. C'est pour résumer du terrorisme logiciel – demander un changement dans la politique de quelqu'un d'autre en leur disant qu'ils ne sont pas libres de faire leur propre choix, basés sur leur propre politique. Les personnes rationnelles peuvent être en désaccord sur la question de Mono mais jusqu'à ce qu'il y ait des alternatives adéquates pour remplacer les applications Mono, le choix est simple : rendre GNU/Linux moins attrayant en le livrant avec des applications inférieures, ou accepter d'utiliser Mono. Il faut noter que des personnes qui ont plus de choses a perdre que l'utilisateur lambda sur un forum – comme Mark Shuttleworth par exemple – ont dit a plusieurs reprises qu'elles n'ont pas ce genre de craintes. Je supporterais personnellement un changement d'une application Mono vers une application non-Mono qui démontre une supériorité technique.

« l'inclure dans les dépôts standards est inacceptable » – C'est parfaitement acceptable, cependant ce n'est pas le seul argument qui est avancé. Les suggestions vont de reclassifier Mono comme logiciel non Libre (le plaçant en tant que citoyen de troisième zone), jusqu'à sa suppression complète des archives et jusqu'à l'expulsion complète de Debian et d'Ubuntu de toute personne ayant travaillé dans le packaging de Mono. Les applications Libres en général doivent être dans les dépôts standards, sans tenir compte de quel framework elles utilisent, mais si une application est la meilleure de sa catégorie, alors elle doit être intégrée par défaut.

« L'incapacité des fans de Mono a répondre a cette simple question m'inquiète un peu, comme s'il y avait un agenda caché» – Si vous voulez porter des accusations, faites les de façon claire. Ne jouez pas le jeux de Fox News de « bien , je trouve cela intéressant » , dites les choses de manière directe. Si vous avez des accusations spécifiques a faire aux gens qui ne sont pas anti-mono alors faites les, ou pour le dire plus simplement : Ne répandez pas des mensonges.

Le « mouvement » anti-Mono

Certaines personnes sont « pour » quelque chose. Elles sont pour la Liberté, ou pour la supériorité technique, ou pour une équipe de sport, ou n'importe quoi d'autre. D'autres personnes sont « contre » certaines choses. Elles sont contre un candidat politique, ou Microsoft, ou des gens d'une certaine provenance, etc... Certaines personnes se définissent sur la base de ce qu'elles veulent, sur sur ce qu'elles ne veulent pas. Mono provoque une colère immense parmi le second groupe – spécifiquement, des gens qui utilisent GNU/Linux pas parce qu'elles sont « pour » quoi que ce soit mais parce qu'elles sont « contre » Microsoft. C'est facilement visible dans l'usage de terme comme « Microshaft » ou « Micro$oft » ou tout autre appellation puérile qui tente de mettre en place une situation de « nous et eux »et de ridiculiser « eux ». Mono est symbolique – c'est un produit Libre (quelque chose auquel ils sont sensé être favorable), mais basé sur quelque en provenance du Grand Satan, une alliance impardonnable.

Nombreux sont ceux qui se définissent comme anti-Mono qui sont franchement effrayants. Souhaitant la mort des employés de Microsoft (voir les commentaires sur Boycott Novell), ou essayant de faire licencier les personnes qui émettent des commentaires positifs sur Mono (voir les mailing lists d'Ubuntu), ou faisant des insinuations sur tous ceux qui ont un avis différent du leur (voir quasiment toutes les news de Boycott Novell). C'est un comportement très moche, et surement la pire publicité qu'on puisse imaginer pour la communauté du Logiciel Libre. Si des gens veulent être « contre »Mono alors il y a des moyens sensés de le faire, par exemple en travaillant sur ou en packageant des alternatives. Souhaiter de voir exclure des communautés de Logiciels Libre les personnes qui ne travaillent pas sur les applications que vous aimez est, pour faire court, tout le contraire de l'esprit du Logiciel Libre. Si le groupe anti-Mono veux être pris au sérieux, ils ont besoin de COMPRENDRE ce contre quoi ils se battent, ils ont besoin d'avoir un minimum de connaissances sur ce qu'est Mono, et comment il fonctionne, pour savoir ou diriger leur énergie. (Et des déblatérations du style « ZOMG, MICRO$HAFT! » ne sont pas bien dirigées). J'aimerais vraiment voir des applications de haute qualité pour Gnome écrites en Java ou Python car la compétition amènerais seulement a avoir de meilleures applications.

Cependant, la grande majorité du groupe anti-mono n'est pas composée de développeurs ou de packageurs,  ce sont des « backseat drivers » (ndt : personne assise sur le siège arrière qui râle sur le style de conduite du conducteur) . Ils font de grandes proclamations sur comment les autres développeurs (qui consacrent leur temps a développer des Logiciels Libres) devraient utiliser le framework de LEUR choix et pas celui du développeur. C'est une autre raison pour laquelle les arguments anti-mono sont considérés avec aussi peu de respect, la seule présomption qu'ils soient d'une façon ou d'une autre en mesure de faire des demandes aux autres développeurs est extrêmement irritante. Le Logiciel Libre est une méritocratie, ceux qui font des choses gagnent le respect de leurs pairs. Tant que le groupe anti-mono ne fera pas une réelle contribution au Logiciel Libre, ils continueront d'être considérés comme des fanatiques excentriques, et leurs questions resteront sans réponses.

Pour finir, il n'y a RIEN qui arrêtera la controverse au sujet de Mono, tant que cette vague menace d'attaques en justice sera fabriquée et alimentée par certains membres de la communauté. Tout comme un acte de naissance présidentiel, il n'y a simplement rien qui calmera ceux qui ont déjà crée leur opinions sans se soucier des faits réels. Les arguments anti-mono sont acceptable et sont les bienvenus mais j'en ai très rarement vu. Et même quand ils apparaissent ils sont noyés dans une masse de démagogie et de FUD qu'ils obscurcissent tout point pertinent.

Voila, je pense est qui ce que vous recherchiez. Repostez le ou non. Il ne fera qu'un  chapitre de plus dans les attaques personnelles quotidiennes que je reçois du groupe anti-Mono si élaborée.

Jo Shields

Ca y est, j'ai bien conscience que je viens de perdre plusieurs heures de mon temps a traduire cet article de qualité. Pourquoi considérer cela comme un perte de temps ? Parce que je considère que la communauté du Logiciel Libre est sur une pente glissante avec quelques gus devant leur écrans très bruyants et pas forcément des plus pertinents. Je vois a longueur de journée, des gens qui prennent des position encore plus extrèmes que celles de Richard Stallman, sans pour autant apporter une quelconque contribution. La communauté telle que je la voit actuellement a de quoi faire peur, les nouveaux venus doivent être térrifiés et pire encore, les personnes qui pourraient être intéréssés par les technologies libres pour l'industrie doivent voir en nous une ribambelle de rigolos.

Voyez la réalité avec les résultats affligeants du sondage de Phillipe Scoffoni : 

sondage Mono

Cela représente bien l'état actuel des choses : 90% de gens qui sont plus ou moins contre Mono et donc qui font parti de ce groupe de gens qui sont "contre" comme le disait Jo Shields. Des gens qui utilisent Linux surtout parce qu'ils ne veulent pas utiliser Windows, des gens qui n'ont pas a mon avis réellement confiance dans le Logiciel Libre. J'ai le plus grand respect pour les gens qui ont voté "Sans avis" sur ce sondage, je ne crois pas que 95% des lecteurs de Phillipe connaissent si bien que ça Mono.

Mais tout n'est pas perdu, je peux prendre mes distances vis a vis de la blogosphère et des forums et me concentrer sur les communautés de réels contributeurs. Tant que le Logiciel Libre offrira des solutions de très haute qualité, les blogs et forums ne sont rien de plus qu'un bruit de fond (irritant certes dans certains cas) qui peut être ignoré selon le manque de pertinence des propos tenus.

Faire un screencast live avec Firefox 3.5 et VLC 1.0

Dans ce billet je vais montrer les possibilités offertes par Firefox 3.5 en diffusant un screencast via VLC et en incrustant dans l'image une webcam. On peux facilement imaginer l'utilité de ce genre d'application pour les Classrooms Ubuntu par exemple.
Le tutoriel se fera sur Ubuntu 9.04 mais il est facilement adaptable pour d'autres distributions.

1) Installation de Firefox 3.5 et de VLC 1.0.0

Pour bénéficier des dernières versions de ces logiciels nous allons utiliser les PPA fournis par Launchpad.net. Pour cela il est possible d'utiliser la méthode traditionelle, ou alors utiliser un script Python que j'ai écrit qui facilite la tache. Pour récupérer le script (ppatool) s'assurrer que bzr est installé et lancer cette commande :

bzr branch lp:ppatool

Nous allons ensuite ajouter le ppa relatif a Firefox.

cd ppatool 
sudo ./ppatool.py add ubuntu-mozilla-daily ppa

puis celui de VLC (Ce n'est pas obligatoire mais VLC 1.0.0 permet d'avoir le pointeur de la souris dans le screencast)

sudo ./ppatool.py add c-korn vlc

Pour la méthode traditionnelle, les PPA se trouvent à ces adresses ;
https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
https://launchpad.net/~c-korn/+archive/vlc
Mettre a jour la liste des paquets et installer ou mettre a jour firefox-3.5 et vlc

2) Streaming de l'affichage et de la webcam

Nous allons commencer par le screencast, récupérez une image de pointeur et placez la dans le répertoire courant avec le nom cursor.png. Nous allons faire une video en ogg theora en 640x480 qui suivra les mouvements de la souris :

vlc screen://  --screen-fps 10 --screen-follow-mouse --screen-mouse-image cursor.png --screen-width 640 --screen-height 480 --sout "#transcode{vcodec=vorb,venc=theora,fps=10,vb=500,width=640,heigth=480}:std{access=http,mux=ogg,dst=0.0.0.0:8090/stream.ogg}"

Pour vérifier que la capture est en cours lancez une autre instance de vlc :

vlc http://localhost:8090/stream.ogg

Maintenant passons a la webcam :
Les périphériques /dev/video et /dev/audio peuvent changer selon votre configuration.

 vlc v4l2:///dev/video0  --input-slave oss:///dev/audio  --sout "#transcode{vcodec=vorb,venc=theora,fps=10,vb=500,width=160,heigth=120,acodec=vorb,ab=64,channels=1,samplerate=44100}:std{access=http,mux=ogg,dst=0.0.0.0:8091/stream.ogg}"
Faites de même et testez le bon fonctionnement du streaming dans vlc ou firefox

3) Diffusion de vos videos dans Firefox 3.5


Nous allons faire une simple page HTML de test qui va regrouper trois éléments vitaux : deux éléments video pour le screencast et la webcam, et un canvas.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>

<title>Ogg screencast + webcam</title>
<script type="text/javascript" src="livecast.js"></script>
</head>

<body onload="processor.doLoad()">

<h1>OGG Testing</h1>
<div id="player">

<canvas id="livecast" width="640" height="480" />
</div>
<video id="screencast" style="display:none;" src="http://192.168.1.11:8090/stream.ogg" controls="true" autoplay></video>
<video id="webcam" style="display:none;" src="http://192.168.1.11:8091/stream.ogg" controls="true" autoplay></video>
</body>

</html>

Dans les tags video j'ai mis mon adresse réseau privée pour pouvoir utiliser cette page sur différents poste de mon réseau local, prenez soin de modifier cette adresse selon votre configuration.

La plus grande partie du code va se trouver dans un fichier javascript annexe. Il est inspiré par les démos diffusées par les développeurs de chez Mozilla. (Essentiellement celles de Paul Rouget )
var processor = {
timerCallback: function() {
this.computeFrame();
var self = this;
setTimeout(function () {
self.timerCallback();
}, 0);
},
doLoad: function() {
this.screencast = document.getElementById("screencast");
this.webcam = document.getElementById("webcam");
this.livecast = document.getElementById("livecast");
this.livecastContext = this.livecast.getContext("2d");
var self = this;
this.screencast.addEventListener("canplay", function() {
self.width = self.screencast.videoWidth;
self.height = self.screencast.videoHeight;
self.camwidth = self.webcam.videoWidth;
self.camheight = self.webcam.videoHeight;
self.timerCallback();
}, false);
},
computeFrame: function() {
this.livecastContext.clearRect(0, 0, this.width, this.height);
try {
this.livecastContext.drawImage(this.screencast, 0, 0, this.width, this.height);
this.livecastContext.drawImage(this.webcam, this.width - this.camwidth -20 , this.height -this.camheight -20 , this.camwidth, this.camheight);
} catch(e) {
return;
}
}
};

La fonction doLoad est executée au chargement de la page et récupère les objets relatifs aux videos puis lance un timer (timerCallback) qui va créer a intervalles réguliers le contenu du canvas (computeFrame). Seul problème dans l'ensemble : une latence d'environ 20 secondes entre l'aquisition par VLC et l'affichage par Firefox 3.5. Le screencast et la webcam sont presques synchrones (moins d'une seconde de décalage dans le pire des cas). Reste maintenant a trouver une solution pour diffuser la video a grande échelle, si on part du principe que l'on diffuse a partir d'une ligne ADSL et que le débit montant n'est pas suffisant pour de nombreux clients connectés. J'irais jeter un coup d'oeil sur icecast pour cela.

Pour finir, un petit screencast récursif, enregistré avec recordmydesktop. Désolé mais je n'ai pas trouvé comment enregistrer la sortie de la carte son dans recordmydesktop donc c'est un film muet ;)
On peut aussi constater les effets du lag sur firefox (on peut voir la fenètre de gtk-recordmydesktop par exemple)

Télécharger livecast.ogg (20,8 Mo , 1min43)

Controler Amarok 1.4 avec un clavier multimédia

J'avais posté il y a quelques temps une astuce pour revenir a la version 1.4 d'Amarok sous Jaunty. Pour rappel il faut installer les paquets publiés sur ce PPA (en ayant pris soin de supprimer Amarok 2 au préalable).
N'utilisant pas KDE je ne sais pas comment celui ci se comporte avec les touches multimédia des claviers mais sur Gnome (ou tout autre Gestionaire de fenêtres), les raccourcis claviers pour faire Play/Pause, Next, Previous, Stop ne sont pas modifiables (il s'agit d'une combinaison des touches <super>+lettre ).
J'ai cherché une solution permettant de redéfinir ces raccourcis (pour tirer meilleur parti des capacités de mon clavier) et je me suis tiré d'affaire très simplement grâce a Compiz.
Avant toute chose il faut supprimer les raccourcis existant pour les touches multimédia, pour cela ouvrir dans le menu Preferences les Racourcis Clavier et supprimer les mappings correspondant aux touches que l'ont veux redéfinir. De cette manière il n'y aura pas de conflits entre plusieurs lecteurs audio.
raccourcis-gnome Ensuite ouvrir le panneau de configuration de Compiz, activer le plugin Commandes si ce n'est pas déjà fait et assigner les commandes suivantes. (Pour avoir un détail des commandes disponibles taper amarok --help dans une console )
raccoucis-compiz1 Pour finir il suffira d'assigner ces commande aux touches multimédia
raccoucis-compiz2 Et voila, c'est terminé =)

The state of gaming on Linux

- no title specified

Many view gaming as the biggest obstacle keeping them from removing Windows from their computers. I can 't count the number of times I've things such as “I keep a dual boot because I still want to play some games on Windows”.

I myself like gaming but the reasons I don't use Windows are 1) that I'm not into the latest games as the majority of PC users are and 2) I'm willing to hack for hours in order to get a game working (what regular users want to avoid at all cost). But to be honest, I'm not a hardcore gamer, and that must be the reason that I've easily given up on Windows.

When a user gets into Linux there's not that many games to choose from (I mean big commercial titles working out of the box). Sure there's Open Source games, I'll talk about them later, and sure there is Wine but this just isn't a reliable solution. Take for example Silent Hill 2 which is a really great game by the way, it works flawlessly in Wine and I had a really good experience playing it in Linux. Silent Hill 3 is also a great game, and technically it's not that different from the second episode so one would say it should also work in Linux. Well no,  it just crashes (at least it did when I tried it, it seems that there is better support for this game now) so in order to play this game I had no choice but to play on a Windows computer. And that's what the majority of users will do, regardless of the game they want is rated Platinum or rated Garbage on Wine's AppDB.

Speaking of these ratings, these are just unreliable for any normal user. Many Wine testers have really low expectations and they might think that rating a game as “Gold”makes Wine more prestigious, but really it doesn't. When you play a game rated Gold, you expect some good results, but sometimes all you get is a framerate 2 or 3 times less than the one you get in Windows. Of course this rating can be legitimate sometimes, some users submit tests result that have been done with a big fat Core2 processor and a big fat Nvidia G2xx but totally forget to mention it in the results, and it's kinda hard to see the difference between 70FPS and 200FPS : both are just really playable.

There are also many games with a good rating where the tester tells us the game runs pretty well in 640x480. Come on, it's 2009, I would think no one judges playing games in such a low resolution as an acceptable solution but sadly, many do. Same thing goes with the level of details the game let you use. If you turn off HDR and put low resolution textures, it's not how the game was meant to be played.

It seems that these kind of tests do not even comply with Wine's rating guidelines. I remember that in the past, ratings where based solely on compatibility and not performance but now, reading from the current guidelines, an application running much slower than expected should be rated Bronze.

This doesn't change the fact that Wine developers target  better compatibility and not necessarily better performance and that's where Cedega got my attention. Cedega is the closed source version of Wine and aims to provide a better support for 3D games. For many games it does the job pretty well, the best example I have in mind being Left4dead which is unplayable in Wine but totally playable in Cedega. Cedega might be non free in the both ways, it brings gaming to the next level, providing support for many recent games.

I've been talking a lot about Windows games but nothing gets as good as native games and when I think about the current situation all I can do is cry in despair. The only recent titles that I can think of with a linux port are Quake Wars, Prey and World of Goo (and Prey is already kinda old). Other than this, there is Linux Game Publishing that sells ports of old games that I've never heard of before (Sacred is from 2004 and X3: Reunion from 2005). I miss the old Loki days in 2000-2002 when they ported really good games like Soldier of Fortune, Quake 3 or Unreal Tournament. Now all is left of Loki is Ryan 'Icculus' Gordon how seems the only guy on the planet really capable to do a Linux port.

The major question I asked myself is why is there less native games now than in 2002 ? Well, I have some clues about this. The game market has evolved since then and it has become much more expensive to make a game. The days where games where made by a small group of hackers are over and the current gaming industry is now even bigger than the movie industry. Game editors want to be paid for their games,  and the Linux market is just too low to even think about a port. I've been reading the Linux support thread on Unity3D forums and it's really enlightening to see what professional game developers think about the Linux community.

First major problem : the marketshare is way too low to even think about developing on Linux. The real problem is that this marketshare is low because Linux has almost no games to offer so the dog bites its tail here and we're stuck in an infinite loop. Arguments like “There is no DirectX on Linux” or “Linux is missing this library” are totally invalid. Game developers can do ports for any platform when they want to. Saying that Half Life ² will never get to Linux because it uses DirectX is wrong, HL² has been ported to the Playstation 3 and I've never heard of DirectX on Sony's console. When you look at the Sega Lindbergh arcade board, you see it's nothing more than a PC running Linux, still we don't get to play The House of the Dead 4 or Virtua Figher 5. All the latest generation consoles run on IBM Cell architecture and most of them don't use DirectX, meaning that every game is portable if you really want to.

Another problem adds to the problem of having a 1 or 2% market share of the whole desktop PC market, it's that Linux user have a reputation of not paying for stuff (because most of their software are free as in free speech AND free as in free beer). I think that is mostly untrue, at least in my case. I bought a few games on the Steam platform but how will Valve be aware that I don't run their games on Windows ? I think this reputation comes from the fact that you hear a lot from Free Software activists on the Internet whereas casual users, who are potential buyers, tend to stay quiet.

A user on the Unity 3D thread sums it up like this :

“Linux (desktop) users are (a) smaller in number even than Mac users, (b) buy less software than anyone, (c) have ridiculously high support costs unless they support themselves ... feel like GPLing your codebase? ”

The last point this user made is also a big problem. Sure there are some application that you can just download from a website and they will work on any distribution : think about Firefox, Google Earth , Eclipse or Doom 3. But as the application ages, it gets much worse when we're dealing with closed source software. Think about those old Loki installers, it's horrible to get them working on a recent Linux distribution : you'll have to deal with OSS, glibc 2.1 compatibility, and these sort of obsolete stuff. Quake 3 is a good example for this problem. When running the official closed source installer from iD software I'm pretty sure you'll run into some kind of problem at some point. If you use the open source ioquake3 binaries then you can except it to run out of the box. So yes, GPLing your codebase is indeed a good idea. At least game developers  should do it when stopping to support their applications.

I don't think that any game company has brought more to Linux gaming than iD software, they have written great game engines and more important Open Sourced them after a few years. Even though, on the same Unity3D thread I can read

“John Carmack of id Software has been quoted as saying that porting to Linux isn't worth it. Even though id does it, they do it as as technical exercise and not because it makes them any actual money.”

and

“ They started out developing on NeXT machines (no kidding) because they understand that you develop on the machine you like and ship on the machine you have to. They make so much money (and have so much technical skill) they can afford to take that attitude. Most games companies fail in both departments.”.

This is far from encouraging, knowing that the next engine id tech 5 might not be ported to Linux. Linux marketshare is slowly growing but game companies and offering less support than ever ! We already lost Epic Games with their failure at providing a UT3 client for Linux (while I think it's more Midway's fault than Epic's), if we also loose ID Software then ours chances of seeing future games on Linux are close to zero.

So what's left ? Open Source games ? Well excuse me but I'm a bit skeptical about these. Two years ago I thought that Open Source game where technically inferior to their commercial counterparts. Engines like Cube 2 (used in Sauerbraten) and Darkplaces (used in Nexuiz) have proved recently that they where capable of great things while others like Crystal Space / Blender Game Engine used in Yo Frankie! didn't impress me much, giving me the impression of an engine dating from 5 years ago. But I'm okay with poor graphics, I enjoy a lot of old games that don't look nearly as good as todays games. The only thing I ask for is good design and good gameplay or in one word: immersion. This is where Open Source games fail, I've never encountered a Free game that I wanted to play from start to finish if it's a single player game, or challenge me enough to keep me playing if it's multiplayer. I can't figure out how a large community of contributors fail at providing good design and gameplay. I guess that talented game designers get in the game industry and get paid making commercial games.  One good example of this Open Source failure is Open Arena. I've played Quake 3 Arena for hours, finished every level in Hardcore mode, finished some in Nightmare mode, I find the maps fun to play in, the models look cool, the sound effects are memorable. When playing the Open Source remake Open Arena is always got bored, the maps are awkward, the models and sound effects are pretty lame and more important than all, I don't have this feeling of playing a game with the perfect gameplay (Quake3 was pretty awesome for that). Actually, the best hope in Open Source gaming is Nexuiz, the gameplay is almost good (they still have to work on the movements and the part dealing with taking damage), and while I find the models poorly designed, the gameplay is fast enough so that I don't care about them that much. At some point I though that I was just beginning to get bored with video games in general. But then I found great new games that I enjoyed : Portal, Team Fortress 2 and Left4dead. That's what I call great design, perfect gameplay and total fun !  The new Prince Of Persia was really cool too and I enjoyed playing this great platformer.

Looking at the forums and blogs, I can clearly see that there are gamers on Linux that actually like all these Open Source games. These people are mainly the ones who reject all proprietary software. And while I understand the dislike of  proprietary code, I don't get why some people also insist on having Free (as in speech) content. Even Free Software activist Richard Stallman doesn't care about Free artwork ! Some activists gamers got carried too far away, I just think that the only reason they want Free games is to get free (as in beer) games. Free Software is not about this, it's about having the control on your programs, and we cans see why game developers deserve to get paid.

I think that games with proprietary artwork and gameplay running with an Open Source engine is the only hope left for Linux gaming. Imagine that Valve open sourced their Source Engine (while they could start with their HL1 engine …), would they sell less Orange Boxes and Left4deads ? I don't think so …We would see Source games ported to Mac and Linux in a few months or weeks and then Valve could see that making an engine Free Software does increase sales. Of course this method doesn't work for companies that only sell a game engine to other game developers like Unity3D does. In these cases it would be a good idea to use iD software's method and Free only the engines where you don't make anymore profit. Of course, in order to deliver a Free game engine, a game company is required to care about it's costumers, and we all know that's pretty rare : They're mostly here for the money, we're not in 1999 anymore, back when games were still made by a small team of passionate hackers. Open Source games also raise the issue of not having malicious code like DRM, in the game. I don't think game published like the idea of  giving their costumers this amount of power, neither do they have the desire to bring unlimited support for their games (Open Source code can be maintained forever), because supporting old games can mean selling less of the newer ones. Given all these facts, Linux gaming is in a pretty bad situation today, and maybe that video games aren't compatible with the spirit surrounding Free Software and open systems like Linux. In the book “The cathedral and the bazaar”, the author Eric Raymond states that 90% of all software development in for in-house use only, and using Free Software as proved to be the  most efficient method here. Sadly, video games are part of the remaining 10% and while I think that most the value resides in gameplay and design (which have no point in being Free), I'm not sure that an editor would be willing to Free its codebase just to gain a few Mac and Linux users.

Un point sur l'état du jeu vidéo sur Linux

- no title specified

Beaucoup d'utilisateurs considèrent le jeu vidéo comme étant l'obstacle majeur les empêchant de supprimer définitivement Windows de leur ordinateur. Je ne compte plus le nombre de fois ou j'ai pu lire des choses du genre « Je garde un dual boot parce que je veux  jouer a des jeux sur Windows ».

J'aime jouer mais les raisons pour lesquelles je n'utilise plus Windows sont parce que 1) je suis moins friand de jeux de dernière génération que la majorité des joueurs sur PC et 2) Je suis prêt a bidouiller pendant des heures pour avoir un jeu qui tourne bien (ce que la majorité des utilisateur veux éviter a tout prix). Pour être honnête , je ne suis pas un hardcore gamer, et c'est probablement la raison pour laquelle j'ai abondonné Windows si facilement.

Lorsqu'un utilisateur arrive sur Linux, le choix de jeux vidéos est maigre (Je parle de gros titres commerciaux qui marchent nativement). Bien sur il y a les jeux Open Source, j'en parlerai plus loin, et bien sur il y a Wine mais ce n'est pas une solution assez fiable. Prenons pour exemple Silent Hill 2, qui est au passage un excellent jeu : Il marche sans aucun problème avec Wine et je garde une très bonne expérience de ce jeu sur Linux. Silent Hill 3, qui est aussi un excellent jeu, et il est techniquement très proche de son prédécesseur. On serait donc amené a penser qu'il devrait aussi fonctionner sur Linux. Et bien non, le jeu plante avant de démarrer (ou tout du moins il plantait quand je l'ai essayé, il semble que ce jeu fonctionne mieux avec les dernières versions de Wine), donc pour jouer a ce jeu je n'ai pas eu d'autre choix que de jouer sur Windows. C'est ce que la majorité des utilisateurs feront que le jeu soit noté Platinum ou Garbage sur Wine AppDB.

En parlant de ces notations, elles ne sont pas fiable pour un utilisateur normal. Beaucoup de testeurs de Wine se suffisent de peu et doivent penser que noter un jeu « Gold » rends Wine plus prestigieux, mais en vérité c'est loin d'être le cas. Quand on joue a un jeu noté Gold, on s'attend a de bons résultats, mais souvent on a juste droit a un framerate de 2 a 3 fois inférieur a celui qu'on a sur Windows. Bien sur cette notation est quelque fois justifiée, certains testeurs soumettent des tests effectué avec  un bon gros  processeur Core2 et une bonne grosse carte Nvidia G2xx mais oublient totalement de le mentionner dans leurs compte rendu, et il est très difficile de faire la différence entre 70FPS et 200FPS : les deux sont parfaitement jouables.

Il y a aussi de nombreux jeux ou le testeur nous informe que le jeu tourne bien en 640x480. Allons … Nous sommes en 2009, j'aurais pensé que personne n'aurais considéré que jouer a un jeu dans une résolution aussi faible soit acceptable mais malheureusement beaucoup le pensent. La même chose est valable pour le niveau de détail que le jeu permet d'utiliser. Si on coupe le HDR et qu'on utilise les textures basses résolution, ce n'est pas ainsi que le jeu a été prévu de fonctionner.

Il me semble que ce type de tests n'est même pas en accord avec les règles de notation de Wine. J'ai souvenir que dans le passé, les notes étaient basées uniquement sur la compatibilité et non les performances mais maintenant, en lisant les recommendations actuelles, une application dont les performances sont fortement réduites doit être notée Bronze.

Ceci ne change pas le fait que les développeurs de Wine visent une meilleure compatibilité parfois au détriment des performances et c'est sur ce point que Cedega gagne mon attention. Cedega est la version propriétaire de Wine et offre un meilleur support des jeux 3D. Pour de nombreux jeux, il fait très bien son travail, le meilleur exemple que j'ai en tête étant Left4dead qui est injouable avec Wine alors qu'il est fluide avec Cedega. Cedega a beau être fermé et payant, il amène le jeu sur Linux a un niveau supérieur et offre un bon support pour de nombreux jeux récents.

 

J'ai parlé des jeux Windows mais rien ne vaux les jeux natifs et quand je pense a la situation actuelle je ne peux que pousser un cri de désespoir. Les seuls derniers titres récents qui me viennent a l'esprit et qui ont bénéficié d'un portage vers Linux sont Quake Wars, Prey et World of Goo (et Prey commence a dater). Mis a part ceux ci, il y a Linux Game Publishing qui porte d'anciens jeux dont je n'avais jamais entendu parlé auparavant (Sacred date de 2004 et X3: Reunion de 2005). L'époque des jeux Loki en 2000-2002 me manque, nous avions alors des portages d'excellents jeux comme Soldier Of Fortune, Quake 3 ou Unreal Tournament. Maintenant tout ce qui reste de Loki est Ryan 'Icculus' Gordon qui semble être le seul type sur la planète vraiment capable de faire un portage Linux.

La principale question que je me pose est pourquoi y a t'il moins de jeux natif maintenant qu'en 2002 ? J'ai bien quelques idées a ce sujet. Le marché du jeu vidéo a évolué depuis cette époque et la conception d'un jeu est beaucoup plus onéreuse. Les jours ou les jeux étaient le fruit d'une petite équipe de hackers est terminée et l'industrie des jeux vidéos a dépassé celle du cinéma. Les éditeurs de jeux attendent principalement une rentrée d'argent et le marché que représente les utilisateurs de Linux est trop faible pour penser a un portage. J'ai lu le sujet concernant  le support de Linux sur les forums d'Unity3D et il est très enrichissant de voir ce que les développeurs de jeux professionnel pensent de la communauté Linux.

Le premier problème majeur : la part de marché est trop faible pour penser a développer pour Linux. Le vrai problème étant que si ce marché est si faible c'est justement parce que Linux a très peu de jeux a offrir, le serpent se mords la queue et nous sommes coincés dans une boucle infinie. Les arguments tels que « Il n'y a pas DirectX sur Linux » ou «Telle librairie n'existe pas sur Linux »sont totalement invalides. Les développeurs savent faire des portages sur n'importe quelle plateforme quand ils en ont la réelle volonté. Dire que Half Life² ne sera jamais porté sur Linux parce qu'il utilise DirectX est faux, HL² a été porté sur Playstation 3 et je n'ai jamais entendu parler de DirectX sur les consoles de Sony.

Quand nous jetons un oeil sur la borne d'arcade Sega Lindbergh , nous voyons qu'il ne s'agit de rien de plus qu'un PC faisant tourner Linux, pourtant nous ne jouons pas a House of the Dead 4 ou Virtua Fighter 5. Toutes les consoles de dernière génération utilisent une architecture basée sur le Cell d'IBM et la majorité n'utilisent pas DirectX, prouvant ainsi que n'importe quel jeu est portable si la volonté est la.

Un autre problème viens se rajouter au fait d'avoir un marché comptant 1 ou 2 % des utilisateurs des PC de bureau, c'est la réputation qu'on les utilisateurs de Linux de ne pas payer leurs logiciels (car ils sont majoritairement libres et gratuits). Je pense que c'est partiellement faux, au moins dans mon cas. J'ai acheté quelques jeux sur la plateforme Steam, mais comment Valve peut il être au courant que je ne lance pas ses jeux sur Windows ?

Je pense que cette réputation viens du fait que les activistes du logiciels libres sont très présents sur la toile alors que les simples utilisateur qui sont aussi des acheteurs potentiels ont tendance a rester très discrets.

Un membre des forums d'Unity3D résume la situation comme ceci :

 “Linux (desktop) users are (a) smaller in number even than Mac users, (b) buy less software than anyone, (c) have ridiculously high support costs unless they support themselves ... feel like GPLing your codebase? ”

«Les utilisateurs de Linux sont (a) encore moins nombreux que les utilisateurs de Mac, (b) achètent moins de logiciels que n'importe qui, (c ) ont des coûts de support ridiculement hauts sauf s'il se maintiennent eux même … vous vous sentez de mettre votre code sous GPL ? »

Le dernier point abordé par ce membre est aussi un gros problème. Bien sur il y a des applications qui peuvent être téléchargées a partir du site officiel et qui fonctionneront sur n'importe quelle distribution : pensez a Firefox, Google Earth, Eclipse ou Doom 3. Mais avec le temps, cela deviens très dur de garantir la compatibilité d'une application propriétaire. Pensez aux installeurs Loki, les utiliser sur une distribution Linux récente est une horreur : vous aurez a régler des problème lié a OSS, a la compatibilité glibc 2.1 et ce genre de choses obsolètes. Quake 3 illustre très bien ce problème. Si vous lancez l'installeur propriétaire d'iD Software, je garanti que vous rencontrerez des problèmes. En revanche si vous utilisez son équivalent libre ioquake3 alors tout devrais fonctionner sans souci.

Donc oui,passer son code sous les termes de la GPL est une très bonne idée, les développeurs devraient au moins le faire quand ils arrêtent de supporter une application.

 

Je ne pense pas qu'une société ai apporté autant au jeu vidéo sur Linux qu'iD Software, il ont écrit de formidables moteurs 3D et plus important encore, ils les ont libérés après quelques années.

Pourtant sur le même topic du forum d'Unity3D on peut lire :

“John Carmack of id Software has been quoted as saying that porting to Linux isn't worth it. Even though id does it, they do it as as technical exercise and not because it makes them any actual money.” ( « John Carmack a été cité pour avoir dit que le portage de jeux sur Linux n'en vaut pas la peine. Et si ID le fait, c'est pour eux un exercice tehnique et pas parce que cela leur rapporte de l'argent » )

et  

“ They started out developing on NeXT machines (no kidding) because they understand that you develop on the machine you like and ship on the machine you have to. They make so much money (and have so much technical skill) they can afford to take that attitude. Most games companies fail in both departments.” («Ils ont commencé leur développement sur des machines NeXT (véridique!) parce qu'il ont compris qu'on développe sur la machine de son choix et qu'on livre sur la plateforme que l'on doit. Ils gagnent tellement d'argent et ont tellement de compétences techniques qu'ils peuvent se permettre d'avoir cette attitude. La plupart des studios de développement n'ont ni l'un ni l'autre »)

Ceci est loin d'être encourageant maintenant que nous savons que le prochain moteur ID Tech 5 a des chances de ne jamais voir le jour sur Linux. Les parts de marché de Linux augmentent lentement mais les sociétés de jeux vidéos n'ont jamais aussi peu supporté ce système ! Nous avons déjà perdu Epic Games avec leur échec concernant Unreal Tournament 3 (même si je pense que la faute est plutot du coté de Midway que d'Epic Games), si nous perdons aussi iD Software alors les chances de voir les jeux de demain sur Linux sont proche de zéro.

Alors que nous reste t'il ? Les jeux Open Source ? Excusez moi de me montrer un peu sceptique a leur propos. Il y a deux ans, je pensais que les jeux Open Source étaient techniquement inférieurs a leurs équivalents commerciaux. Aujourd'hui avec des moteurs comme Cube 2 (utilisé par Sauerbraten) et Darkplaces (utilisé par Nexiuz) ont prouvé qu'ils étaient capables de très bonnes choses, alors que d'autres comme Crystal Space / Blender Game Engine utilisé dans Yo Frankie ! n'ont pas réussi a vraiment  m'impressionner , me donnant l'impression d'être en face d'un jeu vieux de 5 ans. Mais je ne suis pas contre des graphismes rudimentaires, j'apprécie de nombreux anciens jeux qui sont loin d'être aussi beaux que ceux produits actuellement. Les seules choses que je demande sont un bon design et une bonne jouabilité ou en un seul mot : immersion.

C'est la où les jeux Open Source échouent, je n'ai jamais rencontré un jeu libre que j'ai voulu finir s'il s'agit d'un jeu solo, ou qui me branche assez pour que je continue a y jouer dans le cas d'un jeu multijoueur.  Je ne vois pas comment une grande communauté de contributeurs n'arrivent pas a fournir un bon gameplay et un bon design. J'assume que les game designers talentueux intègrent l'industrie du jeu vidéo et sont payés pour faire des jeux commerciaux.

Un exemple de cet échec des jeux libre est Open Arena. J'ai joué a Quake 3 pendant des heures, fini toutes les maps en niveau Hardcore, et certaines en niveau Nightmare. Les maps sont bien pensées , les modèles ont un bon look, les effets sonores sont mémorables. En jouant a son remake libre Open Arena, je me suis lassé au bout de quelques minutes. Les maps sont bizarres, les modèles et effets sonores sont très pauvres et plus important que tout, je n'avais pas le sentiment d'avoir un jeu au gameplay parfait (Quake 3 était assez impressionnant sur ce point). En fait, le meilleur espoir pour le jeu Open Source est Nexuiz. Le gameplay est presque bon (il y a encore des efforts a faire sur le mouvement et la partie qui s'occupe des dommages pris), et même si je trouve que les modèles sont loins d'être exceptionnels, le gameplay est assez rapide pour que je n'y prête pas attention. A un moment j'ai même pensé que les jeux vidéos en général me lassaient, puis j'ai découvert des jeux géniaux que j'ai vraiment apprécié : Portal, Team Fortress 2 et Left4dead. Ça, c'est que j'appelle un bon design,  un gameplay parfait et du fun a l'état pur ! Le dernier Prince of Persia était aussi de très bonne qualité, et je n'avais pas joué a un jeu de plateforme aussi bon depuis très longtemps.

En lisant les  forums et les blogs, je vois clairement qu'il y a un public qui apprécie les jeux Open Source. Ce sont majoritairement les mêmes personnes qui rejettent tout programme propriétaire. Et si je comprends qu'on aime pas les logiciels propriétaires, j'ai beaucoup plus de mal a comprendre pourquoi certains insistent pour avoir un contenu Libre. Même l'activiste du Logiciel Libre Richard Stallman n'accorde pas grande importance aux artworks libres ! Certains joueurs activistes se sont laissés emporté trop loin, et je pense que la seule raison de vouloir des contenus libres est d'avoir des jeux totalement gratuits. Ceci n'est pas le but du logiciel libre, son but est de garder le contrôle sur ses programmes, et il est aisé de voir pourquoi les designers de jeux doivent être rémunérés.

A mon avis les jeux offrant des artworks et un gameplay non libre mais utilisant un moteur Open Source sont le plus grand espoir qu'il reste au jeu vidéo pour Linux.  Imaginez un instant que Valve libère les sources de son moteur Source (même s'il pourraient commencer par le moteur d'HL1 …), vendraient t'il moins d'Orange Boxs et de Left4deads ? Je ne pense pas …Nous verrions des portages des jeux Source sur Mac et Linux en quelques mois ou semaines et Valve pourrait constater que rendre son moteur libre permet d'augmenter considérablement les ventes. Cette méthode ne fonctionne pas pour les société qui vendent un moteur de jeu a d'autres développeurs comme le fait Unity3D. Dans ces cas, il serait bon d'employer la méthode d'iD Software et de libérer seulement les moteurs qui ne génèrent plus assez de profit.

Bien sur, pour qu'un moteur de jeu soit publié en tant que Logiciel Libre, une société de jeux vidéos doit avoir le respect de ses clients comme une de ses priorité, ce qui aujourd'hui est assez rare : Beaucoup sont la principalement pour l'argent, nous ne sommes plus en 1999, où les jeux étaient encore  produits par de petites équipes de hackers passionés.

Les jeux Open Source soulèvent des problèmes comme ne pas avoir de code malicieux tel que des DRM dans le jeu. Je ne crois pas qu'un éditeur apprécie l'idée de donner autant de pouvoir a ses clients, et n'ont pas non plus le désir de fournir un support illimité dans le temps (un programme Open Source peut être maintenu indéfiniment), car supporter les anciens jeux c'est aussi vendre moins de nouveaux.

 

En prenant tous ces paramètres en compte, la situation actuelle du jeu sur Linux est bien mauvaise, et peut être que les jeux vidéo ne sont pas compatible avec l'esprit qui entoure les Logiciels Libres et les systèmes ouverts comme Linux. Dans le livre « The cathedral and the bazaar », l'auteur Eric Raymond affirme que 90% des développements logiciels sont destinés a un usage interne a une entreprise, et l'utilisation de logiciels libres s'est montrée la meilleure solution dans ce cas. Malheureusement les jeux vidéos font parti des 10% restant, et même si je suis intimement persuadé que toute la valeur d'un jeu réside dans son design et son gameplay (qui n'ont aucune raison d'être libres ou gratuits), je ne suis pas sûr qu'un éditeur soit prêt a prendre le risque de libérer son code pour gagner quelques utilisateurs Mac ou Linux.

The cathedral and the bazaar : une lecture indispensable !

Depuis le temps que j'ai terminé ce livre je me suis toujours dit qu'il serait bien que je fasse un billet a son sujet, car il fait parti, a mon avis, des ouvrages indispensables a la compréhension du logiciel libre. Son auteur, Eric Raymond, est créateur de logiciels libres comme fetchmail, mais est surtout connu pour avoir fondé l'Open Source Initiative. Pour la petite anecdote, c'est l'ouvrage dont je parle aujurd'hui qui a poussé les dirigeants de Netscape a libérer leur code, ce qui a donné naissance a Mozilla et plus tard Firefox.
La première version de cette ouvrage date d'il y a 10 ans en arrière mais les sujets abordés sont toujours d'actualités et mis a part quelques extrapolations sur le futur qui se sont plus ou moins vérifiées, les essais de Raymond sont très pertinents même en 2009.
Je parle d'essais au pluriel car je me limite pas au seul "Cathedral and the bazaar" mais a la totalité du livre publié par O'Reilly, c'est a dire :

  • A brief history of hackerdom
  • The cathedral and the bazaar
  • Homesteading the noosphere
  • The magic cauldron
  • Revenge of the hackers
  • How to become a hacker

Si je parle de ce livre aujourd'hui, c'est que je remarque que la communauté francaise, au travers des blogs, des forums se dirige vers une sorte de monoculture du libre, passant obligatoirement par Richard Stallman et ses idées. Si RMS est une des pierres angulaires du libre, réduire le logiciel libre a seulement la Free Software Foundation et a la General Public License est trop réducteur pour représenter la réalité des choses. Il ne s'agit pas de dénigrer le travail de Stallman, mais de mettre au même plan d'autres acteurs qui ont joué un rôle tout aussi important dans la construction du logiciel libre tel qu'il est aujourd'hui (En plus d'Eric Raymond, on pourrais rajouter Theo de Raadt, Linux Torvalds, Alan Cox, et j'en oublie).

Quand je parle de monoculture, c'est que moi aussi j'en ai fait parti, et la lecture de ce livre m'a ouvert a d'autres manière de voir les choses, toutes aussi pertinentes que celles de Stallman, tout en m'apprenant des bases importantes sur le modèle de développement Open Source. Un des points a retenir c'est le rapprochement a faire entre les termes Open Source et Logiciel Libre, si Stallman fait tout sont possible pour séparer les deux et tenter de dénigrer le terme Open Source , Raymond quand a lui, montre que les deux termes sont très semblables et qu'il ne devrait y avoir aucune animosité entre les partisans des deux camps. C'est un point important, car ce n'est pas en se querellant sur les détails qui séparent les deux termes que cela fera avancer quoi que ce soit vis a vis du véritable adversaire qui est le logiciel propriétaire.
Les essais de Raymond montrent un autre aspect important : Le modèle de développement Open Source est supérieur au modèle privateur, ce qui fait qu'on ne perçois plus le propriétaire comme une menace mais simplement un modèle dépassé avec lequel on doit vivre avec en attendant qu'il s'éteigne de lui même. On ne combat pas le logiciel propriétaire en le rejetant en bloc, on le combat en développant des alternatives libres supérieures. Oui, le camp de l'Open Source a raison de se focaliser sur la technique car c'est la technique qui fait qu'un produit libre est meilleur que son concurrent propriétaire (par exemple Firefox, ou Apache). Je suis un peu désolé de voir tout ces utilisateurs qui utilisent du libre parce que c'est libre. J'utilise du libre parce qu'il offre de meilleurs produits, et ces produits sont meilleurs parce qu'ils sont libres ! Certes la différence est subtile mais elle se voit dans la manière dont les gens parlent du Libre. La ou Stallman est sur la défensive par rapport au propriétaire, Raymond se pose en attaquant et montre la supériorité de l'Open Source. C'est toute la relation de dominant / dominé qui change,

Eric Raymond a fait parler de lui récemment en affirmant que la licence GPL n'était plus nécessaire, Si ce point de vue est un peu extrême, il va dans la continuité de ce qu'il a pu écrire 10 ans plus tôt. Il montre en effet sa confiance absolue dans le modèle Open Source en disant que ceux qui voudraient prendre du code libre pour en faire un logiciel fermé seraient au final perdants. La GPL étant une très bonne licence, il n'y a aucune raison de ne pas l'utiliser, mais cette interview montre bien le sentiment de domination sur le propriétaire que l'auteur ressent.

Bref, la cathédrale et le bazar et les essais qui l'entourent sont une lecture indispensable a toute personne intéressée par le logiciel libre. Et si je vous encourage a commander la version papier, vous pouvez tout de même tout lire en ligne gratuitement : http://www.catb.org/~esr/writings/c...
La majorité des essais sont aussi traduits en Français pour ceux qui auraient du mal avec la version originale :)

Astuces en vrac pour Jaunty Jackalope

Le passage de Intrepid Ibex vers Jaunty Jackalope beta s'étant très bien déroulé j'en ai immédiatement fait mon OS principal.Pour les fonctionnalités, pas de changement extraordinaires mais j'ai remarqué une stabilité et une réactivité accrue par rapport aux anciennes version.
Voici quelques astuces qui sont applicables sur Jaunty Jackalope et peut être sur d'autres distributions :

Si le lancement de Google Earth 5 beta crashe avec un message d'erreur concernant le fichier libcrypto.so.0.9.8, le fait de supprimer ou renommer ce fichier devrait remettre les choses dans l'ordre (il se trouve dans le dossier de Google Earth)

Ubuntu 9.04 mettra fin au support de Python 2.4, ce qui posera un problème aux utilisateurs de Cedega 7 dont l'installeur demande python2.4-dbus en dépendance. En attendant un correctif officiel, il faut reconstruire le paquet de la manière suivante :

mkdir -p cedega_000133_all/DEBIAN
ar p cedega_000133_all.deb data.tar.gz | tar zx -C cedega_000133_all/
ar p cedega_000133_all.deb control.tar.gz | tar zx -C cedega_000133_all/DEBIAN/
mv cedega_000133_all.deb cedega_000133_all.prerebuild.deb
perl -pi -e 's/python2.4-dbus/python-dbus/' cedega_000133_all/DEBIAN/control
dpkg-deb --build cedega_000133_all
rm -rf cedega_000133_all
sudo dpkg -i cedega_000133_all.deb 

Cedega donne encore quelques messages d'avertissement liés a l'utilisation de Python2.6 mais ceux ci peuvent être ignorés.

Toujours dans Python et ses versions, la 2.6 intègre le module json par défaut, mais possède une implémentation différente de la librairie du paquet python-json fournie pour python 2.5

Ceux qui comme moi préfèrent (a juste titre) Amarok 1.4 a Amarok 2, un dépot PPA a été mis en place pour en profiter , il suffira d'ajouter les lignes suivantes dans les dépots tiers dans synaptic.

deb http://ppa.launchpad.net/bogdanb/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/bogdanb/ppa/ubuntu jaunty main

Pensez a déinstaller Amarok 2 sinon il sera en conflit avec Amarok 1.4

La dernière version de Gnome-Do permet de remplacer avantageusement avant-window-navigator ou cairo dock. Pour cela il faut sélectionner le thème Docky dans l'onglet apparence des préférences. Gnome Do placera automatiquement dans le dock les programmes les plus souvent appelés via le lanceur. Il est aussi possible de procéder demanière plus traditionnelle en glissant des icônes vers le dock.

Lancement de Open Source Developer Network

Dans le précédent billet, j'exposais certaines difficultés que le développeur novice peut avoir lors d'une première approche dans le monde du logiciel libre.
Une des difficultés est de savoir ou trouver la documentation, car si l'on me dit RTFM je répondrais : WFP ? (Which F**king Paragraph ?).
L'autre rengaine courante est GIYF (Google Is Your Friend), et bien pas vraiment a vrai dire. Google est surtout très fort pour indexer tous les forums, toutes les mailings list, tous les blogs et s'il est facile de trouver des personnes qui ont le même problème que celui posé, il l'est déjà moins de trouver la bonne réponse.
Voila où OSDN (déformation du nom d'un célèbre site de documentation, d'un éditeur logiciel pas très apprécié dans les parages) rentre en jeu.
OSDN, ce n'est rien de bien compliqué techniquement : Un peu de HTML, et d'Ajax mais c'est surtout un travail de recherche et de classification. Cette page vise a regrouper toutes les pages de documentation de tous les langages et toutes les technologies Open Source. Oui, rien que ça... et la page n'a même pas un jour qu'elle commence déjà à être assez fournie.
La page comporte un moteur de recherche qui ira chercher uniquement sur le site en cours de consultation. (ou sur google.com/linux si aucune documentation n'est affichée)
Bien entendu je suis ouvert a toutes les suggestions, n'hésitez pas a m'envoyer dans les commentaires ou par mailavec le formulaire dédié les liens vers les documentations que vous jugez essentielles. Et ne soyez pas limités aux documentations officielles non plus, un bon tutoriel peut avoir sa place.
Aussi, si vous jugez l'organisation de l'arborescence inappropriée a certains endroits, n'hésitez pas a le signaler.
J'espère que cette page Web sera aussi utile pour vous qu'elle l'est déjà pour moi ;)

Des difficultés de la participation aux logiciels libres

L'idée de ce billet m'est venu a la suite de celui de xbright intitulé La difficulté d'exister pour les petits projets de logiciel libre ou son auteur met en avant le manque de contributeurs sur les petits projets Open Source. Hormis le fait d'écrire des rapport de bugs, je n'ai jamais réellement codé pour un projet libre existant, donc j'ai voulu tenter l'expérience en prenant comme projet Bluemindo, le player audio de xbright écrit en Python.
Récupérer un projet et se lancer dans l'analyse de son code source est une tâche très intimidante au premier abord, il faut consacrer un certain temps afin d'apprivoiser les sources, tester le programme, repérer quelle fonction fait quoi, visualiser l'architecture du logiciel. Toutes ces tâches n'existent pas lorsque l'on est le créateur d'un projet puisque l'on est parti de zéro pour arriver au résultat que l'on a en tête.
Il faut dire que les développeurs ne facilitent pas toujours la vie de ceux qui passent derrière. Les difficultés sont multiples : manque de commentaires dans le code, noms de variable peu explicites, identifiants des widgets du fichier Glade laissé avec leur valeurs par défaut (button1, progressbar3, .....).
Un code source ouvert se doit avant tout d'être clair et lisible. Eric S. Raymond évoque ce problème dans le livre "The cathedral and the bazaar" en disant que la clarté du code est plus importante que sa vitesse d'exécution. De mon point de vue, un nom de variable composé d'une seule lettre est toujours un mauvais nom de variable. C'est une perversion venue du monde obscur des mathématiques et qui n'a rien a faire dans la programmation. Les éditeurs de code source modernes supportent tous l'autocomplétion des noms de variable, donc il n'y a aucune raison pour ne pas utiliser des noms explicites qu'ils fassent 15 caractères ou plus.
Une fois que l'on a parcouru une bonne partie du code source de l'application, on commence a saisir le fonctionnement global, et on peut s'attaquer a l'écriture de code... Ouhla, pas si vite ... Ne perdez pas une seule minute a écrire la moindre ligne de code avant d'avoir obtenu l'accord de l'auteur. Open Source ne veux pas dire que c'est la fête et que chacun écrit ce qu'il veut dans un projet, ne contribuez pas avant d'avoir la bénédiction du "benevolent dictator for life", il m'est arrivé de soumettre des patchs qui n'ont pas été accepté et pour plusieurs raisons : l'auteur avait déjà codé la modification de son propre coté ou l'auteur a refusé l'intégration du patch. Ici, on voit la deuxième difficulté : le développeur principal, n'a de comptes a rendre a personne et il ne va pas précéder chaque patch de son cru par un rapport de bug sur sa forge.
J'ai beau avoir trainé dans le monde de l'open source quelques années, avoir quelques bonnes bases en programmation, j'ai toujours l'impression qu'il manque quelque chose d'essentiel afin se saisir complètement le mode de développement du logiciel libre. Les sources sont libres, oui très bien, mais est ce suffisant ? L'exemple de Rhythmbox nous prouve que non, Dans son billet Cyrille Borne exprime ses doutes quand a la viabilité d'un projet Open Source :

Il me semblait pourtant que l'un des intérêts de l'ouverture du code, c'était qu'en cas d'arrêt d'un développeur, un autre apparaît pour prendre la relève. Un système auquel je n'ai jamais cru, tant il est difficile dans le cas de l'écriture d'un code de repasser derrière, si bien que les gens préfèrent créer leur propre application.

Dans les commentaires de ce même billet, RunningTracker cerne très bien le problème :

il est (très) difficile de reprendre un logiciel développé par quelqu'un d'autre. C'est là où la documentation prend tout son sens. Une bonne documentation (avec schémas UML, explication des algos... etc) et un code bien commenté (ce qui est très rare...) facilitent grandement la compréhension et la reprise du code. Je pense qu'en tant que développeurs, nous devrions passer plus de temps sur ces deux aspects (même si c'est parfois rébarbatif).

Dans la communauté, personne ne pense a reprendre le développement de Rhythmbox, et on réfléchi déjà a son successeur. Je peux comprendre : s'il a déjà été compliqué de se plonger au coeur de Bluemindo qui est un projet jeune et écrit en Python, je n'imagine même pas quels efforts il est nécessaire de faire pour comprendre le fonctionnement de Rhythmbox qui est plus mature et codé en C.
La page concernant le développement de Rhythmbox ressemble plus a une mauvaise blague avec ses liens vers SVN et IRC. Avec ces deux éléments, il va être difficile d'aller très loin ...
Maintenant voila ce que je propose :
Utiliser Internet pour ce a quoi il a été construit a la base: permettre a des chercheurs de travailler ensemble. Partager les sources n'est pas suffisant, il faut aussi avoir un système collaboratif permettant d'étudier, d'analyser un projet libre. Il manque un outil qui aide a la compréhension de la programmation, parce qu'il y a un fossé qui est en train de se créer entre les programmeurs vétérans et les novices. Pour reprendre les concepts de Eric Raymond, les plans de la cathédrale doivent être rendus public et le bazaar doit être ordonné.
Il est aussi important a mes yeux d'avoir une documentation centrale, une mère de toutes les documentations, avec tous les langages, toutes les librairies, tous les outils de développement, avec en bonus des tutoriels et des exemples. En quelque sorte l'équivalent de MSDN pour le logiciel libre.
Une grande partie de la communauté reste bloquée dans le test de différentes distributions, la compilation de logiciels, et les rapports de bug. C'est bien mais j'ai envie que les choses aillent plus loin, et pour cela il faut que la marche qui sépare le simple utilisateur du réel contributeur soit plus simple a gravir.

Ubuntu n'est pas libre : Une affirmation absurde

Mettons les choses au clair, quand je dit "une affirmation absurde", cela ne signifie en aucun cas une affirmation fausse. Oui, Ubuntu contient du code fermé, et je veux ici montrer que se baser sur cette caractéristique du système pour le rejeter est totalement incohérent.

Tout d'abord il est bon de savoir quels sont précisément les logiciels installés contenant du code propriétaire. Pour cela j'ai lancé la commande vrms sur une installation fraiche d'Ubuntu 8.10 dans Virtual Box, le résultat est le suivant :

            Non-free packages installed on strider-vbox

fglrx-modaliases          Identifiers supported by the ATI graphics driver
human-icon-theme          Human Icon theme
linux-generic             Complete Generic Linux kernel
linux-restricted-modules- Non-free Linux 2.6.27 modules helper script
linux-restricted-modules- Restricted Linux modules for generic kernels
nvidia-173-modaliases     Modaliases for the NVIDIA binary X.Org driver
nvidia-177-modaliases     Modaliases for the NVIDIA binary X.Org driver
nvidia-71-modaliases      Modaliases for the NVIDIA binary X.Org driver
nvidia-96-modaliases      Modaliases for the NVIDIA binary X.Org driver
tangerine-icon-theme      Tangerine Icon theme

            Contrib packages installed on strider-vbox

nvidia-common             Find obsolete NVIDIA drivers

  10 non-free packages, 0.8% of 1201 installed packages.
  1 contrib packages, 0.1% of 1201 installed packages.


Parmi cette liste ,j'élimine d'emblée les deux thèmes d'icones : Human et Tangerine qui sont sous license Creative Commons Attribution-ShareAlike 2.5 et qui n'ont rien a bénéficier d'une license GPL. Pour les libristes les plus intransigeants rappelons que Stallman lui même ne tiens pas particulièrement a voir des fichiers autre que du code source sous licence libre. Bref, ces thèmes d'icônes sont librement distribuables et c'est le principal. Un parenthèse sur Firefox et son logo qui ne sont pas utilisables librement. Un nom et un logo ne contiennent pas de code source, ils n'ont aucune raison d'être sous licence libre.

Un tour rapide des paquets concernant les drivers ATI et NVidia. nvidia-common est un script Pyhton sous GPL V2, il n'a rien a faire dans cette liste. Les paquets modaliases sont plus subtils : ils disposent d'un copyright d'AMD ou NVidia et ne sont pas sous GPL. Mais il ne s'agit pas des drivers a proprement parler mais uniquement d'une liste d'identifiant de cartes PCI avec le driver le plus adapté. En gros cela va indiquer au gestionnaire de pilote quel est le bon paquet a télécharger pour la carte en cours d'utilisation.

strider@strider-desktop:/usr/share/jockey/modaliases$ head -n2 nvidia-177 
# Listing generated by nvidia_supported. Do not edit manually.
alias pci:v000010DEd00000040sv*sd*bc03sc*i* nvidia nvidia-glx-177


Il nous reste maintenant le plus intéressant : Linux !
Le paquet linux-restricted-modules est le premier paquet comportant réellement du code propriétaire inclus dans trois projets distincts : ltmodem, broadcom et madwifi. Donc sans ce paquet vous aurez très peu de chance de voir votre modem interne avec un chipset Lucent, ou votre carte wifi avec un chipset Broadcom ou Atheros fonctionner. Si vous ne possédez aucun de ces trois type de matérie, vous pouvez désinstaller ce paquet si la présence de blobs binaires sur votre disque dur qui ne seront jamais exécutés vous dérange.
Et puis le meilleur pour la fin, le logiciel le moins libre de la distribution Ubuntu : le noyau Linux.
Je n'ai pas été chercher si les développeurs d'Ubuntu avaient rajouté certains modules fermés au noyau de base car celui ci, celui qui est en téléchargement sur kernel.org, en contient déjà suffisamment. Le noyau contient effet des blobs qui seront chargé sur les périphériques qui en ont besoin pour fonctionner. La FSF a bien évidemment crée un kernel linux libre dépourvu de ces blobs. Pour générer cette version spéciale du noyau, un script bash parcours toutes les sources du noyau a la recherche de microcode écrit en code machine et le supprime.
Kernel-libre
Le code nécessaire au bon fonctionnement du matériel est remplacé par le commentaire /*DEBLOBBED*/ . Le kernel libre offre donc les mêmes fonctionnalités que le kernel de base, les mêmes drivers sont présents, mais le périphérique demandant un microcode risque d'avoir quelques suprises quand il essayera de s'initialiser avec un kernel libre. La FSF n'a pas retiré les drivers propriétaires, elle les a rendu disfonctionnels ! On entre ici dans l'absurde mais on peut facilement continuer plus loin. Regardez autour de vous, essayez de vous faire une représentation de tout les appareils électroniques qui vous entourent et qui comportent un microprocesseur ou un microcontrolleur. Lesquels fonctionnent avec un code totalement libre ? Il y a de grande chances que la réponse soit zéro. La machine la plus "libre" que je connaisse est le XO Laptop de l'OLPC et celle ci demande quand même un microcode propriétaire pour faire fonctionner le chipset wifi...
Sérieusement, quelle est la raison pour laquelle on pousse les utilisateurs de systèmes GNU/Linux a installer des versions 100% libre ? Un noyau de base offre 2 possibilités : soit on a un périphérique nécessitant un microcode fermé et dans ce cas le périphérique fonctionnera, soit la machine n'a pas besoin de microcode (parce qu'elle inclus le code propriétaire dans une ROM, ce qui est encore plus hermétique) et alors le code fermé de Linux ne sera jamais exécuté. Dans le cas d'un kernel libre, on aura beau avoir l'âme en paix du fait de ne pas avoir quelques chaines en héxadécimal sur son disque dur, si on a la malchance de posséder un périphérique qui en a besoin, celui ci n'aura aucune chance de fonctionner.
Rendez vous a l'évidence : le moindre appareil électronique contient du code fermé, et il n'y a aucune raison de punir l'utilisateur parce que ce périphérique offre la possibilité de charger un firmware dynamiquement (en opposition a un firmware écrit de manière permanente en ROM, qui n'aura aucune chance d'être mis a jour). Le noyau Linux n'est pas libre a 100%, nous n'y pouvons rien, et nous pouvons déjà nous estimer chanceux que certains constructeurs aient permis la distribution de leurs firmwares pour assurer le bon fonctionnement de leurs périphériques.
Au final, on se rends compte qu'Ubuntu comporte quatre logiciels contenant du code propriétaire : ltmodem, broadcom, madwifi et linux. Tous concernent la gestion du matériel et il n'y aucun code non libre présent dans les programmes de l'utilisateur. Les alternatives 100% libres que sont BLAG, gNewSense et ututo n'ont aucun avantage par rapport aux autres si ce n'est la garantie de la liberté du code source. Il manque toutefois une liste mise en évidence sur les sites de ces distributions avec en titre "Voici la liste des périphérique qui ne fonctionneront pas sur notre distribution". Hormis les 3 distributions citées, toutes les autres distributions atteignent le même degré de liberté qu'Ubuntu, il est donc complètement absurde de dire "je quitte Ubuntu pour Mandriva/Debian/Gentoo/Fedora/etc... parce qu'Ubuntu n'est pas assez libre pour moi".


PS(1): Je ne souhaite pas m'étendre sur les facilités d'installation que propose Ubuntu pour certains logiciels propriétaires. Ubuntu n'est pas installé par défaut avec ceux ci et il appartient a l'utilisateur d'installer des programmes qui sont susceptibles de lui offrir une meilleure expérience au détriment de l'ouverture du code source. Toute fonctionnalité visant, d'une manière ou d'une autre a faciliter l'usage de la machine ne peut être qu'encouragée.

PS(2): Malheureusement certaines personnes font un amalgame entre logiciels propriétaire et format breveté. La plupart des codecs audio/video sont des logiciels libres, qui sont concus pour traiter des formats sous licence. Ce ce fait leur utilisation n'est pas légale dans tous les pays. Aussi on ne dit pas d'un format qu'il est libre mais qu'il est ouvert. Encore une raison pour insister sur le fait que le terme "libre" doit être appliqué uniquement aux logiciels (et aux documentations qui en découlent).

PS(3): Oui, Mono est un logiciel 100% libre

Test des performances de l'OpenGL avec VirtualBox 2.1

Depuis sa sortie, les annonces ne manquent pas pour annoncer l'évolution majeure de VirtualBox 2.1 : Le support de l'OpenGL. Qu'en est il des performances par rapport a un système natif ? C'est ce que nous allons voir !
L'installation se passe comme les mise a jour habituelles de VirtualBox, je déconseille fortement l'utilisation de la version Open Source car amputé de nombreuses fonctionnalités et bien plus compliquée a installer si vous sortez de la version maintenue par votre distribution. Une fois VirtualBox mis a jour, pensez à réinstaller les Additions Clients sur Windows, qui contiennent les drivers OpenGL. (Il vous faudra aussi activer la case 'Accélération 3D' dans les préférences de la machine virtuelle.
Les tests que j'ai lancés sont ioquake3 (la version libre de quake3) et Warcraft 3 : The Frozen Throne. J'ai voulu tenter le test de Unreal Tournament 2004 mais celui ci ne se lance pas en mode OpenGL mais seulement avec le rendu logiciel, qui est très lent. Je n'ai pas voulu abuser en testant Doom 3 ou Quake 4, on reste tout de même sur une machine virtuelle, mais si un utilisateur téméraire veux faire le test, je serai curieux de voir ce que ça donne.
Passons aux résultats des benchmarks :
Pour Warcraft 3 ,les FPS ont été mesurés avec le logiciel Fraps sous Windows et avec l'option WINEDEBUG=+fps sur Wine. Etant donné la différence des méthodes de mesure il ne faudra pas être trop regardant sur l'exactitude des résultats de Linux VS Windows mais plutot se concentrer sur les différences entre la version native et la virtualisée.
Pour activer l'OpenGL, il faudra ajouter l'option -opengl au lancement. Le jeu a été lancé en 1280x1024 avec les options graphiques au maximum.

Benchmark Warcraft III

Pour Quake 3, le jeu a été lancé en 1024x768, toujours avec les détails poussés au maximum. Dans la console de Quake il faudra taper timedemo 1 , lancer une démo et retourner sur la console pour voir les résultats. A noter qu'il y a un bug de ioquake3 sur Linux qui empeche de voir la console si on ne passe pas son clavier en qwerty...

Benchmark Quake 3

Au final, les résultats sont assez surprenants. En effet il y a tout de même une grosse différence entre la version native et VirtualBox, mais les 2 jeux testés restent utilisables compte tenu des performances. Pour cette première version supportant l'accélération c'est déja un très bon début. Évidement les jeux testés n'ont aucun intérêt a êtres virtualisés étant donné que Quake 3 existe en natif et que Wine donne des performances au moins aussi bonne que Windows sur Warcraft.
Les futures versions apporterons probablement le support de l'OpenGL sur les clients Linux et le support de DirectX sur les clients Windows, ce qui sera tout de suite plus utile.