rewind a écrit 3429 commentaires

Pour ceux qui n'auraient pas compris comment ça fonctionne, je vais essayer d'éclaircir ce point parce que le journal est assez confus. J'ai mis pas mal de temps à bien comprendre comment ça fonctionnait donc je vais en faire profiter tout le monde.

libretro est une API qui tient dans un .h et on a donc deux côtés à l'API : ceux qui vont implémenter l'API (les backends ou cores) et ceux qui vont l'utiliser (les frontends). Le frontend est chargé de fournir au backend via des callbacks tout un tas de service comme les entrées (clavier, souris, etc), le son, l'image, etc. C'est ce qui est fait dans le projet présenté dans ce journal. Le backend lui est l'implémentation générique d'un émulateur ou même d'un jeu. Il va utiliser les services génériques fournis par le frontend sans avoir à s'occuper de la plateforme sur laquelle il tourne. C'est donc le frontend qui assure la portabilité d'une plateforme à une autre. Comme libretro est orienté émulateur à la base, il y a la notion de rom qui est prise en charge nativement dans l'API. Le frontend de référence s'appelle RetroArch (un peu austère).

Les possibilités sont énormes puisqu'au delà des émulateurs, il est également possible de demander au frontend un contexte OpenGL et donc, n'importe quel jeu moderne pourrait être implémenté en utilisant libretro. Je crois savoir que certains moteurs de jeu ont implémenté cette API et les jeux utilisant le moteur sont alors vu comme des roms. Il est également possible d'utiliser libretro pour implémenter des visionneurs de vidéo, il y a un portage de FFMPEG pour utiliser libretro. Bref, c'est une API à surveiller, avec beaucoup de projets très actifs qui tournent autour.

L'API de Retro n'est pas à considérer comme stable pour le moment, mais elle est proche de l'être et ne devrait pas trop changer.

Raté ! Après avoir freiné des quatre fers pour introduire des changements incompatibles, les auteurs de libretro ont décidé de travailler à une version 2 de l'API pour corriger tout un tas de choses bancales. Le travail se fait dans le dépôt git libretro-arb. Parmi les modifications, l'introduction d'un pointeur utilisateur dans toute l'API (ce qui permettra d'éviter les variables globales comme c'est le cas actuellement quand on implémente un core). Il y a encore du travail mais ça prend forme doucement.

Chez nous, il y a une liste spéciale syndicats sur laquelle tout le monde est inscrit (et on peut se désabonner si on veut) et ils envoient quand ils ont envie. Simple, efficace. Mais ça n'empêche pas qu'on reçoit plein de mails.

Et on ne va pas se plaindre de devoir voter, on ne peut pas vraiment dire qu'on souffre d'un trop plein de démocratie en ce moment, ça serait même plutôt le contraire. Déjà que le gouvernement a supprimé les élections prud’homales…

Apparemment, c'est encore pire que ça, parce qu'il faut des identifiants pour se connecter au bouzin et aussi son numéro d'adhérent d'UMP, et que plein de gens n'ont pas reçu le premier ou ont perdu le second. Bref, ça va être très funky. Je prépare le pop corn. Si ça pouvait éviter à tous les élus UMP de se lancer dans le vote électronique dans leur commune après ça, ça serait déjà ça de gagné.

Il y a un groupe de travail nommé SG13, dont le but est de travailler à avoir du graphique dans la bibliothèque standard. Certes, ça n'ira sans doute pas jusqu'à une GUI, mais c'est un début. Les spécifications techniques sont issues de ces groupes de travail.

Bon, pour l'instant, je dois dire que je suis assez déçu par les travaux engagés. Ils sont partis sur définir une API de dessin à partir de cairo. Mais du coup, on ne sait pas à quoi s'applique cette API : écran, fichier ? Et malgré toutes les interventions sur la liste disant que ce n'est pas la bonne direction ni la bonne méthode, ils persistent. Certains avaient même bien fait l'état des lieu : ce qui est difficile actuellement, c'est d'obtenir une fenêtre (et c'est pas là dessus qu'un système se différencie de nos jours, c'est un peu la base), pouvoir ensuite y créer un contexte de dessin (que ce soit pour OpenGL, DirectX ou cairo, peu importe), et pouvoir récupérer les événements sur cette fenêtre.

Tu a oublié une date.

2014 : une implémentation de référence pour les principales plateformes et avec une licence qui va bien (Boost). Alors bon, il faudrait vraiment le faire exprès pour ne pas avoir une implémentation dans les principaux compilateurs d'ici 2017.

Je préfère que ce soit efficace.

Je connais une méthode efficace : le despote qui décide tout seul, ça va vite, pas de paperasse. Pas sûr que ça soit dans l'intérêt de tous. Autre méthode efficace : le tirage au sort. Est-ce que c'est souhaitable ? Pour moi, le fait qu'un concours soit équitable évite de se retrouver avec des gens placés là parce qu'ils connaissent le neveu du cousin du maire.

D'ailleurs, quand on voit le nombre de poste non pourvus en maths (c'est à dire qu'on refuse des candidats qui théoriquement devraient être admis), est-il si évident que ces difficultés n'apparaîtrait pas en informatique ?

Si on lit le rapport du jury (qui est public parce que c'est un concours, ça fait partie des avantages), on peut voir que pour être admissible (donc passer les oraux), il fallait avoir 7,80 sur 20. On comprend mieux pourquoi ils n'arrivent pas à pourvoir tous leurs postes ! On voit aussi dans les statistiques que dans les années 90, il y avait plus de 7 candidats par postes, puis dans les années 2000, il n'y avait plus que 3 à 4 candidats par postes. Et depuis 2010 (date du gel des salaires des fonctionnaires), il n'y a plus que 1 à 1,5 candidats par poste. Forcément, la sélection est plus difficile dans le sens où il risque d'y avoir moins de bons candidats. La première année où on a commencé à recruter en dessous du nombre de postes au concours, c'est 2011.

On en parle pour la GPL ? ;)

Encore un héritage du passé dont on est incapable de se séparer, et pourtant…

Tous les fonctionnaires (en France) sont recrutés sur concours, c'est la manière la plus équitable de recruter des agents de l'État. Si tu en trouves une meilleure, n'hésite pas à en parler.

moi, je veux que tous les paquets acceptés compilent sur toutes les architectures de Debian avant d'être validés, ce serait obligatoire et non conseillé, ça serait rigolo comme liberté

C'est le cas. Si les paquets ne compilent pas sur toutes les architectures, il y a des bugs qui sont ouverts pour le paquet sous le joli acronyme FTBFS (Fail To Build From Source) et le mainteneur du paquet doit les corriger (avec l'aide des responsables d'architecture). Debian met à disposition tout un ensemble de machine de toutes les architectures pour faire les tests. Donc, plutôt que de parler pour ne rien dire (ta spécialité), renseigne-toi avant de débiter une autre connerie.

Rien de bien nouveau. Mais ce n'est pas étonnant quand on aborde le «numérique» sous l'angle uniquement économique. On retrouve tous les poncifs du genre qu'on nous débite depuis des années avec l'accent mis sur les technologies (mais on ne sait pas d'où elles sortent) et les usages (mais sans comprendre fondamentalement comment ça marche). Avec aggravation de la situation pour les données personnelles (ça veut dire quoi «personnalisation anonyme» ? En revanche, je comprends bien «captation et exploitation des données des clients finaux»). Et tout l'attirail du parfait petit libéral y passe : agence de notation numérique, baisse d'impôts, mobilité, etc. En revanche si vous cherchez où se trouve la généralisation de la fibre (nécessaire à toutes ces propositions), pas un mot. Et si vous cherchez les enseignements à l'informatique (tels que proposés par l'Académie des Sciences), c'est timide : «CAPES du numérique» (quoi qu'est-ce ?). Franchement, plus de 300 pages pour ça, ça ne valait pas le coup.

Et bien pour gérer les collisions (joueur/terrain, joueur/bombe, etc). On pourrait le faire à la main directement, mais avoir cette fonctionnalité encapsulée dans une classe permet d'en avoir une abstraction sympa. Après, quand je dis moteur physique, ce n'est pas un truc énorme non plus, ça tape dans les quelques centaines de lignes, guère plus.

Tout d'abord, on n'a pas gardé les cochons ensemble donc tu éviteras les attaques personnelles.

Ensuite, tu compares des choses pas comparables et tu te plains. Comparer des «bibliothèques userspace» aux modules du noyau n'a tout simplement pas de sens : l'un est une interface externe, l'autre est une interface interne. Donc si on veut comparer des choses comparables, on compare avec l'interface externe du noyau… qui elle est extrêmement stable.

En nombre de quoi ? De commits ? De lignes de code ?

«Les hobbyistes occupent comme d’habitude la troisième place (…) Le développement de Linux est donc majoritairement sponsorisé par des entreprises, mais il reste encore de nombreux passionnés qui font ça pour eux.»

C'est à toi de prouver que les modules non-intégrés dans le noyau sont "de la merde".

Mais ce n'est pas mon hypothèse à moi, hein. Je cite karteum59 : «tous les constructeurs n'adhèrent pas au mode de développement du noyau car pour nombre d'entre eux ça ne vaut pas le coup/coût de se conformer aux exigences de qualité des devs kernel pour faire rentrer leur code dans l'arbre officiel, et donc (au mieux) le bout de code est maintenu sous forme de module externe.» C'est bien de ça dont on parle depuis le début, et c'est pour ceux-là qu'on devrait, selon certains, maintenir une API interne stable.

Moi, j'ai appelé ça «faire de la merde». Et j'ai dit que chacun pouvait appeler ça comme il le souhaitait, y compris : «participer de manière positive et responsable au noyau Linux».

Donc, je maintiens, il faut suivre la conversation plutôt que d'insulter gratuitement.

Ben oui, c'est pas anodin. Exactement comme pour les bibliothèques userspace, sauf que bizarrement, un certain Linus Torvalds se plaint que l'userland ne stabilise pas ses ABI.

L'API/ABI externe du noyau est très stable. On parle des interfaces internes. Faut suivre.

Quant au problème du surcroît de travail, on remarquera quand même que le développement de Linux est abondamment financé de nos jours.

Abondamment ? C'est pour ça que les amateurs sont souvent parmi les premiers contributeurs en nombre. Et après, est-ce que tu préfères que ces financements aillent à de la maintenance qui ne sert à rien excepté pour des constructeurs qui font de la merde, ou aillent dans de nouveaux développements qui amélioreront le noyau ?

Ce que je n'arrive pas à comprendre, c'est pourquoi la recherche publique continue de dépendre aujourd'hui, avec les moyens de communications qu'on possède, des revues.

Un chercheur a besoins de confronter ses trouvailles au regard de ses pairs. Et pour l'instant, la méthode qu'on a trouvé, c'est d'écrire un bout de papier dans lequel on explique la trouvaille et qui peut être relu par d'autres chercheurs. Le fait que ce processus soit géré par des entreprises privées n'est qu'une anecdote (et historiquement assez récente).

Ce que je voulais dire par là, c'est que ce n'est pas l'éditeur qui rémunère le scientifique pour écrire son article. Du point de vue de l'éditeur, ce travail est bénévole.

Moi je propose qu'on supprime les éditeurs qui sont payés par tous les bouts. Ils ne servent à rien au niveau des publications, les revues sont faites bénévolement par des scientifiques, les articles sont écrits bénévolement par des scientifiques. Ils sont juste là pour prendre une marge, et faire un joli PDF, rien de plus. Ils avaient un rôle à une époque où le papier était roi et où les moyens de communication n'étaient pas aussi développés. Mais à l'heure du numérique, ils ne servent vraiment plus à rien. De nombreuses confs, et pas les plus mauvaises, se sont déjà passés des éditeurs, et ça fonctionne bien, les articles sont en CC-BY-ND, ils sont accessibles directement et tout le monde y gagne. C'est ça le vrai modèle alternatif.

Tu compares des choses pas comparables. Avoir une API/ABI stable dans le noyau Linux, ce n'est pas anodin, parce que si on veut pouvoir continuer à évoluer, il faut maintenir des couches de compatibilités (un peu ce que fait MS), et donc ça veut dire du travail en plus ! Or, ce travail en plus devrait être assumé par des gens qui n'en ont rien à foutre (ceux qui sont impliqués dans le noyau), et pas du tout par ceux qui sont à l'origine de la demande (parce qu'ils ne s'impliquent pas du tout dans le développement du noyau). Bref, on arriverait à une situation complètement ahurissante de mon point de vue. MS et Apple peuvent se permettre ça parce que des gens paient (et chers) pour que ça soit comme ça. Ce n'est pas le cas dans Linux. Je vais faire mon Zenitram de base : si les entreprises qui demandent ça en avaient vraiment besoin, elles se cotiseraient pour payer quelqu'un pour le faire, mais elles ne le font pas.

Non, ce qui est décrit, c'est un constructeur qui ne veut pas être intégré dans le noyau "à cause" des standard de qualité et qui laisse tomber son module. Moi, j'appelle ça "faire de la merde". Mais tu peux appeler ça comme tu veux.

Certains constructeurs font de la merde et donc, le noyau Linux devrait s'adapter à la merde ? C'est moi où ce raisonnement a un problème ?

Problèmes rencontrés pendant le dev :
bibliothèque de jeu ClanLib qui subissait de lourde modifications internes, API instable

Ici, j'ai conseillé SFML parce que je connais bien, que je suis le développement et que la 2.1 est plutôt bien fichu (ça permet de faire du graphique, mais aussi du son et du textes avec gestion des fontes, et du réseau).

le moteur physique a été codé à partir de nos cours de physique au lycée : le moteur était plutôt bancal, instable et bogué

Pour des jeux où la physique compte beaucoup, je conseille Box2D (et je pense que Wormux fait partie de ces jeux là). Mais pour l'exemple que je donne, il n'y a pas beaucoup de physique et des trucs bien maîtrisés donc ça vaut le coup de refaire un bout de code pour ça.

le réseau est arrivé très tard dans le jeu et fonctionnait mal sur Internet (bien en local avec une très faible latence)

Ça, j'ai prévenu tous les groupes dès le départ. Le réseau, ce n'est pas quelque chose qu'on ajoute après avoir fait un jeu solo. Et je pense qu'inconsciemment, j'avais Wormux en tête parce que je me souviens avoir lu au cours des news sur LinuxFR la difficulté à faire ce travail d'ajout. Donc tous les jeux solos resteront solo et les jeux réseaux le sont dès le départ. Et je les ai prévenu que le réseau, c'était pas facile, surtout quand on veut faire du temps-réel (ce qui est le cas pour tous les groupes).

on a passé une grosse partie du temps à s'occuper des aspects qui n'ont pas de lien avec le jeu directement : pile graphique, réseau, entrées-sorties, etc.

Est-ce que ça ne dépend pas des libs utilisées ? Avec SFML où tout est intégré, et où les interfaces sont très simples à utiliser, j'espère que ça se passera bien et qu'on pourra se concentrer sur les aspects importants. Mes expériences avec des projets semestriels utilisant SFML me donnent plutôt confiance sur ces aspects.

Il y a 10 ans, les bibliothèques de jeu n'était pas bien packagé sous Linux, les pilotes graphiques libres était très lents, et une nouvelle version mettait plusieurs mois à être disponible dans les distributions Linux. La distribution était un gros problème.

10 ans après, c'est guère mieux. Bon, on a des pilotes libres qui sont tout à fait convenables pour les jeux développés dans le cadre du club. Mais niveau libs, c'est quand même pas la joie parfois. Quand j'ai commencé Akagoria, dans Debian, Box2D était packagé comme un cochon (changement du nom de la lib par rapport au reste du monde !) et SFML en était encore à la version 1.6 alors que la 2.1 était sorti depuis un moment quand même. Donc, au départ, je compilais tout ça à la main. Depuis, ça s'est amélioré, les packages sont maintenant présents, mais seront-ils maintenus ? Rien n'est moins sûr. Les jeux, c'est vraiment le parent pauvre des distributions malheureusement.

Je pensais aux codes correcteurs mais effectivement, ça va un peu plus loin. En tout cas, ça n'a rien à voir avec «programmation» ou «développement»

Codage, ça existe, mais c'est des maths, pas (trop) de l'informatique ;)

C'est triste ton avis sur GNOME

Quand tu dois corriger plein de TP, tu leur apprends très vite à indenter correctement et tu inclues ça dans la notation !