Tweekers' Blog

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.

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'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.

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.

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.

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

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

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.

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.
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 )
Pour finir il suffira d'assigner ces commande aux touches multimédia
Et voila, c'est terminé =)

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

“ 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.