GuieA_7 a écrit 689 commentaires

Rust a été nommé comme ça parce que justement il n'inventait rien, il se base sur ce qui a été fait par les autres langages, et essaie d'en corriger les erreurs.

Même si c'est l'explication qu'on trouve sur wikipedia par exemple, ce n'est pas la vraie origine (ceci dit ça a j'imagine aussi été gardé pour le double sens) :

https://www.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/

TL;DR: Rust is named after a fungus that is robust, distributed, and parallel. And, Graydon is a biology nerd.

(Graydon étant un des créateurs)

À ma connaissance Parrot est mort (je n'ai jamais trouvé de gros intérêt au projet, mais j'étais quand même curieux de voir ce qu'ils arriveraient à faire).

Par ailleurs, je ne compte plus le nombre de liens et de journaux ici qui déplorent le système de dépendances de Python, et les soucis pointés ne sont pas présents chez l'autre.

Les gens du CPAN ont vraiment une solution à ce problème, ou bien le problème existe quand même mais on en n'entend juste pas (ou moins) parler ?

Non django n'impose heureusement pas l'utilisation d'un framework JS ; mais libre à toi de choisir celui que tu veux (React, Vue.js …) si tu veux faire une One Page Application (c'est ce que je comprends de "qui n'ouvre pas pleins de pages html" mais ce n'est pas super clair). Bien que beaucoup de projets ne semblent pas très actifs, il y a pas mal de réponses sur PyPI pour la recherche "django react": https://pypi.org/search/?q=django+react

Ce que tu cherches à faire n'est pas très clair de manière générale ; si tu veux un Wix-like libre clé en main, cherche un Wix-like libre ; il en existe peut-être, peut-être même qui utilisent entre autres django (j'ai des doutes mais bon). Et s'il n'en existe pas, libre à toi d'en coder un (avec django ou autre). Mais se lancer dans django (qui est juste un framework, il faut coder derrière) et s'attendre à avoir un équivalent à facebook/twitter/instagram/wix clé en main juste en installant une app django, c'est probablement faire fausse route.

En espérant avoir éclairé quelques points.

l existait avant un moteur (en Java) (dont j'ai oublié le nom) qui était décentralisé peer-to-peer. On l'installait sur son PC et il indexait en permanence le Web. Il était pas efficace mais j'espérait qu'il progresse…

J'imagine que tu parles de https://yacy.net/
Je ne m'y suis jamais mis (et je m'aperçois que ne je fais pas tant de recherches génériques que ça, souvent j'esquive Qwant pour rechercher directement sur Wikipedia/Wiktionray…), et donc je ne sais pas à quel point ça fonctionne, mais le repo a l'air de bouger encore.

Comme d'habitude la version 2.2 sera encore maintenue jusqu'à la sortie, l'année prochaine, de la version 2.4. Cela vous laisse donc 1 an pour faire tranquillement votre migration. Vous pouvez donc attendre quelques versions de correctifs si ça peut vous rassurer.

On sort généralement une version corrective par mois ; j'ai préféré avancer la sortie de 2.3.1 car il y avait des petits soucis avec l'installation du paquet (donc pas de régression au cours du fonctionnement de l'application, mais des problèmes --contournables à la main—que je trouvais dommage, surtout pour des gens qui feront une première installation).

Je suis globalement confiant sur les régressions ; vous travaillons pour nos nouveaux clients avec la version 2.3 depuis qu'elle est en RC1 (ce qui nous a permis de corriger quelques bugs mineurs).

Et en général les bugs sont corrigés très rapidement après qu'ils sont rapportés ; si basculer sur une branche GIT ne vous fait pas peur, vous pouvez avoir votre version corrigée en 1 poignée de jours (par exemple la branche v2.3.2 sera disponible bien avant d'être fusionnée dans v2.3 lors la release officielle de la version 2.3.2).

Évidemment le mieux est de tester votre workflow sur la 2.3 avant de l'utiliser en production, afin de nous remonter les éventuels problèmes (il n'y a pas de secret, parfois mêmes des bugs triviaux passent au travers des mailles du filet pendant des mois parce que personne ne se sert d'une fonctionnalité d'une certaine façon, ou ne prend le temps de faire un rapport de bug plutôt que de contourner le souci).

J'espère que tout ira bien avec votre migration !

De souvenir, il y a quelques années une personne avait demandé de l'aide dans le forum pour trouver une licence qui oblige à envoyer les patches à l'upstream ; nous en avons trouvé une nommée RPL il me semble, qui était listée comme OpenSource par le site de l'OSI, mais pas considérée comme libre par la FSF/Debian…

On parle évidemment de licences assez obscures, les licences majeures qui représente 99.9% des cas d'utilisations n'ont pas ce souci.

… pour la série de journaux centrés sur Ada; (même si c'est suite à un de mes commentaires, c'est toi qui fait le boulot.

Je suis surpris de voir dans la liste que l'atelier Jeux Vidéos de l'EPN des Rancy travaille avec Unity, un moteur de jeu propriétaire, surtout quand il existe maintenant au moins Godot en alternative libre sympathique (il y a quelques années ça aurait plus compliqué de proposer une alternative libre accessible aux non développeurs).

Ils font évidemment ce qu'ils veulent, et la promotion des logiciels n'est qu'un de leurs combats (ils ne sont pas obligés de tous les mettre en pratique à chaque atelier), mais la présence de cet atelier dans un Agenda du libre est un peu hors sujet.

C'est toujours super intéressant je trouve ces compilateurs écrits dans le langage compilé (le côté Dogfooding notamment).

Le site du projet (à moins que j'ai raté quelque chose) est plutôt chiche en informations ; on imagine qu'un tel projet a du prendre à son créateur bon nombre de mois de travail, dommage d'aussi mal le présenter. Par exemple, si le compilateur est en lui-même très portable, j'aurai bien aimé connaître les architectures cibles (pour les binaires générés par le compilateur donc).

Merci pour la découverte !

Pas forcément. Par exemple (chiffres pipo), beaucoup de gens préféreront pondre une application avec un langage A en une semaine, et la corriger ensuite pendant 2 semaines de plus (après moult rapports de bug), plutôt que de faire une application similaire très peu buggée avec un langage B, mais en 2 mois.

Au final tout le monde veut trouver la métrique qui démontrera incontestablement au monde entier que son langage fétiche est le meilleur…

PS: pour Ada, langage que j'estime beaucoup (du peu que je connais), j'aimerai bien voir des dépêches LinuxFR nous présentant des applications libres écrites avec (parce qu'à titre personnel ça me fait une belle jambe que ça soit très utilisée par une partie de l'industrie qui ne fait quasi que du propriétaire), mais j'ai peur que ça n'existe pas vraiment.

s/Antialising/Antialiasing

Genre bytes = b"rgb FF0000FF"

(à terme je te conseille aussi d'utiliser with pour ne pas avoir à fermer ton pipe explicitement).

Il semble que vous ayez réglé votre navigateur pour avoir le header "Referrer-Policy: no-referrer", ce qui n'est pas supporté par la protection contre les CSRF.

Qu'entendez vous par simple ? simple à installer ? simple à configurer ? simple à modifier ? simple à utiliser (une fois installé/configuré) ?

Je suis le développeur principal de CremeCRM:

• ça gère la relation clients, les devis & factures.
• c'est en Python.
• ce n'est pas trop dur à installer (pour une personne qui sait lancer 3 commandes dans un terminal).
• par défaut ça gère beaucoup plus de choses que ce que vous demandez, mais en passant 15 minutes dans l'interface de configuration vous pouvez enlever la plupart des choses dont vous n'avez pas besoin (que ce soit des blocs, boutons, champs…).
• assez simple à hacker pour les besoins les plus pointus.

Peut-être que cela vous donnera une piste.

Merci pour ces explications !

D'une part, il y a le problème du temps de compilation qui affecte Rust parce que le compilateur Rust émet des formes intermédiaires LLVM de mauvaise qualité, que LLVM met beaucoup de temps à compiler.

rustc a introduit il y a quelques années une représentation intermédiaire (appelée MIR—voir cet article par exemple) qui permet de faire "facilement" des optimisations avec la sémantique de Rust que LLVM ne pouvait pas faire (ou difficilement) et qui a permis de gagner en temps de compilation (entre autres choses), même si ça sera toujours perfectible. LLVM est quand même pas mal tourné vers C/C++ (pour des raisons évidentes), mais au final il y a tellement de gens qui travaillent dessus que faire une solution ad-hoc qui fasse mieux est loin d'être évident. Il y a aussi un travail en cours pour un frontend Rust à GCC ; je ne sais pas si/quand ça aboutira, mais je ne serais pas étonné qu'il y ait le même genre d'écueils.

Oui tout à fait, ça revient un peu à faire jouer une IA sur un jeu d'échec en ligne par exemple. Et même si tu fais jouer les gens en présentiel, un jour tu pourras te faire assister par une puce cérébrale, qu'on se mettra à essayer de détecter, etc… Bref c'est l'éternelle lutte de l'épée contre le bouclier.

Le compilateur OCaml gère deux modes de compilation : un mode bytecode qui fonctionne sur toute architecture où un compilateur C est disponible ; et un mode natif qui émet directement des binaires natifs.

Hum je ne suis pas sûr d'avoir bien compris cette phrase. Tel que je l'avais compris ces dernières années, le compilateur pouvait :

• soit générer un bytecode destiné à une VM spécifique (le code est portable, il "suffit" que la VM ait été portée sur la plateforme, comme d'habitude)
• soit générer du C, qui est alors passé à un compilateur C afin de générer un exécutable natif, l'idée étant d'avoir un compilateur ciblant beaucoup de plateformes avec relativement peu d'effort (l'équipe derrière OCaml étant plutôt petite). J'imagine que faire un frontend GCC demande plus d'efforts que pondre du C (et LLVM est plus récent—j'ai entendu parlé d'un projet de frontend OCaml pour ce dernier mais je ne sais pas où ça en est).

Le bout de phrase "un mode bytecode qui fonctionne sur toute architecture où un compilateur C est disponible" c'est parce que la VM est écrite en C très portable ? C'est une erreur ? N'ai-je rien compris ?

Glaneur de Cellule (GC)

C'est la première fois que je vois cette traduction, j'aime beaucoup.

C'est quoi l'intérêt pour le joueur, de tricher?

Une fois qu'on a vaincu tous les monstres, qu'on a tout vu, l'intérêt d'un jeu se perd.

Il est clair que dans un jeu purement solo, on se fiche (ou en tout cas on devrait) qu'un joueur triche. Si une personne prend du plaisir en allant voir directement l'identité du tueur quand elle lit un polar, en sautant 90% du livre, c'est son droit ; les créateurs (que ce soit un livre, film, jeu vidéo…) proposent une expérience telle qu'ils la pensent intéressante, les utilisateurs/consommateurs en font ce qu'ils veulent. Donc protéger cette expérience via du logiciel propriétaire (voire des logiciels anti-triche) est clairement une aberration.

Mais pour des jeux multi-joueurs en ligne la question se pose. Il y a toujours eu, bien avant le jeu vidéo, des gens qui préfèrent tricher plutôt que perdre (ou n'être que 2ème) ; c'est triste je te l'accorde, mais c'est comme ça. Et ces tricheurs rendent l'expérience moins bonne pour les joueurs honnêtes.

En l'occurrence ces systèmes anti-triche sont plutôt associés à des jeux multi-joueur en ligne (en tout cas il me semble, je ne pratique pas les jeux proprios sur PC).

À la fin, les joueurs joueront sans le tricheur…

Tu pars du principe que c'est facile de savoir qu'une personne triche; ce n'est pas forcément le cas.

• la triche peut permettre de gonfler artificiellement son niveau sans faire des choses fondamentalement illégitimes (comme avoir des munitions illimitées dans un jeu où elles ne doivent pas l'être) (voir exemple les wall hacks qui permettent de voir à travers les murs).
• dans des jeux avec énormément de joueurs, où tu es amené à croiser des gens que tu ne croiseras parfois plus jamais, comment savoir qu'une personne triche bien ou est juste forte ?

Chose qui à été résolu depuis peu en ajoutant le calcul de distance entre le coffre et le joueur pour permettre l’interaction.

C'est très naïf de croire que les devs de Minetest ont globalement résolu le problème de la triche dans les jeux, que la solution consistait à mettre un test côté serveur, et que personne dans l'industrie du JV n'y a pensé.

Faire tourner toute la simulation côté serveur [*] enlève une majorité de types de triche, mais ça amène un coût important pour les serveurs. Au final je pense qu'une majorité de joueurs préfère avoir des logiciels anti-triche sur leur machine (aussi dégueulasse soient-ils) que de devoir payer le surcoût engendré. Ça ne me réjouit pas, mais c'est pour souligner que le problème n'est pas trivial. Je ne cautionne pas ces logiciels, mais je ne vais pas affirmer que le problème est facile à résoudre.

[*] il est amusant de noter que techniquement parlant le cloud gaming (les jeux qui sont rendus coté serveurs, ces derniers envoyant l'image et le son aux joueurs, qui eux envoient juste leurs inputs ) est ce concept poussé à l’extrême, et évite beaucoup de triches possibles (il y a évidemment d'autres problèmes qui viennent avec, comme le besoin d'une très bonne connexion). En pratique le cloud gaming tel que proposé par l'industrie du JV va à l'encontre de ce que j'aime en informatique (le libre) avec une approche jetable des œuvres et ôtant tout le contrôle aux utilisateurs. Mais dans l'absolu un service payant faisant tourner des jeux libres en mode cloud, permettant d'affronter d'autres joueurs (utilisant ce même service) sans triche majeure, est imaginable (on peut rêver).

Si les utilisateurs peuvent avoir le code (sous licence libre, et donc peuvent eux-même le modifier, le redistribuer…) quand il le demande, alors c'est libre. Pas besoin que ça soit public.
Après c'est un peu dommage de ne pas pouvoir, entre autre, jeter un coup d'oeil au code et se faire une (petite) idée de la qualité du soft.

Post intéressant merci.

Je ne suis pas sûr de comprendre ce que tu veux dire par rapport aux plugins en Rust, mais au pire on peut produire des bibliothèques dynamiques en Rust (avec une API C, c'est très utile pour remplacer des bibliothèques existantes par une versions en Rust), et on peut faire du chargement dynamique (j'ai trouvé https://lib.rs/crates/dlopen en cherchant 2 secondes, aucune idée de si c'est la meilleure méthode). J'imagine quand même qu'on doit perdre quelques garanties au passage (et certaines optimisations genre LTO).

Dans les avantages de la chrysalide, je me demande dans quelle mesure ça peut être frustrant avec la solution des lignes de vue que le jeu interdise de se transformer à un endroit mais qu'il l'autorise quelques pixels plus (mais je ne sait pas ce qui est fait comme feedback de la part du jeu, et peut-être qu'en pratique cela ne sera jamais gênant).

Merci pour ta réponse très complète !

Journal très intéressant comme d'habitude !!

Les extra-terrestres étaient limités par le fait qu’ils ne pouvaient pas évoluer à proximité d’humains, ce qui posait problème sur les petits niveaux de jeu. Dans le future, la présence des humains seuls ne sera plus suffisante pour interférer, à la place, les extra-terrestres supposément timides seront empêchés d’évoluer par la connexion visuelle avec les ennemis et leurs constructions.

(disclaimer: je n'ai jamais joué au jeu)
J'imagine bien ne pas être le seul à y avoir pensé, mais quel souci ça poserait (ou posait si ça déjà été essayé) que l'alien passe dans un état de chrysalide où il est particulièrement vulnérable pendant plusieurs secondes, rendant de facto risqué de faire sa mutation à proximité des ennemis ?

La plupart des jeux Battle Royale (…) (exactement ce qu'ils sont, des bousins répétitifs qui utilisent des techniques d'accrochage et de manipulation sur les enfants),

une Switch Lite, ça se trouve à 150€ en occaz' et il y a quelques jeux dessus (Minecraft, Fortnite, Fall Guys, etc)

Fortnite et Fall Guys étant des battle royale j'ai du mal à comprendre ton message et ce que tu conseilles (je me demande si tu ne parles pas de Gatcha).

Voilou:
https://www.youtube.com/watch?v=kJSNTfSUz3o