barmic 🦦 a écrit 5918 commentaires

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

T'as tout pareil avec un ordre de grandeur en plus en HTML hein, et depuis toujours, alors même que ça a été pensé à l'origine pour régler ce problème précis et laisser la gestion de la mise en page au client !

Dans les faits c'est faux. Tous les MUA que je connais ne font pas du optimisé pour je en sais quel taille quand ils sont configuré pour envoyer du HTML et tu marche sur les conventions si tu envoi des lignes de plus de 78 caractères.

On revient au propos de base : tu laisse plus de liberté au lecteur avec du html qu'avec du texte.

Bref, faire du mail textuel ça fonctionne, et on pourrait faire du texte enrichi, mais il aurait fallut un sous-ensemble assez strict du HTML dès l'origine pour que ça fonctionne bien.
Là on a des clients lourds qui intègrent un moteur de rendu HTML (ou plutôt l'inverse : un moteur de rendu HTML utilisé comme client mail, comme les webmails ou même thunderbird), ce qui est salement overkill pour de la transmission de texte enrichi.

On aurait pu faire pleins de choses, par exemple normaliser un markup et s'en servire. Mais aujourd'hui ça n'est pas le cas.

Yth, qui ne voit pas plus le lien avec le base64…

Tu peux faire des lignes de la taille que tu souhaite en encodant le corps en base64. Il me semble que c'est plutôt bien géré par les MUA.

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

Je n'ai toujours pas compris qui était volé quand les cours des actions changeaient, et je pense sincèrement que c'est absurde de penser que l'argent gagné par la spéculation vient de quelque part (surtout quand il est virtuel et que les actions n'ont pas été vendues).

Ce n'est pas de la spéculation. Ils sont en mesure de manipuler les cours. Par exemple en faisant que l'entreprise rachète des actions. Ils n'achètent pas de l'or ou autre, ils ont leur entreprise et utilisent la bourse.

Du coup, il faudrait prévoir de remettre à zéro régulièrement? Le plan c'est de renflouer encore et encore ceux qui ne savent pas garder leur argent?

Ou simplement plafonner ? L'État récupère et c'est démocratiquement que l'on décide de ce que l'on en fait.

"Savoir garder son argent" tu trouve que c'est une valeur que l'on doit mettre en avant ? Un peut comme si on changeait notre devise pour remplacer "liberté, égalité, fraternité" par "savoir garder son argent" ? C'est pas mon avis personnellement et je préfère que par fraternité, on aide ceux qui n'y arrivent pas. Surtout que c'est pas comme si la finance n'avait pas des angles morts qui sont très difficiles à financer (un tas de services aux enfants, aux vieux ou à ceux qui ont un handicap par exemple). Tu as un paquet de gens qui ne savent pas garder leur argent mais qui ama contribuent plus positivement que moi à la société.

Après, dans cette discussion, les entrepreneurs

On parle des ultra riches ne confond pas ton boulanger avec Bernard Arnaud.

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

Je n'aurais pas dis mieux.

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