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.
Avec une gestion manuelle tu peux facilement prendre des mesures pour l'évacuer petit à petit, et choisir ce qui est primordial d'évacuer en fonction du contexte, et avoir une garantie de stabilité dans les performances.
Pas simplement. Les use-after-free, double-free, etc n'existeraient pas par exemple.
La mémoire n'est pas une question triviale indépendamment du langage que tu utilise et la manière de simplifier ça c'est de se placer dans des cas typiques qui vont rendre mécaniques la gestion de la mémoire. Et quand elle est mécanique le faire à la main, via RAII, gc,… est simple.
Ne pas s'intéresser à la question et se la prendre quand on découvre que ça fait des semaines, mois, années qu'on applique aucune règle posera toujours problème.
rust te contrains à entrer dans des cas qu'il sait gérer (mais il y a des patterns qu'il ne sait pas gérer) dès le départ.
RabbitMQ en particulier ne touche par défaut pas au disque, les messages de 50Mio tout en mémoire ça peut devenir très consommateur.
Le principe broker de message + db pour le volume est assez classique ça n'est pas quelque chose de particulièrement alambiqué.
Ah et ça n'a rien à voir, mais si tu utilise rabbitmq activer le plugin manager (dispo de base) aide beaucoup à s'y retrouver avec une interface pour comprendre et administrer le tout.
De plus l'eau froide l'été et l'eau froide l'hiver ne sont pas la même température d'eau (outre le fait qu'on ai envi de chaud l'hiver et de froid l'été).
[^] # 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
[^] # 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.
Pas simplement. Les use-after-free, double-free, etc n'existeraient pas par exemple.
La mémoire n'est pas une question triviale indépendamment du langage que tu utilise et la manière de simplifier ça c'est de se placer dans des cas typiques qui vont rendre mécaniques la gestion de la mémoire. Et quand elle est mécanique le faire à la main, via RAII, gc,… est simple.
Ne pas s'intéresser à la question et se la prendre quand on découvre que ça fait des semaines, mois, années qu'on applique aucune règle posera toujours problème.
rust te contrains à entrer dans des cas qu'il sait gérer (mais il y a des patterns qu'il ne sait pas gérer) dès le départ.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Si je puis me permettre ...
Posté par barmic 🦦 . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 2.
La loi c'est toi ET L'ORDRE !
Je ne me permettais pas :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Broker de messages
Posté par barmic 🦦 . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 2.
RabbitMQ en particulier ne touche par défaut pas au disque, les messages de 50Mio tout en mémoire ça peut devenir très consommateur.
Le principe broker de message + db pour le volume est assez classique ça n'est pas quelque chose de particulièrement alambiqué.
Ah et ça n'a rien à voir, mais si tu utilise rabbitmq activer le plugin manager (dispo de base) aide beaucoup à s'y retrouver avec une interface pour comprendre et administrer le tout.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Si je puis me permettre ...
Posté par barmic 🦦 . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 2.
C'est à Guillaume Maillard que je pensais.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Douches froides
Posté par barmic 🦦 . En réponse au journal économie d'electricité. Évalué à 2.
De plus l'eau froide l'été et l'eau froide l'hiver ne sont pas la même température d'eau (outre le fait qu'on ai envi de chaud l'hiver et de froid l'été).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll