rewind a écrit 3412 commentaires

Dans l'absolu, je ne suis pas contre payer pour ses études, car le fait de payer implique le consommateur du service.

Non, un étudiant est un usager du service, pas un consommateur, pas un client. D'ailleurs, il ne paie pas pour le service (sinon, il paierait bien plus cher), mais pour s'inscrire. Si on fait payer des milliers d'euros, les usagers vont vraiment se transformer en consommateur/client, mais il ne faudra pas s'étonner des effets de bords.

Houla, que de confusion…

C'est très bien, ça incitera les étudiants à aller à la fac.

Non, parce que cette augmentation des frais d'inscription, c'est également ce qui attends les universités. Depuis la loi LRU, elles ont l'autonomie dans la gestion de la pénurie, et une des seules solutions pour compenser cette pénurie de moyens, c'est d'augmenter les frais d'inscription. On va y venir assez vite, malheureusement.

Les écoles d'ingé sont un vestige de Napoléon qui n'a plus de raison d'être aujourd'hui.

Ça dépend lesquelles. Certaines écoles avaient pour mission de former techniquement les hauts fonctionnaires (je ne parle pas de l'ENA) de manière à ce qu'ils assurent un service public de grande qualité : Ponts et Chaussée, Centrale, Mines, Polytechnique, ENS, etc. De nos jours, on délègue tout au privé donc ça a moins de sens. Mais du coup, on continue de former des ingénieurs de très bonne qualité.

D'ailleurs ça n'existe quasiment pas à l'étranger et c'est incompatible avec le système LMD européen en place depuis plus de 10 ans.

Les écoles délivrent un BAC+5 qui est l'équivalent d'un master. Le seul problème pour nos dirigeants du CAC40 issues de ces grandes écoles, c'est qu'à l'étranger, les dirigeants ont souvent un doctorat, ça pose problème quand ils essaient de se vendre en dehors de la France. C'est pour ça que le ministère a dans ses cartons une sorte de doctorat en VAE qu'on pourrait donner à n'importe qui.

En plus, ça coûte cher

Alignons pas le bas, la bonne idée ! Il faudrait plutôt que des moyens similaires soient mis dans l'université et ça serait top.

ça favorise la dispersion, avec les conséquences que l'on connait sur les classements internationaux des universités.

Alors ça, on s'en fout complètement. Ces classements sont tous biaisés et ne reflètent absolument pas la qualité des formations. Les auteurs du classement de Shangai (puisque c'est le plus connu) reconnaissent eux-mêmes toutes les limites de leur approche.

un prêt étudiant à des taux usuriers et irrévocable en cas de faillite personnelle.

Un adhérent de LREM a trouvé encore mieux que ça ! Il proposait que les prêts soient garantis par l'État. Comme ça, en cas de faillite, les banques retrouvent leur argent. Le document était un bijou d'ultra-libéralisme avec sa dose d'anti-syndicalisme comme il faut.

D'un autre côté, on parle de centraliens. S'ils doivent faire un emprunt, ils devraient pouvoir le rembourser assez vite avec un brut moyen de 52 000 € par an.

C'est exactement l'argument employé aux États-Unis et ailleurs pour justifier tous les frais d'inscription. Et on voit le résultat : la dette étudiante aux États-Unis est abyssale et va péter à la gueule de tout le monde façon subprime.

Quand bien même cet argument serait vérifié, ça avantage qui de devoir rembourser un prêt dès les études finies ? Je veux dire, globalement et socialement parlant, il n'y a que les banques qui y trouvent leur compte. Toujours dans cette hypothèse farfelue, ces gens pourraient contracter un prêt pour s'acheter un logement, une voiture ou que sais-je, mais vu leur niveau d'endettement au départ, ils se retrouvent à devoir attendre avant de pouvoir acquérir un bien onéreux.

Et du coup, est-il plus facile de programmer en gObject (GTK+) qu'en C++ (Qt) ?

Il y a deux questions là. S'il s'agit de comparer uniquement gObject et C++, alors C++ est clairement gagnant, puisqu'en gObject, il faut faire à la main ce qui est fait automatiquement par le compilateur en C++, à savoir le polymorphisme via les vtables. S'il s'agit de comparer GTK+ à Qt, c'est une affaire de goûts et de couleurs. Il existe même Gtkmm qui permet d'utiliser GTK+ en C++.

Ça a l'air d'être un problème de packaging, il faut le signaler à Debian ;)

Je ne connais pas par coeur Go mais son modèle ressemble également à celui d'Erlang. Pourquoi dire que ce sont de vieux modèles de programmation parallèle?

Le modèle de Go est un dérivé de CSP qui date des années 70. Ce modèle a été étudié en continu depuis et est extrêmement bien connu.

Qu'est-ce qui est plus moderne? Aurais-tu des exemples?

Le vol de travail par exemple est un modèle un peu plus récent.

Avoir une garantie de sûreté d'un code threadé avec Rust est un leurre puissant mais qui, au fond, ne sert pas à grand chose. Parce que personne ne devrait lancer un thread directement, tout le monde devrait utiliser un modèle de programmation parallèle. Par exemple, en Go, il y a un modèle de programmation parallèle, certes vieux, certes plein de limites, mais qui fonctionnent et offre des garanties sans avoir à manipuler le moindre thread. Autre exemple, MapReduce qui est un modèle de programmation parallèle (qui ne résout pas tous les problèmes, mais if non plus ne résout pas tous les problèmes séquentiels) où l'utilisateur final n'a pas à se soucie de l'ordonnancement, ça marche. On pourrait aussi parler des futures, du vol de travail, ou de tout un tas d'autres modèles déjà existants et éprouvés et dont on sait comment ça se programme correctement avec des threads.

Le seul qui doit faire attention, c'est celui qui va implémenter le modèle de programmation parallèle par dessus les threads, mais a priori lui il sait ce qu'il fait, il peut tout vérifier de son côté (soit directement, soit à l'aide d'un outil, soit parce que comme Rust le compilateur va lui dire que c'est bon). Mais ça fait quand même peu de monde qui a une réelle utilité de cet outil de mon point de vue.

Pour un premier langage, Python ou Go me semblent plus pertinents

Tu viens de péter mon trollomètre. Dans les universités, les discussions sur les langages de programmation à apprendre à des débutants ressemblent à ça : c'est violent et ça n'avance pas parce que chacun a ses idées préconçues et ses préférences.

Après, ça dépend ce qu'on veut faire avec un premier langage. Si par exemple un des objectifs est d'apprendre les types (types simples puis structurés), je ne suis pas sûr qu'un langage à typage implicite comme Python soit une bonne idée. Choisir le bon type, c'est aussi de la programmation, et ça se fait beaucoup plus facilement si le type est explicite. Après, si on ne s'intéresse qu'aux structures de contrôle, tous les langages partagent à peu près les mêmes à un chouia près.

Mon avis, c'est que le C++ est un bon langage pour débuter. Évidemment, pas tout C++, juste ce qu'il faut pour comprendre les concepts de base. Parmi les avantages que je vois : les entrées/sorties sont «faciles» (même si la syntaxe peut paraître bizarre), et quand on commence, c'est un frein en moins ; les fonctions permettent de passer les arguments par valeur ou par référence au choix, et c'est un des rares langages qui le permettent (avec la famille Pascal/Ada) ; le langage est suffisamment peu verbeux au démarrage (je dis ça parce que dans mon université, on utilise Java comme premier langage et il y a tout un tas de trucs que les étudiants écrivent sans les comprendre «public class Toto { public static …»). Sans même utiliser la bibliothèque standard (sauf les entrées/sorties), on peut faire un cours pour débutant sans aucun problème et voir tout ce qu'il y a à voir pour commencer (structures de contrôle, types, fonctions).

Qu'il y ait des petits studios qui utilisent Rust, oui, pourquoi pas. On peut aussi en trouver qui le font en D, en Go, ou en Pascal je suis sûr. Ça n'est pas vraiment un indicateur. Tous les gros studios restent encore en C++, ça c'est un indicateur.

Sinon, que veut dire le modèle mémoire va venir se mettre en travers des développeurs ?

Qu'on ne peut pas faire de trucs «sales» en Rust. Je mets «sale» entre guillemet parce que ce n'est pas vraiment le bon terme. Je dirais plutôt qu'en dehors de ce qui est prévu par le langage (avec toutes les vérifications), on ne peut rien faire (sinon il ne peut plus vérifier et on perd l'intérêt du langage). Par exemple, dans certains jeux, il existe des allocateurs qui permettent d'allouer de la mémoire qui sera utilisée uniquement dans la construction de la frame courante, donc on peut désallouer tout d'un seul coup à la fin de la construction (voir ici pour les explications). L'avantage, c'est que l'allocation et surtout la désallocation sont très rapides. Faire ça en Rust, je demande à voir.

Dire qu'on va faire qqch et dire qu'on l'a déjà fait, ce n'est pas pareil. J'attends de voir un jeu complet et fini avec Rust et avoir le retour d'expérience.

Dans beaucoup de jeu, la gestion de la mémoire est un composant critique qui est optimisé pour différents usages. Avec Rust, je pense qu'on n'a pas le choix, le modèle mémoire va venir se mettre en travers des développeurs à un moment donné et là, il n'y aura aucune solution.

Franchement, ça se tente en game jam ce genre d'idées. Tu mets des licornes et c'est bon, tu as le jeu de l'année.

C'est une idée intéressante mais ça serait un autre jeu.

C'est bien dans l'esprit du jeu. Je prends note ;)

Le sadisme dans le jeu de rôles, ça se travaille.

Je rappelle que l'héroïne du jeu est une sorcière maléfique qui recherche son pouvoir perdu, donc a priori, elle va déjà faire de la merde tout au long du jeu (les quêtes annexes, ça ne sera pas pour sauver des chatons mais plutôt pour empoisonner des chatons).

Tu pourrais même faire en sorte qu'il soit possible de jouer des parties purement pacifistes — c'est pas courant, mais il existe déjà des RPG dans lesquels c'est possible :)

Purement pacifiste, ça me paraît compliqué. Mais disons que pour la plupart des combats, il faudra les provoquer plutôt que les subir. Genre tu traverses une forêt, il y a des monstres, normal, mais ils n'attaqueront pas forcément si tu restes sur le chemin, tandis que si tu prends le raccourci en hors piste, là ce n'est plus pareil, c'est la baston qui se profile.

Sinon, j'envisage aussi qu'on puisse attaquer et tuer n'importe qui, même éventuellement des PNJ cruciaux pour la quête principale. Bon, la plupart du temps, ça ne sera pas un bon calcul, parce que les PNJ seront forts ou alors qu'il y aura des gardes bien puissants, etc. Et dans le cas où un PNJ crucial meurt, il y aura une quête annexe pour fabriquer un parchemin de résurrection et donc, être capable de continuer la quête principale.

Ceci dit, c'est daté, de nouvelles idées depuis ?

Pas vraiment d'idées révolutionnaires. J'ai quelques idées que j'aimerais tester mais rien de bien concret pour l'instant. Il faudrait que je mette à jour ce document.

Concernant le combat, temps-réel, le but est-il a priori de faire un système qui encourage de faire pause pour prévoir son prochain sort (style baldur's gate et compagnie, mais avec un seul personnage) ou bien style hack and slash et privilégiant l'action (à la diablo, flare, etc.) ?

J'aurais envie de dire : ni l'un, ni l'autre mais plutôt le second si je dois choisir. J'aime beaucoup le style de combat de FF12 où les combats s'intègrent dans l'exploration (et surtout, peuvent être entièrement automatisé mais ça, c'est une autre histoire). De manière générale, dans les RPG, je ne suis pas un super fan de la partie combat, je les fais parce que c'est un passage obligé mais ça m'ennuie. Je préfère l'exploration, les quêtes, la recherche. Donc, du combat, il y en aura, ça ne sera pas le cœur du gameplay.

Je peux emporter 80 pièces.

ATTENTION SPOILER ! ATTENTION SPOILER ! ATTENTION SPOILER !

Au départ, je sépare en trois tas de 27 pièces et je pèse les deux premiers tas. S'ils ont la même masse, c'est que la pièce plus lourde se situe dans le dernier tas. Si un des deux est plus lourd, la pièce plus lourde se situe dans le tas le plus lourd. Dans tous les cas, j'ai identifié un unique tas de 27 pièces qui contient la pièce plus lourde (j'ai donc déjà 54 pièces).

Je recommence à nouveau en séparant mes 27 pièces en trois tas de 9 pièces et je pèse les deux premiers tas. De la même manière, je peux identifier le tas de 9 pièces qui contient la pièce plus lourde. Je recommence en séparant les 9 pièces restantes en trois tas de 3 pièces. Puis idem que précédemment. Et enfin, je sépare le dernier tas de 3 pièces en trois et j'en pèse deux. J'ai ainsi pu identifié la pièce plus lourde et je peux emporter les 80 pièces restantes.

De rien ;)

L'IA, ça peut recouper plusieurs choses. De mon point de vue, il y a tout d'abord tout un tas de trucs bien déterministes, comme alpha-bêta, avec lesquels je n'ai pas de problèmes, c'est juste de l'algorithmique bien pensée.

D'un autre côté, il y a en revanche, tout un tas de trucs qui se rapprochent plus de méta-heuristiques (réseaux de neurones par exemple) qui donnent certes des résultats impressionnants mais qui restent des heuristiques : on ne sait pas trop pourquoi et comment ça marche mais ça marche. La hype est de ce côté là en ce moment et c'est problématique, parce qu'on fait croire qu'une méta-heuristique peut traiter n'importe quel problème et le résoudre de manière «intelligente» (et quand je dis «on», je ne parle pas de tous les chercheurs sérieux du domaine). C'est rapprocher l'informatique d'une sorte de magie, c'est très malsain. Une heuristique, ça peut aussi ne pas marcher sur certains cas.

D’après moi on peut conclure aussi bien « oui » que « non » …

Après avoir fait quelques recherches de mon côté, j'en suis arrivé grosso modo aux mêmes conclusions. La seule chose qui soit complètement impossible en l'état, c'est du HTTPS-Only (c'est-à-dire sans même le port 80 ouvert). Alors que si le HTTP est ouvert et redirige vers le HTTPS, ça a l'air de passer.

(Cela dit, chez moi, pour être sûr de ne pas avoir de soucis y compris en cas de changement de comportement de l’implémentation de Let’s Encrypt je préfère continuer à tout rediriger sur le port 443 sauf les requêtes pour .well-known/acme-challenge/.)

Je vais essayer en redirigeant tout et voir ce que ça donne dans quelques mois ;)

Une remarque et une question.

La remarque : pour mettre en place HSTS, c'est assez simple. Mozilla fournit un super outil pour configurer son serveur web préféré avec ses versions installées. Ça prend en charge HSTS directement. Et avec ça, on a un beau A+ chez SSL Labs. Je pense qu'il serait aussi intéressant d'ajouter une entrée DNS CAA. C'est assez simple et ça assure un peu plus la sécurité.

La question : je pensais que pour le renouvellement des certificats Let's Encrypt, il était nécessaire de conserver le http (pour les challenges), apparemment ce n'est pas le cas. Est-ce moi qui me suis trompé ?

Tu peux ajouter build2 à ta liste.

Le logiciel libre, entendu comme 4 libertés, prospère dans les piles logicielles éloignées de l'utilisateur final, mais peine à s'imposer dans les logiciels plus proches de l'utilisateur final.

Firefox, Chromium, VLC, LibreOffice ?

Dans mon idée, cette fonctionnalité sert surtout pour les systèmes où l'installation est… chaotique. Sur un système Unix, tout est bien rangé donc on sait où on va retrouver ses assets. Mais sur un Windows, c'est plus compliqué et mettre tout dans le même répertoire est une solution à peu près correcte. Mais ça implique de savoir où se trouve le binaire.

Je ne savais pas que sur certains systèmes, cette fonctionnalité étaient absente.

Super !

Moi ce qui me chagrine là dedans, c'est le vide après «Base path». Mais bon, sur un système Unix, ce n'est pas très grave.

Dans gf, la portabilité est assurée par SDL et Boost. Ils font le travail et après, je n'ai plus qu'à utiliser le résultat ;) J'oubliais OpenGL aussi. Ce qui fait que dans gf, je n'ai aucun code spécifique à une plateforme particulière. Et je suis très satisfait de savoir que sous OpenBSD, ça compile et ça fonctionne correctement.

Tiens, d'ailleurs, si tu pouvais faire un petit gf_info et me coller le résultat histoire que j'enrichisse mes stats. Ce n'est pas obligatoire, ça donne des informations sur ton système (notamment les versions utilisées pour compiler), mais ça m'aidera à voir l'étendue des configurations possibles.