rewind a écrit 3416 commentaires

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 !

C'est justement ce que je conteste. La notion de type est une notion technique induite par la manière dont l'ordinateur stocke les données et par l'utilisation que tu peux en faire.

Malheureusement, on ne code pas encore sur des pizzas mais sur des ordinateurs, donc savoir ce qu'est capable de faire un ordinateur pour lui donner les bonnes instructions, c'est ça la programmation.

Pour un débutant, il pourrait n'exister que deux types de données : les nombres et les chaines de caractères.

Je vais te donner un problème simple : tu as un tonneau de x litres et des bouteilles de y litres, combien de bouteilles te faut-il pour vider le tonneau ? Et bien si tu ne sais pas si ton nombre est un entier ou un flottant, tu pourrais très bien ne pas savoir résoudre ce problème.

Il ne faut pas prendre le débutant pour un débile.

Ce n'est pas mon cas, moi je veux lui apprendre les types et la manière de les choisir pour résoudre un problème, pas lui faire croire que tout est pareil et que l'ordinateur va bien se débrouiller pour comprendre ce qu'il a voulu dire. Il y a un exercice classique qu'on donne en première année, c'est la calculatrice : il faut rentrer deux nombres (donc deux variables, mettons a et b) et un opérateur (qu'on stocke dans un caractère qu'on appelle op). Et bien c'est généralement là qu'on voit ceux qui ont compris et ceux qui restent à «l'ordinateur doit comprendre ce que je lui dit». Ces derniers écrivent : res = a op b qui n'a absolument aucun sens. Et qui est du même acabit que 4 + "4" à mon avis. Et souvent, même quand on leur a expliqué, ils ont du mal à comprendre pourquoi ça ne marche pas.

C'est pareil que pour la différence entre un int et un float ; la différence n'existe qu'à cause d'une contrainte technique.

Absolument pas. Voir mon problème simple ci-dessus avec les bouteilles. C'est fondamentalement différent, même sans aller jusqu'à parler des limites des entiers ou des floats.

Mais je vois ça comme un défaut inhérent à la formalisation d'un programme, ça n'est pas intuitif, et ça n'est pas important pour comprendre la logique d'un programme.

J'insiste, un programme, ce n'est pas qu'une «logique», c'est également un choix adéquat de types et de structures de données et ce n'est pas une nouveauté !

À mon avis, l'intérêt du typage fort ne saute aux yeux qu'après des années à avoir expérimenté les bugs dus aux ambiguités du typage faible.

Ce ne sont pas des ambiguïtés, c'est une manière erronée d'apprendre les choses. Ça va beaucoup mieux dans le sens inverse : quand on a compris les types, on sait mieux utiliser les langages faiblement typés.

"C'est compliqué et ça vous gêne maintenant, mais vous verrez plus tard que c'est important" est un argument très faible ; c'est un argument d'autorité, souvent d'ailleurs employé pour justifier une pédagogie archaïque

Premièrement, ce n'est pas compliqué, c'est même plutôt naturel. Deuxièmement, ça a des applications très concrètes et très rapidement, aucun argument d'autorité derrière. On peut montrer que c'est utile (et j'ai donné deux exemples qui montrent que ça a du sens comparé à une approche trop empirique !) et que ça ne gêne personne, au contraire, ça permet d'avoir une meilleure maîtrise de ce qu'on fait.

Plus il y a de choses intuitives et plus l'élève va pouvoir se concentrer sur les aspects logiques du code. Les aspects techniques, il les apprendra plus tard.

La notion de type est très très loin d'être une notion technique. De nos jours, on a pris conscience que les données sont tout aussi importante que le code qui les manipule. Bien choisir comment représenter ses données, ça fait partie de l'apprentissage de la programmation. Pour moi, apprendre uniquement des structures de contrôles et faire l'impasse sur les types, c'est faire la moitié du boulot. Dans mon univ, on donne un quantité impressionnante d'exercice en première année dans lesquels le choix du bon type est importante pour la résolution du problème. Et je ne parle même pas de structure là, juste entier/flottant/booléen/caractère.

Je pense que si la différence entre les deux n'est pas visible, c'est d'une part (comme dit plus haut) parce qu'il y a les appels SDL qui prennent beaucoup de temps, et d'autre part, parce que tes composants sont petits et peu nombreux, ce qui fait que même avec le layout "array of struct", tu as une bonne localité des données. Il faudrait faire le même test avec des données plus grosses et je pense qu'on verrait la différence. J'essaierai de bricoler un truc si je trouve du temps.

Dernier point, ton benchmark étant simple, il omet une des difficultés (à mon goût) des E/S : comment stocker de manière efficaces des composants pour N entités sachant que les entités n'ont pas toutes les mêmes composants.

Il doit mal expliquer mais en fait, c'est exactement ce qu'il fait : comparer comment stocker les entités. Avec deux variantes : "struct of array" et "array of struct".

(dans mon cas j'ai choisis après divers test : une entité représente un index, et les composants sont stockés dans des std::vector. Ça permet d'améliorer l'utilisation du cache pour l'opération la plus couteuse : la maj des systèmes)

Dans son cas, ce sont aussi des vector. Et toutes les entités ont potentiellement tous les composants (d'après ce que j'en ai compris).

Il compare le layout "struct of array" vs "array of struct" pour voir quelle est le meilleur en terme de performance.

Le conteneur peut être une hashmap ou un arbre.

Localité des données et arbre (ou hashmap) ne font pas bon ménage (vu que c'est bourré d'indirections). Ou alors, il y a un truc que je n'ai pas compris.

Moi, avec mes PDF (beamer), je les gonfle car il ne peuvent pas faire copier coller ;-)

C'est une de mes features préférées de beamer face à PowerPoint !

En fait, tu prends les chiffres qui t'arrangent pour servir un propos qui t'arrange. Mais le fait est là : il est possible de se faire beaucoup d'argent en dehors des États-Unis (ce qui invalide ton propos). Je peux prendre un exemple européen si tu veux. Volkswagen par exemple ne vend pas énormément de voiture aux États-Unis, n'est pas un monopole, et pourtant, pareil, dans le top 10 mondial pour le CA. Mais c'est sans doute pas pareil non plus.

Sinon, les réserves de changes de la Chine, c'est en roubles, c'est ça?

Depuis longtemps, la Chine essaie de diversifier ses réserves pour ne plus dépendre du dollar.

Tu parles de PIB là, donc uniquement d'économie. En quoi tout ce que tu dis a un quelconque rapport ? La zone européenne est intégré économiquement, donc ça a un sens de la considérer comme une unité, même si ce n'est pas un pays.

Connaîs-tu les entreprises Sinopec, China National Petroleum Corporation ou State Grid Corporation ? Pourtant, elles font partie des 10 plus grandes entreprises au monde (en terme de CA) et elles ne sont absolument pas implantés aux US. Ce sont des entreprises chinoises. Le monde n'est plus centré autour des US. Il se passe plein de chose ailleurs qui font que les US sont en train de perdre leur leaderchip. Comme par exemple l'accord entre la Chine et la Russie pour ne plus utiliser le dollar pour leurs échanges, l'accord entre les BRICS pour avoir un équivalent de la Banque Mondiale et du FMI mais sans utiliser le dollar, etc. Ton américanisme béat n'y changera rien, le monde évolue.

L'UE est une région fortement intégré économiquement, qui partage (pour une bonne part) la même monnaie et dont les principales décisions économiques (puisqu'on parle de PIB) sont coordonnées à la Commission. Certes, ce n'est pas un pays, mais il faut être sacrément de mauvaise foi pour continuer à comparer des trucs pas comparables et refuser de comparer ce qu'on peut comparer parce que sinon ça risque de fâcher l'Oncle Sam.

C'est une blague… Tu prends une entreprise américaine, normal qu'elle fasse un gros chiffre dans son pays. Prend une grosse entreprise française, tu vas voir, elle fait aussi au moins 50% de son chiffre en France. Et tu peux faire pareil avec chaque leader industriel de chaque pays. Ton exemple n'a pas de sens.