Tweekers' Blog

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

Balise - Planet-Libre

Fil des billets

Utiliser le plugin sfEasyGMapPlugin avec symfony 1.4

Le plugin sfEasyGMapPlugin permet d'ajouter simplement les fonctionnalités de Google Maps a votre projet Symfony. La documentation donnée sur la page du plugin est loin d'être complète et à jour, et installer ce plugin sur un projet Symfony 1.4 n'est pas trivial, d'où ce billet.

Pour commencer il faut obtenir une clé pour l'API Google Maps. Il vous faudra autant de clés que de domaines et cela vaut pour les domaines locaux. Étant donné que je travaille sur plusieurs machines a des lieux différents, il m'a fallu créer 2 clés uniquement pour les machines de développement, il m'en faudra une troisième pour le site réel.
Les clés sont a placer dans le fichier app.yml de votre application:

all:
  google_maps_api:
    keys:
      domaine1: clé gmaps
      domaine2: autre clé gmaps

Il faudra aussi ajouter au fichier settings.yml une référence au plugin dans les modules utilisés :

all:
  .settings:
    enabled_modules:      [default, sfEasyGMapPlugin]

Ceci fait parti des choses qui ne sont indiquées nulle part dans la documentation, il m'a fallu chercher dans les listes de discussions pour trouver cela... Un fois la clé mise en place on récupère le plugin.

cd plugins
svn co svn co http://svn.symfony-project.com/plugins/sfEasyGMapPlugin/branches/v3 sfEasyGMapPlugin
cd ..
ln -s ../plugins/sfEasyGMapPlugin/web web/sfEasyGMapPlugin

Tout ce qui concerne les taches qui automatisent l'installation des plugins comme symfony plugin:install ou symfony plugin:publish-assets ne fonctionne pas, pas la peine de perdre du temps la dessus, le plugin a besoin d'être mis a jour. Cela ne l'empêche pas de fonctionner a merveille, il est juste plus compliqué a mettre en place que d'autres plugins. Dernière chose a mettre en place, dans le fichier config/ProjectConfiguration.class.php ajouter a la liste de vos plugins utilisés :

    $this->enablePlugins('sfEasyGMapPlugin');

On n'oubliera pas le clear cache de rigueur pour ce types d'opérations:

.symfony cc

Le plugin est maintenant utilisable, nous allons le tester sur une des actions du projet.
Dans l'action:

    public function executeIndex(sfWebRequest $request)
    {
        $this->gMap = new GMap();
        $this->gMap->addMarker(new GMapMarker(51.245475,6.821373));
        $this->gMap->addMarker(new GMapMarker(46.262248,6.115969));
        $this->gMap->centerAndZoomOnMarkers();
    }

Dans le template:

<?php use_helper('GMap') ?>
<?php include_map($gMap,array('width'=>'512px','height'=>'400px')); ?>
<?php include_map_javascript($gMap); ?>

Ceux qui suivent la documentation officielle en parallèle remarqueront certaines différences. J'ai ajouté un appel a la fonction centerAndZoomOnMarkers() dans l'action, sinon on se retrouve avec un carré gris et j'ai supprimé l'helper 'Javascript' dans use_helper() qui est déprécié dans Symfony 1.4.

Nous voyons ici les fonctionnalités de base du plugin, mais celui est en réalité beaucoup plus riche. Essayez le Sample 2 de la documentation et vous verrez qu'il est très simple de faire une recherche GoogleMaps et de convertir le nom d'une ville en coordonnées.
En plus du plugin et grace a Doctrine, stocker des coordonnées deviens un jeu d'enfant grâce au comportement Geographical. Voila pour le plugin sfEasyGMapPlugin, j'espère que ce billet deviendra rapidement inutile et que le code source et la documentation seront mises a jour pour prendre en compte Symfony 1.4 et compléter les informations manquantes.

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.

Il n'y a pas de site web libre

Il y a une erreur qui est souvent commise, c'est celle de penser qu'il existe des sites web "Libres" au même titre que vos logiciels sur votre machines sont libres. On pourrais citer comme exemple Identi.ca, le Twitter libre ou libre.fm, le last.fm libre. Ces sites web et les autres qui ont l'étiquette "libre" ne sont en réalité pas plus libre que leurs équivalents dis "fermés". Certes le code qui permet a ces sites de fonctionner est disponible sous une licence Open Source : Status.net pour Identi.ca, DotClear ou Wordpress pour mes blogs mais cela ne rends pas un site plus ouvert.
Tout comme dans un logiciel fermé, l'utilisateur n'a aucun contrôle sur le code exécuté. Rien ne garanti que le programme qui tourne sur le serveur web soit le même que celui que l'on télécharge sur le dépôt de sources. Et même si le code source est identique, l'hôte possède vos données et a plusieurs moyen pour en faire une utilisation détournée (analyse de fichiers de logs, ou de ses propres bases de données, capture de paquets réseaux).
Pourquoi s'en révolter ? Après tout chaque webmaster est libre de faire ce qui lui plait de ses serveurs, il est votre hôte et vous n'êtes qu'un invité et vous êtes responsable des données que vous lui transmettez. Contrairement a un logiciel propriétaire, un site web a un accès limité a vos données, chaque donnée importante qui sortira de chez vous par le réseau est un choix délibéré de votre part.
On peut aussi, à la manière de Richard Stallman, limiter fortement son utilisation du web et ne visiter ses propres sites web ou ceux de ses amis proches.

I have several free web browsers on my laptop, but I generally use my own machine only to talk with a few sites operated for or by the GNU Project, FSF or me.

"J'ai plusieurs navigateurs libres sur mon portable, mais j'utilise généralement ma propre machine pour discuter avec quelques sites construits pour ou par le projet GNU, la FSF ou moi même."

Nombreux sont ceux qui choisiront de ne pas être aussi extrême que Stallman. Il est cependant dommage que des services web soient favorisés par rapport a d'autres a cause d'une prétendue liberté du logiciel. Le seul site web ouvert c'est celui auquel on peut accéder par SSH ou FTP, autrement dit le votre.
Une autre façon de voir les choses c'est ne plus considérer le code source qui fait fonctionner le serveur mais uniquement les données. Nous n'avons pas accès au code source exécuté par la machine distante, l'ouverture d'un site sera donc définie par l'ouverture de ses données. La majorité des briques qui ont permis la construction d'internet sont Open Source : Linux, BSD, Apache, MySql, Php, Python, Perl, jQuery, Django, Symfony, DotClear, MediaWiki, etc, etc, etc.... Tout composant sensé être utilisé sur le web est voué a l'échec s'il n'est pas Open Source (a l'exception de Flash, qui est tenace ...). Ces composants a eux seuls ne sont pas intéréssants et peuvent être substitués a tout moment (Linux contre BSD, MySQL contre PostgreSQL, PHP contre Python, et ainsi de suite). La seule chose importante dans un site web ce sont les données. Les vôtres en priorité, mais aussi celles de tout le site.
La question qui se pose alors n'est pas de savoir si le code exécuté sur le serveur est totalement libre, quelle importance au final ? Personne ne peux contrôler ce qui est réellement exécuté sur le serveur et les outils modernes (frameworks, libraires, ...) poussent tous dans le même sens : écrire le moins de code possible pour déployer une application web efficace. L'important dans le web, ce n'est pas le code, ce sont les données comme le fait comprendre Tim Berners Lee sur Ted Talks.
Une fois que l'ont se focalise sur les données, les acteurs du web qui servent souvent de cibles pour les défenseurs du libre, comme Google, sont bien moins néfastes qu'on veux bien le faire croire. Pour rester sur l'exemple de Google, les protocoles utilisés pour les mails sont le POP, l'IMAP et le SMTP, pour la messagerie instantanée le protocole XMPP, pour Google Calendar il est possible d'exporter au format ical et ainsi de suite. D'autres débats peuvent être soulevés comme l'utilisation faite par Google de ces données mais c'est un autre sujet. En aucun cas vos données ne sont prisonnières d'un service web qui utilise des standards reconnus. Bien sur, l'utilisateur est responsable des sauvegardes de ses données sur ses propres machines.

D'une manière générale, les choses vont dans le bon sens, nombreux sont les sites a proposer une API pour leur site permettant à n'importe quel utilisateur de récupérer des données brutes. Cependant nous restons dans l'analogie du Minitel que Benjamin Bayart affectionne particulièrement. Pour se détacher de ce modèle il faut de nouveaux outils et de nouveaux protocoles (ou adapter les outils et protocoles existants pour les rendre plus simple d'accès). L'asymétrie dans les débits des offres ADSL actuelles est un frein au développement du Web 3.0. Cependant, les débits actuels, même en upload sont bien suffisant pour diffuser un contenu à une centaine de personnes. Au lieu de stocker l'information sur un seul et même endroit, elle est copiée de machine en machine, l'information est diffusée un peu à la manière des re-tweets sur Twitter. C'est le principe de Bittorrent, généralisé au Web: je diffuse tout ce que je télécharge. Un tel mode de fonctionnement permettrait un web décentralisé, non contrôlable et serait un grand pas pour sa neutralité. Bien sur cela soulève quelques questions : qu'en est il de la fiabilité des informations relayées ? Et de leur pérennité ? Pour la fiabilité il existe déjà des système permettant de signer des documents comme GnuPG et qui rends toute modification au document d'origine visible et / ou suspecte. Pour la pérennité, je fais bien plus confiance dans un schéma ou l'information est répliquée de machine en machine que dans un schéma où une information est stockée sur un seul et même serveur. Combien de fois ai je cliqué sur un lien vers une vidéo Youtube pour me rendre compte que la vidéo en question avait été supprimée (censurée) ? Le tout est de trouver un système pour qu'une URL ne corresponde plus a un fichier sur un serveur donné, mais à un document précis, quelle que soit sa localisation.
Dans les petites icônes que l'ont voit en bas de page des blogs : partager sur Delicious, Digg, Facebook et autre réseau social il manque une icône essentielle : partager sur mon propre serveur web.
Le cloud computing pourra être quelque chose de révolutionnaire et rester dans l'esprit du logiciel libre a partir du moment où les mailles de son réseau seront assez fine pour relier des individus entre eux sans les faire passer par de gros services web qui sont tous sans exceptions fermés, quelle que soit la licence des programme exécuté sur le serveur.

Du neuf dans la video avec HTML5

J'écris ce billet depuis Firefox 3.6, fraichement sorti et qui possède quelques nouveautés et améliorations intéressantes. Ce qui a retenu mon attention dans les Release Notes, c'est le support de la video plein écran. Enfin ! Le format Flash n'a désormais plus aucun avantage par rapport au HTML 5 ! Coté performances, aucune amélioration, la lecture d'un OGG sur Firefox mettra a genoux vos anciennes machines.

Ceux qui ont Firefox 3.6 pourront tester avec la vidéo ci dessous (Daniel Holbach présentant les bases du packaging pour Ubuntu).

Tout aussi récemment, YouTube a décidé de suivre son petit frère DailyMotion et de se mettre a la balise <video>. Le problème, et pas des moindres, est que Youtube ne stocke pas ses vidéos au format OGG Theora mais en mp4 ou x264, du coup Youtube en HTML5 n'est compatible qu'avec Google Chrome. L'avenir nous dira si Firefox supportera davantage de codecs et/ou Google va penser à convertir les vidéos YouTube en OGG Theora.

Dernière nouvelle sur le HTML 5, c'est le lancement de TinyOgg, un projet soutenu par la FSF et proposant de convertir n'importe quelle video YouTube en Ogg/Theora. Bon, le problème c'est que justement ça ne supporte *que* YouTube, mais d'autres plateformes de partage video seront bientôt supportées. D'autres, d'accord mais pas toutes, c'est pourquoi j'ai proposé a Osama Khalid, créateur de TinyOgg, une méthode universelle pour récupérer les vidéos de n'importe quel site.
Le principe est pour l'instant tout a fait théorique mais s'inspire de la méthode que j'utilise pour trouver un lien vers une vidéo flv. Bien sur il existe des extensions pour Firefox telles que DownloadHelper, mais avoir une URL, cela permet de télécharger sur un serveur avec wget.
Voici la méthode manuelle : Je me rends sur un site proposant une vidéo en Flash et je lance la capture des paquets de mon réseau sur Wireshark. Je lance la lecture de la vidéo et repère une trame susceptible d'être la requète ou le swf demande le flv au serveur. Une fois le flv trouvé, je colle le champ Host avec la requète GET et je donne ça a wget qui télécharge la vidéo.
Ce hack est bien sympa, mais le but est d'automatiser toute cette procedure pour qu'un utilisateur puisse coller une URL, n'importe quelle URL (tant que le player n'utilise pas le protocole fermé RTMP), et récupérer son .ogg à la fin.
Dans la théorie, cela donne :

  • Xvfb installé sur le serveur pour permettre le lancement d'applications graphiques sans avoir besoin d'écran.
  • Firefox et le plugin Adobe Flash installés sur ce serveur
  • Un script python envoyant des XEvents via python-xlib pour faire des faux clics de souris, au cas ou un appui sur Play est nécessaire
  • Un sniffer (wireshark ou tcpdump) configuré pour capturer toutes les urls se terminant par .flv
  • mencoder ou ffmpeg2theora pour la conversion
J'aimerais mettre en place un prototype mais il me manque les connaissances en TCP/IP pour capturer les requètes contenant un .flv. Le reste n'est pas trop problématique.
Avis au experts du réseau, si vous souhaitez faire une grosse contribution aux formats ouverts, postez dans les commentaires la commande magique a base de tcpdump, wireshark ou tout autre sniffer pour récupérer les url des vidéos .flv.

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 :)

Rappel : Qu'est ce qu'un fork ?

J'aurais aimé faire un billet un peu plus élaboré comme par exemple parler de l'appel système fork() ou étudier l'évolution des fourchettes a travers les âges ... mais il est quelques fois nécessaire de revenir sur des concepts de base que l'on pensait acquis pour beaucoup.
Je me suis rendu compte que de nombreuses personnes ont une conception très inexacte de ce qu'est un fork, ou du moins en ce qui concerne les distributions GNU/Linux. Quand je dis de nombreuses personnes, je ne parle pas de Linuxiens novices qui ont bouffé du Windows pendant 15 ans et rentrent dans le monde merveilleux d'Unix et de l'Open Source. Non, je parle de bloggeurs reconnus, de vétérans, qui ont plusieurs années d'expérience dans le logiciel libre, et je peux balancer des noms. Cyrille Borne, Frédéric Bezies, Christophe Gallaire, vous faites parti des gens qui ont une conception fausse du terme fork, voila c'est dit.
Reprenons tout depuis le début.
Un fork est l'acte de reprendre le code source d'un projet pour fonder un autre projet totalement indépendant. Ce nouveau projet va rarement contribuer du code au projet d'origine. Un fork viens dans la plupart des cas d'un désaccord au sein d'une équipe de développement quand plusieurs groupes n'arrivent pas a trouver un terrain d'entente sur l'évolution du futur d'un logiciel. Un fork part d'une intention précise : celle de rentrer en compétition, voire de remplacer le projet de base.
On prendra comme définition de référence celle donnée par Eric Raymond dans le Jargon File.
Ce n'est pas un concept très compliqué mais il s'arrête à cette définition. L'étendre au delà engendre une utilisation abusive du terme fork comme nous allons le voir. Beaucoup d'utilisateurs de Linux, comme par exemple les bloggeurs cités plus haut, on tendance a appeler les dérivées d'une distribution un fork. Dire qu'une distribution est le fork d'une autre est très rarement vrai. Prenons l'exemple le plus simple : les dérivées d'Ubuntu. Ceux ci sont souvent qualifiés, dans la majorité des cas a tort, de forks. Que ce soit parmi les dérivées officielles (Kubuntu, edubuntu, mythbuntu,...) ou des non-officielles (CrunchBang, OpenGEU, ...) aucune de ces distributions ne sont des forks.
Regardons de plus prêt :
- Les distributions en question utilisent elles la même plateforme de développement qu'Ubuntu (Launchpad) ? Oui
- Les distributions en question utilisent elles les mêmes dépôts qu'Ubuntu ? Oui
- Les distributions en question fournissent elles des logiciels supplémentaires ou modifiés par rapport a Ubuntu ? Très rarement
- Les distributions en question ont elles pour but de rentrer en compétition et/ou de remplacer Ubuntu ? Non
- Les distributions en question ont elles un autre but que d'apporter a l'utilisateur une autre offre logicielle installée par défaut ? Non
Dans la majorité des cas, aucune modification du code source n'est faite, elles ont uniquement lieu sur les artworks et les fichiers de configuration.
On va même aller jusqu'à parler de temps et d'efforts perdus pour la conception de ces distributions (car étant des 'forks' on leur donne aussi le titre de 'distribution', ce qui est tout de même un peu moins faux). C'est mal connaitre la réalité des choses. Un repackaging d'une image ISO d'Ubuntu n'est couteux ni en temps, ni en efforts sauf si l'on considère qu'un après midi est un temps énorme gâché pour la communauté du logiciel libre...
On pourra reprocher de nombreuses choses a ceux qui souhaitent concocter leur propre version d'Ubuntu, de gâcher de la bande passante en distribuant des ISO et non des scripts de post-installation, ou de ne pas tirer parti de l'outil tasksel par exemple mais certainement pas de diviser la communauté, ou de rajouter une dose de chaos dans les distributions existantes.
Pour aller plus loin, on peut même aller jusqu'à affirmer qu'Ubuntu n'est pas un fork de Debian. Certes les dépôts et le bugtracker sont différents et le but d'Ubuntu est clairement de rester en position dominante par rapport aux autres distributions mais Ubuntu et Debian restent deux projets qui communiquent énormément entre eux, et le code de Debian est sans cesse repris, a intervalles réguliers, tous les 6 mois. La FAQ Debian mentionne Ubuntu et Knoppix mais n'emploie nulle part l'appellation 'fork' (elle indique que ce sont des distributions *basées sur* Debian).
Si tous ces projets ne sont pas des forks alors que sont ils ? J'aurais tendance a dire, très simplement : des Logiciels Libres. En tant qu'utilisateur de logiciel libre, je considère comme un droit fondamental de pouvoir étudier, modifier et distribuer tout logiciel que j'utilise.
Ne pas avoir saisi cela, crier au fork la où il n'y en a pas, c'est en quelque sorte montrer que l'on a pas totalement saisi l'essence du logiciel libre.

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

Tweekers : le réseau social Open Source - 1: Cahier des charges

Ce billet est la continuation directe du précédent ( Comment aider la communauté du Libre ? ) où j'exposais l'idée un site communautaire pour faciliter le développement des logiciels Open Source.
J'ai eu plusieurs commentaires encourageants qui ont confirmé que l'idée valait la peine qu'on s'y penche dessus. Aujourdh'ui marque donc la première étape de développement qui est la publication de la première version du cahier des charges.

Télécharger le cahier des charges (format ODF, 10 pages)

Ce projet est aussi l'occasion de tester un autre modèle de développement, que je n'ai pas vraiment eu l'occasion de rencontrer parmi les logiciels Open Source : Tout est rendu public avant même que la moindre ligne de code soit écrite. On saute l'étape Cathédrale et on passe directement au Bazaar. Je ne met pas tout mes espoirs dans cette méthode de développement, mais je pense qu'elle peut être une solution envisageable pour concevoir des projets de taille conséquentes.
Cette méthode de développement aura au moins l'avantage de rendre les documents d'élaboration du projet public (cahier des charges, maquettes, schéma de BDD...), contraremenent à ce que j'avais critiqué par le passé en disant que la disponibilité du code source seul n'était pas suffisant pour encourager les contributeurs a participer.
Rien qu'en exposant l'idée de base dans le précédent billet, j'ai eu des commentaires qui ont mis le doigt sur des points importants sur lesquels je ne m'était pas attardé et j'espère que la publication du cahier des charges permettra a tout le monde d'exprimer ses idées sur le développement du projet.

Et maintenant ?


Une feuille de route préliminaire figure a la fin du document, la prochaine étape est la publication de maquettes d'écrans prévue pour prévue ce vendredi. Je prendrais en considération toutes les participations. Et pas besoin d'être un expert d'Inkscape pour apporter sa contribution, une maquette griffonée sur un vieux bout de papier peut aussi bien faire l'affaire. (Et si vous n'avez pas de scanner, un appareil photo est bien suffisant). Ce n'est pas un concours de design, le but est uniquement de structurer les pages de l'application.

Vos avis m'intéressent


Vous pouvez me faire part de vos remarques sur les commentaires de ce blog, ou en utilisant mon adresse mail / jabber : strycore@gmail.com . J'ai reçu plusieurs propositions pour aider au développement dans les commentaires du billet précédent, sachez juste que vous n'avez pas besoin de compétences de développement a ce stade de l'application et donc que la contribution est ouverte a tout le monde.

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é =)

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.