- > Construire une communauté en tant que service : comment cesser de souffrir « ce code est censé être forké ».+ > Construire une communauté en tant que service : comment cesser de souffrir de « ce code est censé être forké ».
- Je serai le conférencier. C’est en anglais et mon accent français va piquer un peu. =)+ Je serai le conférencier, [la diffusion en direct est ici](https://mdco2.mini.debconf.org/schedule/venue/3/). C’est en anglais et mon accent français va piquer un peu. =)
Ça me fait bizarre à lire vos commentaires (celui-ci, ceux d’autres personnes à d’autres occasions)… Depuis que j’ai un téléphone Android (6 ou 7 ans peut-être ?), je ne crois pas avoir utilisé autre chose que Firefox sur mon téléphone, que ce soit d’abord via F-droid, ou mainline ensuite, et je n’ai jamais eu de problème, à part peut-être quelque crashs dans le passées alors que j’avais des centaines d’onglets et que c’est trop pour la mémoire du téléphone mais j’aurai du mal à l’attribuer entièrement à Firefox et même ça ils semblent l’avoir corrigé… C’est à dire que dans mon expérience, les dernières versions de Firefox sont meilleures, plus stables, plus robustes à un point que ça semble relever de la magie (il est utilisable comme s’il en avait que faire des limites matérielles)… En fait question performance et utilisabilité j’ai vraiment vu le jour et la nuit entre la version classique de Firefox et leur nouvelle version, wow, je ne pensais pas qu’aussi bien ce soit possible.
Et euh… ergonomie étrange, bon j’ai un biais vu que je n’utilise que ça¹, mais elle marche très bien et surtout elle m’étonne parfois de ce qu’elle permet aussi simplement toutes les multiples fonctionnalités du navigateur. De plus, à chaque fois que j’encourage quelqu’un à passer à Firefox sur son mobile (avec un antipub), et ça inclut du public pas du tout technicien, ça se passe toujours très bien. Question ergonomie, vous ne seriez pas en train de regretter que Firefox ne soit pas Chrome, en fait ?
¹ en vrai, à chaque fois que j’utilise un autre navigateur sur le téléphone d’un autre, je souffre tellement les fonctionnalités sont médiocres et que les interfaces (je parle pas de l’apparence, mais de la façon dont on interagit) sont limitées autour du minimal « consomme, clique, consomme » qui ne prévoit pas que ce soit vraiment moi qui navigue sur le web. Le fait que je navigue sur le web implique une navigation non-linéaire et non un éternel tunnel de micro-paiement : ouvrir plusieurs onglets, revenir, en fermer quelques uns, passer de l’un à l’autre, explorer une branche, basculer sur une autre branche…
ce commentaire est sous licence cc by 4 et précédentes
Pour la licence du Windows, effectivement comme tu l’as remarqué, une fois que tu l’as aspirée, tu peux techniquement la réutiliser ailleurs, ça inclut une machine virtuelle sur l’ordinateur d’origine, bon par contre obtenir une 3D fonctionnelle pour le jeu voulu dans la machine virtuelle est encore une autre aventure.
Pour la xboite et vu que tu y trouves un intérêt comme remplaçant du lecteur DVD du salon, tu pourrais toujours aller faire un tour du côté de Kodi qu’on ne présente plus mais que je présente quand même car à son origine, ce XB* Media Center^WXBMC^WKodi a pris naissance comme un logiciel tournant sous Linux sur la toute première Xbox et ce dans le dos de Microsoft, dans le dos de Microsoft à la fois pour Linux et XBMC. Kodi est normalement disponible pour ta Xboite toute neuve, et tu pourras ainsi te servir une tranche de sentiment revanchard à pas cher et justifier via le mécanisme de rétribution narcissique d’autres actions moins avouables (microtransations, DLC ?). Bon, en terme de rebellitude, tu n’iras pas bien loin : XBMC^WKodi est désormais officiellement distribué dans le catalogue de Microsoft en s’appliquant à faire toutes les courbettes requises.
Au final, j’y vois une certaine conclusion à ton journal : Windows est tellement peu compatible avec le matériel disponible du marché (y compris celui sur lequel il était livré initialement) que le moyen le plus simple de l’utiliser est d’acheter un appareil dédié conçu spécialement pour lui, une sorte d’émulateur matériel en fait.
ce commentaire est sous licence cc by 4 et précédentes
En fait le concept fondamental c’est que ce qui est gratuit est déjà payé. Le payeur peut être celui qui va te manger à la fin (le schéma GAFAM/publicitaire/etc.), ou bien le payeur est tout simplement celui qui a besoin pour lui-même de quelque chose que tu peux faire. La grande question du financement du logiciel libre est de faire se rencontrer le payeur et le faiseur. Le bénévolat c’est quand le payeur est le faiseur (le bénévolat étant la première des subventions).
ce commentaire est sous licence cc by 4 et précédentes
Attention pour le x220t, je ne sais pas pour le x220t, mais le x61t existait en deux exemplaires: avec écran utilisable au stylet uniquement, avec écran utilisable au stylet et au doigt, ma sœur avait le premier, j’avais le second modèle. Pour le clavier virtuel le doigt c’est vraiment plus pratique. Vérifie donc bien ce que fait le x220t si tu en achetais un.
Pour rester dans le sujet de la connaissance utile à partager, pour la reconnaissance d’écriture je connaissais CellWriter:
C’est de la reconnaissance à l’ancienne où il faut entrainer le logiciel et écrire les lettres dans des cases. En vrai je n’en ai jamais eu besoin moi non-plus. Mais c’est bon de savoir vers qui se tourner au cas où…
À noter qu’avec le stylet j’ai parfois retranscrit des partitions dans MuseScores (pas en dessinant… en sélectionnant les symboles dans la barre d’outil, comme on ferait à la souris), ça marchottait suffisamment à l’époque pour que je produise des choses.
ce commentaire est sous licence cc by 4 et précédentes
Pour l’écriture manuscrite n’ayant pas besoin d’être reconnue, Xournal++.
J’ai utilisé Xournal pendant très longtemps, dans les années 2010 j’avais un Thinkpad X61 Tablet (avec tablette Wacom intégrée à l’écran) et j’ai écrit des tas de lettres manuscrites sur Xournal. J’ai découvert récemment l’existence de l’itération Xournal++ à l’occasion d’une dépêche sur OpenBoard, qui bien que soit un logiciel de tableau blanc, ressemble furieusement à Xournal(++).
Avec Xournal++ tu peux non seulement prendre des notes manuscrites, mais aussi gribouiller au dessus d’un PDF comme tu ferais avec un vrai papier, ou simplement remplir un formulaire qui n’est pas éditable, etc.
Bon par contre ça ne répond pas à ta question de la prise en charge du matériel de saisie : stylet, etc.
Côté clavier virtuel, il me semble que celui de GNOME Shell est efficace et bien intégré.
Voilà, juste pour l’exercice j’écris cette phrase avec le clavier virtuel de GNOME Shell (un détail, pour les caractères spéciaux ce n’est pas presser-glisser mais presser-cliquer, ce qui ne me semble pas gênant). Le bouton pour l’activer définitivement est dans le menu accessibilité en haut à droite, en deux clics depuis un bureau standard.
ce commentaire est sous licence cc by 4 et précédentes
c'est pas un peu comme préparer les papiers du divorce en plein mariage ?
Ben justement, ils ne semblent pas vouloir que ce soit un mariage. C’est pas courant de se marier avec le propriétaire de son logement quand on est locataire… À mes yeux c’est plutôt l’espèce de concubinage généralisé et pas vraiment discerné qui semble être la norme sur GitHub qui devrait questionner.
ce commentaire est sous licence cc by 4 et précédentes
On dirait que tu dis ça comme si ça contredisait mon commentaire.
Comparer une twingo avec une 206 ce n’est pas problématique. Comparer la voiture, la caisse et le siège c’est problématique.
Pour celui qui fabrique la caisse ou le siège, la spécifications pour la caisse ou le siège couvrent l’ensemble du besoin. À son niveau, une caisse ou un siège c’est un ensemble cohérent. Pour celui qui assemble la voiture, sa spécification contient la caisse en question et le siège en question.
Bien sûr que le siège est lié à la caisse.
À aucun moment tu ne me contredis. Je rappelle simplement qu’il est possible de concevoir une spécification qui repose sur une autre spécification pour décrire le format des champs, et d’autres spécifications pour décrire tel ou tel type de donnée. On ne compare pas un format comme SQLite à CSV ou ASCII Delimited Text. Là si quelqu’un compare SQLite à CSV ou ASCII Delimited Text, il va avoir des problèmes. CSV ou ASCII Delimited Text c’est le format pour les champs, pas l’ensemble.
À ce que je sache, ni JSON, ni YAML, ni XML ne redéfinissent les standards pour formater les caractères, ils reposent sur des standards établi. Quand XML réutilise base64 pour stockent les blob, la spécification XML repose précisément sur une autre spécification. Idem pour les autres formats qui reposeraient sur uuencode pour les blobs. J’avais cité les dates au format ISO 8601, c’est normal pour une spécification de se reposer dessus.
Tu peux très bien faire face à une spécification qui repose sur UTF-8, ASCII Delimited Text, base64 et ISO 8601 et d’autres trucs de ce genre. La comparaison avec une spécification riche ne se portera pas sur ASCII Delimited Text uniquement, ce ne serait pas juste. Bon, même si on sera sûrement d’accord sur le fait qu’il est peut-être dommage de réinventer la roue alors que d’autres ont travaillé dur sur tous les cas particuliers auxquels on ne pense pas.
Ce fil de discussion tourne autour d’un problème de partie et de tout. Qu’au moins les comparaisons soient faites avec ce qui est comparable !
ce commentaire est sous licence cc by 4 et précédentes
Ce qui doit te manquer pour comprendre mon commentaire est qu’il y a eu toute une polémique sur le fait que sur la base de ce que la spécification JSON définit un objet comme “an unordered set of name/value pairs”, certains développeurs significatifs de bibliothèque JSON qui faisait référence refusaient catégoriquement et ce pendant de très longues années de considérer l’implémentation optionnelle de la conservation de l’ordre, et c’était une forme d’obstruction puisque c’était une opposition par principe au concept même, et pas simplement un argument du genre « faites-le vous-même, moi je ne perdrai pas de temps là-dessus ». Ça a été un sérieux obstacle au choix d’utiliser le format JSON ou au choix d’utiliser telle bibliothèque qui fait référence. Personnellement j’ai fait face au problème quand j’ai eu besoin de stocker dans des dépôts versionnés des données générées par des outils que j’écrivais. C’est pour ça qu’historiquement mes outils ne génèrent pas du JSON. Je ne sais pas où ça en est, je pourrai reconsidérer la chose. Tout ça est loin dans mes souvenirs je ne sais pas comment retrouver de lien sur le sujet, mais toujours est-il que mes outils en gardent la trace et que ça a donc marqué durablement mes projets et que tant que ces projets vivront, ils témoigneront de ces temps troublés par une cicatrice toujours visible.
Un tel argumentaire suppose que le JSON généré par un logiciel est immédiatement lu par un autre logiciel, et que puisque le second logiciel ne doit pas supposer d’ordre pour fonctionner, le besoin d’implémenter un ordre à la génération du json serait en fait le témoin d’un problème de conception dans le logiciel qui parse.
Mais ça c’est un cas typique de courte-vue et d’assomption fausse sur le fait que les gens n’auront que ce besoin et strictement que ce besoin. Dans la vraie vie les gens développent des tas de besoins dont certains sont tout à fait honorables, comme le fait de stocker des données sérialisées dans un dépôt versionné.
Ce qui est amusant c’est qu’avec la spécification Vulkan est fournit un fichier JSON qui est utilisé pour faire de la validation. Comme toute spécification versionnée, c’est typiquement le genre de fichier qu’on peut vouloir stocker dans un dépôt versionné, et bien que la spécification JSON permette le désordre, conserver l’ordre simplifie vraiment les choses pour les gens, par pour l’outil de validation qui n’en a rien à faire de l’ordre, mais pour les gens, typiquement pour comparer deux commits tu n’aurais pas besoin d’outil dédié. N’en déplaise à ceux qui se cachent derrière la spécification de JSON elle-même pour supposer que ce besoin n’existe pas.
La spec json n’interdît pas de trier les clés de façon déterministe, ni de conserver l’ordre des clés entre une lecture et une écriture.
Exactement, c’est pour cela que faire de l’obstruction sur un besoin qui ne contredit pas la spécification est… surprenant.
ce commentaire est sous licence cc by 4 et précédentes
Tu peux commencer par lancer Caja en anglais pour savoir comment le message d’erreur est écrit en anglais, tapes ceci dans un terminal:
killall caja
LANGUAGE=C.UTF-8 caja
Note: killall est fourni par le paquet psmisc si je ne me trompe pas.
Avec le message d’erreur en anglais tu trouveras peut-être plus facilement des messages d’autres gens ayant déjà rencontré ton problème, avec éventuellement des pistes de solution !
Ce serait bien si tu pouvais faire pareil mais en ligne de commande, quelque chose comme :
Quant à « Pourquoi vouloir utiliser Samba? », Samba est un très bon produit par ailleurs, sshfs ne fait pas tout ce que fait Samba. Par exemple au hasard… Samba sait faire de la copie côté serveur, ce qui, avec le système de fichier adéquat (btrfs) et la bonne option activée permet de faire de la déduplication à la copie.
Bon, il est possible que ses besoins ne soient pas très grand et que sshfs lui suffise, mais on s’en fout, il n’a aucune raison de changer, Samba c’est très bien.
ce commentaire est sous licence cc by 4 et précédentes
Une chose est de ne pas prendre en compte une fonctionnalité dont on a pas besoin lorsqu’on conçoit un outil pour un besoin très spécifique, une autre chose est d’empêcher que cet outil puisse servir à wat mille autres besoins en refusant que soit implémenté un comportement optionnel qui n’a aucun impact sur le design et le fonctionnement initial et le besoin très spécifique de départ.
Si {"a":2, "b":3} est égal à {"b":3, "a": 2} dans le besoin initial, ça ne casse rien de permettre de produire {"b":3, "a": 2} dès le départ pour ceux qui ont ce besoin indépendamment des besoins pour lequel JSON a été conçu. L’outil qui testera l’égalité n’a pas besoin d’être modifié, à aucun moment. Ça ouvre des perspectives, mais ça ne casse rien, ça ne modifie pas le format, la compatibilité est totale…
La question n’est pas que le comportement se tienne dans son contexte de départ, mais qu’une opportunité qui n’a aucun impact sur le contexte de départ ne soit pas permise, quand la demande est simple, bien expliquée, et facilement justifiable, et que le coût est mineur (et totalement absent pour le contexte de départ).
Par exemple avec pytoml, tu peux décider du constructeur de dictionnaire: {} ou OrderedDict(). Ça n’a aucun impact sur le format. Aucun outil tiers pytoml n’a à être modifié.
Puisque justement JSON est conçu pour fonctionner indépendamment de l’ordre, ordonner des données JSON n’a aucun impact sur son fonctionnement. On peut dire que JSON est précisément conçu pour ne pas être affecté par le fait que les données soient ordonnées. Donc quelqu’un qui produit des données ordonnées et veut parser ces données peut choisir JSON : JSON lui garantit déjà que les données sont correctement parsées bien qu’elles soient ordonnées. Alors, vraiment, rien ne justifie de s’opposer à la reproductibilité optionnelle de l’ordre des données dans la production de fichier JSON.
ce commentaire est sous licence cc by 4 et précédentes
Je crois que tu confonds format de la table pour extraire convenablement les champs, et le format du champ pour interpréter convenablement les données.
Par exemple il me semble que wordpress met du json dans des cellules mysql (ou un autre format sérialisé). Quelqu’un a montré ici un exemple de CSV embarquant du CSV dans des champs. Le format des numéros de téléphones, des données géographiques, les unités et précision de tes chiffresnombres, c’est un format de champ.
Tu peux très bien imaginer stocker un document odt dans une cellule, tu peux spécifier que ton format est CSV ou Json ou ASCII delimited machin, et spécifier que pour les documents odt ils doivent être encodés en base64 sans saut de ligne.
Et pour l’ordre des colonne et autre choses comme ça, c’est une information supplémentaire qui n’est pas vraiment propre au format de la table.
En gros tu dois documenter :
Le format du fichier (ce que j’ai appelé table), en gros, comment séparer et adresser les champs,
Le format des données dans les champs, ce qui peut être spécifique à chaque type de donnée,
Certains aspects comme l’ordre ou des choses comme ça.
Faut pas tout mélanger !!! Au final, tu auras une description de format qui fera appel à plusieurs standards. Mais, ce format final, ce ne sera pas CSV, JSON ou ASCII delimited machin.
De la même manière que l’ODT est un format qui fait appel à plusieurs formats : PKZIP, XML et d’autres pour chaque besoin. On peut décider d’un format d’échange qui utilise XML pour distinguer les champs quel que soit le contenu, et décider que le champ date sera sous la forme normalisée YYYY-mm-ddTHH:MM:SS (il faudra donc deux parseurs, mais ce n’est pas un problème). Tu peux pas demander à XML de prendre en charge n’importe quoi. Ce ne serait pas XML ton format, XML serait alors un des formats utilisés dans ton format final.
Pour revenir au journal, quand par exemple Excel essaie d’interpéter des valeurs dans une table alors que l’utilisateur avait simplement l’intention d’afficher proprement des lignes et des colonnes, Excel il prend le risque de détruire des données. Parce que le format de la structure et le format du champ sont deux choses différentes.
ce commentaire est sous licence cc by 4 et précédentes
C'est un peu comme gérer les noms de personnes : la plupart des gens pensent que un champs nom et un champs prénom et c'est plié.
Ah oui, ça aussi… Tu connais Marcus Tullius ? Il est plus connu sous le nom de… « Cicéron ».
En fait, « Cicéron » est un surnom. Les romains avaient en gros un prénom, un nom de famille, et un surnom, le surnom pouvant être hérité, c’est un surnom de famille… « César » et « Auguste » font partie de ces surnoms célèbres, que l’on peut associer pour plus de swag : César Auguste, ça en jette !!!
Ah, et il y a aussi les cultures qui forment le nom de famille par le prénom du père. En gros, si tu as Martin qui a un fils qui s’appelle Jean qui a un fils qui s’appelle Michel, Jean s’appelle Jean Martinfils, et Michel s’appelle Michel Jeanfils (les personnes d’origine nordique avec des patronymes françisés en machin-son, c’est ça). Quelqu’un de cette culture pourrait typiquement penser que demander le prénom de la personne et le prénom de son père serait suffisant, sans demander de nom de famille du tout puisque ça n’existe pas, non ?
Ah au fait, pour revenir au surnom, Cicéron c’est pour « pois chiche ». Oui, le grand Cicéron était surnommé « pois chiche », je crois que c’était hérité en fait.
Bref, quand on appelle le roi « Louis le gros », son surnom fait véritablement partie de son identité…
Et quand on écrit en 2020 : Thomas “illwieckz” Debesse, on n’est pas très original en fait…
ce commentaire est sous licence cc by 4 et précédentes
Si ta conf peut être générée/modifiée par une machine, ca va te créer des diffs très durs a lire.
Exactement, par exemple quand j’ai vu certains répondre que conserver l’ordre du dictionnaire est inutile “par principe” parce que forcément, par principe il n’y aurait aucun besoin pour cela… J’ai immédiatement pensé que ces personnes ne savaient pas vraiment ce que c’était de stocker des fichiers dans un dépôt (git ou autre chose).
Il est très important de pouvoir conserver l’ordre des données, ou de déterminer cet ordre, même si cet ordre n’a aucune sémantique pour les données elle-même. C’est important parce qu’il devient alors très aisé de versionner. Au delà de fichier de paramétrages dans git, va versionner un csv de millier de lignes si elles sont mélangées… alors que si l’ordre est conservé, un simple outil générique comme diff te sortira les différences en un temps record. Idem avec json, xml et je sais pas quoi.
La possibilité de conserver l’ordre est importante. J’ai remarqué que j’utilisais énormément OrderedDict dans Python, et quand il s’agit de traiter des données extérieures (pas des dictionnaires intégrés au code), j’ai remarqué que j’utilise OrderedDict de manière écrasante, par nécessité.
C’est d’ailleurs pourquoi par exemple quand je traite du TOML en python, j’utilise pytoml au lieu de python-toml. Je ne sais pas où ça en est maintenant, mais quand j’ai commencé à travailler sur Urcheon (un outil pour construire des dépôts de données, en gros un CMake mais pour des images, du son et des modèles 3D), seul pytoml permettait de spécifier le type de dictionnaire et donc de sortir un fichier de configuration qui conservait l’ordre de l’entrée, ou encore… très important dans ce cas, de traiter les opérations dans l’ordre de l’entrée… Je lis maintenant que pytoml est déprécié et recommand python-toml, il faudra que je réévalue python-toml et voir s’ils ont enfin implémenté la possibilité de forcer le constructeur de dictionnaire…
ce commentaire est sous licence cc by 4 et précédentes
Pour Arch, il y a effectivement un paquet AUR qui est maintenu par Viech, un des autres membres du triumvirat à la tête du projet Unvanquished.
Pour Debian, le dépôt fournit un dossier debian/ que j’ai corrigé cette année. Donc techniquement, la connaissance pour empaqueter chez Arch et Debian existe. Mais c’est tout.
Je ne pense pas que le projet va dépenser de l’énergie à empaqueter pour les distributions par principe, c’est un métier à part entière. Si quelqu’un du projet (comme Arch) c’est son initiative. Dit autrement, si ces paquets sont bienvenus, nous sommes alors à la recherche de contributeurs dans ce domaine.
Le projet fournit un programme (appelé actuellement « updater » par manque d’imagination) qui est pensé comme le point d’entrée du jeu. Il agit comme un splash screen évolué qui peut annoncer au joueur la présence d’un nouvel article sur le blog du jeu, la présence de mise à jour, et opérer l’installation de la mise à jour elle-même.
Ce qui serait vraiment bienvenu, c’est une alternative qui ait la même ambition d’universalité que ça. Quelque chose comme Snap ou Flatpak (avis personnel pour des raisons qui sont sans rapport avec Unvanquished et que je peux développer, ma préférence va à Flatpak).
Le besoin est réel. On vient tout juste ces dernières semaines de découvrir que notre version actuelle, sortie en 2018, ne tourne plus sur les distributions les plus « fraîches », que ce soit les « rolling relase » comme Arch, les préversions comme Debian testing ou les « cutting edges » comme Fedora 33, ça ne marche plus et c’est vraiment tout récent. On ne sait pas quelle est la cause, mais le binaire segfault quasi immédiatement au démarrage, sans autre forme de procès. Avec les mises à jour progressives des distributions, ce binaire ne tournera simplement nulle-part à moyen terme. Pour pallier à ce genre de problème qui survient sans prévenir, un paquet Mageia ou OpenSuse ou Debian n’est d’un intérêt que… très limité. Là concrètement si on avait déjà un Flatpak de prêt, ça satisferait l’écrasante majorité de ceux qui rencontrent le problème.
Donc voilà, vous savez faire un Flatpak ? Vous voulez faire entrer votre nom dans l’histoire d’Unvanquished ? Viendez !
Par ailleurs, concernant l’inclusion dans les distributions, la liberté c’est une chose mais ça ne fait pas tout. Un projet comme Unvanquished c’est compliqué à empaqueter selon les critères de Debian. Actuellement, à cause de la machine NativeClient, nous distribuons un SDK NaCl précompilé pour Linux, macOS et Windows. Celui-ci est téléchargé par CMake lors de la compilation du jeu. Ça ne va pas faire plaisir à Debian. =)
Compiler quelque chose comme NaCl c’est énorme, c’est bien plus complexe que compiler le moteur Dæmon ou le jeu Unvanquished : il faut compiler LLVM etc.
Ça changera peut-être avec Wasm. Le SDK de Wasm n’est probablement pas moins complexe à construire que celui de NaCl, mais on peut s’attendre à ce que les distributions le fournisse à moyen terme.
Xonotic est entièrement libre, GPLv2+ des pieds à la tête, moteur, jeu et données artistiques. C’est pas pour autant empaqueté dans Debian, presque dix ans plus tard.
Ce ticket Xonotic chez Debian est parti dans tous les sens, par exemple certains ont commencé à parler de recompiler les maps. Y a un moment ça va trop loin. Oui les sources des maps sont fournies, oui les sources du compilateur de map sont fournies (et c’est pareil pour Unvanquished, contrairement à Tremulous qui ne fournissait pas les sources de nombre de ses maps), mais « compiler une map », c’est entre autre faire tourner un traceur de rayon pendant des heures, et en 2011, le faire pour l’intégralité des cartes de Xonotic était probablement une affaire de plusieurs jours…
De plus, il est vraiment important que les données des joueur soient strictement identiques au bit près à celles du serveur, et c’est pas seulement pour des raisons de prévention de la triche, mais c’est aussi le moyen pour le serveur de s’assurer que le joueur est équipé correctement pour pouvoir jouer sur le serveur, et c’est aussi le moyen de sélectionner les bons fichiers s’il y a un doute. Obtenir une reproductibilité sur les données, c’est un projet plus grand que le projet Unvanquished, ça demande éventuellement d’auditer et corriger tous les outils mis en œuvre, jusqu’au convertisseur de format d’image et je sais pas quoi, dès lors qu’il y a une transformation. Perso j’aimerai que ce soit possible, mais l’objectif réaliste que je poursuis c’est que déjà, n’importe qui puisse construire le jeu intégralement, code et données. Et ça c’est déjà possible. En gros ça signifie que n’importe qui peut produire la prochaine version d’Unvanquished sur son ordinateur. Ce ne sera pas égal bit à bit à ce qu’obtiendrait son voisin si son voisin le ferait, mais l’expérience serait exactement la même et complète.
Bref, on est loin de satisfaire à toutes les ambitions idéologiques. Mais techniquement n’importe qui peut produire le jeu intégralement sur sa propre machine, et techniquement n’importe qui peut déjà empaqueter Unvanquished en se contentant de reprendre les fichiers DPK tels quels.
Et puis si on regarde bien le ticket Xonotic dans Debian, le plus gros problèmes n’est pas tant ceux qui partent dans tous les sens et dont il faudrait calmer les ardeurs, mais tout simplement l’absence de contributeur, l’absence de celui qui fait le boulot.
Les fichiers DPK sont les archives qui contiennent les données du jeu. Un des problèmes difficiles à résoudre est que l’un d’entre eux embarque le code du jeu lui-même, et pas que des données.
Donc tout ça dépend du niveau de concession acceptable par une distribution. De plus, autant une distribution comme Debian est exactement ce qu’il faut pour installer un système Linux pour un serveur ou un bureau, autant ce n’est pas forcément son rôle de distribuer Unvanquished en particulier. Si Debian le fait tant mieux, si Debian ne le fait pas, Debian n’est pas en faute.
Un Flatpak pour commencer serait vraiment super.
ce commentaire est sous licence cc by 4 et précédentes
Pour UnrealArena, c’est un projet ex nihilo, il n’y a pas de portage depuis un autre moteur. C’est le moteur qui a été choisi par ce projet et c’est comme ça.
Pour Smokin'Guns, il se trouve que Smokin' Guns est, comme Tremulous, un mod de Quake3 devenu standalone. On sait qu’un portage depuis le moteur Quake 3 vers Dæmon est possible: Unvanquished l’a fait. Il est assez naturel pour un projet basé sur les technologies de Quake 3 qui voudrait se réinventer un peu de lorgner du côté de Dæmon. Les données utilisent les mêmes formats, avec les mêmes outils pour les gérer. Dæmon apporte quelques changements par-dessus et autour de ces formats parce qu’avec des décennies de recul on sait ce qui pouvait être mieux pensé, mais même quand la compatibilité est cassée pour faire mieux, porter les données de l’un à l’autre n’est pas très compliqué.
Au final Dæmon est un moteur qui est réellement utilisé par un jeu et qui est maintenu. Un projet comme ioquake3 apporte de nouvelles fonctionnalités, mais elles ne sont pas vraiment éprouvées parce que la vocation première d’ioquake3 est de faire tourner Quake 3 sans le casser. Ça veut aussi dire qu’ioquake3 ne peut pas corriger certains défauts de conception.
Par exemple ce que je vais dire pourra paraître surprenant et à contre-courant des présupposés, mais Quake3 n’as pas vraiment été pensé pour être “moddé”, il a été pensé pour être mis à jour facilement. La nuance, c’est que les mécanismes utilisés par les “moddeurs” sont des mécanismes qui permettent à l’éditeur du jeu de modifier son propre jeu pour l’améliorer, distribuer ses mises à jour, mais ces mécanismes ne sont pas pensés pour isoler les modifications du jeu original. N’importe quel serveur malintentionné peut distribuer un fichier de mise à jour qui casse le jeu tant que ce fichier n’est pas supprimé manuellement par le joueur (s’il l’identifie). Dæmon a amélioré le format des archives à la base du système de fichier virtuel du jeu en ce sens par exemple.
Par ailleurs, le moteur est juste plus avancé dans plein de domaines, notamment graphique.
Pour Xonotic, la raison n’est pas « plus beau ». En termes de résultat final (ce qui est affiché à l’écran), Dæmon est encore un peu en retrait de Darkplaces (le moteur actuellement utilisé par Xonotic. Pour être au même niveau il faut réparer les effets d’eau et implémenter les lightmaps dans l’espace sRGB. Par ailleurs Darkplaces est encore un peu plus performant que Dæmon. DarkPlaces a l’avantage d’être bien plus mature et éprouvé, 3D Realms a même sorti un jeu dessu en 2020: Wrath: Aeon of Ruin.
Mais DarkPlaces est un vieux cheval. C’est initialement un moteur pour faire tourner Quake 1, et aucune modification qui pourrait casser Quake 1 ne sera implémentée. Dans DarkPlaces, les jeux sont codés en QuakeC, une espèce de langage dédié qui ressemble un peu au C, et tournent dans une machine virtuelle maison communément dénommée Q1VM. C’est un langage et un environnement très spécifique, avec des tas de vieilleries, de limitations, et de bizarreries.
Le moteur de Quake 3 avait fait le choix de partir sur du C pour le code des jeux, du véritable C, mais compilé avec un compilateur spécifique (et non-libre, LCC) dont les binaires tournaient sur une machine virtuelle maison (QVM). C’est déjà énorme par rapport à la Q1VM et le QuakeC. Dæmon est allé plus loin. Le problème de la QVM est que là encore, c’est une technologie spécifique, on est donc loin des performances que peut permettre l’état de l’art actuel, même s’il faut le reconnaître, c’est tout de même pas mal. L’autre problème de la QVM c’est que si c’est du vrai C, c’est du C assez ancien qui compile avec un compilateur ancien et limité. On oublie tous les progrès sur les compilateurs qui ont pu être fait en 20 ans, on oublie la réutilisation de certains codes en C écrit depuis qui ne seraient tout simplement pas compilable sur LCC, etc. Sachant que pour conserver des fichiers sources commun entre le moteur et le jeu, le moteur en subit des limitations
Dæmon prend en charge le même C++ dans le moteur et le jeu. La machine virtuelle actuelle est NativeClient (NaCl), maintenant que celui-ci est déprécié au profit de WebAssembly (WASM, le mal nommé, qui n’est pas du tout spécifique au web), nous avons un plan de migration vers celui-ci, mais jusqu’à très récemment d’après les spécialistes, WebAssembly n’était pas encore prêt pour nos besoins. À suivre…
Le but de Xonotic serait donc de s’affranchir de DarkPlaces. Il y a plusieurs expérimentations. Celle qui donne des résultats déjà visibles est une espèce de glue qui en réalité implémente une Q1VM par-dessus NaCL. L’idée serait de porter le jeu en Quake C d’abord, puis de l’améliorer par partie dans un autre langage si j’ai bien compris. Actuellement tout ce qu’on peut faire avec ça c’est se ballader dans les maps et c’est tout. C’est une démo technique, une preuve de concept.
J’ai vu passer deux projets de transpileurs. L’un qui transpile du code vers du C++ mais sans tenir compte du fait que ce soit lisible à la sortie. L’idée serait là aussi de porter petit à petit le code tout en transpilant ce qui n’est pas porté, si j’ai bien compris.
Un autre projet plus ambitieux est un projet qui vise à transpiler le code QC vers du rust directement exploitable.
Tout ça ce sont fondamentalement des travaux de recherche en fait. Le futur appartient aux audacieux, aux persévérants, et aux chanceux qui survivent aux chauffards.
Il est tout à fait possible que Xonotic reste sur DarkPlaces encore longtemps.
De ce que je sais, même si Dæmon est un peu à la traine derrière Darkplaces concernant certains effets graphiques (mais pourrait être en avance sur d’autres, mais pour Xonotic forcément l’éventuel « plus » ne peut pas se voir), Dæmon aurait une architecture plus moderne sur le plan du moteur de rendu. L’idée serait donc de bénéficier de ce que DarkPlaces n’a pas en ajoutant ce qui manque a Dæmon, sur une base déjà plus accueillante.
Il se trouve que DarkPlaces a implémenté nombre de technologies de Quake 3: le format des paquets, le format des maps, et partiellement le format des matériaux. Xonotic a donc des données qui se chargent à 90% dans Dæmon sans trop pousser. Ceci est vraiment important pour Xonotic car avec 19 ans d’histoire (en comptant Nexuiz) ça fait plusieurs milliers de cartes communautaires dont il serait dommage de casser la compatibilité.
Et globalement, derrière tout ça, il y a l’idée d’aller plus loin ensemble.
Par exemple revient parfois la discussion de l’éventualité d’intégrer le moteur graphique de Dæmon dans ET:Legacy, mais seulement la partie rendu graphique parce qu’ils doivent rester binairement compatible avec le jeu Wolfenstein: Enemy Territory. Ce serait là aussi pour éviter la dispersion. Mais comme beaucoup de choses ce sont des idées qui flottent au-dessus de nos têtes et on verra bien dans le futur ce qu’il en deviendra…
Les communautés de joueurs ne se mélangent pas vraiment, mais plusieurs développeurs ont un pied dans plusieurs projets. Et personnellement je travaille beaucoup à entretenir le réseau. Je pense que c’est vraiment ce qui me tient le plus à cœur : jeter des ponts et rassembler. J’essaie de faire ce qui est à ma portée. =)
ce commentaire est sous licence cc by 4 et précédentes
En quoi le fait que Gecko n’est pas été prévu pour être embarquer dans d’autre navigateur rend son code mal fait au juste ?
Tu juges une truite sur sa capacité à grimper aux arbres toi ?
C’est tout de même un gros problème : si les développeurs d’application utilisant des framework web ou intégrant des technologies web et développeurs de sites webs ont toujours sous les yeux un moteur hérité de Webkit et que Safari, Opera, Chrome et Edge ont un moteur hérité de Webkit, alors la nécessité de tester Firefox prend des airs de développement spécifique et les pratiques de développement se modèlent naturellement autour de bugs pris pour des fonctionnalités.
Aussi, tu perds les développeurs qui intègrent le moteur et donc qui connaissent ne serait-ce qu’en surface une partie de la mécanique interne.
Personnellement je suis repassé de Epiphany à Firefox quand Epiphany est passé à Webkit, et tant pis pour l’intégration du trousseau des mots de passe. Et entre nous depuis 2008 EpiphanywWeb n’a toujours pas réussi à redevenir aussi fonctionnel et stable que la version gecko de l’époque.
Si vous n’êtes pas capable de nommer une seule application embarquant Gecko (en excluant celles dérivées du projet Mozilla comme BlueGriffon), dites-moi comment trouver des développeurs connaissant Gecko. Super l’écosystème ! Tout seul on va plus vite, ensemble on va plus loin.
Personnellement j’en connais qu’une seule, avec un public de niche, et qui ne fait même pas partie des logiciels installés sur mon ordinateur : Xiphos. Je ne sais même plus comment je sais que c’est Gecko qui est utilisé.
Toutes les autres applications qui embarquaient Gecko et que je connaissais ont toutes migrées sur Webkit. Maintenant que Mozilla vire 250 personnes, comment tu recrutes une communauté pour prendre le relai quand pas même la surface du moteur est connue ?
ce commentaire est sous licence cc by 4 et précédentes
Il faudra m’expliquer en quoi ce n’est pas la description d’un complot : ils ont des intérêts communs, et en travaillant à ces intérêts (ou ne travaillant pas aux autres intérêts) chacun y trouve son compte.
Un truc qui m’étonne c’est que lorsqu’on décrit des choses comme ceci, ou une entente sur les prix, ou encore l’obsolescence programmée, il y en a souvent un ou deux pour venir dire « mais il n’y a pas de feuille de route », etc. Mais il n’y a pas besoin de faire des rendez-vous dans des caves pour trouver un intérêt à satisfaire un autre qui trouve un intérêt à te satisfaire, pas non-plus besoin de mémos secrets pour sonder le marché et s ’aligner sur les prix de ses concurrents en faisant exprès de ne pas casser les prix si ce serait une logique perdante à moyen terme, tout comme il n’y a pas besoin de programmer l’obsolescence sur un calendrier pour se satisfaire d’un sous-traitant médiocre dont l’intégration des composants stimule, oh surprise, le cycle de renouvellement des produits chez les clients.
Il faut peut-être cesser d’agiter le foulard rouge du complot de roman d’aventure, au risque de systématiquement abdiquer devant l’opportunisme.
Que le complot soit le fruit d’une confrérie secrète ou le cercle des opportunistes dispersés, le résultat est le même. Le mal se traite quelque soit l’intention. Si l’on se coupe le doigt en coupant des carottes, on ne va pas refuser de traiter la coupure au motif que la coupure est opportuniste et que l’intention de se couper le doigt n’a pas été démontrée par la découverte d’un parchemin médiéval décrivant les circonstances et l’intention.
Un complot est une entente secrète aux effets négatifs, le « tu vois ce que je veux dire » ou la simple omission entendue est une forme d’entente informelle. On condamne bien la « non-assistance à personne en danger », l’exemple type de l’omission entendue au service d’un profit quelconque (ne serait-ce que la simple paresse).
Quand Georges Bernanos écrit que le mode moderne est une « conspiration universelle contre toute espèce de vie intérieure » dans La France contre les robots, personne ne suppose un seul instant qu’il suppose un cercle d’initiés qui ne serait-ce qu’imaginent en conscience les effets qu’il décrit. Même pas besoin de plan, même pas besoin d’imaginer les effets, même pas besoin de les rechercher, même pas besoin d’en avoir conscience. L’opportunisme, la lâcheté et l’égoïsme sont des conditions suffisantes à la conspiration dès lors qu’il existe plus d’une personne à pouvoir s’y abaisser.
Pas besoin de procès d’intention quand le conflit d’intérêt est avéré.
ce commentaire est sous licence cc by 4 et précédentes
# Toujours se relire sept fois après s’être relu sept fois… 🤦♀️
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Unvanquished: un patch de dernière minute pour la 0.51 et une conférence ce dimanche. Évalué à 3.
Bah oui, avec le lien direct vers la page de diffusion c’est mieux : https://mdco2.mini.debconf.org/schedule/venue/3/ 👀
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Ton CISO a validé la démarche ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal La fibre Orange à 2Gbps, sur un routeur MikroTik 10Gbps CCR2004, via un ONT SFP+. Évalué à 3.
Depuis quand le DPO peut être responsable du système ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: .
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Warp : les performances de Firefox s’améliorent. Évalué à 10.
Ça me fait bizarre à lire vos commentaires (celui-ci, ceux d’autres personnes à d’autres occasions)… Depuis que j’ai un téléphone Android (6 ou 7 ans peut-être ?), je ne crois pas avoir utilisé autre chose que Firefox sur mon téléphone, que ce soit d’abord via F-droid, ou mainline ensuite, et je n’ai jamais eu de problème, à part peut-être quelque crashs dans le passées alors que j’avais des centaines d’onglets et que c’est trop pour la mémoire du téléphone mais j’aurai du mal à l’attribuer entièrement à Firefox et même ça ils semblent l’avoir corrigé… C’est à dire que dans mon expérience, les dernières versions de Firefox sont meilleures, plus stables, plus robustes à un point que ça semble relever de la magie (il est utilisable comme s’il en avait que faire des limites matérielles)… En fait question performance et utilisabilité j’ai vraiment vu le jour et la nuit entre la version classique de Firefox et leur nouvelle version, wow, je ne pensais pas qu’aussi bien ce soit possible.
Et euh… ergonomie étrange, bon j’ai un biais vu que je n’utilise que ça¹, mais elle marche très bien et surtout elle m’étonne parfois de ce qu’elle permet aussi simplement toutes les multiples fonctionnalités du navigateur. De plus, à chaque fois que j’encourage quelqu’un à passer à Firefox sur son mobile (avec un antipub), et ça inclut du public pas du tout technicien, ça se passe toujours très bien. Question ergonomie, vous ne seriez pas en train de regretter que Firefox ne soit pas Chrome, en fait ?
¹ en vrai, à chaque fois que j’utilise un autre navigateur sur le téléphone d’un autre, je souffre tellement les fonctionnalités sont médiocres et que les interfaces (je parle pas de l’apparence, mais de la façon dont on interagit) sont limitées autour du minimal « consomme, clique, consomme » qui ne prévoit pas que ce soit vraiment moi qui navigue sur le web. Le fait que je navigue sur le web implique une navigation non-linéaire et non un éternel tunnel de micro-paiement : ouvrir plusieurs onglets, revenir, en fermer quelques uns, passer de l’un à l’autre, explorer une branche, basculer sur une autre branche…
ce commentaire est sous licence cc by 4 et précédentes
# Putain d'ornithorynque
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au lien Nouvelle faille découverte sur les CPU Intel via l'implémentation RAPL . Évalué à 5.
Putain d'ornithorynque
ce commentaire est sous licence cc by 4 et précédentes
# licence et xboîte
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Ivre, il tente de réinstaller Windows, ça tourne mal. Évalué à 8.
Pour la licence du Windows, effectivement comme tu l’as remarqué, une fois que tu l’as aspirée, tu peux techniquement la réutiliser ailleurs, ça inclut une machine virtuelle sur l’ordinateur d’origine, bon par contre obtenir une 3D fonctionnelle pour le jeu voulu dans la machine virtuelle est encore une autre aventure.
Pour la xboite et vu que tu y trouves un intérêt comme remplaçant du lecteur DVD du salon, tu pourrais toujours aller faire un tour du côté de Kodi qu’on ne présente plus mais que je présente quand même car à son origine, ce XB* Media Center
^WXBMC^WKodi a pris naissance comme un logiciel tournant sous Linux sur la toute première Xbox et ce dans le dos de Microsoft, dans le dos de Microsoft à la fois pour Linux et XBMC. Kodi est normalement disponible pour ta Xboite toute neuve, et tu pourras ainsi te servir une tranche de sentiment revanchard à pas cher et justifier via le mécanisme de rétribution narcissique d’autres actions moins avouables (microtransations, DLC ?). Bon, en terme de rebellitude, tu n’iras pas bien loin : XBMC^WKodi est désormais officiellement distribué dans le catalogue de Microsoft en s’appliquant à faire toutes les courbettes requises.Au final, j’y vois une certaine conclusion à ton journal : Windows est tellement peu compatible avec le matériel disponible du marché (y compris celui sur lequel il était livré initialement) que le moyen le plus simple de l’utiliser est d’acheter un appareil dédié conçu spécialement pour lui, une sorte d’émulateur matériel en fait.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Financement de Debian
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Debian donne 10 000 € à Framasoft pour développer Peertube. Évalué à 7.
En fait le concept fondamental c’est que ce qui est gratuit est déjà payé. Le payeur peut être celui qui va te manger à la fin (le schéma GAFAM/publicitaire/etc.), ou bien le payeur est tout simplement celui qui a besoin pour lui-même de quelque chose que tu peux faire. La grande question du financement du logiciel libre est de faire se rencontrer le payeur et le faiseur. Le bénévolat c’est quand le payeur est le faiseur (le bénévolat étant la première des subventions).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pour l’écriture manuscrite n’ayant pas besoin d’être reconnue
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Une tablette (grand format) sous Linux?. Évalué à 6.
Attention pour le x220t, je ne sais pas pour le x220t, mais le x61t existait en deux exemplaires: avec écran utilisable au stylet uniquement, avec écran utilisable au stylet et au doigt, ma sœur avait le premier, j’avais le second modèle. Pour le clavier virtuel le doigt c’est vraiment plus pratique. Vérifie donc bien ce que fait le x220t si tu en achetais un.
Pour rester dans le sujet de la connaissance utile à partager, pour la reconnaissance d’écriture je connaissais CellWriter:
C’est de la reconnaissance à l’ancienne où il faut entrainer le logiciel et écrire les lettres dans des cases. En vrai je n’en ai jamais eu besoin moi non-plus. Mais c’est bon de savoir vers qui se tourner au cas où…
À noter qu’avec le stylet j’ai parfois retranscrit des partitions dans MuseScores (pas en dessinant… en sélectionnant les symboles dans la barre d’outil, comme on ferait à la souris), ça marchottait suffisamment à l’époque pour que je produise des choses.
ce commentaire est sous licence cc by 4 et précédentes
# Pour l’écriture manuscrite n’ayant pas besoin d’être reconnue
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Une tablette (grand format) sous Linux?. Évalué à 10.
Pour l’écriture manuscrite n’ayant pas besoin d’être reconnue, Xournal++.
J’ai utilisé Xournal pendant très longtemps, dans les années 2010 j’avais un Thinkpad X61 Tablet (avec tablette Wacom intégrée à l’écran) et j’ai écrit des tas de lettres manuscrites sur Xournal. J’ai découvert récemment l’existence de l’itération Xournal++ à l’occasion d’une dépêche sur OpenBoard, qui bien que soit un logiciel de tableau blanc, ressemble furieusement à Xournal(++).
Avec Xournal++ tu peux non seulement prendre des notes manuscrites, mais aussi gribouiller au dessus d’un PDF comme tu ferais avec un vrai papier, ou simplement remplir un formulaire qui n’est pas éditable, etc.
Bon par contre ça ne répond pas à ta question de la prise en charge du matériel de saisie : stylet, etc.
Côté clavier virtuel, il me semble que celui de GNOME Shell est efficace et bien intégré.
Voilà, juste pour l’exercice j’écris cette phrase avec le clavier virtuel de GNOME Shell (un détail, pour les caractères spéciaux ce n’est pas presser-glisser mais presser-cliquer, ce qui ne me semble pas gênant). Le bouton pour l’activer définitivement est dans le menu accessibilité en haut à droite, en deux clics depuis un bureau standard.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: travail en double
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal OpenJDK est désormais hébergé chez Github tout en se donnant les moyens de l'indépendance. Évalué à 7.
Ben justement, ils ne semblent pas vouloir que ce soit un mariage. C’est pas courant de se marier avec le propriétaire de son logement quand on est locataire… À mes yeux c’est plutôt l’espèce de concubinage généralisé et pas vraiment discerné qui semble être la norme sur GitHub qui devrait questionner.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Mal
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 4. Dernière modification le 08 octobre 2020 à 22:04.
On dirait que tu dis ça comme si ça contredisait mon commentaire.
Comparer une twingo avec une 206 ce n’est pas problématique. Comparer la voiture, la caisse et le siège c’est problématique.
Pour celui qui fabrique la caisse ou le siège, la spécifications pour la caisse ou le siège couvrent l’ensemble du besoin. À son niveau, une caisse ou un siège c’est un ensemble cohérent. Pour celui qui assemble la voiture, sa spécification contient la caisse en question et le siège en question.
Bien sûr que le siège est lié à la caisse.
À aucun moment tu ne me contredis. Je rappelle simplement qu’il est possible de concevoir une spécification qui repose sur une autre spécification pour décrire le format des champs, et d’autres spécifications pour décrire tel ou tel type de donnée. On ne compare pas un format comme SQLite à CSV ou ASCII Delimited Text. Là si quelqu’un compare SQLite à CSV ou ASCII Delimited Text, il va avoir des problèmes. CSV ou ASCII Delimited Text c’est le format pour les champs, pas l’ensemble.
À ce que je sache, ni JSON, ni YAML, ni XML ne redéfinissent les standards pour formater les caractères, ils reposent sur des standards établi. Quand XML réutilise base64 pour stockent les blob, la spécification XML repose précisément sur une autre spécification. Idem pour les autres formats qui reposeraient sur
uuencodepour les blobs. J’avais cité les dates au format ISO 8601, c’est normal pour une spécification de se reposer dessus.Tu peux très bien faire face à une spécification qui repose sur UTF-8, ASCII Delimited Text, base64 et ISO 8601 et d’autres trucs de ce genre. La comparaison avec une spécification riche ne se portera pas sur ASCII Delimited Text uniquement, ce ne serait pas juste. Bon, même si on sera sûrement d’accord sur le fait qu’il est peut-être dommage de réinventer la roue alors que d’autres ont travaillé dur sur tous les cas particuliers auxquels on ne pense pas.
Ce fil de discussion tourne autour d’un problème de partie et de tout. Qu’au moins les comparaisons soient faites avec ce qui est comparable !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: SQLlite
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 6.
Quand l’outil livré requiert que Windows soit configuré avec un format numérique étranger pour que ça marche. C’est du vécu. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: JSON? YAML?’
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 8. Dernière modification le 08 octobre 2020 à 21:37.
Ce qui doit te manquer pour comprendre mon commentaire est qu’il y a eu toute une polémique sur le fait que sur la base de ce que la spécification JSON définit un objet comme “an unordered set of name/value pairs”, certains développeurs significatifs de bibliothèque JSON qui faisait référence refusaient catégoriquement et ce pendant de très longues années de considérer l’implémentation optionnelle de la conservation de l’ordre, et c’était une forme d’obstruction puisque c’était une opposition par principe au concept même, et pas simplement un argument du genre « faites-le vous-même, moi je ne perdrai pas de temps là-dessus ». Ça a été un sérieux obstacle au choix d’utiliser le format JSON ou au choix d’utiliser telle bibliothèque qui fait référence. Personnellement j’ai fait face au problème quand j’ai eu besoin de stocker dans des dépôts versionnés des données générées par des outils que j’écrivais. C’est pour ça qu’historiquement mes outils ne génèrent pas du JSON. Je ne sais pas où ça en est, je pourrai reconsidérer la chose. Tout ça est loin dans mes souvenirs je ne sais pas comment retrouver de lien sur le sujet, mais toujours est-il que mes outils en gardent la trace et que ça a donc marqué durablement mes projets et que tant que ces projets vivront, ils témoigneront de ces temps troublés par une cicatrice toujours visible.
Un tel argumentaire suppose que le JSON généré par un logiciel est immédiatement lu par un autre logiciel, et que puisque le second logiciel ne doit pas supposer d’ordre pour fonctionner, le besoin d’implémenter un ordre à la génération du json serait en fait le témoin d’un problème de conception dans le logiciel qui parse.
Mais ça c’est un cas typique de courte-vue et d’assomption fausse sur le fait que les gens n’auront que ce besoin et strictement que ce besoin. Dans la vraie vie les gens développent des tas de besoins dont certains sont tout à fait honorables, comme le fait de stocker des données sérialisées dans un dépôt versionné.
Ce qui est amusant c’est qu’avec la spécification Vulkan est fournit un fichier JSON qui est utilisé pour faire de la validation. Comme toute spécification versionnée, c’est typiquement le genre de fichier qu’on peut vouloir stocker dans un dépôt versionné, et bien que la spécification JSON permette le désordre, conserver l’ordre simplifie vraiment les choses pour les gens, par pour l’outil de validation qui n’en a rien à faire de l’ordre, mais pour les gens, typiquement pour comparer deux commits tu n’aurais pas besoin d’outil dédié. N’en déplaise à ceux qui se cachent derrière la spécification de JSON elle-même pour supposer que ce besoin n’existe pas.
Exactement, c’est pour cela que faire de l’obstruction sur un besoin qui ne contredit pas la spécification est… surprenant.
ce commentaire est sous licence cc by 4 et précédentes
# pour t’aider à diagnostiquer, essaie en anglais, ça t’aidera dans les recherches sur le web
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au message Erreur copie fichier avec Caja à partir de CIFS/SMB [MATE Manjaro]. Évalué à 6.
Tu peux commencer par lancer Caja en anglais pour savoir comment le message d’erreur est écrit en anglais, tapes ceci dans un terminal:
Note:
killallest fourni par le paquetpsmiscsi je ne me trompe pas.Avec le message d’erreur en anglais tu trouveras peut-être plus facilement des messages d’autres gens ayant déjà rencontré ton problème, avec éventuellement des pistes de solution !
Ce serait bien si tu pouvais faire pareil mais en ligne de commande, quelque chose comme :
Et voir s’il y a aussi un message d’erreur et le quel.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pourquoi Samba?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au message Erreur copie fichier avec Caja à partir de CIFS/SMB [MATE Manjaro]. Évalué à 8.
Il cherche des réponses, pas des questions.
Quant à « Pourquoi vouloir utiliser Samba? », Samba est un très bon produit par ailleurs, sshfs ne fait pas tout ce que fait Samba. Par exemple au hasard… Samba sait faire de la copie côté serveur, ce qui, avec le système de fichier adéquat (btrfs) et la bonne option activée permet de faire de la déduplication à la copie.
Bon, il est possible que ses besoins ne soient pas très grand et que sshfs lui suffise, mais on s’en fout, il n’a aucune raison de changer, Samba c’est très bien.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: JSON? YAML?’
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 8.
Cicéron c’est Poincarré, ou pas…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: JSON? YAML?’
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 3.
Une chose est de ne pas prendre en compte une fonctionnalité dont on a pas besoin lorsqu’on conçoit un outil pour un besoin très spécifique, une autre chose est d’empêcher que cet outil puisse servir à wat mille autres besoins en refusant que soit implémenté un comportement optionnel qui n’a aucun impact sur le design et le fonctionnement initial et le besoin très spécifique de départ.
Si
{"a":2, "b":3}est égal à{"b":3, "a": 2}dans le besoin initial, ça ne casse rien de permettre de produire{"b":3, "a": 2}dès le départ pour ceux qui ont ce besoin indépendamment des besoins pour lequel JSON a été conçu. L’outil qui testera l’égalité n’a pas besoin d’être modifié, à aucun moment. Ça ouvre des perspectives, mais ça ne casse rien, ça ne modifie pas le format, la compatibilité est totale…La question n’est pas que le comportement se tienne dans son contexte de départ, mais qu’une opportunité qui n’a aucun impact sur le contexte de départ ne soit pas permise, quand la demande est simple, bien expliquée, et facilement justifiable, et que le coût est mineur (et totalement absent pour le contexte de départ).
Par exemple avec pytoml, tu peux décider du constructeur de dictionnaire:
{}ouOrderedDict(). Ça n’a aucun impact sur le format. Aucun outil tiers pytoml n’a à être modifié.Puisque justement JSON est conçu pour fonctionner indépendamment de l’ordre, ordonner des données JSON n’a aucun impact sur son fonctionnement. On peut dire que JSON est précisément conçu pour ne pas être affecté par le fait que les données soient ordonnées. Donc quelqu’un qui produit des données ordonnées et veut parser ces données peut choisir JSON : JSON lui garantit déjà que les données sont correctement parsées bien qu’elles soient ordonnées. Alors, vraiment, rien ne justifie de s’opposer à la reproductibilité optionnelle de l’ordre des données dans la production de fichier JSON.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Mal
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 7.
Je crois que tu confonds format de la table pour extraire convenablement les champs, et le format du champ pour interpréter convenablement les données.
Par exemple il me semble que wordpress met du json dans des cellules mysql (ou un autre format sérialisé). Quelqu’un a montré ici un exemple de CSV embarquant du CSV dans des champs. Le format des numéros de téléphones, des données géographiques, les unités et précision de tes
chiffresnombres, c’est un format de champ.Tu peux très bien imaginer stocker un document odt dans une cellule, tu peux spécifier que ton format est CSV ou Json ou ASCII delimited machin, et spécifier que pour les documents odt ils doivent être encodés en base64 sans saut de ligne.
Et pour l’ordre des colonne et autre choses comme ça, c’est une information supplémentaire qui n’est pas vraiment propre au format de la table.
En gros tu dois documenter :
Faut pas tout mélanger !!! Au final, tu auras une description de format qui fera appel à plusieurs standards. Mais, ce format final, ce ne sera pas CSV, JSON ou ASCII delimited machin.
De la même manière que l’ODT est un format qui fait appel à plusieurs formats : PKZIP, XML et d’autres pour chaque besoin. On peut décider d’un format d’échange qui utilise XML pour distinguer les champs quel que soit le contenu, et décider que le champ date sera sous la forme normalisée YYYY-mm-ddTHH:MM:SS (il faudra donc deux parseurs, mais ce n’est pas un problème). Tu peux pas demander à XML de prendre en charge n’importe quoi. Ce ne serait pas XML ton format, XML serait alors un des formats utilisés dans ton format final.
Pour revenir au journal, quand par exemple Excel essaie d’interpéter des valeurs dans une table alors que l’utilisateur avait simplement l’intention d’afficher proprement des lignes et des colonnes, Excel il prend le risque de détruire des données. Parce que le format de la structure et le format du champ sont deux choses différentes.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: JSON? YAML?’
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 6.
Ah oui, ça aussi… Tu connais Marcus Tullius ? Il est plus connu sous le nom de… « Cicéron ».
En fait, « Cicéron » est un surnom. Les romains avaient en gros un prénom, un nom de famille, et un surnom, le surnom pouvant être hérité, c’est un surnom de famille… « César » et « Auguste » font partie de ces surnoms célèbres, que l’on peut associer pour plus de swag : César Auguste, ça en jette !!!
Ah, et il y a aussi les cultures qui forment le nom de famille par le prénom du père. En gros, si tu as Martin qui a un fils qui s’appelle Jean qui a un fils qui s’appelle Michel, Jean s’appelle Jean Martinfils, et Michel s’appelle Michel Jeanfils (les personnes d’origine nordique avec des patronymes françisés en machin-son, c’est ça). Quelqu’un de cette culture pourrait typiquement penser que demander le prénom de la personne et le prénom de son père serait suffisant, sans demander de nom de famille du tout puisque ça n’existe pas, non ?
Ah au fait, pour revenir au surnom, Cicéron c’est pour « pois chiche ». Oui, le grand Cicéron était surnommé « pois chiche », je crois que c’était hérité en fait.
Bref, quand on appelle le roi « Louis le gros », son surnom fait véritablement partie de son identité…
Et quand on écrit en 2020 : Thomas “illwieckz” Debesse, on n’est pas très original en fait…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: JSON? YAML?’
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 6.
Exactement, par exemple quand j’ai vu certains répondre que conserver l’ordre du dictionnaire est inutile “par principe” parce que forcément, par principe il n’y aurait aucun besoin pour cela… J’ai immédiatement pensé que ces personnes ne savaient pas vraiment ce que c’était de stocker des fichiers dans un dépôt (git ou autre chose).
Il est très important de pouvoir conserver l’ordre des données, ou de déterminer cet ordre, même si cet ordre n’a aucune sémantique pour les données elle-même. C’est important parce qu’il devient alors très aisé de versionner. Au delà de fichier de paramétrages dans git, va versionner un csv de millier de lignes si elles sont mélangées… alors que si l’ordre est conservé, un simple outil générique comme
diffte sortira les différences en un temps record. Idem avec json, xml et je sais pas quoi.La possibilité de conserver l’ordre est importante. J’ai remarqué que j’utilisais énormément
OrderedDictdans Python, et quand il s’agit de traiter des données extérieures (pas des dictionnaires intégrés au code), j’ai remarqué que j’utiliseOrderedDictde manière écrasante, par nécessité.C’est d’ailleurs pourquoi par exemple quand je traite du TOML en python, j’utilise pytoml au lieu de python-toml. Je ne sais pas où ça en est maintenant, mais quand j’ai commencé à travailler sur Urcheon (un outil pour construire des dépôts de données, en gros un CMake mais pour des images, du son et des modèles 3D), seul pytoml permettait de spécifier le type de dictionnaire et donc de sortir un fichier de configuration qui conservait l’ordre de l’entrée, ou encore… très important dans ce cas, de traiter les opérations dans l’ordre de l’entrée… Je lis maintenant que pytoml est déprécié et recommand python-toml, il faudra que je réévalue python-toml et voir s’ils ont enfin implémenté la possibilité de forcer le constructeur de dictionnaire…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Enpaquetage dans les distributions GNU/Linux
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Unvanquished : maintenant nous sommes libres !. Évalué à 10. Dernière modification le 05 octobre 2020 à 23:32.
Pour Arch, il y a effectivement un paquet AUR qui est maintenu par Viech, un des autres membres du triumvirat à la tête du projet Unvanquished.
Pour Debian, le dépôt fournit un dossier
debian/que j’ai corrigé cette année. Donc techniquement, la connaissance pour empaqueter chez Arch et Debian existe. Mais c’est tout.Je ne pense pas que le projet va dépenser de l’énergie à empaqueter pour les distributions par principe, c’est un métier à part entière. Si quelqu’un du projet (comme Arch) c’est son initiative. Dit autrement, si ces paquets sont bienvenus, nous sommes alors à la recherche de contributeurs dans ce domaine.
Le projet fournit un programme (appelé actuellement « updater » par manque d’imagination) qui est pensé comme le point d’entrée du jeu. Il agit comme un splash screen évolué qui peut annoncer au joueur la présence d’un nouvel article sur le blog du jeu, la présence de mise à jour, et opérer l’installation de la mise à jour elle-même.
Ce qui serait vraiment bienvenu, c’est une alternative qui ait la même ambition d’universalité que ça. Quelque chose comme Snap ou Flatpak (avis personnel pour des raisons qui sont sans rapport avec Unvanquished et que je peux développer, ma préférence va à Flatpak).
Le besoin est réel. On vient tout juste ces dernières semaines de découvrir que notre version actuelle, sortie en 2018, ne tourne plus sur les distributions les plus « fraîches », que ce soit les « rolling relase » comme Arch, les préversions comme Debian testing ou les « cutting edges » comme Fedora 33, ça ne marche plus et c’est vraiment tout récent. On ne sait pas quelle est la cause, mais le binaire segfault quasi immédiatement au démarrage, sans autre forme de procès. Avec les mises à jour progressives des distributions, ce binaire ne tournera simplement nulle-part à moyen terme. Pour pallier à ce genre de problème qui survient sans prévenir, un paquet Mageia ou OpenSuse ou Debian n’est d’un intérêt que… très limité. Là concrètement si on avait déjà un Flatpak de prêt, ça satisferait l’écrasante majorité de ceux qui rencontrent le problème.
Donc voilà, vous savez faire un Flatpak ? Vous voulez faire entrer votre nom dans l’histoire d’Unvanquished ? Viendez !
Par ailleurs, concernant l’inclusion dans les distributions, la liberté c’est une chose mais ça ne fait pas tout. Un projet comme Unvanquished c’est compliqué à empaqueter selon les critères de Debian. Actuellement, à cause de la machine NativeClient, nous distribuons un SDK NaCl précompilé pour Linux, macOS et Windows. Celui-ci est téléchargé par CMake lors de la compilation du jeu. Ça ne va pas faire plaisir à Debian. =)
Compiler quelque chose comme NaCl c’est énorme, c’est bien plus complexe que compiler le moteur Dæmon ou le jeu Unvanquished : il faut compiler LLVM etc.
Ça changera peut-être avec Wasm. Le SDK de Wasm n’est probablement pas moins complexe à construire que celui de NaCl, mais on peut s’attendre à ce que les distributions le fournisse à moyen terme.
Par ailleurs, pour parler de Debian… tu peux regarder le ticket pour l’inclusion de Xonotic qui est ouvert depuis le 23 octobre… 2011.
Xonotic est entièrement libre, GPLv2+ des pieds à la tête, moteur, jeu et données artistiques. C’est pas pour autant empaqueté dans Debian, presque dix ans plus tard.
Ce ticket Xonotic chez Debian est parti dans tous les sens, par exemple certains ont commencé à parler de recompiler les maps. Y a un moment ça va trop loin. Oui les sources des maps sont fournies, oui les sources du compilateur de map sont fournies (et c’est pareil pour Unvanquished, contrairement à Tremulous qui ne fournissait pas les sources de nombre de ses maps), mais « compiler une map », c’est entre autre faire tourner un traceur de rayon pendant des heures, et en 2011, le faire pour l’intégralité des cartes de Xonotic était probablement une affaire de plusieurs jours…
De plus, il est vraiment important que les données des joueur soient strictement identiques au bit près à celles du serveur, et c’est pas seulement pour des raisons de prévention de la triche, mais c’est aussi le moyen pour le serveur de s’assurer que le joueur est équipé correctement pour pouvoir jouer sur le serveur, et c’est aussi le moyen de sélectionner les bons fichiers s’il y a un doute. Obtenir une reproductibilité sur les données, c’est un projet plus grand que le projet Unvanquished, ça demande éventuellement d’auditer et corriger tous les outils mis en œuvre, jusqu’au convertisseur de format d’image et je sais pas quoi, dès lors qu’il y a une transformation. Perso j’aimerai que ce soit possible, mais l’objectif réaliste que je poursuis c’est que déjà, n’importe qui puisse construire le jeu intégralement, code et données. Et ça c’est déjà possible. En gros ça signifie que n’importe qui peut produire la prochaine version d’Unvanquished sur son ordinateur. Ce ne sera pas égal bit à bit à ce qu’obtiendrait son voisin si son voisin le ferait, mais l’expérience serait exactement la même et complète.
Bref, on est loin de satisfaire à toutes les ambitions idéologiques. Mais techniquement n’importe qui peut produire le jeu intégralement sur sa propre machine, et techniquement n’importe qui peut déjà empaqueter Unvanquished en se contentant de reprendre les fichiers DPK tels quels.
Et puis si on regarde bien le ticket Xonotic dans Debian, le plus gros problèmes n’est pas tant ceux qui partent dans tous les sens et dont il faudrait calmer les ardeurs, mais tout simplement l’absence de contributeur, l’absence de celui qui fait le boulot.
Les fichiers DPK sont les archives qui contiennent les données du jeu. Un des problèmes difficiles à résoudre est que l’un d’entre eux embarque le code du jeu lui-même, et pas que des données.
Donc tout ça dépend du niveau de concession acceptable par une distribution. De plus, autant une distribution comme Debian est exactement ce qu’il faut pour installer un système Linux pour un serveur ou un bureau, autant ce n’est pas forcément son rôle de distribuer Unvanquished en particulier. Si Debian le fait tant mieux, si Debian ne le fait pas, Debian n’est pas en faute.
Un Flatpak pour commencer serait vraiment super.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Avantages pour les autres projets
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Unvanquished : maintenant nous sommes libres !. Évalué à 9.
Du plus simple au plus complexe à décrire…
Pour UnrealArena, c’est un projet ex nihilo, il n’y a pas de portage depuis un autre moteur. C’est le moteur qui a été choisi par ce projet et c’est comme ça.
Pour Smokin'Guns, il se trouve que Smokin' Guns est, comme Tremulous, un mod de Quake3 devenu standalone. On sait qu’un portage depuis le moteur Quake 3 vers Dæmon est possible: Unvanquished l’a fait. Il est assez naturel pour un projet basé sur les technologies de Quake 3 qui voudrait se réinventer un peu de lorgner du côté de Dæmon. Les données utilisent les mêmes formats, avec les mêmes outils pour les gérer. Dæmon apporte quelques changements par-dessus et autour de ces formats parce qu’avec des décennies de recul on sait ce qui pouvait être mieux pensé, mais même quand la compatibilité est cassée pour faire mieux, porter les données de l’un à l’autre n’est pas très compliqué.
Au final Dæmon est un moteur qui est réellement utilisé par un jeu et qui est maintenu. Un projet comme ioquake3 apporte de nouvelles fonctionnalités, mais elles ne sont pas vraiment éprouvées parce que la vocation première d’ioquake3 est de faire tourner Quake 3 sans le casser. Ça veut aussi dire qu’ioquake3 ne peut pas corriger certains défauts de conception.
Par exemple ce que je vais dire pourra paraître surprenant et à contre-courant des présupposés, mais Quake3 n’as pas vraiment été pensé pour être “moddé”, il a été pensé pour être mis à jour facilement. La nuance, c’est que les mécanismes utilisés par les “moddeurs” sont des mécanismes qui permettent à l’éditeur du jeu de modifier son propre jeu pour l’améliorer, distribuer ses mises à jour, mais ces mécanismes ne sont pas pensés pour isoler les modifications du jeu original. N’importe quel serveur malintentionné peut distribuer un fichier de mise à jour qui casse le jeu tant que ce fichier n’est pas supprimé manuellement par le joueur (s’il l’identifie). Dæmon a amélioré le format des archives à la base du système de fichier virtuel du jeu en ce sens par exemple.
Par ailleurs, le moteur est juste plus avancé dans plein de domaines, notamment graphique.
Pour Xonotic, la raison n’est pas « plus beau ». En termes de résultat final (ce qui est affiché à l’écran), Dæmon est encore un peu en retrait de Darkplaces (le moteur actuellement utilisé par Xonotic. Pour être au même niveau il faut réparer les effets d’eau et implémenter les lightmaps dans l’espace sRGB. Par ailleurs Darkplaces est encore un peu plus performant que Dæmon. DarkPlaces a l’avantage d’être bien plus mature et éprouvé, 3D Realms a même sorti un jeu dessu en 2020: Wrath: Aeon of Ruin.
Mais DarkPlaces est un vieux cheval. C’est initialement un moteur pour faire tourner Quake 1, et aucune modification qui pourrait casser Quake 1 ne sera implémentée. Dans DarkPlaces, les jeux sont codés en QuakeC, une espèce de langage dédié qui ressemble un peu au C, et tournent dans une machine virtuelle maison communément dénommée Q1VM. C’est un langage et un environnement très spécifique, avec des tas de vieilleries, de limitations, et de bizarreries.
Le moteur de Quake 3 avait fait le choix de partir sur du C pour le code des jeux, du véritable C, mais compilé avec un compilateur spécifique (et non-libre, LCC) dont les binaires tournaient sur une machine virtuelle maison (QVM). C’est déjà énorme par rapport à la Q1VM et le QuakeC. Dæmon est allé plus loin. Le problème de la QVM est que là encore, c’est une technologie spécifique, on est donc loin des performances que peut permettre l’état de l’art actuel, même s’il faut le reconnaître, c’est tout de même pas mal. L’autre problème de la QVM c’est que si c’est du vrai C, c’est du C assez ancien qui compile avec un compilateur ancien et limité. On oublie tous les progrès sur les compilateurs qui ont pu être fait en 20 ans, on oublie la réutilisation de certains codes en C écrit depuis qui ne seraient tout simplement pas compilable sur LCC, etc. Sachant que pour conserver des fichiers sources commun entre le moteur et le jeu, le moteur en subit des limitations
Dæmon prend en charge le même C++ dans le moteur et le jeu. La machine virtuelle actuelle est NativeClient (NaCl), maintenant que celui-ci est déprécié au profit de WebAssembly (WASM, le mal nommé, qui n’est pas du tout spécifique au web), nous avons un plan de migration vers celui-ci, mais jusqu’à très récemment d’après les spécialistes, WebAssembly n’était pas encore prêt pour nos besoins. À suivre…
Le but de Xonotic serait donc de s’affranchir de DarkPlaces. Il y a plusieurs expérimentations. Celle qui donne des résultats déjà visibles est une espèce de glue qui en réalité implémente une Q1VM par-dessus NaCL. L’idée serait de porter le jeu en Quake C d’abord, puis de l’améliorer par partie dans un autre langage si j’ai bien compris. Actuellement tout ce qu’on peut faire avec ça c’est se ballader dans les maps et c’est tout. C’est une démo technique, une preuve de concept.
J’ai vu passer deux projets de transpileurs. L’un qui transpile du code vers du C++ mais sans tenir compte du fait que ce soit lisible à la sortie. L’idée serait là aussi de porter petit à petit le code tout en transpilant ce qui n’est pas porté, si j’ai bien compris.
Un autre projet plus ambitieux est un projet qui vise à transpiler le code QC vers du rust directement exploitable.
Tout ça ce sont fondamentalement des travaux de recherche en fait. Le futur appartient aux audacieux, aux persévérants, et aux chanceux qui survivent aux chauffards.
Il est tout à fait possible que Xonotic reste sur DarkPlaces encore longtemps.
Il y a des choses intéressantes à lire à ce sujet ici :
https://gitlab.com/xonotic/xonotic/-/issues/244
Et là:
https://gitlab.com/xonotic/daemon-glue/-/issues/1
De ce que je sais, même si Dæmon est un peu à la traine derrière Darkplaces concernant certains effets graphiques (mais pourrait être en avance sur d’autres, mais pour Xonotic forcément l’éventuel « plus » ne peut pas se voir), Dæmon aurait une architecture plus moderne sur le plan du moteur de rendu. L’idée serait donc de bénéficier de ce que DarkPlaces n’a pas en ajoutant ce qui manque a Dæmon, sur une base déjà plus accueillante.
Il se trouve que DarkPlaces a implémenté nombre de technologies de Quake 3: le format des paquets, le format des maps, et partiellement le format des matériaux. Xonotic a donc des données qui se chargent à 90% dans Dæmon sans trop pousser. Ceci est vraiment important pour Xonotic car avec 19 ans d’histoire (en comptant Nexuiz) ça fait plusieurs milliers de cartes communautaires dont il serait dommage de casser la compatibilité.
Et globalement, derrière tout ça, il y a l’idée d’aller plus loin ensemble.
Par exemple revient parfois la discussion de l’éventualité d’intégrer le moteur graphique de Dæmon dans ET:Legacy, mais seulement la partie rendu graphique parce qu’ils doivent rester binairement compatible avec le jeu Wolfenstein: Enemy Territory. Ce serait là aussi pour éviter la dispersion. Mais comme beaucoup de choses ce sont des idées qui flottent au-dessus de nos têtes et on verra bien dans le futur ce qu’il en deviendra…
Les communautés de joueurs ne se mélangent pas vraiment, mais plusieurs développeurs ont un pied dans plusieurs projets. Et personnellement je travaille beaucoup à entretenir le réseau. Je pense que c’est vraiment ce qui me tient le plus à cœur : jeter des ponts et rassembler. J’essaie de faire ce qui est à ma portée. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: EDF
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Hégémonie et navigateurs. Évalué à 5.
Obsolescence opportuniste =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Firefox a eu sa chance par le public
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Hégémonie et navigateurs. Évalué à 9.
C’est tout de même un gros problème : si les développeurs d’application utilisant des framework web ou intégrant des technologies web et développeurs de sites webs ont toujours sous les yeux un moteur hérité de Webkit et que Safari, Opera, Chrome et Edge ont un moteur hérité de Webkit, alors la nécessité de tester Firefox prend des airs de développement spécifique et les pratiques de développement se modèlent naturellement autour de bugs pris pour des fonctionnalités.
Aussi, tu perds les développeurs qui intègrent le moteur et donc qui connaissent ne serait-ce qu’en surface une partie de la mécanique interne.
Personnellement je suis repassé de Epiphany à Firefox quand Epiphany est passé à Webkit, et tant pis pour l’intégration du trousseau des mots de passe. Et entre nous depuis 2008 EpiphanywWeb n’a toujours pas réussi à redevenir aussi fonctionnel et stable que la version gecko de l’époque.
Si vous n’êtes pas capable de nommer une seule application embarquant Gecko (en excluant celles dérivées du projet Mozilla comme BlueGriffon), dites-moi comment trouver des développeurs connaissant Gecko. Super l’écosystème ! Tout seul on va plus vite, ensemble on va plus loin.
Personnellement j’en connais qu’une seule, avec un public de niche, et qui ne fait même pas partie des logiciels installés sur mon ordinateur : Xiphos. Je ne sais même plus comment je sais que c’est Gecko qui est utilisé.
Toutes les autres applications qui embarquaient Gecko et que je connaissais ont toutes migrées sur Webkit. Maintenant que Mozilla vire 250 personnes, comment tu recrutes une communauté pour prendre le relai quand pas même la surface du moteur est connue ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: User agent...
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Hégémonie et navigateurs. Évalué à 10.
Il faudra m’expliquer en quoi ce n’est pas la description d’un complot : ils ont des intérêts communs, et en travaillant à ces intérêts (ou ne travaillant pas aux autres intérêts) chacun y trouve son compte.
Un truc qui m’étonne c’est que lorsqu’on décrit des choses comme ceci, ou une entente sur les prix, ou encore l’obsolescence programmée, il y en a souvent un ou deux pour venir dire « mais il n’y a pas de feuille de route », etc. Mais il n’y a pas besoin de faire des rendez-vous dans des caves pour trouver un intérêt à satisfaire un autre qui trouve un intérêt à te satisfaire, pas non-plus besoin de mémos secrets pour sonder le marché et s ’aligner sur les prix de ses concurrents en faisant exprès de ne pas casser les prix si ce serait une logique perdante à moyen terme, tout comme il n’y a pas besoin de programmer l’obsolescence sur un calendrier pour se satisfaire d’un sous-traitant médiocre dont l’intégration des composants stimule, oh surprise, le cycle de renouvellement des produits chez les clients.
Il faut peut-être cesser d’agiter le foulard rouge du complot de roman d’aventure, au risque de systématiquement abdiquer devant l’opportunisme.
Que le complot soit le fruit d’une confrérie secrète ou le cercle des opportunistes dispersés, le résultat est le même. Le mal se traite quelque soit l’intention. Si l’on se coupe le doigt en coupant des carottes, on ne va pas refuser de traiter la coupure au motif que la coupure est opportuniste et que l’intention de se couper le doigt n’a pas été démontrée par la découverte d’un parchemin médiéval décrivant les circonstances et l’intention.
Un complot est une entente secrète aux effets négatifs, le « tu vois ce que je veux dire » ou la simple omission entendue est une forme d’entente informelle. On condamne bien la « non-assistance à personne en danger », l’exemple type de l’omission entendue au service d’un profit quelconque (ne serait-ce que la simple paresse).
Quand Georges Bernanos écrit que le mode moderne est une « conspiration universelle contre toute espèce de vie intérieure » dans La France contre les robots, personne ne suppose un seul instant qu’il suppose un cercle d’initiés qui ne serait-ce qu’imaginent en conscience les effets qu’il décrit. Même pas besoin de plan, même pas besoin d’imaginer les effets, même pas besoin de les rechercher, même pas besoin d’en avoir conscience. L’opportunisme, la lâcheté et l’égoïsme sont des conditions suffisantes à la conspiration dès lors qu’il existe plus d’une personne à pouvoir s’y abaisser.
Pas besoin de procès d’intention quand le conflit d’intérêt est avéré.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: PWA FTW!
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Moins d'applications sur smartphone.. Évalué à 5. Dernière modification le 29 septembre 2020 à 04:34.
J’imagine que PWA c’est Progressive web application ?
ce commentaire est sous licence cc by 4 et précédentes