Linux France

S'abonner à flux Linux France
Mis à jour : il y a 9 min 20 sec

Hackathon 76 : les lauréats et le clip

Lundi 28 Avril

Créativité, audace et innovation ont été au rendez-vous du premier Hackathon 76. Organisé par le département de Seine-Maritime les 11 et 12 avril dans le cadre du lancement du portail Open Data 76, en partenariat avec l'association Hack Hours et Normandie Web Xperts, le Hackathon 76 a connu une des plus fortes affluences en France pour ce genre de manifestation.

Organisés par équipes, 100 développeurs ont réalisé sur une période de 24 heures, sans interruption, des applications en s’appuyant sur les données présentes dans le portail Open Data 76, couplées à d’autres données nationales ou locales en libre accès. 25 projets ont été présentés et le jury du Hackathon 76 a distingué des équipes (dont la liste est fournie en seconde partie de dépêches).

NdM : Ni le code, ni même les binaires des applications ne semblent être disponibles pour le moment.

1er prix : « Checktaroute »

Cette application inédite pour smartphone permet d’analyser la qualité des routes départementales grâce à l'accéléromètre du smartphone. Ce dernier enregistre chacune des secousses subies par le véhicule. Cela permet de créer une cartographie des routes en fonction de la qualité de leur revêtement. Cette application a été développée par :

  • Alexandre Brehmer, étudiant à l’INSA de Rouen en 3è année ASI (Architecture de Systèmes d'Information) ;
  • Angelo Carlier, en recherche d'emploi secteur informatique ;
  • Nathan Malo, étudiant à l’INSA de Rouen en 3è année ASI et
  • Simon Wallon, étudiant à l’INSA de Rouen en 3è année ASI.
2è prix : « Hitchhik'R »

Cette application veut révolutionner la pratique de l’auto-stop en facilitant la mise en relation entre auto-stoppeurs et conducteurs, de façon géolocalisée, tout en identifiant des zones sécurisées de point de rencontre (arrêts de bus, zones de covoiturage,…).

3è prix : « Culturovore »

Grâce à cette application tous les collégiens peuvent géolocaliser facilement l’ensemble des lieux, sites, activités… où ils peuvent utiliser leur Pass’Culture et le gérer directement depuis un smartphone ou une tablette.

Coup de coeur du jury : « Bâticité »

Avec cette application, le citoyen est au coeur des chantiers de sa ville. Il sera désormais possible de donner son appréciation sur les travaux en cours ou suggérés, de géolocaliser des projets d'urbanisme et des travaux engagés par les collectivités et de connaître les informations détaillées sur ces projets (coût, avancement…).

Télécharger ce contenu au format Epub

Lire les commentaires

Je crée mon jeu vidéo E10 : génération procédurale de carte (partie 2)

Lundi 28 Avril

«Je crée mon jeu vidéo» est une série d'articles sur la création d'un jeu vidéo, depuis la feuille blanche jusqu'au résultat final. On y parlera de tout : de la technique, du contenu, de la joie de voir bouger des sprites, de la lassitude du développement solitaire, etc. Vous pourrez suivre cette série grâce au tag gamedev.

Dans l'épisode 10, on a fabriqué des cartes d'altitude avec diverses méthodes et divers opérateurs qui permettent de rendre la carte plus réaliste. Dans cette deuxième partie de ce double épisode consacré à la génération de carte pour un RPG, on va décorer notre carte.

Sommaire En retard

Avant toute chose, cet épisode a pris beaucoup plus de temps que prévu. La fatigue de la vie quotidienne est un élément qu'il ne faut jamais sous-estimer, surtout quand elle s'accumule. Elle réduit considérablement la capacité à avancer, malgré une motivation intacte. C'est ce qui m'est arrivé ces dernières semaines, ce qui a provoqué un énorme retard. Pourtant, les tâches étaient simples et claires, il y avait un peu de travail algorithmique, comme nous allons le voir, mais rien de vraiment insurmontable. Juste qu'une fois devant le clavier, je n'arrivais plus à taper les choses efficacement, tout mettait des heures alors que ça aurait dû mettre quelques minutes.

Les vacances actuelles seront sans doute profitables pour me remettre sur les rails. En tout cas, elles m'ont déjà permis de finir cet épisode, même s'il est assez loin de ce que j'avais imaginé au départ. Parce qu'il reste du travail sur ce sujet.

Rappel de l'objectif

L'idée de ce double épisode est d'être capable de générer des cartes pour un RPG. Plus précisément, on utilisera notre carte comme un fond, étant donné que le jeu utilise la vue de dessus. Ça veut donc dire que cette carte sera très présente sur l'écran et qu'il faut la préparer au mieux. Pourquoi la générer ? Il ne s'agit pas ici de générer toute la carte dans ses moindres détails, mais simplement de produire un canevas assez précis qui puisse être manipulé par la suite. Toute la question est dans cette précision.

Le premier épisode permettait de générer une carte d'altitude, ce qui est une première étape essentielle. Cette carte d'altitude avait de bonnes caractéristiques, par exemple en terme de déplacement possible des unités, ce qu'on avait matérialisé par le score de jouabilité. On avait donc à notre disposition une carte d'unité dont on va se resservir ici.

Pour cet épisode, on va voir trois aspects essentiels : la génération des rivières, la génération des biomes, la génération des formes de collision. Puis on discutera de ce qu'on peut apporter de plus.

Les étapes de construction Génération des rivières

La génération des rivières est sans doute la partie la plus facile. Il s'agit d'ajouter à notre carte des rivières pour la rendre un peu plus réaliste. Et puis le franchissement de rivière peut devenir une activité importante quand on joue à un RPG.

L'algorithme utilisé ici est extrêmement simple, tout en donnant des résultats pas trop mauvais. L'idée est de partir d'un point en altitude (on peut fixer l'altitude minimale) puis de suivre la pente la plus forte jusqu'à arriver à la mer. Ça a l'air simple comme ça mais ça ne l'est pas. Parce qu'il se peut que l'eau se retrouve piégée dans un minimum local, et il faut donc savoir comment sortir de ce minimum local sans effondrer les performances de la génération.

La solution la plus efficace est d'utiliser une file de priorité. Pour chaque case ajoutée à la rivière, on ajoute toutes les cases adjacentes à la file avec comme priorité l'altitude la plus faible. Ainsi, on a toujours en tête de file la case qui permet de descendre le plus. Ainsi, quand on se retrouve dans un minimum local, cet algorithme va permettre de faire monter l'eau petit à petit jusqu'à trouver un endroit par où descendre un peu plus. On crée ainsi des lacs naturels.

Ensuite, on itère un certain nombre de fois pour avoir plusieurs rivières. Si on repart à chaque fois de la carte initiale, certaines rivières vont parcourir les mêmes cases, créant ainsi des affluents.

Voilà ce que ça peut donner avec vingt rivières. On voit en particulier le lac qui s'est créé au nord-est et comment la rivière longe la colline. Et on observe aussi qu'avec six rivières, on arrive à former un fleuve avec ses affluents à l'ouest.

Génération des biomes

Un biome est, d'après Wikipédia, «un ensemble d'écosystèmes caractéristique d'une aire biogéographique et nommé à partir de la végétation et des espèces animales qui y prédominent et y sont adaptées». Un biome est caractérisé par un climat, lui-même étant associé à des températures et des précipitations. Pour savoir quel biome correspond à quelle fourchette de températures et de précipitations, on utilise généralement le diagramme Whittaker.

Sur notre carte, nous n'avons ni températures, ni précipitations. Mais nous avons des altitudes et des rivières ! On va considérer que plus on monte en altitude, plus il fait froid. En vrai, la température baisse entre 0.6 et 1.0°C tous les 100m, donc l'approximation n'est pas si insensée. Il reste donc à calculer l'humidité, et là, on va considérer que plus on est loin d'un point d'eau (rivière ou mer), moins on est humide. Pour cela, on fait un parcours en largeur de toutes les cases, en commençant aux points d'eau et on décrémente l'humidité petit à petit.

On obtient une carte d'humidité : plus c'est clair, plus c'est humide. Et inversement, les zones sombres indiquent des zones très sèches.

Ensuite, en fonction de l'altitude et de l'humidité, on doit déterminer un biome. On s'inspire pour cela du diagramme de Whittaker qu'on adapte. J'ai utilisé la même adaptation que celle du tutoriel d'Amit Patel. On peut le visualiser de la manière suivante.

En abscisse, on a l'humidité (plus on va à droite, plus c'est humide), et en ordonnée, on a l'altitude (plus on va en haut et… plus on monte logique). Chaque couleur représente un biome différent. Depuis les forêts tropicales jusqu'au sommets enneigés, en passant par les steppes, tout y est à peu près.

Reste ensuite à appliquer les biomes en fonction de la carte d'altitude et de la carte d'humidité qu'on vient de calculer. Et tadam !

Ou, si on veut une version avec du relief :

On se rend compte que la zone quasi-désertique au sud-est correspond à une dépression où il n'y a pas de rivière. On voit également les montagnes qui se dégagent avec les zones neigeuses.

Générations des formes de collisions

Un des objectifs de cette génération de carte est de pouvoir générer automatiquement les formes de collisions. Parce que les faire à la main peut être assez long et fastidieux. Dans l'épisode précédent, on avait vu comment on générait une carte d'unité, c'est-à-dire un ensemble de cases accessibles à une unité dont on précise à la fois la taille (en nombre de cases) et la capacité à franchir les pentes.

La carte d'unité est donc une carte binaire. Il reste à déterminer les polygônes qui forment les contours infranchissables, c'est-à-dire la limite des zones blanches et noires. Je dois avouer que c'est un des algorithmes qui m'a demandé le plus de réflexion et dont je suis assez fier. Voici comment j'ai procédé.

Pour chacune des cases accessibles (les cases blanches), j'ai ajouté quatre arcs orientés qui représentent le contour de cette case à un premier ensemble E1. Toutes les cases sont orientés dans le même sens, ici le sens des aiguilles d'une montre. Ensuite, il faut enlever des arcs pour ne garder que ceux des contours des zones blanches. L'idée est ici d'enlever les arcs (A,B) tels que l'arc (B,A) fait également partie de l'ensemble E1. En effet, si on trouve ces deux arcs, c'est qu'ils ont été ajoutés par deux cases adjacentes et donc, ils font partie de l'intérieur de la zone. Nous obtenons alors un ensemble E2 qui contient tous les contours mais en petits morceaux. Dernière étape, il faut donc reconstituer les contours ! Pour ça, tant que E2 n'est pas vide, on prend un arc, puis on cherche le ou les arcs qui ont comme origine l'extrêmité de cet arc.

Je dis «le ou les» parce qu'il se peut qu'il y en ait deux, dans le cas où deux cases sont reliées uniquement par un sommet, comme on peut le voir sur la figure ci-dessus. Il faut alors faire un choix non-aléatoire : un choix aléatoire pourrait nous faire tourner en rond assez longtemps. Pour maximiser la taille du contour, on choisit de toujours tourner à gauche. Comme on parcoure le contour dans le sens des aiguilles d'une montre, on inclue dans chaque zone les cases qui sont reliées uniquement par un sommet et donc on minimise le nombre de contours. On itère tout ça et on obtient nos contours.

Cet algorithme est assez efficace si on prend garde à utiliser les bonnes structures de données et les bons algorithmes. S'il y a n1 cases accessibles, c'est-à-dire 4*n1 arcs dans l'ensemble E1, la construction de E2 peut se faire en O(n1 log n1), grâce à un tri préalable des arcs, puis à une recherche dichotomique pour essayer de trouver l'arc inverse pour chaque arc. Ensuite, s'il y a n2 éléments dans E2, on peut reconstruire les contours en O(n2 log n2) de la même manière, c'est-à-dire en triant les arcs et en faisant une recherche dichotomique pour trouver le ou les prochains arcs. Au final, on n'est jamais quadratique, ce qui est une performance tout à fait honorable à mon sens.

Cette fois, on a tout ce qu'il nous faut en terme de données.

La carte prête à l'emploi

Il faut désormais générer la carte prête à l'emploi, c'est-à-dire au format TMX de Tiled, et plus précisément avec les conventions retenues pour le jeu lui-même.

Le problème fondamental

Tiled est un très bon logiciel et il permet de faire plein de choses. Il a notamment une brosse qui permet de créer des «terrains» de manière très facile, une fois qu'on a indiqué sur le tileset quel morceau de tuile était associé à quel terrain. La brosse est capable de générer des gros morceaux de carte de manière à ce que les cases adjacentes de la carte aient des terrains identiques. Tout ceci est bien expliqué dans un tutoriel pour créer les terrains et utiliser la brosse.

Pour pouvoir bénéficier de cette fonctionnalité le jour où on passera à l'édition manuelle de la carte, il nous faut deux choses. Premièrement, déterminer les terrains. Ça, c'est la partie facile, parce qu'on peut identifier les biomes aux terrains et donc, on a autant de terrains que de biomes. Deuxièmement, il faut avoir un tileset adapté à cette brosse. Et ça, c'est la partie difficile. Parce qu'on voit bien dans le tutoriel que ce qui marche bien, c'est quand la limite entre deux terrains est sur la tuile, puisque c'est ça qui va permettre à l'outil de pouvoir générer des zones complètes.

Or, notre carte, pour l'instant, ce sont uniquement des cases monochromes. Au départ, j'avais pensé à modifier la carte pour étendre certaines zones d'une demi-case. Ça permettait notamment d'élargir les rivières facilement. Le problème, c'est qu'on arrive très vite à des cas particuliers impossible à démêler. On doit prendre en compte au moins les huit cases adjacentes (directement ou par un coin) et donc, si on prend en compte qu'on peut avoir autant de biomes que de cases, ça fait un nombre de cas beaucoup trop importants. La solution est toute bête, il suffit de décaler notre grille d'une demi-case suivant les deux axes ! Et pour faire simple, on sacrifie une rangée sur le bord. Ainsi, toutes les limites de biomes sont maintenant au milieu des cases.

Notre nouvelle carte est alors composée de tuiles, elles-mêmes découpés en quatre parties qui ont les couleurs de quatre cases de la carte originale. Évidemment, on va trouver toute sorte de tuiles et il va bien falloir déterminer le tileset.

Détermination du tileset

Comme notre carte est générée, il faut également générer le tileset qui sera utilisée pour la carte. Pour ça, il faut déterminer l'ensemble de tuiles qui a été utilisé. Au départ, on place déjà dans le tileset les tuiles pleines qui seront les référents pour chacun des terrains et qui les identifie dans Tiled.

Ensuite, on parcoure toute notre carte et pour chaque tuile nouvelle, on l'ajoute à notre ensemble de tuile. Puis, une fois qu'on a fini, il ne reste plus qu'à générer l'image avec toutes les tuiles, comme les attends le format TMX. Ici, en l'occurrence, les tuiles font 32x32 à l'affichage mais à cause d'un pseudo-bug, les tuiles font en fait 34x34. Le bug provoquait des petits défauts d'affichage, on voyait notamment la couleur de la tuile voisine à la limite des tuiles, ce qui était assez désagréable. Je crois avoir lu que ce bug vient d'une erreur d'arrondi dans les nombres flottants, voilà pourquoi je parle de pseudo-bug. La solution que j'avais trouvée à l'époque, c'était d'agrandir mes tuiles d'un pixels, ce qui permet de masquer ces petits défauts.

Touche finale, plutôt que d'avoir des limites de biomes uniquement horizontales et verticales, on peut modifier un peu les tuiles de manière à avoir des biseaux. Et ce n'est pas si simple. Il y a notamment le cas merdique où la tuile a deux couleurs mais disposées en diagonales. Dans ce cas, il faut donner la priorité à une des deux couleurs pour les joindre. C'est essentiel quand une de ces deux couleurs représente une rivière, on veut que la rivière soit continue. Je passe les détails qui tiennent parfois de la magie sur comment déterminer si on dessine un biseau ou pas, et je passe aussi sur la taille de ce biseau pour que les diagonales joignent parfaitement sans qu'on ne puisse voir les limites des tuiles.

Au final, on obtient ça :

Évidemment, une fois ce tileset généré, rien n'empêche un artiste de l'améliorer comme bon lui semble. Mais cette version de base peut tout à fait convenir, dans un premier temps, pour le développement du jeu.

La carte finale dans Tiled

Ce moment où on ouvre la carte générée dans Tiled la toute première fois est un moment assez intense. On se demande si on a tout fait correctement, si ça va marcher, si ça ne va pas être trop gros pour Tiled. Et puis tadam, ça s'affiche et c'est merveilleux. Voici quelques captures d'écran pour montrer le résultat dans Tiled.

Sur cette première capture, on voit les contours qu'on a calculés précédemment. On retrouve les formes qu'on avait dans la carte d'unité (ce qui est plutôt une bonne nouvelle). On peut également voir le tileset en bas à droite, avec les limites des tuiles qui a été ajouté par Tiled, ce qui permet de mieux les distinguer.

Sur cette seconde capture, on voit exactement le même endroit mais avec les biomes, c'est-à-dire ici l'ensemble des tuiles. En bas à droite, j'ai mis la vue où on peut voir tous les terrains.

Sur cette troisième capture, j'ai zoomé sur une des rivières au nord pour observer les limites biscornues entre les biomes qu'on obtient avec les biseaux. Ce n'est pas si mal que ça, non ?.

La carte finale dans le jeu

Évidemment, la carte marche également dans le jeu. Pour vous convaincre, voici une petite capture d'écran avec Kalista à la plage. L'endroit correspond à la troisième capture dans Tiled, au nord de l'île.

Pour les contours, vous devez me faire confiance, ça marche aussi. Presque trop bien d'ailleurs, et nous allons en parler maintenant.

La suite ! Les zones inaccessibles

Dans le jeu, les zones inaccessibles sont bien inaccessibles, aucun problème pour ça. Malheureusement, ces zones ne sont pas distinguées visuellement des autres zones. Ce qui fait qu'on a l'impression de heurter des murs invisibles en permanence. C'est très désagréable. Je suis à la recherche d'un artefact visuel permettant de distinguer ces zones.

J'ai fait quelques essais qui sont pour l'instant non-convaincant. Le premier essai consistait à mettre par dessus chaque tuile inaccessible une autre tuile, partiellement transparente qui assombrissait la tuile du dessous. Outre le fait que ça ne rendait pas très bien visuellement, on n'avait pas l'impression d'une zone infranchissable mais plutôt d'un biome différent. Bref, solution abandonnée. Au second essai, j'ai essayer de placer des objets qui montrerait que la zone est infranchissable, en l'occurrence des cailloux. J'ai donc fabriqué une tuile avec trois cailloux. L'impression visuelle était nettement meilleure, et on distinguait bien la zone infranchissable. Mais avec une tuile unique, on avait des zones très géométriques avec un même motif répété beaucoup trop de fois.

J'ai encore trois idées. La première, c'est de générer plusieurs tuiles de cailloux de manière à éviter cet aspect géométrique. Seulement, à force de voir des cailloux partout, ça risque d'être un peu rébarbatif à la longue. La seconde idée, c'est d'utiliser non pas des tuiles, mais des sprites complets, un peu comme mes arbres de l'épisode 06. On pourrait par exemple avoir des rochers. La difficulté ici consiste à recouvrir exactement la zone infranchissable avec ces sprites mais pas plus, ni moins. Une troisième idée est de se servir des informations de pentes (puisque ces zones correspondent à des endroits trop pentus pour notre unité) et de trouver des tuiles qui puissent rendre compte de la pente. Avec un rebord, par exemple.

Peut-être que la solution viendra d'un mélange de plusieurs idées.

Les décorations

Une autre manière de rendre la carte moins monotone est d'ajouter des décorations. Et là, je pense immédiatement à mes arbres. Pourquoi ne pas tout simplement créer des forêts complètes ? Générer des forêts aléatoirement n'est pas si difficile. Avec les biomes, je sais où elles sont situées, j'ai déjà des sprites d'arbres, yapluka. Ça permettrait d'avoir une première version de la carte pas trop pauvre.

Dans la même idée, on pourrait aussi ajouter des rochers, et pas seulement sur les zones infranchissables. Dans les zones montagneuses par exemple, ça ferait assez couleur locale. Reste à pouvoir générer des rochers aléatoirement. J'ai un peu avancé sur ce point, ça rend assez bien, dans le même style que les arbres en fait, donc ça pourrait marcher.

En termes d'éléments naturels, ça me paraît déjà une bonne base. Mais je suis sûr que les idées vont venir au fur et à mesure. N'hésitez pas à donner vos idées !

D'autres pistes à explorer

Parmi les autres pistes à explorer, il y également la génération de routes. Et là, il faut vraiment que je vous fasse découvrir quelque chose. J'ai eu l'occasion de discuter sur le canal IRC #akagoria avec un doctorant d'une équipe de recherche française qui étudie, entre autre, la génération procédurale de paysage, l'équipe GeoMod du LIRIS à Lyon. Ils ont notamment une plateforme de développement de mondes virtuels, malheureusement propriétaire. Mais on peut voir des vidéos de démonstration assez époustouflantes. Vraiment, je vous les conseille toutes, ça ne dure pas très longtemps et c'est bluffant.

Parmi tous les travaux de cette équipe, il y a notamment des travaux sur la génération de routes, ainsi que sur la génération de réseaux routiers hiérarchiques. On peut retrouver une partie de ces travaux dans la thèse d'Adrien Peytavie sur la génération procédurale de monde (en français). Ça donne une bonne base pour générer des routes, même si les algorithmes sont décrits très succinctement.

Surtout, les discussions que j'ai eues avec ce doctorant m'ont ouvert des pistes de réflexion intéressantes. Il regrettait (et je ne peux pas l'en blâmer) que la plupart du temps, la génération procédurale de paysage suit le même schéma : celui que j'ai présenté au cours de ces deux épisodes. Je partage son analyse. J'ai choisi cette voie par facilité, parce que je savais qu'elle donnerait des résultats suffisamment convaincants. Mais je pense comme lui qu'on peut faire mieux que le bruit de Perlin et le diagramme de Whittaker. Notons bien que ce couple est utilisé dans de nombreux jeux, dont le célèbre Minecraft.

Il défendait l'idée que c'était une erreur de faire de la génération de paysage à grain fin directement, comme je l'ai fait. Les algorithmes utilisés ne conviennent pas pour traiter à la fois les paysages globaux (des montagnes, des plaines) et les détails (un arbre, un cailloux). Il proposait plutôt de procéder en plusieurs étapes, tout d'abord déterminer un paysage global avec du bruit de Perlin ou autre, ce qui permet de déterminer des zones globales. Puis, dans chaque zone, d'utiliser à nouveau du bruit pour générer les détails. Pour donner un exemple concret, si on considère que chaque case de ma carte initiale représente non pas une tuile au final mais un grand carré de tuiles, on aurait alors la possibilité, pour chaque carré de tuiles d'ajuster les limites de biomes avec du bruit de manière à avoir des formes un peu moins rectilignes (même avec les biseaux). J'ai trouvé cette idée très intéressante même si le temps me manque pour l'expérimenter dans l'immédiat. Et dans son esprit, on pouvait même avoir plusieurs niveaux dans ce genre.

Le deuxième point qui mériterait sans doute un peu de travail, c'est d'oublier le diagramme de Whittaker. En effet, ce diagramme est très pratique mais il donne des paysages hautement irréalistes ! Qui a déjà vu un désert, une taïga, une forêt tropicale et des steppes sur une île aussi petite ? Bon, on est dans un jeu donc on peut faire un peu comme on veut, mais quand même. On pourrait aussi rester dans un climat tempéré, et donc limiter le nombre de biomes, et ça ne serait pas moins intéressant. On pourrait partir sur l'étagement et avoir toute une série de climat et de végétation très intéressante. Je crois que je vais approfondir ce point quand j'aurai un peu de temps parce qu'il me semble qu'il peut donner des résultats plus «réaliste» que le diagramme de Whittaker, si on peut parler de «réalisme» dans un jeu de cette nature.

Conclusion

Voilà donc où nous en sommes rendu : nous avons une carte de base qui demande encore quelques ajustements avant de pouvoir entrer dans la phase d'édition manuelle. Je n'ai pas encore tout pushé sur les dépôts git mais ça sera sans doute fait entre le moment où j'écris ces lignes et le moment où elles seront publiées. En particulier, j'ai mis tout ce que j'ai décrit ici dans un binaire à part dans le projet mapmaker de manière à séparer ce qui relève des algorithmes génériques (ceux de la partie 1) et des algorithmes spécifiques au jeu (ceux de la partie 2).

Pour la suite immédiate, je vais laisser cet aspect en plan et je vais m'intéresser aux inputs. Parce que ma réflexion sur les dialogues (prochain point dans ma roadmap), ainsi que la bibliothèque jnuit de devnewton, m'ont amené à y réfléchir et de manière plus générale à réfléchir aux intéractions entre mon personnage et mon univers. Sur les dialogues, les questions arrivent très vite : qui initie le dialogue ? est-ce qu'il faut appuyer sur un bouton ? comment détecter qu'on est bien à côté de quelqu'un qui veut dialoguer ? comment gérer les dialogues intéractifs ? L'exemple, donné dans un commentaire sur un épisode précédent, des dialogues du jeu Andor's Trail donne une piste.

Bref, encore de nombreux épisodes en perspective !

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de Tryton 3.2

Lundi 28 Avril

Tryton la plate-forme de développement d'applications pour entreprise (progiciel de gestion intégré ou PGI mais aussi ERP) continue son petit bonhomme de chemin et sort une version 3.2.

Pour cette version les développeurs se sont focalisés sur l'amélioration des nombreuses fonctionnalités apportées lors de ces 2 dernières années et sur l'augmentation de la couverture métier des modules (par ajout ou rationalisation). Cette version prépare aussi le passage à Python 3 en arrêtant le support pour Python 2.6. Comme toute nouvelle version, elle vient avec son lot de correctifs de bogues, d'améliorations de modules et de nouveaux modules.

Comme c'est l'habitude chez Tryton tout a été fait pour que la migration depuis les versions précédentes se passe sans encombre.

Détail des nouveautés Fuseau horaire

La gestion des fuseau horaire a été revue et simplifiée. Du côté serveur, le temps est en UTC mais un fuseau horaire est défini pour la société afin de déterminer la date. Par contre le client utilise le fuseau horaire de la machine et fait la conversion automatique.

Intreface utilisateur

Quelques améliorations sont à noter :

  • Le copier/coller crée un nouvel enregistrement quand il arrive à la fin de la liste.
  • Il est possible de créer un attachement à un enregistrement en glissant-déposant un fichier sur le bouton des attachements.
  • Les boutons définis sur la vue sont également disponibles dans le menu d'action pour un accès rapide via le clavier. Bien sûr, ce menu respecte l'état des boutons et donc les boutons inactifs pour l'enregistrement courant ne seront pas présents dans le menu.
  • Un nouveau widget multi-sélection fait son apparition pour les champs Many2Many. Il est pratique quand les possibilités de sélection sont petites.
Sécurité

Le serveur utilisera l'algorithme bcrypt au lieu de SHA-1 pour hacher les mots de passe si la bibliothèque est disponible.

Historisation

L'historisation des enregistrements est disponible depuis la version 1.2 mais il n'y avait pas encore de prise en charge côté client pour accéder à celle-ci si le développeur ne l'avait pas prévu dans son module. C'est maintenant chose faite, il est possible de consulter les enregistrements à une révision choisie, voire de consulter l'ensemble des enregistrements à une date entrée.

Interface de programmation

Là aussi, plusieurs améliorations :

  • L'amélioration faite pour la méthode create lors de la version 2.8 a été appliquée sur la méthode write. Il est maintenant possible d'écrire en un seul appel des valeurs différentes sur des enregistrements différents. Ceci permet un gain de performance lors de la validation. D'ailleurs, cette validation a aussi été rendue plus intelligente car elle ne valide plus que les champs qui sont susceptibles d'être invalides suite à l'écriture.
  • Un nouveau décorateur est aussi introduit fields.depends qui permet de spécifier les dépendances d'une fonction à certain champs. Ceci remplace les attributs on_change, on_change_with etc. des champs.
  • Sur tous les types de champs, il est maintenant possible de définir une contrainte sous forme d'un domaine. Celui-ci sera, pour les cas simples, vérifié par le client et il le sera dans tous les cas par le serveur.
Nouveaux modules

Les nouveaux modules de Tryton :

  • Relation tiers : permet de définir tous types de relation entre les tiers.
  • Paiement et Paiement SEPA : permet de gérer les paiements et de générer les fichiers SEPA correspondant.
  • Emballage : permet de définir les emballages utilisés pour les expéditions.
  • Limite de crédit : ajoute une limite de crédit par client
La suite Client web

Il a été décidé que les nouvelles fonctionnalités développées pour le client GTK doivent l'être aussi pour le client web afin d'être acceptées. Ceci limite le gap entre les fonctionnalités des deux clients, mais il reste encore quelques fonctionallités manquantes pour pouvoir publier une version de celui-ci.

TU? 2014

Les appels à candidature pour l'organisation de la prochaine réunion annuelle de la communauté est ouvert jusqu'au 30 avril. Jusqu'à présent, il y a 2 propositions : Barcelone et Leipzig.

Python 3

Toutes les dépendances de Tryton supportent maintenant Python 3. Le travail a commencé pour avoir une version fonctionelle en utilisant 2to3

GTK 3

La migration vers la version 3 du toolkit GTk est en cours. Le problème principal rencontré fut la disparition des GenericTreeModel et quelques bugs y afférent. À l'inverse de la migration vers Python 3, celle-ci prendra la forme d'un big-bang.

Télécharger ce contenu au format Epub

Lire les commentaires

Le webmail Roundcube atteint la version 1.0.0

Dimanche 27 Avril

Roundcube est un webmail, c'est-à-dire une interface web d'une client (User Agent) de mail. Il est développé en PHP, publié sous licence GPLv3. Il permet en vrac l'IMAP, l'édition riche, la recherche, et plein d'autre chose qu'un mailer mature sait faire.

Nouveautés

Cette nouvelle version apporte les nouveautés suivantes :

  • La configuration a été nettoyée et ne nécessite plus qu'un seul fichier. En réalité, il y en a deux, un avec la configuration par défaut, et un autre pour que l'administrateur puisse surcharger les options.
  • Des fonctionnalités avancées pour l'utilisation du carnet d'adresses avec LDAP.
  • Un bouton pour basculer facilement des messages textes aux message HTML.
  • Une sauvegarde des message dans l'espace de local storage du navigateur pour les retrouver facilement, même en cas de perte du réseau.
  • Une amélioration de la navigation au clavier dans les listes de messages.
  • Une interface graphique qui s'adapte aux tablettes.
  • Un greffon qui vous rappelle d'attacher une pièce jointe.
  • Les messages de réponses peuvent être enregistrés pour servir de modèles faciles d'accès.
  • Import des emails et des groupes de contacts.
Greffons

Avec cette version, vient aussi un nouveau dépôt centralisé pour les greffons, permettant une installation simplifiée basée sur Composer and Packagist.

Le site est encore en beta, mais le nombre de greffons est déjà bien élevé, comme :

  • advanced search
  • global address book
  • image paster
  • message highlight
  • HTML5 notifier
  • sieve rules
  • keyboard shortcuts
  • etc.
Copies d'écran

La vue en trois panneaux, avec drag n drop :

Composition de messages en HTML avec pièces jointes :

Carnet d'adresse avec intégration LDAP :

Calendrier :

Télécharger ce contenu au format Epub

Lire les commentaires

Appel à traduction et amélioration d'un article sur Wikipédia : liste des migrations vers GNU/Linux

Vendredi 25 Avril

Wikipédia en anglais dispose d'une page recensant les migrations vers le libre et GNU/Linux dans les administrations, collectivités et grands groupes sur le plan mondial. Le groupe de travail éducation de l'April a initié sa traduction en français. Il est aussi question de l'améliorer en rajoutant des exemples de migrations dans le contexte français, étayés par des sources fiables.

Une fois traduite et améliorée, cette page pourra venir enrichir Wikipédia en français, et surtout servir de base documentaire pour nos actions en faveur du libre. N’hésitez pas y contribuer sur le pad de traduction.

Un grand merci à William qui a initié ce travail et en assure le suivi !

Télécharger ce contenu au format Epub

Lire les commentaires

Core Infrastructure Initiative

Vendredi 25 Avril

Après la réponse musclée d'OpenBSD face à la faille Heartbleed d'OpenSSL, la fondation Linux a aussi une tentative de solution. C'est un groupe de plus d'une dizaine d'entreprises qui vont fournir plusieurs millions de dollars pour financer des projets capitaux et libres dans le besoin.

Les financements pourront aller à des développeurs clefs pour qu'ils puissent travailler à plein temps sur leur projet, à des audit de sécurité, à de l'infrastructure de test ou de développement, à des voyages ou même à des réunions physiques. Ce projet sera administré par la fondation Linux et les fonds seront attribués par un groupe composé des différents bailleurs de fond, de développeurs de logiciels libres ou d'autre membres des entreprises impliquées dans le libre.

Pour l'instant, les premières sociétés impliquées sont (par ordre alphabétique) : Amazon, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Qualcomm, Rackspace et VMWare. La fondation espère que d'autres rejoindront le mouvement.

Télécharger ce contenu au format Epub

Lire les commentaires

Seafile, un Dropbox-like libre à héberger sort en version 3

Vendredi 25 Avril

Suite à la dépêche présentant les alternatives à Dropbox, , qui évoquait Seafile, il semble intéressant de présenter de façon plus approfondie ce logiciel.

Seafile est une solution de synchronisation et de partage de fichiers bâtie sur trois composants :

  • un serveur, Seafile (sous licence GPLv3) ;
  • une interface web, SeaHub (sous licence Apache), permettant de consulter les fichiers gérés par Seafile directement via le web ;
  • un client de synchronisation.

Le projet utilise un modèle inspiré de Git pour la gestion de fichiers, avec certaines adaptations, permettant par exemple de gérer de façon plus performante les gros fichiers.

Éditions

Deux éditions de Seafile sont disponibles :

  • une édition communautaire, sous licence libre, qui est l'objet de cette dépêche ;
  • une édition entreprise, payante, qui rajoute principalement la recherche plein texte, la visualisation des documents Microsoft Office et la prise en charge de la clusterisation.
Fonctionnalités

Seafile dispose de nombreuses fonctionnalités de , qu'on peut répartir en trois catégories : serveur, interface web et client.

Serveur

Quelques propriétés du serveur :

  • installable sur Windows et Linux ;
  • multi-utilisateurs ;
  • chaque utilisateur peut avoir plusieurs bibliothèques de fichiers ;
  • système de groupes, un groupe peut avoir ses propres bibliothèques ;
  • serveur WebDAV ;
  • support du chiffrement des bibliothèques côté client (via mot de passe) ;
  • support de HTTPS ;
  • les fichiers peuvent être versionnés ;
  • possibilité de fixer un quota d'espace disque pour les utilisateurs.
Interface web

  • installable sur Windows et Linux ;
  • multilingue ;
  • support de HTTPS ;
  • partage de fichiers/dossiers en lecture via lien public (avec envoi automatisé par mail) ;
  • système de lien public permettant à un utilisateur non authentifié de mettre en ligne des fichiers directement dans une bibliothèque Seafile (très pratique pour récupérer des fichiers lourds qui ne passent pas par mail, des packs de photos, etc.) ;
  • accès à l'historique des modifications des fichiers, dossiers et bibliothèques, et possibilité de les restaurer à un état antérieur en un clic ;
  • éditeur de texte minimaliste pour les fichiers textes/Markdown ;
  • module permettant d'héberger un wiki en Markdown, synchronisable et éditable en local comme une bibliothèque standard ;
  • téléchargement par fichier mais aussi par dossier (sous forme d'archives) ;
  • corbeille permettant de restaurer des éléments supprimés ;
  • messagerie en ligne (en groupe ou avec un utilisateur particulier) ;
  • prévisualisation/consultation de certains fichiers directement dans le navigateur : musique, texte, PDF, images…
Client
  • compatible Windows, Mac, Linux, Android et iOS ;
  • possibilité de synchroniser seulement certaines bibliothèques ;
  • possibilité de synchroniser des bibliothèques depuis différents serveurs Seafile ;
  • possibilité de fixer une limite pour les vitesses d'envoi et de réception ;
  • possibilité d'ignorer certains fichiers ou patterns, d'une façon similaire au .gitignore de Git.
Nouveautés de la version 3

La version 3.0 a apporté un certain nombre de changements, principalement dans l'interface qui a été redessinnée pour l'occasion. La gestion des fichiers a été partiellement revue, notamment pour améliorer la rapidité du serveur et de l'interface web.

Pré-requis

Contrairement à certains autres logiciels similaires, comme OwnCloud, Seafile requiert un serveur dédié pour fonctionner, ainsi que Python, l'interface web étant basée sur Django. Côté base de données, Seafile peut fonctionner avec SQLite, MySQL et PostgreSQL. SQLite est cependant déconseillée pour des instances de taille importante. Pour le serveur HTTP, Nginx est recommandé, mais on peut tout à fait déployer Seafile avec Apache, comme je l'ai fait.

Conclusion

Dans une optique d'auto-hébergement ou de recherche d'alternatives par rapport à des services centralisés/propriétaires (Google Drive, Dropbox…), Seafile est ainsi une solution tout à fait valable et performante. Que ce soit, d'ailleurs pour une utilisation personnelle ou au sein d'une organisation. Seafile offre également des réponses intéressantes aux problématiques de confidentialité, grâce à l'utilisation possible de HTTPS et du chiffrement des bibliothèques côté client.

Étant un utilisateur satisfait de Seafile depuis plusieurs mois, je vous invite à garder un œil sur ce projet vraiment bluffant.

Télécharger ce contenu au format Epub

Lire les commentaires

Deux mois après, le fork d'Ampache fusionne avec l'original

Vendredi 25 Avril

Ampache est un serveur de diffusion de musique. Alors que le projet semblait à l'abandon (pas de releases, pas de commits, plus de site web), un fork nommé Ampache Doped a secoué cette communauté, recevant des échos plutôt positifs. Après quelques releases, voilà que Ampache Doped et le projet original Ampache fusionnent à nouveau :

This project was merged with Ampache project.

Happy end ? Apparemment, puisque le développement a repris sur le dépôt Git de Ampache.

Apanage du libre, parfois décrié, banalisé notamment par Github, le fork semble parfois nécessaire pour revitaliser des projets au potentiel inexploité.

NdM : merci à Nicolas Raoul pour son journal.

Télécharger ce contenu au format Epub

Lire les commentaires

PGDay France 2014 - 5 et 6 juin à Toulon

Jeudi 24 Avril

Les 5 et 6 juin prochains le PGDay France fêtera les dix ans de la communauté francophone de PostgreSQL ! À cette occasion, la communauté francophone aura le grand plaisir d'accueillir Bruce Momjan, l'un des co-fondateurs et leader du SGBDR open source.

Le PGDay France 2014 est un évènement de deux jours, composé d'ateliers, de conférences et d'échanges sur le thème de PostgreSQL.

Que vous soyez DBA, architecte, développeur, administrateur système, chef de projet utilisant PostgreSQL, vous découvrirez des retours d'expérience d'autres utilisateurs, ainsi que des présentations techniques de PostgreSQL, de PostGIS (cartouche spatiale) ou d'autres extensions.

Rendez-vous à Toulon les 5 et 6 juin !

Voyez le détail des ateliers et des conférences dans la suite de l'article.

Cet évènement est organisé par la communauté francophone des utilisateurs de PostGreSQL, avec le soutien de plusieurs entreprises partenaires. Inscrivez-vous dès à présent, et retrouvez les informations complémentaires sur le site PGDay France. Cela sera ainsi l'occasion de rencontrer Bruce Momjan mais aussi les principaux acteurs PostgreSQL en France.

Le 5 juin, participez aux deux ateliers proposés :
  • atelier Performance Tuning par Bruce Momjan (EnterpriseDB) (en Anglais) ;
  • atelier Supervision avec Julien Rouhaud (DALIBO).
Le 6 juin, le programme des conférences vous fera découvrir les sujets suivants :
  • PostgreSQL Past, Present and Future par Bruce Momjan (EnterpriseDB) ;
  • 2TB of RAM ought to be enough for anybody, par Jean-Louis Bergamo (Le Bon Coin) ;
  • les nouveautés de PostgreSQL 9.4, par Damien Clochard (DALIBO) ;
  • gestion du cache en lecture / écriture par Cédric Villemain (2ndQuadrant) ;
  • adoption de PostgreSQL dans les grandes entreprises par Jean-Paul Argudo (DALIBO) ;
  • aller plus loin avec VACUUM par Julien Rouhaud (DALIBO) ;
  • carte Sanitaire, carte Universitaire, carte des Cantines Scolaires de Côte d’Ivoire par Solange NIAMKE ;
  • intégrer des données dans PostgreSQL par Dimitri Fontaine (2ndQuadrant) ;
  • la réplication avec PostgreSQL 9.4 par Thomas Reiss (DALIBO) ;
  • principales avancées et nouveautés de PostGIS par Olivier Courtin (Oslandia) ;
  • expérience du 3ème type par Grégoire Hubert (PragmaFabrik).

Le nombre de places étant limité, nous vous invitons à vous inscrire rapidement !

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de la version 4.9 du compilateur GCC

Jeudi 24 Avril

La nouvelle version majeure du compilateur GCC du projet GNU vient de sortir. Écrit à l'origine par Richard Stallman, le logiciel GCC (GNU Compiler Collection) est le compilateur de référence du monde du logiciel libre. Il accepte des codes source écrits en C, C++, Objective-C, Fortran, Java, Go et Ada et fonctionne sur une multitude d'architectures.

Dans la suite de la dépêche, vous pourrez découvrir les nouveautés et les optimisations mises en œuvre dans cette version 4.9 de GCC

Sommaire Optimisations générales Ubsan

UndefinedBehaviorSanitizer est un projet initialement développé pour LLVM et qui fait son apparition dans GCC. Il rejoint ainsi ThreadSanitizer et AddressSanitizer qui sont entrés dans GCC 4.8.
Contrairement à valgrind qui lance le programme dans une machine virtuelle, il s'agit comme pour tous les *Sanitizer d'instrumenter le code binaire généré. UndefinedBehaviorSanitizer détecte les erreurs qui donnent lieu à un comportement indéfini à l'exécution.
Il s'agit par exemple des divisions par zéro, des erreurs de cast de type non aligné, de valeurs en dehors des bornes représentables par le type (énumérations ou flottants).

Cette option s'active avec -fsanitize=undefined et elle est disponible pour les langages C et C++.

Protection de la pile

Les problèmes de débordement de pile sont un problème récurrent dans les programmes, en particulier avec le langage C qui alloue dans le même espace mémoire les variables locales à une fonction, la sauvegarde des registres et la Pile d'exécution contenant toutes les adresses de retour.

Une personne mal intentionnée (ou un chercheur en sécurité) peut parfois fournir plus de données que le programme n'est prévu pour en traiter et cela entraîne un écrasement des autres données. En visant soigneusement, on s'arrange alors pour écraser l'adresse de retour avec une valeur soigneusement calculée pour exécuter des commandes non prévues. Le processeur, à la fin de la fonction, pensant revenir à la fonction appelante, va exécuter du code écrit par l’attaquant, qui n'a rien à voir avec le programme d'origine.

L'idée de base pour se protéger de ce genre de chose est de déposer une valeur secrète juste avant l'adresse de retour, cette valeur est appelée "Canari" à l'image des oiseaux utilisés par les mineurs pour détecter les nappes de gaz. Lorsque la fonction se termine, cette valeur est contrôlée. S'il y a eu débordement, la valeur du "Canari" est écrasée, elle ne correspond plus et le programme est arrêté avant d'utiliser l'adresse de retour corrompue.

GCC dispose déjà de deux fonctions permettant de mettre un tel mécanisme en place.

L'option -fstack-protector-all comme son suffixe l'indique, provoque l'ajout d'un canari pour tous les appels de fonction. Cet ajout est coûteux car il y a plus d'instructions à exécuter, le code est plus long et va diminuer l'efficacité des différents caches.

L'option -fstack-protector provoque l'ajout d'un canari sur toutes les fonctions qui contiennent une variable locale de type chaîne de caractères prévue pour 8 octets ou plus (8 étant paramétrable avec l'option --param=ssp-buffer-size=N). Cette option est nettement moins coûteuse, mais laisse pas mal de trous.

Les ingénieurs de Google ont donc développé une troisième alternative appelée -fstack-protector-strong pour améliorer la couverture des canaris sans avoir à l'ajouter à toutes les fonctions d'un programme. Elle est déjà utilisée avec succès dans Chrome OS depuis au moins 10 mois. Par rapport à -fstack-protector, cette option protège également plusieurs autres situations à risque :

  • toutes les fonctions qui utilisent des variables locales contenant des tableaux (En C, tous les tableaux sont susceptibles de déborder par rapport à la taille allouée, les chaînes de caractères n'en sont qu'un cas particulier), y compris si le tableau est dans une structure ou une union ;
  • toutes les fonctions qui utilisent un pointeur vers une autre variable (l'adresse d'une autre variable) ;
  • et toutes les fonctions qui stockent des variables dans les registres.

La version 3.14 du kernel Linux a été également modifiée pour permettre de le compiler avec les différentes options (il n'y a pas d'option pour -fstack-protector-all) :

  • CONFIG_CC_STACKPROTECTOR_NONE n'utilise pas de canaris;
  • CONFIG_CC_STACKPROTECTOR_REGULAR (anciennement CONFIG_CC_STACKPROTECTOR) pour -fstack-protector
  • CONFIG_CC_STACKPROTECTOR_STRONG pour -fstack-protector-strong

Ingo Molnar a mesuré quelques valeurs par rapport à l'usage de ces options (ces valeurs ne sont pas absolues et dépendent bien évidement de la configuration générale du kernel) :

  • -fstack-protector augmente la taille du kernel de 0.33% et protège 2.81% des fonctions ;
  • -fstack-protector-strong augmente la taille du kernel de 2.4% mais protège 20.5% des fonctions.

Bien que cette méthode ne soit pas parfaite, elle bloque un nombre significatif de problèmes de sécurité dans les applications. Comme toutes ces méthodes, elle a le double désavantage de faire payer à tous les utilisateurs les éventuelles bugs de sécurité des applications et de ne pas inciter à la correction de ces problèmes. On peut s'attendre à ce que dans le futur, un certain nombre de distributions soient compilées avec cette option.

Pour aller plus loin :

Améliorations LTO

La technique LTO (pour Link Time Optimization) qui a été introduite dans GCC 4.5 reçoit encore une fois son lot d'améliorations incrémentales.
Cette fonction LTO permet des passes d’optimisations supplémentaires lors de l’édition des liens au prix d'un temps de compilation et d'une empreinte mémoire largement augmentés.

La version 4.9 de GCC vise à réduire ces coûts afin de permettre une utilisation plus aisée par les distributions. On note en particulier une réécriture de l'algorithme de « type merging », un travail sur les méthodes virtuelles afin de les éliminer le plus tôt possible, un chargement du corps des fonctions à la demande et un déchargement le plus tôt possible.
Tout ces patchs (et les nombreux autres non cités) constituent une importante amélioration globale de LTO et suppriment des goulets d'étranglements qui existaient dans les versions précédentes de GCC.

Selon les notes de version, l'occupation mémoire d'une compilation LTO de Firefox (avec les symboles de debug) passe ainsi de 15 Go à seulement 3,5 Go. Le temps passé à faire l'édition des liens dégringole quant à lui de 1 700 secondes à 350 secondes.

Point important à noter, plusieurs patchs ont été proposées à Linus afin d'intégrer la possibilité de compiler le noyau en mode LTO. Ces patchs sont écrits par Andi Kleen et Michal Marek et ont été proposées pour le futur noyau 3.15.
Linus a jugé que ces patchs étaient encore trop expérimentaux et a demandé des tests prouvant qu'une compilation LTO du noyau apportait vraiment des bénéfices :

So I think I'll let this wait a bit longer, unless people start talking about the upsides.
How much smaller is the end result? How much faster is it? How much more beautiful is it? Does it make new cool things possible? Are those cool things really close on the horizon and really want this merged even though it's not really quite ready yet?
So please: convince me.

Après divers échanges sur la LKML il s'avère que, pour l'instant, la fonction LTO de GCC n’apporte que peu de bénéfices en terme de performances sur un projet déjà extrêmement optimisé comme l'est le noyau. En revanche on observe une réduction de la taille finale du noyau ce qui intéresse les gens travaillant dans l'embarqué.
Andi Kleen ajoute également que les benchmarks utilisés sont peu sensibles aux performances du compilateur et qu'on sous-estime généralement le gain apporté par LTO.

Langages ISO C11

Le support de la norme C11 s’améliore encore dans cette version 4.9 de GCC. On note en particulier l'arrivée des types _Atomic, _Generic ainsi que de _Thread_local.
Cette norme C11 est maintenant considérée comme aussi bien supportée que l'ancienne C99

C++1y

On retrouve dans cette nouvelle mouture de GCC plusieurs nouveautés concernant le support de la future version de C++ (connue sous le nom de C++14).
Le récapitulatif est disponible sur cette page mais on peut citer les polymorphic lambdas (N3649) ou encore la déduction automatique du type de retour d'une fonction (N3638).

Plus anecdotique on peut maintenant séparer de longs nombres par une simple quote afin d'améliorer la lisibilité.
On aura ainsi :
int j = 1'048'576'752'870;

au lieu de :
int j = 1048576752870;

OpenMP

GCC 4.9 apporte le support de la version 4.0 de l'interface de programmation OpenMP.
OpenMP 4.0 est sorti en fin d'année 2013 avec beaucoup de nouveautés notamment en terme de support des accélérateurs ou des directives SIMD. La branche GOMP 4.0 de GCC qui suivait l'évolution de la norme et a permis son inclusion rapide dans la branche principale de GCC.

Une nouvelle option -fopenmp-simd permet d'activer le support des directives SIMD d'OpenMP dans avoir à suivre les autres directives. Il est également possible de régler plus finement le modèle utilisé pour évaluer le coût de vectorisation des boucles de code. Il suffit de passer l'option -fsimd-cost-model= avec l'une de ces trois valeurs : unlimited, dynamic, cheap.

Rappelons que le support OpenMP est une des grandes différences qui distinguent encore GCC et LLVM/Clang puisque LLVM ne propose aucun support OpenMP dans sa branche principale.

Architectures AArch64

Avant la déferlante attendue des processeurs ARM 64 bits on note que GCC 4.9 améliore encore sa couverture de l'ISA ARMv8 avec le support des fonctions intrinsèques crypto et CRC mais aussi l'amélioration des performances des intrinsèques de vectorisation SIMD.

Le backend AArch64 profite également l'activation de la passe d'optimisation REE (Redundant extension elimination) ainsi que de du LRA (local register allocator).
Le réglage fin de la génération du code émis par GCC est amélioré pour les coeurs de processeur Cortex-A53 et Cortex-A57. Il est également possible d'indiquer au compilateur que l'on vise une architecture de type big.LITTLE via l'option -mcpu=cortex-a57.cortex-a53.

POWER8

Le titanesque et surpuissant POWER8 d'IBM est maintenant supporté par GCC 4.9 via l'option -mcpu=power8.
GCC a également été modifié afin de supporter le module HTM (Hardware Transactional Memory) de ces nouveaux processeurs POWER8. C'est dans la bibliothèque libitm qu'a été ajouté un fastpath qui profite à fond des circuits spécialisés présents dans le processeur.

Extension AVX512

Les futurs processeurs Intel Xeon Phi Knights Landing et les Intel Core de la génération Skylake ont beau n'être prévus que pour 2015 ou 2016, cette version 4.9 de GCC supporte déjà l'extension AVX512 qui sera incluse dans leurs coeurs de calcul.
AVX-512 est une extension complexe puisqu'elle propose un coeur obligatoire (AVX-512 Foundation) et plusieurs options (Conflict Detection Instructions, Exponential and Reciprocal Instructions, Prefetch Instructions) qui seront activées ou pas selon la gamme de processeur.

GCC 4.9 prend en charge toutes ces extensions (le code assembleur, les intrinsèques, l'autovectorisation) qui s'activent via différentes options (par exemple -mavx512f pour AVX-512 Foundation).

En bref
  • La colorisation automatique des diagnostics émis par le compilateur est maintenant disponible. L'option -fdiagnostics-color=auto permet ainsi de visualiser plus facilement les warnings ou les erreurs ainsi que l'emplacement exact du problème.

  • GCC 4.9 supporte maintenant la version 1.2.1 du langage Go (il s'agit de la toute dernière version sortie le 3 mars).

  • On trouve également dans GCC 4.9 le support de Cilk Plus, l'extension de C et C++ créé par Intel afin de faciliter l'écriture de code parallèle. L'utilisation se fait via l'option -fcilkplus et suit la version 1.2 de l'ABI Cilk Plus.

  • La bibliothèque d'exécution (runtime librairie) pour le langage C++ se nomme libstdc++ et elle a reçu diverses améliorations dans cette nouvelle version de GCC. Outre les nombreux changements lié au support du futur C++14 (par exemple std::exchange(), std::make_unique ou encore std::shared_lock) l'ajout le plus notable est le support de <regex> qui fait partie des nouveautés introduites par C++11.

  • De nouvelles options font leur apparition afin d'optimiser le code pour des processeurs récents ou à venir.
    On trouve ainsi -march=silvermont pour le nouveau coeur Atom avec exécution out-of-order, -march=broadwell pour la déclinaison 14 nm de l'architecture Haswell ou encore -march=bdver4 pour les futurs coeurs Excavator d'AMD.

Suivre le développement de GCC

Si vous voulez suivre le développement de GCC, sans nécessairement vous plonger dans le détail des commits ou des annonces sur les listes de diffusion, un bon moyen est de suivre le blog de Nick Clifton. Ce développeur GCC propose presque chaque mois une synthèse des nouveautés de la chaine de compilation GNU.
Lire rétrospectivement les articles concernant GCC 4.9 permet de mieux mesurer tout le travail et les ajouts qui sont incorporés dans cette version :

Télécharger ce contenu au format Epub

Lire les commentaires

Garradin 0.6 — Gestion d'association, maintenant avec les cotisations

Jeudi 24 Avril

Garradin est un logiciel libre de gestion d'association développé depuis 2 ans. Il se veut être la solution de gestion de petite et moyenne association la plus complète et la plus simple à utiliser. Il permet la gestion des adhérents et des cotisations, la tenue d'une comptabilité en partie double et l'envoi de courriels entre membres ou à tous les membres. Mais il contient aussi un wiki complet, comprenant la possibilité de chiffrer les pages, ainsi qu'un site web simple mais puissant grâce aux squelettes "à la SPIP".

Il est léger, rapide et ne demande aucune configuration pour être installé sur n'importe quel hébergeur supportant PHP 5.4 ou plus (tout est stocké dans une base de données SQLite).

Cette nouvelle version 0.6 fait suite à un an de développement et apporte de nombreuses fonctionnalités très attendues (listées ci-dessous).

Mais un des changements les plus importants est l'ouverture du service commercial Garradin à destination des associations qui ne veulent pas ou ne peuvent pas installer Garradin sur leur propre serveur. Ce service devrait permettre de pérenniser les efforts investis sur le logiciel afin de financer le poste du développeur principal. C'est ainsi une formule semblable à beaucoup de logiciels libres qui a été choisie : un service payant sans installation pour accompagner le logiciel libre.

Ce service est disponible sur le site http://garradin.eu/ pour un tarif de 42 € par an.

Cela ne change rien au développement de Garradin, qui reste un logiciel libre sous licence AGPLv3, garantissant ainsi de reverser toute modification effectuée pour le service commercial.

Principales nouveautés Gestion des cotisations

La gestion des cotisations a été complètement réécrite, l'implémentation originale étant trop simpliste pour être utile.

  • Les cotisations sont maintenant distinctes des catégories de membres pour plus de flexibilité ;
  • gestion fine des cotisations : possibilité de définir des cotisations pour une période fixe (année scolaire par exemple), de date à date (sur une durée à choisir), ou ponctuelle ;
  • suivi et historique des cotisations des membres ;
  • inscription automatique des cotisations dans la comptabilité ;
  • création de rappels automatiques de cotisation par e-mail (le délai avant rappel et le texte sont personnalisables) ;
  • envoi automatique par e-mail de rappels pour les cotisations ;
  • suivi manuel des rappels effectués par téléphone ou courrier.
Comptabilité
  • Liste des opérations créées par un membre (pour suivre qui fait quoi) ;
  • recherche par requête SQL ;
  • amélioration de la clôture d'exercice : création d'un nouvel exercice automatiquement, possibilité de "découper" l'exercice courant pour répartir les écritures postérieures à une date sur un nouvel exercice, création automatique des reports à nouveau ;
  • graphique de la répartition des dépenses et recettes.
Pour les geeks
  • Plugins : il est maintenant possible d'adjoindre des plugins à Garradin, pour le moment seul un plugin de test est disponible mais la documentation pour développer de nouveaux plugins est sur le site du projet.
  • Version hors ligne : Garradin peut maintenant être utilisé sans connexion à Internet. Un paquet Debian/Ubuntu à installer permet de disposer d'une version locale de Garradin.
  • Début du développement des tests automatisés des fonctionnalités.
  • Éditeur de code intégré (en Javascript) pour l'édition des squelettes du site public.
Divers
  • Amélioration design et compatibilité IE8.
  • Possibilité de se connecter en utilisant un autre champ que l'adresse e-mail.
  • Import de membres en CSV.
  • Import de membres depuis Galette.
  • Indicateur de niveau de sécurité du mot de passe.
  • Nouveau design par défaut du site public.

Et encore beaucoup de corrections de bugs et diverses améliorations.

La prochaine version se concentrera sur la mise à disposition d'un porte-documents permettant d'archiver et partager des fichiers entre adhérents. Ainsi il sera possible d'archiver une facture avec une écriture comptable, un scan d'autorisation parentale dans une fiche membre, etc.

Télécharger ce contenu au format Epub

Lire les commentaires

Quelles alternatives libres à Dropbox ?

Mercredi 23 Avril

La société Dropbox a accueillit une nouvelle personne à son conseil d'administration : Condoleezza Rice, conseillère à la sécurité nationale de l'ère Bush et connue pour avoir approuvé des écoutes illégales. Confier ses données à une entreprise requiert une grande confiance et Dropbox vient de perdre la confiance de beaucoup d'utilisateurs. Dropbox s'est empressé d'affirmer que sa stratégie de protection des données reste inchangée.

Si comme beaucoup vous décidez d'abandonner Dropbox, pourquoi ne pas passer à un logiciel libre pour gérer et stocker la mise à disposition de fichiers ? De nombreuses solutions existent, avec serveur ou en peer-to-peer.

    Avec serveur

    Avec ces solutions, l'idéal est d'avoir son propre serveur. Pour ceux qui n'ont pas l'inclination de maintenir un serveur, des offres d'hébergement payantes et gratuites sont souvent disponibles. Choisissez un hebergeur en lequel vous avez confiance, dans un pays respectueux de vos libertés. Une fois que le serveur est en place, il suffit de s'y connecter avec le logiciel client.

    • Owncloud, qui requiert un serveur OwnCloud. Nombreuses offres d'hébergements à travers toute l'Europe. Beaucoup de fonctionnalités annexes, ce qui peut être un inconvénient. GNU-AGPLv3 pour le serveur, GNU-GPLv3 pour Linux/Windows/Mac/Android, licence MIT pour iOS.
    • Seafile, qui requiert un serveur dédié. GNU-GPLv3. Linux/Windows/Mac/Android/iOS.
    • Pydio (anciennement Ajaxplorer), qui est écrit en Javascript et PHP. Nécessite un serveur Web quelconque avec PHP5 dont les extensions MCrypt et GD. Simple à mettre en place. C'est un projet qui semble dynamique, plutôt ergonomique. GNU-AGPL. Linux/Windows/Mac.
    • SparkleShare, qui requiert un serveur Git. Idéal avec de petits fichiers, notament pour les grandes équipes qui veulent un historique complet. GNU-GPLv3. Linux/Mac/Windows.
    • git-annex assistant, aussi basé aussi sur Git mais mieux équipé pour les gros fichiers. GNU-GPLv3. Linux/Windows/Mac/Android. Ne nécessite pas forcément de serveur central.
    • Syncany, qui requiert un serveur FTP ou WebDAV. GNU-GPLv2. Linux/Windows/Mac.
    • CmisSync, qui requiert un serveur de GED. Adapté aux entreprises qui disposent déjà d'un serveur Alfresco, Nuxeo, SharePoint ou autre. GNU-GPLv3. Linux/Windows/Mac.
    • Unison, qui nécessite une configuration en étoile, avec un "hub" au centre. Unison a l'avantage d'exister depuis longtemps, mais il souffre d'une certaine vétusté, il est difficile à mettre en place pour un utilisateur lambda et son code source en OCaml n'attire pas foule de développeurs. GNU-GPLv3. Linux/Windows/Mac.
    En peer-to-peer

    Si votre smartphone est allumé la plupart du temps, vous n'avez pas vraiment besoin d'un serveur. Le logiciel non-libre BitTorrent Sync l'a compris et connait actuellement un succès phénoménal qui lui vaut le surnom de Dropbox-killer. Des solutions Open Source existent aussi, pour l'instant loin de rivaliser (en particulier, pas d'application pour smartphone).

    Le principe est de créer un "secret" sur l'appareil contient le répertoire à partager, puis renseigner ce secret sur chaque appareil à connecter.

    • Tahoe-LAFS est volontairement axé sur la sécurité des données, non seulement du point de vue de la disponibilité (en faisant en sorte que vos données soient suffisamment réparties), mais également du point de vue de la confidentialité (tout est chiffré, seules les personnes qui obtiennent un lien direct ont accès aux données en clair). L'organisation d'un groupe de pairs se fait typiquement sur les relations de confiance entre plusieurs humains qui veulent collaborer ensemble. GNU-GPLv2. Linux.
    • syncthing dont le but affiché est d'être un équivalent Open Source de BitTorrent Sync, codé en Go. Comme BitTorrent Sync, le client est une interface web locale. Licence MIT. Linux/Windows/Mac.
    • ClearSkies, la même chose en C++. GNU-LGPLv3. Seulement au stade de prototype, client basique en Python.
    • Hive2Hive qui se concentre pour l'instant sur sa bibliothèque. Licence MIT. Pas de client.
    Télécharger ce contenu au format Epub

    Lire les commentaires

    Taxonomie des attaques Heartbleed

    Mercredi 23 Avril

    Pour ceux qui se demandent encore si ils doivent vraiment changer leurs mots de passe suite à l'affaire Heartbleed, qui veulent comprendre pourquoi il ne fallait pas le faire trop tôt, ou qui n'ont pas vérifié si leur navigateur détecte les certificats révoqués, l'article Taxonomie des attaques Heartbleed recense et explique schématiquement les diverses attaques rendues possibles par le bug, y compris contre les logiciels clients (reverse heartbleed), Tor et les VPN.

    « Heartbleed » est une des pires failles qui soient arrivées à la sécurité sur Internet. À cause d'elle, les pirates ont pu ou peuvent obtenir des données confidentielles sans avoir besoin d'intercepter les échanges. Après les premières réactions centrées sur la mise à jour des serveurs web vulnérables, la révocation des certificats et le renouvellement des mots de passe, il a fallu quelques jours de plus pour comprendre que la faille Heartbleed affecte également les logiciels clients, les échanges SSL/TLS autres que HTTPS, et une multitude d'appareils embarqués qui ne recevront jamais de mise à jour logicielle.

    Plus de détails dans la suite de la dépêche.

    Scénarios d'attaques et contre-mesures :

    • Extraction de données sensible depuis un serveur HTTPS vulnérable
    • Extraction de données d'authentification depuis un serveur HTTPS vulnérable
    • Détournement de session sur un serveur HTTPS vulnérable
    • Extraction de la clé privée SSL d'un serveur HTTPS vulnérable>
    • Déchiffrement d'interceptions anciennes
    • Déchiffrement d'interceptions récentes
    • Imitation de sites sécurisés
    • Extraction de données depuis un navigateur HTTPS vulnérable, par phishing
    • Extraction de données depuis un navigateur HTTPS vulnérable, via des liens tiers
    • Extraction de données depuis un aspirateur d'URL vulnérables
    • Analyse et corrélation de trafic Tor
    • Identification de serveurs cachés et d'utilisateurs par des noeuds Tor hostiles
    • Attaques contre les services VPN
    • Attaques contre les proxys HTTPS vulnérables

    Au delà de HTTPS, de nombreux services et protocoles basés sur SSL/TLS risquent d'être touchés par la faille Heartbleed :

    • le système sécurisé de noms de domaine DNSSEC ;
    • des tiers de confiance d'horodatage ou de notarisation, où les clés privées sont utilisées à des fins de signature plutôt que de chiffrement ;
    • des systèmes de téléchargement automatique de mises à jour de logiciels ;
    • les protocoles d'authentification RADIUS, Diameter, etc ;
    • le courriel avec SMTPS, POP3S, IMAPS ;
    • la voix/vidéo sur IP avec SIPS ;
    • des systèmes de monnaie électronique et des applications de porte-monnaie ;
    • des infrastructures de développement open-source (git).

    NdM : voir aussi les journaux sur l'émission 14h42, la sélection du meilleur des journalistes, le fork d'Openssl par OpenBSD, etc. Et d'autres liens comme Heartbleed : des cas français existent et les banques ne sont pas épargnées (NextINpact), HeartBleed : une chance qu'OpenSSL soit un logiciel libre ! (April). la réaction de la CNIL, les recommandations de l'ANSSI, Bug Heartbleed, vers un ralentissement mondial du Web ? (ZdNet), etc.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Concours de programmation CodinGame le 26 avril 2014

    Mardi 22 Avril

    La prochaine édition de CodinGame, le challenge de code en ligne, aura lieu ce samedi 26 Avril 2014 à 18h (heure française).

    L'événement accueillera des développeurs du monde entier pour leur permettre de passer un bon moment, défier leurs pairs, gagner des prix ou entrer en contact avec des sociétés qui leur plaisent et qui recrutent.

    Parmi les nouveautés sur la plate-forme :

    • Clojure est ajouté aux langages disponibles ;
    • l'autocomplétion est activée pour C# et Python ;
    • le thème de cette édition est « Skynet Revolution » : Vous êtes John Connor. Votre objectif : détruire Skynet. Votre arme : le code.

    L'objectif du challenge : résoudre deux problèmes de programmation dans le langage de son choix parmi les 19 proposés (C/C++, C#, Java, Javascript, PHP, Python, Python 3, Perl, Go, Dart, Scala, Haskell, Objective-C, Pascal, Ruby, Bash, Groovy et Clojure). La durée moyenne estimée de l'épreuve est de 2h30.

    Modalités de participation : c'est en ligne, c'est gratuit, et c'est anonyme pour ceux qui ne souhaitent pas communiquer leurs coordonnées. L’environnement de développement proposé donne accès à un éditeur de code et un shell Bash, pour lancer son programme depuis le navigateur.

    Comme d'habitude, le règlement prévoit que le code source des participants soit rendu public sous licence libre GPL v3 et affiché sur le site dès la fin du concours, pour que tout le monde puisse apprendre et progresser en consultant les solutions des autres.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Prototypo, ou comment devenir typographe en quelques clics

    Mardi 22 Avril

    Qui n'a jamais été dans la situation où il ne trouvait pas exactement la police d'écriture qu'il cherchait, et surtout compatible multi-suppports, multi-applications ? Malgré le nombre de polices disponibles (gratuites ou non), il y a souvent toujours un détail qui vient entacher un choix. Malheureusement, la création d'une nouvelle police n'est pas chose aisée car cela demande de suivre un minimum de règles typographiques afin d'éviter certaines catastrophes visuelles…

    Campagne de financement

    Imaginez donc une application « WYSIWYG » (What You See Is What You Get) vous permettant de jouer au typographe en herbe sans avoir à vous soucier des bases de la typographie, le tout pouvant être exporté sous différent formats : c'est ce que propose Prototypo.

    Le projet, actuellement en phase de développement, a lancé le 9 avril dernier une campagne de financement participatif sur Kickstater afin d'accélérer son développement ainsi que prendre la température sur les fonctionnalités les plus attendues par la communauté.

    Prototypo est un projet open-source sous licence AGPL dont le but est de fournir une application en ligne permettant de contrôler la conception d'une police à l'aide d'un large choix de paramètres typographiques (plus d'une vingtaine) afin de gérer la forme des lettres, le tout avec sa souris, simplement.

    Yannick Mathey (le designer) et Louis-Rémi Babé (le codeur) utilisent des technologies standards (HTML5, CSS3, SVG et JS) pour réaliser cette application dont le code est mis à disposition sur GitHub.

    Encore en phase beta, Prototypo a besoin d'autres logiciels pour convertir les polices du format svg vers otf. La campagne Kickstarter vise justement à plus d'autonomie (entre autres). Le développement est plutôt actif, le chat des auteurs se charge de la communication.

    Il est aussi à noter qu'une partie du financement sera reversé à d'autres projets open-source contribuant au développement : un juste retour à la communauté, selon l'équipe de Prototypo.

    En à peine une dizaine de jours, le projet à déjà atteint son deuxième objectif. Il lui reste jusqu'au 10 mai prochain pour le troisième. Alors, c'est Français, c'est open-source, et en plus ça facilitera la vie de beaucoup, donc pourquoi ne pas supporter cette initiative !

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Revue de presse de l'April pour la semaine 16 de l'année 2014

    Mardi 22 Avril

    La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

    Sommaire

    [Le Point] Axelle Lemaire veut "rétablir un Internet qui garantit les libertés fondamentales"

    Par la rédaction, le vendredi 18 avril 2014. Extrait:

    Entretien avec la nouvelle secrétaire d'État au Numérique, qui détaille pour la première fois la politique qu'elle entend mener au gouvernement.

    Lien vers l'article original: http://www.lepoint.fr/chroniqueurs-du-point/guerric-poncet/axelle-lemaire-veut-retablir-un-internet-qui-garantit-les-libertes-fondamentales-18-04-2014-1814411_506.php

    Et aussi:

    [Numerama] Des graines open-source pour jardiner librement

    Par Guillaume Champeau, le vendredi 18 avril 2014. Extrait:

    Aux Etats-Unis, des universitaires ont conçu l'Open Source Seed Initiative, une organisation qui vise à distribuer des graines libres d'utilisation et de reproduction, sur le modèle des licences Creative Commons.

    Lien vers l'article original: http://www.numerama.com/magazine/29144-des-graines-open-source-pour-jardiner-librement.html

    [Le Huffington Post] Quelles répercussions politiques pour la faille Heartbleed?

    Par Marc Thiriez, le jeudi 17 avril 2014. Extrait:

    La faille de sécurité Heartbleed liée à la technologie OpenSSL va-t-elle prendre une dimension politique? Considérée déjà comme une des plus importantes failles de sécurité de l'histoire (deux serveurs sur trois seraient concernés selon The Verge), Bloomberg révélait que la NSA, au courant depuis deux ans de l'existence de la faille de sécurité, aurait gardé l'information sous silence en utilisant Heartbleed pour collecter des informations sensibles. D'autres États, aux intentions plus agressives que les États-Unis, ont pu faire de même

    Lien vers l'article original: http://www.huffingtonpost.fr/marc-thiriez/quelles-repercussions-politiques-pour-la-faille-heartbleed-_b_5158431.html

    Et aussi:

    Voir aussi:

    [Le Monde.fr] Il pourrait changer la face de l'Europe: le traité transatlantique décodé

    Par Maxime Vaudano, le mardi 15 avril 2014. Extrait:

    Le traité TAFTA, négocié dans le secret par Bruxelles et Washington, a pour but de constituer un marché commun de 820 millions de consommateurs, qui représenterait la moitié du PIB mondial.

    Lien vers l'article original: http://www.lemonde.fr/les-decodeurs/article/2014/04/15/il-pourrait-changer-la-face-de-l-europe-le-traite-transatlantique-decode_4399476_4355770.html

    [infoDSI] Open Source: l’Etat joue le jeu

    Par Damien Clochard, le mardi 15 avril 2014. Extrait:

    La DISIC vient de publier la dernière version du SILL (Socle Interministériel de Logiciels Libres) émettant des recommandations sur l'usage des logiciels libres au sein des ministères. Force est de constater que depuis la circulaire Ayrault de 2012, le passage au logiciel libre s’est accéléré. Non seulement l’Etat adopte des solutions libres, mais il contribue à leur développement pour le bénéfice des communautés mais aussi des autres institutions : un cercle vertueux qui bénéficie aussi à l’écosystème des sociétés de service informatique.

    Lien vers l'article original: http://www.infodsi.com/articles/147820/open-source-etat-joue-jeu-damien-clochard-directeur-operations-dalibo.html

    [PC INpact] Œuvres orphelines, restrictions d’accès et œuvres libres: les réactions

    Par Marc Rees, le lundi 14 avril 2014. Extrait:

    Le Conseil supérieur de la propriété littéraire et artistique poursuit sa mission sur les œuvres orphelines. Et pour cause, d'ici la fin de l'année, la France devra transposer comme les autres pays membres une directive sur ce sujet. Au ministère de la Culture, le CSPLA a rédigé un questionnaire interne où il se demande s’il faut ou non prévoir des restrictions d'accès sur ces œuvres. Il soulève aussi la question des oeuvres libres. Next INpact a recueilli les réactions de l'Aful, l'April et SavoirCom1 sur ces deux thèmes.

    Lien vers l'article original: http://www.pcinpact.com/news/86925-%C5%93uvres-orphelines-restrictions-d-acces-et-%C5%93uvres-libres-reactions.htm

    [Numerama] Le CSA dresse la liste de ce qu'il veut contrôler sur Internet

    Par Guillaume Champeau, le lundi 14 avril 2014. Extrait:

    Dans son rapport annuel, le CSA dresse la liste des domaines d'expressions dans lesquels il entend pouvoir exercer un droit de regard et de censure sur Internet.

    Lien vers l'article original: http://www.numerama.com/magazine/29080-le-csa-dresse-la-liste-de-ce-qu-il-veut-controler-sur-internet.html

    Et aussi:

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Petit jeu en HTML5 et découverte de Crafty

    Mardi 22 Avril

    Rien de tel que de créer son propre jeu… à jouer dans le navigateur. Petite introduction au développement de jeux sur web avec le moteur Crafty.

    C'est un moteur de jeu pour HTML5 écrit en javascript. Il fonctionne par entités et propose un rendu par DOM ou Canvas. Dans ce tutoriel, on va utiliser un rendu par DOM, qui est apparemment plus rapide que Canvas (c'est ce que dit la doc !). Nous allons donc nous servir de Crafty pour créer un petit tableau de jeu généré aléatoirement, et y déplacer un personnage, tout en gérant les collisions et animations du personnage et son environnement.

    NdM : merci à etenil pour son journal.

    Sommaire Programmer des jeux vidéo avec Crafty

    J'ai commencé à apprendre la programmation pour développer mes propres jeux vidéos. Beaucoup d'eau a coulé sous les ponts depuis et je me retrouve à développer surtout du web et des systèmes de base de données. Mon but initial de faire des jeux vidéos sombrant dans l'oubli…

    J'ai donc choisi de renouveler mon intérêt pour le développement de jeux et de regarder du côté des technologies web. Leur promesse d'être utilisable sur tout support est séduisante et c'est aussi la seule manière de faire des jeux pour Firefox OS (mon téléphone).

    Tout d'abord, trouver quelques sprites; c'est quand même plus intéressant à voir que des blocs colorés ! Une bonne ressource est OpenGameArt.org. J'en ai fait une petite sélection et y ai ajouté une fleur animée.

    Vous pouvez récupérer le code du petit jeu, ça vous évitera d'être perdu.

    L'écran de chargement

    Le fichier HTML qui va nous servir de base est pratiquement nu.

    <!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <script type="text/javascript" src="https://raw.githubusercontent.com/craftyjs/Crafty/release/dist/crafty.js"></script> <script type="text/javascript" src="game.js"></script> <style> body, html { margin: 0; padding: 0; overflow: hidden; } #game { margin: 100px auto 0; } </style> <title>Crafty game test</title> </head> <body> <div id="game"></div> </body> </html>

    Et voici la toute base de notre jeu, à mettre dans le fichier game.js.

    window.onload = function() { var game = document.getElementById('game'); randRange = function(min, max) { return Math.floor(Math.random() * (max - min + 1)) + min; } Crafty.init(320, 240, game); Crafty.sprite(16, "world.png", { grass1: [0,0], grass2: [1,0], grass3: [2,0], grass4: [3,0], flower: [0,1], bush1: [0,2], bush2: [1,2] }); Crafty.sprite(16, 18, "character.png", { player: [0,0] }); Crafty.scene("loading", function() { Crafty.load(["world.png", "character.png"], function() { Crafty.scene('main'); }); Crafty.background('#000'); Crafty.e("2D, DOM, Text") .attr({x: 140, y: 120}) .text('Loading...') .css({'text-align': 'center', 'color': '#FFF'}); }); Crafty.scene('loading'); }

    La première chose qu'on fait ici, c'est initialiser le moteur Crafty. Pour cela, on lance Crafty.init() en définissant la taille de la zone de jeu (320x240), ainsi que la zone de jeu elle-même (le div #game).

    On définit ensuite les sprites. Les sprites se gèrent très facilement dans Crafty; il suffit d'indiquer le fichier de sprites, puis l'index de chaque sprite dans l'objet de mapping. ici grass2 est situé à x=1 et y=0, c'est-à-dire 16px vers la droite, et collé au haut de l'image.

    Les sprites de personnages sont un peu différents car ceux-ci sont plus hauts que larges (16x18). Une fois définis, on pourra invoquer les sprites par leur petit nom directement, simplifiant ainsi les opérations. Notez que les sprites d'animation ne sont définis que par une seule image pour le moment, leur état neutre (voir player).

    Crafty utilise le concept de scène. Ici on a défini la scène de chargement, qui s'affiche jusqu'à ce que les objets nécessaires à la scène suivante soient chargés. Vous ne le verrez peut-être pas car c'est très court, mais le texte loading… devrait apparaitre brièvement sur un écran noir. La scène suivante main n'a pour l'instant pas été déclarée, conduisant à un écran noir.

    Il est temps de passer à la scène principale.

    Planter le décor

    La zone de jeu va être générée en grande partie aléatoirement. Le sol sera tapissé de carrés d'herbe aléatoires, quelques buissons et fleurs animées. Les bords de l'écran seront quant à eux délimités par des buissons. Enfin notre personnage sera au milieu la zone de jeu.

    On va définir empiriquement qu'il y a 1 chance sur 50 d'avoir une fleur sur un carré de sol, et 1 chance sur 25 de trouver un buisson aléatoire. Il sera aisé plus tard d'ajuster ces valeurs si besoin.

    Je vous livre la fonction de génération de monde :

    // Method to randomy generate the map function generateWorld() { // Generate the grass along the x-axis for (var i = 0; i < 20; i++) { // Generate the grass along the y-axis for (var j = 0; j < 15; j++) { grassType = randRange(1, 4); Crafty.e("2D, DOM, grass" + grassType) .attr({x: i * 16, y: j * 16}); // 1/50 chance of drawing a flower. if (i > 0 && i < 19 && j > 0 && j < 14 && randRange(0, 50) > 49) { var flower = Crafty.e("2D, DOM, SpriteAnimation, flower") .attr({x: i * 16, y: j * 16}) .reel("wind", 1000, 0, 1, 3) .animate("wind", 10) .bind("enterframe", function() { if (!this.isPlaying()) this.animate("wind", -1); }); } // 1/25 chance of drawing a bush. if (i > 0 && i < 19 && j > 0 && j < 14 && randRange(0, 25) > 24) { var bush = Crafty .e("2D, DOM, randbushes, bush"+randRange(1,2)) .attr({x: i * 16, y: j * 16}); } } } // Create the bushes along the x-axis which will form the boundaries for (var i = 0; i < 20; i++) { Crafty.e("2D, DOM, wall_top, bush"+randRange(1,2)) .attr({x: i * 16, y: 0, z: 2}); Crafty.e("2D, DOM, wall_bottom, bush"+randRange(1,2)) .attr({x: i * 16, y: 224, z: 2}); } // Create the bushes along the y-axis // We need to start one more and one less to not overlap the previous bushes for (var i = 1; i < 15; i++) { Crafty.e("2D, DOM, wall_left, bush" + randRange(1,2)) .attr({x: 0, y: i * 16, z: 2}); Crafty.e("2D, DOM, wall_right, bush" + randRange(1,2)) .attr({x: 304, y: i * 16, z: 2}); } }

    Passons à la déclaration de la scène principale.

    Crafty.scene("main", function() { generateWorld(); // Create our player entity with some premade components var player = Crafty.e("2D, DOM, player, controls") .attr({x: 152, y: 111, z: 1}) .reel("walk_left", 200, 6, 0, 2) .reel("walk_right", 200, 9, 0, 2) .reel("walk_up", 200, 3, 0, 2) .reel("walk_down", 200, 0, 0, 2); });

    Ici, on génère le monde aléatoirement, puis on place notre personnage principal en plein milieu de la zone de jeu. Les appels .reel() définissent les animations du personnage par rapport à l'arrangement des sprites. Les paramètres de .reel() sont le nom de l'animation, sa durée en ms, la position x du sprite de départ, la position y du sprite de départ, puis la longueur de l'animation en nombre de sprites (vers la droite).

    Pour l'instant le personnage est immobile, et les animations n'ont aucun effet. Nous allons remédier à cela.

    Premiers pas

    Crafty fournit deux contrôles de base. L'un permet d'aller à droite ou gauche et sauter, l'autre de se déplacer dans les quatre directions. Ce n'est pas très satisfaisant, nous allons définir nos propres contrôles qui permettront aussi des diagonales.

    Juste après la ligne generateWorld();, mettez le code suivant:

    Crafty.c('CustomControls', { __move: {left: false, right: false, up: false, down: false}, _speed: 3, CustomControls: function(speed) { if (speed) this._speed = speed; var move = this.__move; this.bind('EnterFrame', function() { // Move the player in a direction depending on the booleans // Only move the player in one direction at a time (up/down/left/right) if (move.right) this.x += this._speed; else if (move.left) this.x -= this._speed; else if (move.up) this.y -= this._speed; else if (move.down) this.y += this._speed; }); this.bind('KeyDown', function(e) { // Default movement booleans to false move.right = move.left = move.down = move.up = false; // If keys are down, set the direction if (e.keyCode === Crafty.keys.RIGHT_ARROW) move.right = true; if (e.keyCode === Crafty.keys.LEFT_ARROW) move.left = true; if (e.keyCode === Crafty.keys.UP_ARROW) move.up = true; if (e.keyCode === Crafty.keys.DOWN_ARROW) move.down = true; }); this.bind('KeyUp', function(e) { // If key is released, stop moving if (e.keyCode === Crafty.keys.RIGHT_ARROW) move.right = false; if (e.keyCode === Crafty.keys.LEFT_ARROW) move.left = false; if (e.keyCode === Crafty.keys.UP_ARROW) move.up = false; if (e.keyCode === Crafty.keys.DOWN_ARROW) move.down = false; }); return this; } });

    Voici notre code de contrôle. La logique est assez simple, à chaque appui sur un bouton, on regarde l'état des touches fléchées pour déterminer les directions du mouvement en une combinaison de gauche, droite, bas et haut. Une fois le mouvement défini dans __move, crafty déplacera l'entité de _speed pixels dans les directions données lors du rafraîchissement d'écran.

    On va maintenant modifier la déclaration du personnage pour le faire se déplacer, et animer son mouvement.

    var player = Crafty.e("2D, DOM, player, controls, CustomControls, SpriteAnimation") .attr({x: 160, y: 144, z: 1}) .CustomControls(1) .reel("walk_left", 200, 6, 0, 2) .reel("walk_right", 200, 9, 0, 2) .reel("walk_up", 200, 3, 0, 2) .reel("walk_down", 200, 0, 0, 2) .bind("EnterFrame", function(e) { if(this.__move.left) { if(!this.isPlaying("walk_left")) this.animate("walk_left", 10); } if(this.__move.right) { if(!this.isPlaying("walk_right")) this.animate("walk_right", 10); } if(this.__move.up) { if(!this.isPlaying("walk_up")) this.animate("walk_up", 10); } if(this.__move.down) { if(!this.isPlaying("walk_down")) this.animate("walk_down", 10); } }) .bind("KeyUp", function(e) { this.pauseAnimation(); this.resetAnimation(); });

    Notez la déclaration de CustomControls comme méthode controle, et la vitesse d'1px/image. Pour gérer les animations, on se greffe sur l'évènement EnterFrame, et on détermine l'animation à jouer par rapport à la direction de mouvement du personnage. Quand une touche est relachée, on arrête et rembobine l'animation pour revenir en position neutre (évènement KeyUp).

    À présent, le personnage devrait évoluer gaillardement sur votre écran, et passer allègrement à travers les buissons et hors de la zone de jeu…

    Collisions

    Il est temps de passer à la gestion des collisions. On va faire très simple et ne pas définir de hitbox. Crafty utilisera alors les sprites eux-mêmes comme hitbox. Pas terrible, mais simple.

    On va aussi ne s'occuper que des collisions entre le joueur et les buissons (quels qu'ils soient). Ça évitera au perso de sortir de la zone de jeu et le forcera à éviter les buissons dans l'herbe.

    Modifiez la déclaration du joueur comme suit :

    var player = Crafty.e("2D, DOM, player, controls, CustomControls, SpriteAnimation, Collision") .attr({x: 160, y: 144, z: 1}) .CustomControls(1) .reel("walk_left", 200, 6, 0, 2) .reel("walk_right", 200, 9, 0, 2) .reel("walk_up", 200, 3, 0, 2) .reel("walk_down", 200, 0, 0, 2) .bind("EnterFrame", function(e) { if(this.__move.left) { if(!this.isPlaying("walk_left")) this.animate("walk_left", 10); } if(this.__move.right) { if(!this.isPlaying("walk_right")) this.animate("walk_right", 10); } if(this.__move.up) { if(!this.isPlaying("walk_up")) this.animate("walk_up", 10); } if(this.__move.down) { if(!this.isPlaying("walk_down")) this.animate("walk_down", 10); } }) .bind("KeyUp", function(e) { this.pauseAnimation(); this.resetAnimation(); }) .collision() .onHit("wall_left", function() { this.x += this._speed; this.pauseAnimation(); this.resetAnimation(); }) .onHit("wall_right", function() { this.x -= this._speed; this.pauseAnimation(); this.resetAnimation(); }) .onHit("wall_bottom", function() { this.y -= this._speed; this.pauseAnimation(); this.resetAnimation(); }) .onHit("wall_top", function() { this.y += this._speed; this.pauseAnimation(); this.resetAnimation(); }) .onHit("randbushes", function() { if(this.__move.left) this.x += this._speed; if(this.__move.right) this.x -= this._speed; if(this.__move.up) this.y += this._speed; if(this.__move.down) this.y -= this._speed; this.pauseAnimation(); this.resetAnimation(); });

    Après avoir déclaré l'utilisation du module Collision, on l'initialise avec collision(). Ensuite il suffit de gérer l'évènement onHit sur les objets intéressants.

    Les évènements de collisions sont résolus après le mouvement, mais avant le rendu. C'est pour cela qu'on fait reculer le personnage d'un pas (enfin, de _speed) lors de la détection d'une collision. Du point de vue du joueur, le personnage restera parfaitement immobile.

    On pourrait bien entendu faire autre chose lors de la collision, comme lancer un combat, ou envoyer un bonus tout en laissant le personnage passer dans le buisson. Les possibilités sont infinies !

    Aller plus loin

    C'est donc une toute base de jeu, mais sans logique. On peut déjà améliorer le code sur beaucoup de points. Vous pourrez vous plonger dans la documentation de Crafty pour vous y atteler.

    On peut s'assurer que les buissons n'apparaissent pas sur des fleurs, et que le joueur n'apparaît pas sur des buissons.

    L'algorithme de génération du monde peut être largement amélioré pour grouper les types d'herbe et faire des zones herbues et d'autres moins. On pourra introduire d'autres types de sprites pour avoir un terrain un peu plus intéressant. Avec de gros sprites, on peut aussi introduire des éléments de décor comme des maisons, ou même des PNJ.

    Les hitbox des entités sont très maladroites. Il serait bien plus élégant de définir des hitbox sur les pieds du personnage et la base des buissons, afin de pouvoir passer derrière les éléments (il faudra aussi gérer l'axe Z des sprites pour le rendu !).

    En faisant des zones de sortie dans les buissons sur les rebords, on pourra lier d'autres tableaux, générés de façon procédurale eux aussi. Voire même générer plusieurs zones contigües à la fois et maintenir une structure de données pour que le jeu reste homogène.

    Et bien plus encore, autant que votre créativité permet !

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Grisbi : après le logiciel, le manuel en version 1.0

    Mardi 22 Avril

    Utilisateur de Grisbi depuis la version 0.3, j'ai un jour constaté que le logiciel avait tellement évolué que le manuel était devenu complètement obsolète ; je me suis donc attelé à sa remise à niveau, d'autant qu'il est écrit en Latex, que ça m'intéressait d'apprendre… D'où les versions 0.6, 0.8 et enfin celle-ci. Alors bonnes lectures !

    En plus de documenter le logiciel version 1.0 (voir la dépêche dédiée), c'est bien le moins (!), ce manuel de l'utilisateur apporte un certain nombre de nouveautés, détaillées en seconde partie.

    Nouveautés du manuel
    • un glossaire pour les termes techniques ;
    • un index pour une recherche plus rapide des fonctions et descriptions ;
    • un format html avec images, accessible par le menu Aide ;
    • la liste des nouveautés du logiciel ;
    • une liste de logiciels libres pour sa lecture ;
    • la réorganisation de certains chapitres pour plus de clarté ;
    • un grand nombre de précisions, en particulier à la demande des utilisateurs ;
    • un chapitre association présentant les principales procédures utilisées en comptabilité d'association ou de petite entreprise ;
    • tous les fichiers sous locale UTF-8 ;
    • et enfin quelques perles du style Album de la Comtesse, pour les aficionados (:-).

    J'ajoute que les utilisateurs disposeront dans quelque temps d'un format epub pour leurs liseuses : surveillez le dépôt sur Sourceforge !

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Logiciels pour survivre avec Docker

    Mardi 22 Avril

    Docker a déjà été présenté via un tutoriel pour manipuler les conteneurs et une présentation de la gestion des containers sur LinuxFR. Il s'agit d'un système de conteneurs qui étend ce que fait le système de cloisonnement Linux Containers LXC sous Linux. Cette dépêche présente un certain nombre de logiciels utiles pour compléter Docker.

    Gestion du réseau Pipework

    Pipework est un script de configuration réseau pour Docker/LXC. C'est un complément à Docker, lequel ne se charge pas directement de configurer le réseau (en tous cas pas suffisamment).

    Site officiel et doc

    Installation apt-get install arping bridge-utils git clone https://github.com/jpetazzo/pipework.git mv pipework/pipework /usr/local/bin/pipework Utilisation

    Créer un réseau privé entre deux conteneurs et l'hôte :

    pipework br1 conteneur1 192.168.1.1/24@192.168.1.254 pipework br1 conteneur2 192.168.1.2/24@192.168.1.254 ip addr add 192.168.1.254/24 dev br1 dnsmasq

    DNSMasq c'est un mini serveur qui vous évite d'installer des services plus lourds (comme Bind, ISC Dhcpd…). Il n'est pas spécifiquement lié à l'environnement Docker mais il peut être très utile pour se monter très simplement un service de noms et une distribution d'adresses.

    Configuration en deux minutes
    Documentation officielle

    Serveur PXE dans un container

    Un container pour booter en PXE des machines sous Debian.
    Les explications et le dockerfile.

    Gestion des containers Interface Web (DockerUI ou Shipyard)

    Docker peut aussi s'administrer avec une interface Web.
    C'est peut-être un gadget mais ça permet à ceux qui ne connaissent pas Docker de faire de l'administration basique (redémarrer un container, …).

    J'aime bien DockerUI qui a le mérite d'être simple.

    Ça s'installe directement dans un container :

    docker build -t crosbymichael/dockerui github.com/crosbymichael/dockerui docker run -d -p 9000:9000 -v /var/run/docker.sock:/docker.sock crosbymichael/dockerui -e /docker.sock

    Dans ce domaine, il y a aussi Shipyard qui semble plus complet, qui propose une API et qui fonctionne en client serveur (avec le shipyard-agent sur les containers).

    nsenter

    Problème habituel dans Docker : une fois qu'on lance un container en mode démon, on ne peut plus rentrer dedans.

    Pour résoudre ça, on va avoir besoin de nsenter fourni par le paquet util-linux > 2.23.
    Sous debian/ubuntu, c'est la version 2.20 donc il faut télécharger et compiler les sources :

    cd /tmp curl https://www.kernel.org/pub/linux/utils/util-linux/v2.24/util-linux-2.24.tar.gz | tar -zxf- cd util-linux-2.24 ./configure --without-ncurses make nsenter cp nsenter /usr/local/bin

    Et maintenant on se crée un script pour Docker (/usr/local/sbin/dkenter) :

    #!/bin/bash CNAME=$1 CPID=$(docker inspect --format '{{ .State.Pid }}' $CNAME) nsenter --target $CPID --mount --uts --ipc --net --pid

    Je lance un container en démon :

    docker run --name lamp1 -d lamp-maria supervisord -n

    Je ne peux plus m'attacher dessus alors j'utilise dkenter pour obtenir un shell.
    Quand j'en ressort, le container continue de tourner.

    dkenter lamp1 root@ff94c159642f# ... root@ff94c159642f# exit Boot2Docker

    Boot2Docker est une distribution Linux ultra-légère pour servir d'hôte Docker.
    On peut télécharger les images ISO ou suivre le manuel.

    Busybox

    Busybox est un système Linux ultra léger (2,5 Mo, qui dit mieux ?).
    Il existe en image Docker sur le dépôt officiel Docker

    Baseimage

    Baseimage c'est le contraire de busybox. Ça part du principe que l'image Ubuntu ou Debian fournie de base par Docker doit être complétée pour fournir d'autres services tels qu'un process init correct, un syslog, un cron, et un serveur SSH.

    Les explications
    Le dépôt git

    Créer son propre dépôt Docker

    Docker registry : un logiciel pour créer son propre dépôt Docker.
    Sur Github

    Télécharger ce contenu au format Epub

    Lire les commentaires

    pkgsrc 2014Q1 est disponible

    Lundi 21 Avril

    Dans un message à des listes de diffusion pkgsrc et NetBSD, Alistair Crooks a annoncé la disponibilité de la branche pkgsrc-2014Q1 ! Pkgsrc est un framework de construction de logiciels tiers pour NetBSD ainsi que pour d'autres systèmes de type UNIX. Il permet donc à NetBSD et à d'autres systèmes d'exploitation de disposer de nombreux logiciels, sous forme source mais aussi sous forme binaire.

    Les développeurs pkgsrc fournissent une nouvelle version stable chaque trimestre. Comme son nom l'indique, pkgsrc 2014Q1 est donc la première sur les quatre de 2014, et est disponible depuis le 4 avril dernier. Anecdote amusante, il s'agit de la 42e version de pkgsrc.

    Plus de détails sur cette version en particulier en deuxième partie de dépêche.

    À propos de pkgsrc

    Pkgsrc est historiquement le système de paquets pour NetBSD, issu d'un fork en 1997 de la collection de ports FreeBSD. Avec le temps, pkgsrc a évolué, dans le même esprit de portabilité que NetBSD il est utilisable sur plusieurs systèmes d'exploitation. Ils peuvent alors gérer leur propre collection de paquets sources et binaires. Ainsi, pkgsrc prend en charge une vingtaine de plateformes, dont voici un extrait :

    Cygwin ;
    Darwin/Mac OS X ;
    DragonFlyBSD ;
    FreeBSD ;
    GNU/kFreeBSD ;
    Interix/SFU/SUA ;
    Linux ;
    Minix3 ;
    NetBSD ;
    OpenBSD ;
    Solaris/illumos.

    On notera que même si des architectures sont prises en charge, cela ne signifie pas pour autant que le projet met à disposition des paquets binaires pour celles-ci, ou que les systèmes d'exploitation concernés fournissent des paquets binaires officiels. À contrario, même si dports a pris le pas sur pkgsrc pour DragonFlyBSD, il est toujours possible de l'utiliser.

    Quelques chiffres

    En terme de paquets, pkgsrc-2014Q1 c'est :

    • 14255 paquets au total pour NetBSD-current/amd64 ;
    • 13841 paquets binaires compilés avec clang pour NetBSD-current/x86_64 ;
    • 12093 paquets binaires compilés avec gcc pour SmartOS/i386 ;
    • 12046 paquets binaires compilés avec gcc pour SmartOS/x86_64 ;
    • 11445 paquets binaires compilés avec gcc pour FreeBSD 9/x86_64 ;
    • 11233 paquets binaires compilés avec clang pour FreeBSD 10/x86_64.

    Ce trimestre, en terme de modifications, c'est :

    • 222 paquets ajoutés ;
    • 33 paquets retirés ;
    • 1681 paquets mis à jour ;
    • et, chose étrange, un paquet a été rétrogradé de version : math/R-zoo.
    Les changements

    Si on s'en tient aux chiffres, on peut penser que ce trimestre est un peu plus calme que le précédent, avec moins d'ajouts et moins de retraits. Il n'en est cependant rien, car il y a au moins 300 nouvelles mises à jour depuis 2013Q4. De plus, Alistair Crooks souligne l'arrivée de Python 3.3, en tant que « citoyen de première classe », ainsi que l'ajout d'une nouvelle plateforme compatible, portant son total à 22 : SCO OpenServer. Parmi les nouveaux arrivants, on peut aussi souhaiter la bienvenue à git-svn, plein de modules Perl et Python, ainsi qu'à Ruby 2.1.1. Du côté des départs, ce sont entre autres cvsup, SmartEiffel, ezm3 et snobol qui tirent leur révérence.

    Contribuez !

    Si aucun appel à contribution en particulier n'a été fait pour pkgsrc, sachez que vous pouvez toujours vous essayer à l'empaquetage pour pkgsrc grâce au projet pkgsrc-wip, qui avait été abordé lors d'une précédente dépêche. Néanmoins, un appel à contribution à été fait, sur Twitter par iMil pour pkgin, le gestionnaire de paquets binaires gérant les dépendances.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Pages