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.
Avec des VM ils est vraiment contraignant, mais tu peut l'utiliser avec docker. C'est très confortable, tu a bien moins de problème d'interface etc. Je l'ai utilisé pendant les confinements. Avec des VM c'est un enfert, mais avec des conteneurs ça passe tout seul.
C'est un outil qui permet de créer et manipuler des sockets tcp et udp.
C'est bien mais pas parfait. Le fait d'utiliser des numéros pour identifier les sockets n'aident pas les étudiants qui doivent jongler entre le port local, le port destinataire, le n° de socket local et le n° de socket destinataires (ils utilisent plusieurs machines à côté les unes des autres donc ils voient les 2 côtés tout le temps).
Garantir non, mais que ce soit le cas dans les faits oui. Dis autrement, tu ne peux pas le prouver, tout en n'observant pas de cas où ça se produit.
Après je connais peu de gens qui s'assurent que leur soft ne soient pas préempté par le noyau. Si tu cherches du temps réel dur clairement, il faut soit pas utiliser de gc soit des gc faits pour ça (tu as des gc qui n'ont pas de stop the world). Si tu ne veux juste pas de freezes c'est tout à fait envisageable et il est possible de trouver des exemples qui fonctionnent avec et sans gc et des exemples qui fonctionnent pas avec et sans gc.
Bref si pour toi avoir des performances stable c'est du temps réel dur, c'est en effet compliqué, mais c'est du coup un usage assez limité.
Mais tu as des outils d'analyse mémoire en java (et tout ce qui est basé sur la jvm) qui sont sans commune mesure avec ce que tu trouve ailleurs. Rien à voir avec valgrind.
Ensuite toujours pour java, tu as du tweak de jvm par rapport à ton code.
J'en profite pour mettre le lien vers la vidéo évoqué dans l'article qui hélas n'est pas passée dans le contenu de l'article : "Pourquoi Maurice ne doit surtout pas coder en GO", de Jean-Laurent de Morlhon (directement sur l'extrait sur le "pourquoi" réel de Go pour Docker).
Pareil avec un GC : si tu gardes une référence vers un objet inutilement, ni Rust, ni Go, ni aucun langage ne va t'aider.
La gestion de l'ownership réduit pas mal le risque, mais tu as toujours la possibilité d'écrire des algos monstrueux d'un point de vue mémoire.
Je suis tombé il y a quelques semaines sur un exercice de simplification sur twitter où pour passer d'un algo en O(n4) à O(n2) pas mal de participants alloués une map de n2 éléments.
Même s'il n'a pas de garantie contre ça le borrow checker va limiter les risques de bugs quand tu voudra corriger.
La JVM et son outillage sont aussi de grandes aides pour détecter et corriger des problèmes mémoire. Je ne connais pas d'équivalent à Memory Analyser ailleurs par exemple.
[^] # 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
# 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.
Je donne aussi ce genre de TP.
Avec des VM ils est vraiment contraignant, mais tu peut l'utiliser avec docker. C'est très confortable, tu a bien moins de problème d'interface etc. Je l'ai utilisé pendant les confinements. Avec des VM c'est un enfert, mais avec des conteneurs ça passe tout seul.
On utilise socklab ici https://github.com/drakkar-lig/socklab
C'est un outil qui permet de créer et manipuler des sockets tcp et udp.
C'est bien mais pas parfait. Le fait d'utiliser des numéros pour identifier les sockets n'aident pas les étudiants qui doivent jongler entre le port local, le port destinataire, le n° de socket local et le n° de socket destinataires (ils utilisent plusieurs machines à côté les unes des autres donc ils voient les 2 côtés tout le temps).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: LibO ce n'est pas qu'un traitement de texte
Posté par barmic 🦦 . En réponse à la dépêche LibreOffice 7.4, un maître numéro de version. Évalué à 2.
D'autant plus sur Apache OpenOffice du coup ;)
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.
Garantir non, mais que ce soit le cas dans les faits oui. Dis autrement, tu ne peux pas le prouver, tout en n'observant pas de cas où ça se produit.
Après je connais peu de gens qui s'assurent que leur soft ne soient pas préempté par le noyau. Si tu cherches du temps réel dur clairement, il faut soit pas utiliser de gc soit des gc faits pour ça (tu as des gc qui n'ont pas de stop the world). Si tu ne veux juste pas de freezes c'est tout à fait envisageable et il est possible de trouver des exemples qui fonctionnent avec et sans gc et des exemples qui fonctionnent pas avec et sans gc.
Bref si pour toi avoir des performances stable c'est du temps réel dur, c'est en effet compliqué, mais c'est du coup un usage assez limité.
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.
Mais tu as des outils d'analyse mémoire en java (et tout ce qui est basé sur la jvm) qui sont sans commune mesure avec ce que tu trouve ailleurs. Rien à voir avec valgrind.
Ensuite toujours pour java, tu as du tweak de jvm par rapport à ton code.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Manque d'humour
Posté par barmic 🦦 . En réponse au journal Élisabeth II bronsonnisée : bien fait ?. Évalué à 0. Dernière modification le 09 septembre 2022 à 10:22.
Doublon
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Manque d'humour
Posté par barmic 🦦 . En réponse au journal Élisabeth II bronsonnisée : bien fait ?. Évalué à 6.
Et linuxfr d'avoir un humour piquant avec la bronsonisation.
L'une des plus belles blagues que j'ai lu de ma vie fut à l'une de ses occasions pour quelqu'un envers qui j'ai un profond respect.
https://linuxfr.org/users/lmouillart/journaux/dennis-ritchie-est-bronsonis%C3%A9#comment-1279771
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.
C'est moins un pourquoi qu'une petite pique.
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.
La gestion de l'ownership réduit pas mal le risque, mais tu as toujours la possibilité d'écrire des algos monstrueux d'un point de vue mémoire.
Je suis tombé il y a quelques semaines sur un exercice de simplification sur twitter où pour passer d'un algo en O(n4) à O(n2) pas mal de participants alloués une map de n2 éléments.
Même s'il n'a pas de garantie contre ça le borrow checker va limiter les risques de bugs quand tu voudra corriger.
La JVM et son outillage sont aussi de grandes aides pour détecter et corriger des problèmes mémoire. Je ne connais pas d'équivalent à Memory Analyser ailleurs par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll