[DE | EN | FR | IT | JA | ES | KO | PT]

Bienvenue pour une nouvelle édition du Brave GNU World, pour un mélange de projets qui devrait susciter quelqu'inspiration chez bien des lecteurs.

Ce mois-ci nous débuterons encore une fois par une présentation de jeux libres, parmi lesquels plus d'un aurait pensé en premier lieu.

Trophy

Andrew Mustun a entamé le développement de Trophy [5] en mars 2000 afin de combler le vide consécutif à la fin de ses études d'informatique. Trophy est un jeu de voitures en 2 dimensions vu de haut, pour lequel être le premier à franchir la ligne d'arrivée ne suffit pas.

Pour être plus précis, c'est au bout du compte le fait même de franchir la ligne d'arrivée qui importe, car, à la James Bond, les voitures sont armées et désireuses de faire usage de leurs gadgets.

Aidé de bons effets sonores et aspect visuel, Trophy est déjà un jeu assez complet qui devrait donner du plaisir aux amateurs de jeux riches en action, même si un ordinateur puissant est recommandé pour un défilement fluide.

Trophy a été écrit en C++ et Andrew l'a publié sous GNU GPL. Son plus grand défaut est l'absence de jeu en réseau. Andrew prévoit de s'en occuper une fois qu'il trouvera du temps pour cela, car ses études récemment reprises l'occupent beaucoup.

À noter : lors de la préparation de ce numéro, Andrew a précisé qu'il était un fervent partisan de la paix qui désapprouve l'usage d'armes à feu en général et qu'il considère que les voitures sont déjà assez dangereuses sans ces derniers instruments ; il est toujours dépourvu de permis de conduire à 25 ans, il ne saurait pas vraiment conduire une voiture.

Tout cela ne devrait pas vous ôter le loisir de perdre une après-midi avec Trophy. Il n'y aurait aucun problème à ce que vous conceviez des circuits supplémentaires, si vous êtes plutôt attiré par la relaxation créative entre 2 courses. Le mode d'emploi pour le faire est accessible sur la page de Trophy.

Si le défaut d'option pour le jeu en réseau devenait intenable, les développeurs intéressés restent les bienvenus pour les mettre en oeuvre eux-mêmes. Andrew apprécierait énormément toute aide en ce sens.

Adonthell

Le projet Adonthell [6] se penche sur la création d'un jeu de rôle en 2 dimensions, tel que ceux qu'on pouvait voir sur les premières consoles comme la SNES, sauf qu'il a pour but de garder un plus haut degré de liberté.

Bien des jeux sont scindés en 2 parties liées l'une à l'autre, qui sont très perceptibles individuellement. L'importance du contenu, comme l'histoire, les graphismes, la musique, etc. est donc évidente. Le composant technique, chargé de l'interface avec l'utilisateur par exemple, est communément désigné sous le terme de "moteur".

Des exemples de la vie de tous les jours seraient la relation entre les programmes et un système d'exploitation, ou bien celle entre des notes et un instrument de musique. Cette séparation permet d'écrire des jeux sous une forme abstraite, dotés d'un langage et de possibilités déterminés par le moteur.

Le projet Adonthell ne développe pas seulement un jeu avec une histoire figée, mais plutôt un moteur pour des jeux de rôles qui vont avec les histoires interprétées par ce moteur. Il est prévu que toutes les éditions contiennent non seulement du code, mais également de petits jeux en intégralité.

Mise à part une certaine fluctuation, l'équipe permanente d'Adonthell compte à son actif Kai Sterker, Alexandre Courbot, James Nash, Benjamin Walther-Franks, Joel Vennin, Joseph Toscano et Mike Nieforth. Seuls trois d'entre eux sont programmeurs, les autres étant musiciens, artistes graphiques ou auteurs. Grâce à ce panachage et au fait que chacun des membres insiste sur la tenue d'une rencontre physique par an, le jeu donne un sentiment de professionalisation et donne un bon exemple pour une coopération active au travers d'Internet.

Le code et les graphismes d'Adonthell sont publiés sous licence GNU GPL, le langage de programmation retenu pour le moteur est le C++. Pour le contrôle du jeu, les extensions et les événements du jeu, l'interpréteur Python a été intégré au moteur. Ceci rend possible d'écrire des jeux pour le moteur d'Adonthell sans toucher à une ligne de C++. Pour les musiques, c'est OGG Vorbis [7] qui est utilisé.

Une des priorités était de pouvoir empaqueter indépendamment le moteur et les jeux. Vous pouvez n'installer que le moteur et grâce à quelques outils, comme des éditeurs de cartes ou de boîtes de dialogues ainsi qu'un peu de Python, il est possible de créer un jeu complet.

Pour rendre le tout encore plus passionnant, l'équipe d'Adonthell travaille également sur un univers complet, avec ses propres histoires, us, coutumes et particularités.

D'après Alexandre Courbot, qui a répondu au questionnaire du Brave GNU World, la prochaines étape serait de récrire de grands pans du code en se basant sur l'expérience accumulée.

L'équipe est toujours à la recherche de gens désireux de porter le jeu sur d'autres plates-formes. Ce dernier tourne aujourd'hui sous GNU/Linux, FreeBSD, OpenBSD et BeOS, mais à long terme, il devrait aussi supporter d'autres systèmes propriétaires afin de donner à leurs utilisateurs un avant-goût de liberté.

Le développement interne est en train de se transformer en une architecture plutôt client-serveur, afin de permettre le jeu en réseau. Même s'il n'est pas à l'ordre du jour de supporter un grand nombre de joueurs, Adonthell devrait être capable de permettre à un nombre moyen de joueurs d'interagir dans un monde persistant.

Depuis ses début en 1999, Adonthell a déjà fait du chemin et poursuit un développement qui laisse présager encore mieux. Ceux qui ont les compétences requises et seraient trop impatients pour attendre sont encouragés à prêter main forte à l'équipe qui accueillera toute aide au long de ce processus. [8]

Les autres peuvent déjà passer une ou deux après-midi sur "Waste's Edge", la première version jouable.

XBindKeys

Philippe Brochard est l'auteur du programme XBindKeys [9], qui permet d'assigner des commandes shell à des touches en environnement X11. Des commandes on ne peut plus fréquentes telles que le logiciel de mél, le butineur ou la fenêtre xterm peuvent être lancées sans le détour par un menu, juste par l'entremise d'une simple combinaison de touches. Une fois que vous serez habitué(e) à ne pas lever la main du clavier, vous ne pourrez plus vous passez de cette fonctionnalité.

Certains gestionnaires de fenêtre acceptent des raccourcis clavier en natif, mais souvent toutes les touches ne sont pas librement assignables - comme les touches spéciales présentes uniquement sur certains types de claviers. Philippe lui-même utilise XBindKeys pour lancer un menu d'extinction de sa machine en appuyant sur la touche d'extinction que comporte son clavier.

Ceux qui essayent un nouveau gestionnaire de fenêtres, ou utilisent différents gestionnaires de fenêtres de temps en temps, ont déjà été confronté aux problèmes liés à l'apprentissage de leurs combinaisons de touche préférées dans ce nouveau gestionnaire de fenêtres.

XBindKeys résout ces deux problèmes et en combinaison avec le mini-programme MoveMouse [10], également écrit par Philippe, il peut même amener la souris à certains endroits prévus grâce à un simple raccourci clavier.

XBindKeys et MoveMouse sont tous deux écrits en C et diffusés sous GNU GPL, car Philippe les considère comme sa contribution au système GNU.

La configuration de XBindKeys se fait par édition directe du fichier de configuration en texte ASCII brut, simple à comprendre, ou en utilisant le frontal en GTK, XBindKeys-Config [11], écrit par Laurent Vuibert.

En marge, il faut signaler qu'il faut s'assurer que XBindKeys est lancé avant le gestionnaire de fenêtres ; ceci afin de garantir que les touches pressées ne soient pas interceptées par ce dernier, et atteignent bien XBindKeys.

Il n'y a pas spécialement de projet de développements futurs, dans la mesure où XBindKeys est stable et que Philippe estime qu'il devait rester petit et utilisable. Ceci illustre bien un exemple de lutte contre la tendance à la "gadgetisation".

Access Road

Le domaine de la sécurité informatique est un sujet des plus complexes, mais reste incontournable. L'éventualité de dysfonctionnements dans les programmes est plutôt connue maintenant, mais il est également possible de créer des problèmes de sécurité en combinant des logiciels qui fonctionnent "sans erreur".

Des environnements et des tâches complexes requièrent des systèmes d'information eux-mêmes plutôt complexes et obscurs.

Sans limitation des accès, les données peuvent être altérées frauduleusement en secret. Ce type de problèmes devient tangible lorsqu'on imagine des hôpitaux informatisés, par exemple. L'opposé, à savoir une limitation complète de tous les accès, n'est pas une meilleure idée puisqu'elle rend toute tâche impossible.

Il devient donc impératif de concevoir un système exploitable rationnellement, tout en rendant les abus impossibles.

Comme la conception de tels systèmes revient à des humains, il reste une marge d'erreur possible. Access Road [12], de Patrick Thazard, tente de modéliser l'environnement complexe des systèmes d'information et de les rendre visualisables par un administrateur. Cela n'augmente pas le niveau de sécurité en soi, mais cela offre une facilité supplémentaire pour trouver des problèmes de sécurité qui auraient pu passer inaperçus autrement.

Patrick Thazard travaille lui-même comme consultant en sécurité informatique depuis 1987 et a écrit Access Road en Java sous GNU General Public License, la documentation étant sous GNU Free Documentation License.

Pour l'instant, Access Road supporte les systèmes de type GNU/Linux, des routeurs simples et des systèmes de type Solaris ; et même si aucune mise à jour des données n'a été faite depuis la dernière publication, Patrick est convaincu que cela sera déjà une bonne base pour d'autres développeurs.

Les plans de développement futurs prévoient d'adjoindre l'interaction entre GNU/Linux et Apache, ainsi que celle entre le système d'exploitation et le système de gestion de base de données employé. À long terme, l'extension de la modélisation en tenant compte de systèmes tels que CORBA ou Windows 2000/XP devrait compléter le système.

D'ici là, il y a bien du travail et Patrick recherche d'autres développeurs désireux de l'aider. Même si l'approche de la modélisation graphique comporte en général quelques faiblesses, ce projet parait très intéressant et permet d'explorer de nouvelles perspectives.

GNU Cons

GNU Cons [13] constitue une alternative à un des aînés des programmes : GNU Make [14]. Quiconque a déjà téléchargé un logiciel sous forme de code source pour l'installer, voire simplement recompilé le noyau Linux, a déjà utilisé GNU Make simplement en entrant la commande "make".

Make a été écrit à une époque où il était tout à fait normal de compiler des programmes à la main ou avec des scripts écrits en scripts Bash, et à l'époque GNU Make représentait un bond en avant. Mais si vous avez déjà tenté d'écrire un fichier Makefile vous-même, vous aurez très certainement trouvé la syntaxe assez difficile à comprendre. C'est une des raison pour lesquelles la plupart des développeurs copient des Makefiles qui marchent à partir d'autres projets pour les modifier pour leurs propres besoins ou font générer les Makefiles automatiquement par des programmes comme GNU Automake.

En plus de cela, Make tente de détecter les modifications des fichiers selon la date de dernier accès uniquement, ce qui est problématique et échoue systématiquement lorsqu'on tente de recompiler avec de nouvelles options de compilation.

Le nom de GNU Cons a été choisi car avec son aide, les programmes peuvent être "Cons-struits" et son but est de faire le travail de GNU Make de la manière dont cela devrait être fait.

Un des composants centraux en ce sens est un bon mécanisme pour détecter si les fichiers ont été modifiés ; GNU Cons ne se contente pas de vérifier les dates de dernier accès, il travaille sur les signatures MD5 des fichiers, permettant une très bonne identification.

Un bon exemple de ces possibilités est le comportement de GNU Cons dans le scénario suivant : le programme "test" est constitué des fichiers objets "test1.o", "test2.o" et "test3.o".

Après une première compilation du programme, le fichier objet "test2.o" est endommagé/corrompu délibérément. Le prochain appel à GNU Cons reconstruira "test2.o", mais ne provoquera pas de re-lier le programme "test" à nouveau, puisque GNU Cons aura réalisé que la version générée de "test2.o" est identique à celle liée dans "test" auparavant.

Que GNU Cons soit appelé avec des options de compilation différentes, toutes les parties sont recompilées et liées, puisque non seulement les résultats mais également les paramètres utilisés pour les créer ont été pris en compte dans la comparaison.

GNU Cons a été écrit en Perl par Bob Sidebotham, qui a maintenant cessé de travailler dessus. Rajesh Vaidheeswarran et Steven Knight ont repris les versions stable (Rajesh) et de développement (Steven) en tant que mainteneurs. Intégré au projet GNU, GNU Cons est publié sous licence GNU GPL.

Grâce à son code écrit en Perl, GNU Cons tourne sous Windows et les différentes moutures d'Unix, et ses fichiers de configuration, équivalents aux courants "Makefiles", permettent d'utiliser des expressions très complexes pour paramétrer au plus juste un programme pour un certain système.

GNU Cons est tout à fait utilisable, bien qu'il soit plutôt porté sur C et C++. On peut néanmoins accéder à d'autres langages de programmation grâce au module Cons::Plus de Johan Holmberg. De même, les fichiers de configuration sont naturellement riches en Perl, ce qui n'est pas un avantage pour bien des gens.

Pour terminer cette présentation, j'aimerais exprimer mes remerciements à l'équipe de GNU Cons, qui m'a fait un plaisir immense en donnant des réponses abondantes aux questions standards du Brave GNU World.

Rajesh Vaidheeswarran et Erich Waelde m'ont fourni de grandes quantités d'informations, étayées par bien des exemples, ce qui fut très intéressant pour moi, même si je n'ai été capable que d'en transmettre peu dans cette édition. Je ne peux que souhaiter que les avantages les plus marquants auront fait leur chemin, assez en tout cas pour donner l'idée aux développeurs intéressés de tester Cons.

SCons

Les similitudes évidentes entre les nom de GNU Cons et SCons [15] ne sont pas fortuites. La conception de SCons est très largement basée sur celle de GNU Cons et a été écrit en août 2000 par Steven Knight, mainteneur de la version de développement de GNU Cons, à l'occasion de la compétition "Software Carpentry".

Après avoir été mainteneur de Cons pendant quelque temps, il a poursuivi le but de combiner les idées de Cons avec la puissance de Python pour la compétition.

SCons est base sur ces travaux. Comme Cons, il fournit des possibilités supérieures pour détecter les modifications et résoudre les dépendances, mais ses fichiers de configuration sont basés sur Python. De plus, SCons permet déjà la compilation parallèle avec la possibilité de spécifier le nombre de processus légers ("threads") comme option en ligne de commande.

SCons reste encore un projet très jeune, la première version alpha datant du 13 décembre 2001. Ceci explique pourquoi les versions se succèdent encore à de très courts intervalles, souvent riches d'ajouts fonctionnels. Donc même si le projet a bénéficié depuis le premier jour d'une infrastructure de tests de régression solide, on peut encore souffrir de sa jeunesse dans un usage quotidien.

La liste des extensions prévues est encore très longue et comporte non seulement un bon support de Java, C# et Fortran, mais également des fonctionnalités de génération de documents en plusieurs formats (PDF, PostScript, TeX et d'autres...), ainsi que l'archivage.

SCons est publié sous une licence de type X11, connue pour ne pas protéger les libertés. Il est possible que la GPL aurait pu être un meilleur choix, mais SCons reste malgré tout un logiciel libre et y jeter un coup d'oeil est vraiment une bonne idée.

Fini

Bon, en voilà terminé pour le Brave GNU World de ce mois ; pour le prochain numéro j'ai déjà un projet dans les cartons que je suis impatient de présenter, puisqu'il me facilite la vie et que j'en souhaite tout autant à votre égard.

D'ici là, je vous souhaite tout de bon et ne vous gênez pas pour les suggestions, idées, commentaires ainsi que présentations de projets ; de préférence par courrier électronique [1].