barmic 🦦 a écrit 5946 commentaires

Je donne aussi ce genre de TP.

Il y a GNS3, qui est l'artillerie (trop) lourde

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

LibreOffice qui est le successeur de OpenOffice.org1 on va dire 2 contributeurs vs 500…

[…]

Donc, bon, si vous aimez l'orthographe ou la typographie, ya de quoi faire :-)

D'autant plus sur Apache OpenOffice du coup ;)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

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

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

Doublon

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

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

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).

C'est moins un pourquoi qu'une petite pique.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

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(n⁴⁾ à O(n²⁾ pas mal de participants alloués une map de n² é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

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.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

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

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

C'est à Guillaume Maillard que je pensais.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

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

Donc les droits unix tu pense que c'est de trop par exemple ? Les LSM, la gestion d'utilisateurs, etc pareil ? La distinction kernelland/userland ? Les switch de context que ça implique nuisent aux performances et ça demande beaucoup de configuration bien complexe. Perso je joue avec TLS tranquillement et je comprends rien à SELinux.

Ta métaphore fais écho à cet article : The End of the Fortress Metaphor [EN].

La sécurité c'est d'abord du bon sens puis de la formation

La sécurité c'est avant tout une science donc non pas du "bon sens" (et globalement à chaque fois qu'on se dit que quelque chose est de l'ordre du bon sens faut faire gaffe). Au niveau le plus bas, tu applique des principes (mots de passe utilisateurs enregistrés salés et hashés par exemple) et quand tu monte tu va jusqu'à définir tes menaces de sécurité (security threat pour les recherches sur internet) et ainsi faire tes propres choix.

Je ne dis pas qu'il faut mettre du TLS partout, mais que l'argument du bon sens et de trouver ça complexe ne sont pas de bon conseillers.

Pour rappel la RGPD crée un délit de manque de sécurité. Il faut sérieusement que la sécurité ne soit plus une variable d'ajustement traitée au bon sens quand ça nous embête pas trop.

Les security threats c'est ce que la CNIL recommande avec l'"approche par les risques". Ici il est question de savoir si un attaquant peut ou pas exécuter du code arbitraire sur la machine si tu ne considère pas que c'est possible alors non seulement le chiffrement offert par TLS est inutile, mais je ne vois pas en quoi gérer des droits sur la machine est utile.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Des fois c'est 2 ou 3 semaines ou simplement dépendant de comment tu fais ton déploiement, de la charge ou de la résilience souhaitée.

On sait en plus maintenant faire du TLS configuré semi automatiquement assez transparent.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ah évidemment comparaison n'est pas raison

cela me fait penser au type qui pose des digicodes sur toutes les portes de sa maison (y compris les toilettes) avec rotation à la semaine des codes :)

C'est comme si l'on appliquait le code de la route qu'hors des villes.

Lien avec les motards un vendredi. C'est un conte kem's ! :p

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Dring<

Ca reste de l'artillerie lourde, mais passer par HTTP permet de profiter de plein de bonnes choses. […]

Christophe B.<

Comme tu le dis cela reste de l'artillerie lourde

Puis mon commentaire qui parle de la simplicité de HTTP et de l'overhead de TLS et TCP.

Avant de me balancer ta condescendance à la gueule, pourrais-tu lire ce à quoi tu répond ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Du coup c'est le mot valise qui est galvaudé ? :D

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il serait pas plus simple de sécuriser les accès extérieurs et de laisser l'intérieur tranquille non ?

Ça dépend. Est-ce que ce sont 2 choses qui sont effectivement toujours sur la même machine ? Est-ce que ça le sera toujours ? Ça dépend du ou des security threats qui te concernent.

C'est toujours plus simple de ne pas faire de sécurité, mais la difficulté n'est pas forcément une métrique très pertinente pour savoir si ça vaut le coût ou non. Particulièrement en matière de sécurité qui peut vite s'avérer rébarbatif sans apporter de fonctionnalité.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour contrebalancer un peu, si une application se met à interagir :

• en ws
• en pipe nommé
• en socket unix
• en bus
• en corba
• en amqp
• en xmpp
• …

parce que chaque bout de l'appli a trouvé plus pertinent d'utiliser son truc qui fit parfaitement. Ce n'est pas une solution.

Et le curseur d'où est-ce qu'on rationalise par rapport à faire le choix spécifique dépend des équipes. Une petite équipe et/ou moins technique rationalisera probablement plus.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Comme tu le dis cela reste de l'artillerie lourde

Je vois pas en quoi. Par exemple j'ai déjà fais du REST avec authentification TLS du client pour transmettre du protobuf. HTTP c'est un adressage (le verbe + le chemin) et des entêtes. TLS et sa négociation ou TCP avec entre autre sa gestion des congestions font déjà peut être plus de bruit.

HTTP est un protocole vraiment simple. Tout ce qui est complexe est en optin. C'est toi qui choisi de transmettre du XML, d'utiliser OAuth, d'avoir une websocket, etc.

Note qu'utiliser une socket unix ou un pipe (nommé ou non) ne change pas la question de l'encodage de ce que tu transmet (XML, JSON, messagepack, avro,…).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour ceux n'auraient pas d'environnement sous la main :

% xclip -o > Sapin.java
% java Sapin.java 12
           *           
          ***          
         *****         
        *******        
       *********       
      ***********      
     *************     
    ***************    
   *****************   
  *******************  
 ********************* 
***********************
           #  

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est pas parce qu'un mot est polysémique ou a un sens dépendant du contexte qu'il est devenu un mot valise et/ou qu'il est vidé de son sens. Surtout qu'ici il parle toujours d'un contrat d'un ensemble de méthode utilisé par un programme qu'il s'agisse d'une API C, dans le langage du dis programme, via dbus, corba, soap, rest, rpc, graphql,…

Tu trouve aussi que sauvegarder est un mot valise parce que ça peut être en mémoire, sur disque, dans une base de données, dans le cloud ou autre ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je vais pas réitérer une troisième fois avec une troisième personne.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais je m'en fou de tout ça. La question initiale que je n'ai jamais quittée c'est : le quel des 2 donne la liberté au destinataire sur comment le lire ?

• HTML peut être bloquant dans des cas de publipostage par exemple effectivement (les MUA que je connais ne permettent pas de contrôler la taille, c'est il faut avoir rédigé le HTML ailleurs, etc)
• le texte les standards te conseille de mettre des retours à la ligne à une taille maximale qui n'est pas si grande

Les 2 autorisent celui qui envoie à saboter la lecture mais d'un côté il faut un usage particulier des MUA pour le pratiquer et de l'autre ne pas le pratiquer constitue un piétinement des bonnes pratiques.

On peut imaginer avoir un autre protocole, de nouveaux standard, des usages différents et envisager tous les tenants et les aboutissants, mais la question était simplement le quel donne le plus de contrôle au destinataire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll