rewind a écrit 3416 commentaires

Licence qui n'aurait jamais du être cessible

Depuis la loi du 1er octobre 2014 (article 6), ce n'est plus le cas. Mais ça ne concerne que les nouvelles licences délivrées.

Ne mélangeons pas tout, le cas des taxis est assez complexe. Les taxis ont raison de gueuler : ils paient une licence très chères (plus que le prix de leur voiture) pour avoir le droit d'exercer un métier et à côté, il y a des gens qui font quasiment le même métier sans avoir besoin de payer une licence. De là, il y a deux possibilités : soit tout le monde paie une licence, soit on rachète les licences des taxis (mais qui et à quelle valeur ?). Dans les deux cas, ça va augmenter le nombre des taxis et donc ça va faire baisser les revenus par taxi. On va se retrouver avec des chauffeurs de taxis obligés de faire beaucoup d'heures pour avoir de quoi vivre dignement. Vous avez envie, vous, d'être emmené par un chauffeur de taxi qui aura déjà travaillé pendant 12 heures d'affilée ? S'il existe des professions régulées, c'est qu'il y a une bonne raison de les réguler, la concurrence libre et non-faussée ne résout pas tous les problèmes magiquement. Et sur le dossier des taxis, je pense que la concurrence tuera la qualité et la sécurité du service.

Ce n'est pas de l'aveuglement, personne ne prétend que C++ est parfait, loin de là. Mais sur les exemples données, les erreurs sont facilement détectables, y compris à la compilation.

Si je reprends certains des exemples :

Sur le premier, clang me sort l'erreur suivante (en gras) :

error: invalid operands to binary expression ('std::vector<int, std::allocator<int> >' and 'int')
    { return *__it == _M_value; }

Je veux dire, c'est difficile d'être plus clair, on ne peut pas comparer un vector et un int.

D'autant plus que son exemple C++ est moisi. Je propose plutôt ça comme exemple comparable :

#include <algorithm>
#include <vector>

struct Foo {
  int i;
};

int main() {
  std::vector<Foo> foo;
  std::sort(foo.begin(), foo.end());
}

Et là, clang sort une erreur en gras :

error: invalid operands to binary expression ('Foo' and 'Foo')
    { return *__it < __val; }

Là, encore, c'est marqué, on ne peut pas comparer des Foo avec des Foo, bref comme Rust en gros. Et ces diagnostics vont s'améliorer dans la prochaine itération de C++ avec les concepts qui arrivent.

Sur la variable non-initialisée, ça fait très longtemps que GCC renvoie des warnings. Et sur l'exemple en question, il renvoie :

warning: ‘currmin’ may be used uninitialized in this function

Bref, comme Rust.

Sur l'exemple du switch, je trouve que c'est là qu'on atteint la mauvaise foi totale. Il ne respecte même pas la sémantique du langage. S'il faut un break, on met un break. Je ne vais pas décider dans mon coin tout seul que c'est con cette histoire de break et monter un exemple idiot comme ça où je montre que ce que je veux ne marche pas. Ben oui, ça pourrait difficilement être autrement. Surtout que son exemple provoque un warning :

warning: enumeration value 'UNKNOWN' not handled in switch

Sur l'exemple du for avec le point-virgule, pareil, on a un joli warning :

warning: for loop has empty body

Bref, dans ces quatre cas (sur dix), un compilateur C++ décent prévient l'utilisateur d'une erreur ou d'un risque d'erreur. Ça réduit son argumentation de 40%.

Je pourrais parler du constructeur par copie implicite où, si on fait un code isomorphe à celui de Rust, on utilise unique_ptr ou shared_ptr et pas besoin d'implémenter quoi que ce soit hormis le constructeur, tous les trucs par défaut fonctionneront sans problème, avec une sémantique claire. Parce que là, le code en Rust, on a du mal à voir sa sémantique : ça compile, ça fonctionne sans erreur, mais qu'y a-t-il dans a et dans _b à la sortie, je ne saurais le dire.

Le principal reproche qu'on peut faire de cet article c'est qu'il ne dis pas clairement que la comparaison est sous l'angle de la fiabilité des 2 langages.

Je ne le dirais pas comme ça. Sur le fond, sa comparaison est parfaitement idiote vu qu'il compare des choses pas vraiment comparables, sur tous les aspects. Mais ce qui importe, ce n'est pas ça, c'est que l'intention de l'auteur est de montrer à tous les dev C++ que le Rust c'est mieux et c'est fait pour eux, qu'ils auront une meilleure productivité et que leur vie sera plus belle. Mais je pense qu'avec ce genre de comparaison complètement farfelue, il se goure complètement. Parce qu'un dev C++ expérimenté, il ne fait pas ces erreurs débiles, ou il les détecte très rapidement (pour certaines de ces erreurs, il y a des warning, comme les variables non-initialisées).

Une comparaison rapide de Rust et C++ si vous êtes pressé

Dans le genre comparaison biaisée, je crois que celle-ci fait très fort. Personne ne code comme ça en C++ en 2014 (puisqu'on compare à un langage de 2014). C'est étouffant de mauvaise foi. J'aurais plutôt intitulé l'article : Comparaison entre Rust et un programmeur C++ d'une semaine qui essaie tous les trucs débiles possibles et imaginables. Oui, C++ permet de se tirer dans le pied, c'est marqué dessus, il n'a jamais prétendu que ce n'était pas possible, au contraire, c'est une feature. Alors à quoi ça sert d'en remettre une couche encore et encore et de comparer des choses pas comparables ?

D'un autre côté, cette news sur SFML est dans l'espace de rédaction depuis mai dernier…

Je suis sans doute allé un peu vite mais bon, ce n'est pas faux de dire que SFML est plus complète que SDL.

Je ne suis pas l'auteur et je ne suis pas impliqué dans le développement, je ne suis qu'un utilisateur. Mais il existe un forum SFML sur lequel tu peux poser ta question. Les dev sont présents et te répondront je pense.

à cause de l'absence de gestion des dépendances

Ok, je m'y mets après Akagoria :P

C et C++ sont si improductif au possible que presque tous les studios doivent lui ajouter un langage de script.

Je dirais plutôt que C/C++ ne sont pas productifs out of the box pour les jeux et qu'il faut développer plein de petits trucs génériques qui servent dans tous les jeux (et qu'on retrouve dans tous les moteurs de jeux).

Dans ce genre de cas, le C est beaucoup mieux. Parce que les cores sont chargés dynamiquement, donc va trouver le nom de la fonction à appeler en C++ avec le mangling ! Sans compter qu'il faut bien connaître l'objet sur lequel appliquer une méthode donc tu es obligé d'avoir au moins une méthode statique (ou une fonction C). Et ça, c'est sans parler du fait que de nombreux cores sont déjà implémentés en C et que je pense qu'ils n'ont pas envie de passer à C++. De toute façon, si l'API version 2 est bien foutu, ça pourra s'intégrer très bien avec du C++ (pour l'instant, ce n'est pas le cas).

Bien tenté, mais j'ai parlé de l'API de Retro (mon wrapper), pas de Libretro

Le nom m'a induit en erreur, mea culpa ! ;)

J'ai vu ce dépôt ARB récement et l'inclusion d'un pointeur utilisateur était un de mes souhaits les plus chers pour une deuxième version de l'API, je suis content d'apprendre que ça viendra, je pourrai alors abandonner mes gros hacks ! =)

Ce n'est pas encore parfait. Pour l'instant, ils l'ont mis en dernière position. Or, il est plus intelligent de le mettre en première position de manière à pouvoir appeler directement une méthode d'un objet plutôt que de transférer l'appel en changeant l'ordre des arguments.

Il y a eu aussi un débat sur ce qui devait faire partie de l'API (donc avec des fonctions ou des callbacks directs) et ce qui devait faire partie d'extensions (donc appelé via la fonction générique retro_environment avec ses multiples constantes). Là dessus je suis assez mitigé.

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.