D'autant plus pour un éditeur d'au moins 3 plateformes (windows, azure, xbox). C'est pas anormal de donner son avis. Surtout qu'on peut pas les taxer de mettre en avant un de leur produit (comme ça pourrait être le cas avec C# ou F# par exemple).
L'analyse statique ne fais que ce qu'elle peut quand le langage ne te donne pas la sémantique de ce que tu veux analyser. D'après-toi, pourquoi est-ce que ces solutions ne sont pas incluses dans gcc ou clang ? Pourquoi est-ce que c'est à ajouter à ton processus de build et pas directement inclut dans ton installation et activé avec un -pdantic ?
vous savez que les applications qui monitorent/contrôlent les réacteurs nucléaires, ou machines médicales à rayons X, ou autre trucs qui peuvent tuer des gens sont minoritaires ?
Les plus hautes sécurités ne sont pas liées au langage. C'est le processus de développement qui assure la qualité et non une silver bullet derrière la quelle on se sentirait protégé. Ça peut incorporer comment faire des tests, quand, sur quelle partie, comment suivre les défauts, la traçabilité des choix, ça peut inclure de la preuve de programme aussi, dans certains cas ça peut aller jusqu'à faire une enquête de de moralité des intervenants.
Aucune solution technique ne te protègera d'un bug fonctionnel hors dans les cas les plus critiques tu ne veux pas avoir de problème fonctionnel.
Vous savez que Rust n'a rien inventé ?
Comme tout langage rust est un équilibre choisi entre tout un tas de paramètres (sécurité mémoire, taille du runtime, sémantique du langage, système de type, etc) en prenant en compte l'état de l'art au moment de sa conception. L'équilibre choisi entre sécurité mémoire par défaut et légèreté du système de type le rend populaire.
C'est aussi bête de croire que rust résout toutes les difficultés sans surcoût que de se cacher les yeux en affirmant qu'il n'apporte rien.
La réalité est que les "libristes par conviction" sont tellement occupés avec leur petite personne qu'ils oublient de fournir quelque chose de concret, en effet.
C'est intéressant parce que tu es aussi l'un de ceux qui pointent du doigt ceux qui "n'aiment pas le libre". Il faut adhérer au libre sans conviction ?
Le plus amusant est qu'il n'y a rien de nouveau depuis pfff longtemps, toujours à se plaindre, jamais à se bouger.
Ça c'est des bêtises beaucoup beaucoup de gens font vivre leur idée du libre, construisent des communautés, du logiciel et/ou du service. Ils font ça avec leurs valeurs, tu peux essayer de leur dire que c'est pas du libre, que c'est à côté ou hors du libre c'est pas grave, c'est ce qu'ils font sans avoir besoin d'un tampon zenitram ou gnu approuval. Ils créent justement plutôt que d'étiqueter (ce qui est la raison d'être principal de tout libriste il faut pas ce le cacher).
Il faut garder une certaine sérénité rust ne fait pas tout. Ils continuent de bosser sur le borrow checker encore de version en version parce que tu as des cas où tu es très très loin de "l'aisance d'un gc sans runtime".
Il est très bien, je suis pas entrain de dire que c'est mauvais ou une fausse bonne idée, mais c'est pas (encore ?) le meilleur des 2 mondes sans aucun accroc.
Dans ton premier lien je ne suis pas sûr de comprendre :
pour le niveau de garantie élevé, il ne suffit pas qu’une carte à puce protège une clé cryptographique contre les manipulations non autorisées ; en outre, le protocole cryptographique doit protéger le mécanisme de vérification de la possession de la clé contre les manipulations non autorisées et les attaques par rejeu ;
Le second lien n'a pas l'air de dire que l'authentification forte nécessite un facteur de possession avec composants de sécurité et qu'il faut privilégier ceux audité par l'ANSI. Ça ne me semble pas proscrire les clefs (dont ils font d'ailleurs mentions en parlant de token fido).
Personne n'a inventé le capitalisme, c'est le système naturel lié à la liberté d'entreprendre qui a su faire ses preuves pour améliorer les conditions de vie de tous.
Ah ? Il a détruit la majorité des économies moins productivistes mais aussi moins destructrice. Il a amené de nouvelles classes de domination sociales lorsque la noblesse et le clergé ont perdu du pouvoir. Il a permis de faire des guerres et des massacres à des niveaux qui n'ont aucun sens.
Aucun autre système n'a d'ailleurs eu les mêmes impacts.
Tu parles de l'écocide ?
Tout n'était pas mieux avant loin de là, mais :
Ça n'est pas une raison pour ignorer ce qu'il produit de plus néfaste
Je ne suis pas certains que l'amélioration du niveau de vie ce soit fait grâce au capitalisme ou malgré lui. Dans le même interval, on a eu des progrès techniques majeurs mais aussi des avancées démocratiques
Quelque soit ce qu'il apporte ça ne le met pas hors de porter des critiques pour l'améliorer ou le remplacer
Simplement avancer qu'il serait "naturel" n'est pas un argument en soit.
Je ne trouve pas que ça mérite le mépris de ton premier commentaire, mais c'est vrai qu'il manque des trucs dans l'article. Comme la structure given/when qui est un switch plus puissant que dans la plupart des langages, le defer qui marche un peu comme go, différentes avancées dans les expressions régulières,… et je n'ai pas particulièrement suivi le langage ses 10 dernières années.
Le problème c'est que j'ai l'impression que les gens pensent "sous linux, la ligne de commande est normal, c'est la routine".
C'est exactement mon cas, mon terminal est mon gestionnaire de fenêtres. Je ne me dit pas "bon c'est de la cli, donc je dois faire particulièrement attention".
Est-ce que je suis un power user ? Probablement, mais pas en tout. Le fait que je sache me servir de git et de certaines fonctionnalités avancées de se dernier ne fait pas de moi quelqu'un qui maîtrise les subtilités d'apt (j'ai appris il y a 2 mois qu'il pouvait installer des .deb, on est plus obligé de passer par dpkg puis faire un apt-get -f install. Ça fait une petite dizaine d'années que j'ai raté l'info 😭).
Tu t'es contenté d'essayer d'adapter le cas de départ pour qu'il puisse fonctionner avec les différentes solutions à base de GC que tu avais en mains,
Tu a précisé le contexte dans le quel tu voulais te placer et je n'ai remis en cause que ton dernier point que je n'ai jamais vu appliqué.
ce qu'on ferait si on était contraint d'en utiliser un
C'était exactement l'objectif tu pense que c'était quoi ma thèse ? Montrer comment on fait avec un gc, en particulier sur la jvm que je connais mieux que les autres.
[…] ou de dire que tu ne vois pas où ça serait utile.
Oui en absence de cas pratique où c'est utilisé, je veux bien qu'on me montre.
Bref, toujours pas de solution à base de GC pour garantir une frame, donc de la stabilité…
Ta façon de répéter continuellement comme s'il s'agissait d'une joute que tu souhaiterais gagner plutôt que comme un échange de comment parvenir à un objectif est extrêmement irritant. Bravo, tu as gagné. Tu m'a écrasé. Je n'ai plus d'argument et tu peux te conforter dans ton idée initial. L'échange a dû te rassurer au détriment de t'enrichir. Tant pis.
Donc, tu ne peux pas dire "il me reste 14ms pour cette frame-ci, gc pendant ce temps" et à la frame suivante lui demander de le faire pendant 5ms parce que tu as du faire du calcul un peu plus intensif.
Je vois pas de cas où ça serait utile, cette gestion a un coût et peu être facilement source de bug.
Mais rien de tout ça n'est dynamique vu ce que tu as écrit plus haut.
Quand tu parle en frame tu n'es pas dynamique. Une frame est une période de temps. Quand tu construit ta logique avec ça, tu considère ton travail max à faire dans ta frame et c'est comme ça que tu dimensionne. Dans le cas des jeux puisque c'est l'exemple dont tu parlais, c'est pour cette raison là que tu as des limites de nombres de sprites par exemple.
mais le gc peut t'expliquer quand il a fait quoi et pourquoi ça couplé aux autres possibilités d'observabilité de la jvm t'es pas laissé tout seul pour te dépatouiller et comprendre ce qu'il se passe.
C'est bien beau, mais quand ça dépend de l'utilisateur on est loin d'un truc qui scale automagiquement
C'est une question de dimensionnement. Tu as une frame tu organise ce que tu peux faire ou non dans cette période. Tu met toujours une limite à ce qu'il est possible de faire sinon tu ne peux plus donner aucune garantie.
Mais si tu te retrouves dans le cas ci-dessus avec les garbage collector actuels, t'as rien d'autre à faire que tortiller tes données et virer des features pour pouvoir éviter d'avoir à nettoyer quand une gestion manuelle aurait pu t'éviter ce soucis.
"Tortiller tes données" oui et non. Il s'agit d'organiser ton logiciel autour des contraintes que tu lui donne. Si tu donne des contraintes forte de performance ça se verra sur ton code quelque soit le langage que tu choisi. Venir poser des contraintes très fortes pour ensuite reprocher que ça a un impact sur le code c'est assez vouloir le beurre et l'argent du beurre. Si tu fais des parallels arrays par exemple ou toute autre technique de data oriented design, tu va faire des choix qui vont s'approcher d'un "tortillage de donnée". C'est l'objectif même de rust de te contraindre à des formes de torillage de données pour ton bien et ceux que la mémoire soit un sujet ou non dans ton programme et il va te demander de débrailler des fonctionnalités (en particulier le borrow checker) pour arriver à ce que tu souhaite (un exemple de comment tu peux en arriver à tortiller tes données ou désactiver des fonctionnalités pour faire des références circulaires en rust).
Je vais arrêter là par contre, j'ai exposé, il me semble, des points précis sur comment faire et je n'ai pas l'impression que tes arguments aillent plus loin que « c'est pas assez parce que dans un contexte théorique on pourrait faire mieux », sans rentrer dans un cas pratique qui demanderait beaucoup de travail je ne vois pas comment aller plus loin dans la discussion et j'avoue que ça me fatigue un peu.
Je vois pas ce qui indique en quoi c'est plus ou moins efficace que ce fais java.
Je connais pas très bien python, mais il me semble qu'il doit bénéficier du fait que les bibliothèques qui manipulent de gros volumes de données font ça en C et sont donc hors de la pile. En java tu peux le faire sans passer par du C, mais ça me semble moins généralisé.
flatpack a une logique uniformisante : un gestionnaire de paquet unique en toutes circonstances, non ?
Le gestionnaire de paquet qui indique ne s'adresser qu'aux logiciels graphiques ? En quoi ? Parce qu'il est disponible quelque soit la distribution comme nix ou pkg-src par exemple ?
La logique hégémonique vient des gens qui disent qu'on devrait tout virer pour mettre ça à la place.
Plus que la LSB qui dit que la norme c'est rpm ? Qu'est-ce qui différencie une volonté d'hégémonie (tout à fait présentée comme négative) et une volonté de standardisation ? La discussion ? C'est ce qu'on a ici et dont fait parti cet article, la discussion n'empêche pas d'avoir un avis.
Monter sur ses grands chevaux comme ça en sortant des grands principes je trouve ça ridicule. Ça fait 20 ans que la discussion existe (oui ça existait avant l'arrivée de flatpack). On peut resté détendu je pense et éviter de prêter à ceux qui ne sont pas du même avis des adjectifs tout à fait superfétatoires.
Je parle de gc particuliers pour du temps réel, pour ne pas avoir de problème de temps de réponse les gc inclus dans openjdk font le travail. Non seulement ils font la majorité de leur travail sans bloquer ton application, mais en plus ils ont des options pour les contraindre en temps et en fréquence d'exécution.
Après tu as le tuning de jvm indépendent du gc. Tu peux dimensionner les générations et spécifier des configurations pour que les étapes du gc s'exécutent au moment opportun (ça n'est pas programmatique et impératif avec System.gc()).
Si tu te pose la question de frame de temps, c'est que tu contrôle finement tes allocations et tu va t'assurer que tes objets sont soient en old gen, soit qu'ils soient en young gen. Ta young gen est dimensionnée pour une seule de tes frame et le gc s'exécutera une fois par frame systématiquement et jamais plus que le temps que tu lui as donné. Son temps pour nettoyer ta young gen est tout à fait prédictible. C'est du grosse maille (oui faire du temps réel même soft c'est un métier), mais le gc peut t'expliquer quand il a fait quoi et pourquoi ça couplé aux autres possibilités d'observabilité de la jvm t'es pas laissé tout seul pour te dépatouiller et comprendre ce qu'il se passe.
Il a bon dos le gc, pas mal de fois où je vois le gc mis en cause il y a surtout des io synchrones utilisées un peu de partout et on essai de gagner 10ms de temps en temps sur le garbage collection sans s'inquiéter des 100ms de blocage fréquent dû à une io. Pour l'asynchrone c'est déjà bien plus hard de s'y retrouver, je sais qu'il y a un outil qui peut te prévenir si ton code sur la jvm fais des io bloquantes mais l'asynchrone peut rendre un code complexe et surtout fait perdre en prédictabilité des performances. Garantir que tu réponds sous un certain seuil demande à avoir des timeouts sur tout ce qui est asynchrone par exemple (du coup async/await t'aident plus beaucoup).
Désolé je suis un peu fleuve c'est pour rentrer un peu dans le détail et montrer l'approche. Il est bien sûr possible de faire mieux en faisant tout à la main, mais tu troque un contrôle plus simple (au sens KISS) pour un outillage très riche qui t'aide énormément à comprendre ce qui se passe. Le plafond indépassable en java ne semble pas à la portée de la première application même s'il existera toujours (mais est repoussé régulièrement encore l'an dernier avec zgc et Shenandoah).
En plus de ça tu peux toujours ne pas mettre les objets les plus volumineux dans la heap. Les assets sont volumineux et peuvent avoir des cycles de vie simples (on les charges et les libèrent à des points clefs) et ça permet de rester sur la simplicité d'usage pour le gros du code (celui qui est complexe, qui gère la partie logique de l'application) qui va interagir avec un gestionnaire d'assets qui sait quand charger/libérer les gros volumes. Ça marche aussi en utilisant un gc en bibliothèque en rust ou c++.
Je pense que la confusion c'est la distinction entre la taille de d'appli elle-même et ses dépendances et la taille des données manipulées. Si c'est peut être un problème pour ton erp, il existe pleins de cas où manipuler des Tio de données et logique (un serveur de sauvegarde par exemple ?).
Tout à fait pour les numéros de ports, mais ajouter des identifiants de sockets confusants ne me paraît pas utile. Ils construisent leur connaissance, c'est normal de tâtonner, c'est l'objectif d'un TP.
On peut présenter les choses différemment, si les sockets étaient identifiées par des lettres ("a", "b", "c",…), les étudiants feraient un peu moins d'erreur et je n'ai pas l'impression qu'ils leur manquerai quelques choses à la fin du TP.
Dans la pratique, c'est pas une difficulté qui va se présenter à eux quand ils manipuleront du réseau. Quand tu code ta socket c'est une variable, le numéro du file descriptor n'est pas un sujet.
De ce que je vois dans le lien c'est hardcore. Je me vois vraiment pas envoyer ça dans les mains de mes étudiants et c'est très spécifique linux.
Je ne connais pas Katharà (j'imagine que c'est au moins du même acabit), mais avec GNS3 une fois que tu as une image de conteneur pour moi une debian avec socklab, les étudiants peuvent facilement instancier autant de conteneurs qu'ils le souhaitent en choisissant pour chacun le nombre d'interfaces qu'ils ont et les relier comme ils souhaitent. Un click sur une machine pour ouvrir un terminal dedans et un sur un lien pour ouvrir Wireshark prêt à scanner ton réseau virtuel.
C'est important de supprimer toute la complexité technique pour ne pas perdre 30 à 45 minutes du temps du TP sur des difficultés techniques qui ne concernent pas le sujet du TP.
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par barmic 🦦 . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 3.
D'autant plus pour un éditeur d'au moins 3 plateformes (windows, azure, xbox). C'est pas anormal de donner son avis. Surtout qu'on peut pas les taxer de mettre en avant un de leur produit (comme ça pourrait être le cas avec C# ou F# par exemple).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par barmic 🦦 . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 8.
L'analyse statique ne fais que ce qu'elle peut quand le langage ne te donne pas la sémantique de ce que tu veux analyser. D'après-toi, pourquoi est-ce que ces solutions ne sont pas incluses dans gcc ou clang ? Pourquoi est-ce que c'est à ajouter à ton processus de build et pas directement inclut dans ton installation et activé avec un
-pdantic?Les plus hautes sécurités ne sont pas liées au langage. C'est le processus de développement qui assure la qualité et non une silver bullet derrière la quelle on se sentirait protégé. Ça peut incorporer comment faire des tests, quand, sur quelle partie, comment suivre les défauts, la traçabilité des choix, ça peut inclure de la preuve de programme aussi, dans certains cas ça peut aller jusqu'à faire une enquête de de moralité des intervenants.
Aucune solution technique ne te protègera d'un bug fonctionnel hors dans les cas les plus critiques tu ne veux pas avoir de problème fonctionnel.
Comme tout langage rust est un équilibre choisi entre tout un tas de paramètres (sécurité mémoire, taille du runtime, sémantique du langage, système de type, etc) en prenant en compte l'état de l'art au moment de sa conception. L'équilibre choisi entre sécurité mémoire par défaut et légèreté du système de type le rend populaire.
C'est aussi bête de croire que rust résout toutes les difficultés sans surcoût que de se cacher les yeux en affirmant qu'il n'apporte rien.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Un train qui arrive à l’heure
Posté par barmic 🦦 . En réponse au journal Tout le monde (ou plutôt, trop de gens) semble se foutre des licences en 2022. Évalué à 6.
C'est des fois décrit comme exception. Dans un cadre pédagogique c'est autorisé grâce au ministère qui fait ce qu'il faut pour : Exception pédagogique
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mes impressions
Posté par barmic 🦦 . En réponse au journal Performances et GC : détruisons les mythes. Évalué à 4.
et dans les 99 autres % (le bon dev n'est pas forcément un bon statisticien) il choisi ocaml
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Un pavé dans la mare
Posté par barmic 🦦 . En réponse au lien les drones utilisent linux : le logiciel libre ce n’est pas suffisant. Évalué à 5.
C'est intéressant parce que tu es aussi l'un de ceux qui pointent du doigt ceux qui "n'aiment pas le libre". Il faut adhérer au libre sans conviction ?
Ça c'est des bêtises beaucoup beaucoup de gens font vivre leur idée du libre, construisent des communautés, du logiciel et/ou du service. Ils font ça avec leurs valeurs, tu peux essayer de leur dire que c'est pas du libre, que c'est à côté ou hors du libre c'est pas grave, c'est ce qu'ils font sans avoir besoin d'un tampon zenitram ou gnu approuval. Ils créent justement plutôt que d'étiqueter (ce qui est la raison d'être principal de tout libriste il faut pas ce le cacher).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Sécurité de la mémoire sans C ni GC
Posté par barmic 🦦 . En réponse au journal Performances et GC : détruisons les mythes. Évalué à 9. Dernière modification le 18 septembre 2022 à 21:17.
Il faut garder une certaine sérénité rust ne fait pas tout. Ils continuent de bosser sur le borrow checker encore de version en version parce que tu as des cas où tu es très très loin de "l'aisance d'un gc sans runtime".
Il est très bien, je suis pas entrain de dire que c'est mauvais ou une fausse bonne idée, mais c'est pas (encore ?) le meilleur des 2 mondes sans aucun accroc.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'authentification multifactorielle n'est pas l'authentifcation forte
Posté par barmic 🦦 . En réponse au journal Clés de sécurité, pas assez utilisées. Évalué à 5.
Dans ton premier lien je ne suis pas sûr de comprendre :
Le second lien n'a pas l'air de dire que l'authentification forte nécessite un facteur de possession avec composants de sécurité et qu'il faut privilégier ceux audité par l'ANSI. Ça ne me semble pas proscrire les clefs (dont ils font d'ailleurs mentions en parlant de token fido).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: je sais que...
Posté par barmic 🦦 . En réponse au journal La richesse des ultra-riches, à raison de 1000 USD par pixel. Évalué à 6.
Ah ? Il a détruit la majorité des économies moins productivistes mais aussi moins destructrice. Il a amené de nouvelles classes de domination sociales lorsque la noblesse et le clergé ont perdu du pouvoir. Il a permis de faire des guerres et des massacres à des niveaux qui n'ont aucun sens.
Tu parles de l'écocide ?
Tout n'était pas mieux avant loin de là, mais :
Simplement avancer qu'il serait "naturel" n'est pas un argument en soit.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Toujours pas convaincu
Posté par barmic 🦦 . En réponse au lien This is not your grandfather’s Perl. Évalué à 4.
Je ne trouve pas que ça mérite le mépris de ton premier commentaire, mais c'est vrai qu'il manque des trucs dans l'article. Comme la structure given/when qui est un switch plus puissant que dans la plupart des langages, le defer qui marche un peu comme go, différentes avancées dans les expressions régulières,… et je n'ai pas particulièrement suivi le langage ses 10 dernières années.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: commande explicite et rollback
Posté par barmic 🦦 . En réponse au journal Comment j'ai installé Fedora 37. Évalué à 4.
C'est exactement mon cas, mon terminal est mon gestionnaire de fenêtres. Je ne me dit pas "bon c'est de la cli, donc je dois faire particulièrement attention".
Est-ce que je suis un power user ? Probablement, mais pas en tout. Le fait que je sache me servir de git et de certaines fonctionnalités avancées de se dernier ne fait pas de moi quelqu'un qui maîtrise les subtilités d'apt (j'ai appris il y a 2 mois qu'il pouvait installer des
.deb, on est plus obligé de passer pardpkgpuis faire unapt-get -f install. Ça fait une petite dizaine d'années que j'ai raté l'info 😭).https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ne pas craindre la Faucheuse
Posté par barmic 🦦 . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 1.
Bon je remet une petite pièce.
Tu a précisé le contexte dans le quel tu voulais te placer et je n'ai remis en cause que ton dernier point que je n'ai jamais vu appliqué.
C'était exactement l'objectif tu pense que c'était quoi ma thèse ? Montrer comment on fait avec un gc, en particulier sur la jvm que je connais mieux que les autres.
Oui en absence de cas pratique où c'est utilisé, je veux bien qu'on me montre.
Ta façon de répéter continuellement comme s'il s'agissait d'une joute que tu souhaiterais gagner plutôt que comme un échange de comment parvenir à un objectif est extrêmement irritant. Bravo, tu as gagné. Tu m'a écrasé. Je n'ai plus d'argument et tu peux te conforter dans ton idée initial. L'échange a dû te rassurer au détriment de t'enrichir. Tant pis.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ne pas craindre la Faucheuse
Posté par barmic 🦦 . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 3.
Je vois pas de cas où ça serait utile, cette gestion a un coût et peu être facilement source de bug.
Quand tu parle en frame tu n'es pas dynamique. Une frame est une période de temps. Quand tu construit ta logique avec ça, tu considère ton travail max à faire dans ta frame et c'est comme ça que tu dimensionne. Dans le cas des jeux puisque c'est l'exemple dont tu parlais, c'est pour cette raison là que tu as des limites de nombres de sprites par exemple.
C'est une question de dimensionnement. Tu as une frame tu organise ce que tu peux faire ou non dans cette période. Tu met toujours une limite à ce qu'il est possible de faire sinon tu ne peux plus donner aucune garantie.
"Tortiller tes données" oui et non. Il s'agit d'organiser ton logiciel autour des contraintes que tu lui donne. Si tu donne des contraintes forte de performance ça se verra sur ton code quelque soit le langage que tu choisi. Venir poser des contraintes très fortes pour ensuite reprocher que ça a un impact sur le code c'est assez vouloir le beurre et l'argent du beurre. Si tu fais des parallels arrays par exemple ou toute autre technique de data oriented design, tu va faire des choix qui vont s'approcher d'un "tortillage de donnée". C'est l'objectif même de rust de te contraindre à des formes de torillage de données pour ton bien et ceux que la mémoire soit un sujet ou non dans ton programme et il va te demander de débrailler des fonctionnalités (en particulier le borrow checker) pour arriver à ce que tu souhaite (un exemple de comment tu peux en arriver à tortiller tes données ou désactiver des fonctionnalités pour faire des références circulaires en rust).
Je vais arrêter là par contre, j'ai exposé, il me semble, des points précis sur comment faire et je n'ai pas l'impression que tes arguments aillent plus loin que « c'est pas assez parce que dans un contexte théorique on pourrait faire mieux », sans rentrer dans un cas pratique qui demanderait beaucoup de travail je ne vois pas comment aller plus loin dans la discussion et j'avoue que ça me fatigue un peu.
Bonne journée
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ne pas craindre la Faucheuse
Posté par barmic 🦦 . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 2.
Tu parle de ça ? https://towardsdatascience.com/memory-management-and-garbage-collection-in-python-c1cb51d1612c
Je vois pas ce qui indique en quoi c'est plus ou moins efficace que ce fais java.
Je connais pas très bien python, mais il me semble qu'il doit bénéficier du fait que les bibliothèques qui manipulent de gros volumes de données font ça en C et sont donc hors de la pile. En java tu peux le faire sans passer par du C, mais ça me semble moins généralisé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Unless the packager works around that
Posté par barmic 🦦 . En réponse au lien Traditional Packaging is not Suitable for Modern Applications. Évalué à 2.
Le gestionnaire de paquet qui indique ne s'adresser qu'aux logiciels graphiques ? En quoi ? Parce qu'il est disponible quelque soit la distribution comme nix ou pkg-src par exemple ?
Plus que la LSB qui dit que la norme c'est rpm ? Qu'est-ce qui différencie une volonté d'hégémonie (tout à fait présentée comme négative) et une volonté de standardisation ? La discussion ? C'est ce qu'on a ici et dont fait parti cet article, la discussion n'empêche pas d'avoir un avis.
Monter sur ses grands chevaux comme ça en sortant des grands principes je trouve ça ridicule. Ça fait 20 ans que la discussion existe (oui ça existait avant l'arrivée de flatpack). On peut resté détendu je pense et éviter de prêter à ceux qui ne sont pas du même avis des adjectifs tout à fait superfétatoires.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Parce que
Posté par barmic 🦦 . En réponse au journal Sobriété, j'écris ton nom. Évalué à 1.
Et le wifi ne va pas jusqu'à la cuisine
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Unless the packager works around that
Posté par barmic 🦦 . En réponse au lien Traditional Packaging is not Suitable for Modern Applications. Évalué à 0.
Ça manque d'exagération à mon avis. Ils tuent pas des bébés chats aussi ? Ça marche bien sur internet
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Parce que
Posté par barmic 🦦 . En réponse au journal Sobriété, j'écris ton nom. Évalué à 0.
Alors que tous les monsieur Michu y arriveront ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ne pas craindre la Faucheuse
Posté par barmic 🦦 . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 3.
Je suis pas sectaire j'veux bien une référence si elle n'a pas encore été garbage collectée bien sûr
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ne pas craindre la Faucheuse
Posté par barmic 🦦 . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 2.
Je suis curieux. Tu as un pointeur ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ne pas craindre la Faucheuse
Posté par barmic 🦦 . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 3.
Je parle de gc particuliers pour du temps réel, pour ne pas avoir de problème de temps de réponse les gc inclus dans openjdk font le travail. Non seulement ils font la majorité de leur travail sans bloquer ton application, mais en plus ils ont des options pour les contraindre en temps et en fréquence d'exécution.
Après tu as le tuning de jvm indépendent du gc. Tu peux dimensionner les générations et spécifier des configurations pour que les étapes du gc s'exécutent au moment opportun (ça n'est pas programmatique et impératif avec System.gc()).
Si tu te pose la question de frame de temps, c'est que tu contrôle finement tes allocations et tu va t'assurer que tes objets sont soient en old gen, soit qu'ils soient en young gen. Ta young gen est dimensionnée pour une seule de tes frame et le gc s'exécutera une fois par frame systématiquement et jamais plus que le temps que tu lui as donné. Son temps pour nettoyer ta young gen est tout à fait prédictible. C'est du grosse maille (oui faire du temps réel même soft c'est un métier), mais le gc peut t'expliquer quand il a fait quoi et pourquoi ça couplé aux autres possibilités d'observabilité de la jvm t'es pas laissé tout seul pour te dépatouiller et comprendre ce qu'il se passe.
Il a bon dos le gc, pas mal de fois où je vois le gc mis en cause il y a surtout des io synchrones utilisées un peu de partout et on essai de gagner 10ms de temps en temps sur le garbage collection sans s'inquiéter des 100ms de blocage fréquent dû à une io. Pour l'asynchrone c'est déjà bien plus hard de s'y retrouver, je sais qu'il y a un outil qui peut te prévenir si ton code sur la jvm fais des io bloquantes mais l'asynchrone peut rendre un code complexe et surtout fait perdre en prédictabilité des performances. Garantir que tu réponds sous un certain seuil demande à avoir des timeouts sur tout ce qui est asynchrone par exemple (du coup async/await t'aident plus beaucoup).
Désolé je suis un peu fleuve c'est pour rentrer un peu dans le détail et montrer l'approche. Il est bien sûr possible de faire mieux en faisant tout à la main, mais tu troque un contrôle plus simple (au sens KISS) pour un outillage très riche qui t'aide énormément à comprendre ce qui se passe. Le plafond indépassable en java ne semble pas à la portée de la première application même s'il existera toujours (mais est repoussé régulièrement encore l'an dernier avec zgc et Shenandoah).
En plus de ça tu peux toujours ne pas mettre les objets les plus volumineux dans la heap. Les assets sont volumineux et peuvent avoir des cycles de vie simples (on les charges et les libèrent à des points clefs) et ça permet de rester sur la simplicité d'usage pour le gros du code (celui qui est complexe, qui gère la partie logique de l'application) qui va interagir avec un gestionnaire d'assets qui sait quand charger/libérer les gros volumes. Ça marche aussi en utilisant un gc en bibliothèque en rust ou c++.
Bref j'ai pas été bref
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Beta
Posté par barmic 🦦 . En réponse au journal Comment j'ai installé Fedora 37. Évalué à 6.
Fedora c'est pas le nom de la beta de RHEL ? :-P
Je suis déjà loin --> []
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Facile
Posté par barmic 🦦 . En réponse au journal Sobriété, j'écris ton nom. Évalué à 4.
Je pense que la confusion c'est la distinction entre la taille de d'appli elle-même et ses dépendances et la taille des données manipulées. Si c'est peut être un problème pour ton erp, il existe pleins de cas où manipuler des Tio de données et logique (un serveur de sauvegarde par exemple ?).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Moi de même
Posté par barmic 🦦 . En réponse au journal Du routage sous Linux ou comment le temps passe et nous laisse seul avec nos souvenirs . Évalué à 4.
Tout à fait pour les numéros de ports, mais ajouter des identifiants de sockets confusants ne me paraît pas utile. Ils construisent leur connaissance, c'est normal de tâtonner, c'est l'objectif d'un TP.
On peut présenter les choses différemment, si les sockets étaient identifiées par des lettres ("a", "b", "c",…), les étudiants feraient un peu moins d'erreur et je n'ai pas l'impression qu'ils leur manquerai quelques choses à la fin du TP.
Dans la pratique, c'est pas une difficulté qui va se présenter à eux quand ils manipuleront du réseau. Quand tu code ta socket c'est une variable, le numéro du file descriptor n'est pas un sujet.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: cloonix
Posté par barmic 🦦 . En réponse au journal Du routage sous Linux ou comment le temps passe et nous laisse seul avec nos souvenirs . Évalué à 2.
De ce que je vois dans le lien c'est hardcore. Je me vois vraiment pas envoyer ça dans les mains de mes étudiants et c'est très spécifique linux.
Je ne connais pas Katharà (j'imagine que c'est au moins du même acabit), mais avec GNS3 une fois que tu as une image de conteneur pour moi une debian avec socklab, les étudiants peuvent facilement instancier autant de conteneurs qu'ils le souhaitent en choisissant pour chacun le nombre d'interfaces qu'ils ont et les relier comme ils souhaitent. Un click sur une machine pour ouvrir un terminal dedans et un sur un lien pour ouvrir Wireshark prêt à scanner ton réseau virtuel.
C'est important de supprimer toute la complexité technique pour ne pas perdre 30 à 45 minutes du temps du TP sur des difficultés techniques qui ne concernent pas le sujet du TP.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Moi de même
Posté par barmic 🦦 . En réponse au journal Du routage sous Linux ou comment le temps passe et nous laisse seul avec nos souvenirs . Évalué à 2.
Euh je ne comprends pas. J'en ai pas parlé, je ne connaissais pas. J'ai juste dis que GNS3 aussi peu utiliser des conteneurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll