barmic 🦦 a écrit 6221 commentaires

Je pense que dans toute entreprise, on ne devrait que très rarement embaucher à un poste de haut niveau car c'est alors beaucoup plus facile de se tromper que de valoriser une personne d'un niveau en dessous pour ses compétences.

La logique c'est de prendre quelqu'un qui est bon à son poste et à l'en changer ? C'est le principe de Peter ça :)

[...] cela rapproche les cadres des ouvriers...

Je connais une boite où tous les employés doivent passer une semaine par an sur le poste le plus bas de l'échelle. Ça n'empêche pas toute la hiérarchie de ne faire aucune confiance en vers leurs employés.

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

Je rajouterai pour les grandes entreprises et administrations françaises, le corporatisme, le filtre pour accéder aux postes à direction se fait sur ton école d'origine, X, Ponts, mine ou centrale pour simplifier et non pas sur la compétence des individus.

C'est un ingénieur sorti des hautes écoles françaises qui est responsable du Vasa ? La NASA est dirigée par des diplômés d'écoles françaises ?

Tu semble chercher avoir un apriori (pas forcément sans fondement) et cherche à y recoller alors qu'il n'y a rien qui permet de le faire. Ce que montre la dépêche c'est que le problème est justement nettement plus large que ça, qu'il le dépasse en espace et en temps. Il est généralement plus intéressant pour corriger un problème de chercher la racine, son essence, plutôt que de s'attaquer à son aspect extérieur.

Ensuite ce n'est pas l'énumération de quelques cas qui peuvent prétendre montrer s'il s’agit d'un problème systémique. À coté de ses cas (non exhaustifs) combien réussissent ? Pourquoi ils réussissent ?

Définir la cause d'un échec est bien complexe, c'est rare qu'une personne sabote un projet. Il y a généralement des séries de problèmes qui mènent à un désastre (ça peut aussi se voir dans la réalisation d'un film d'ailleurs, même si juger de la qualité d'une œuvre est plus subjective).

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

Tu as besoin de révoquer ces certificats et ça ne monte pas en charge. À chaque fois que tu veut valider un certificat, il faut aller vérifier les liste de révocations (CRL). Plus tu allonge la durée de validité plus tu allonge la taille de la CRL.

Une durée de vie longue augmente la durée pendant la quelle tu accepte des algorithmes faibles (algo de chiffrement, somme de contrôle,...).

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

Relance le avec un nouveau profile (firefox -P).

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

Comment la faille du "request" à été utilisée ? Question certainement très bête mais j'ai pas réussi à comprendre la méthode de compromission. Le pirate à vu que tu à mis request et ensuite profité de cette faille, mais comment?

Il existe une bibliothèque très utilisée en python qui s'appelle request, il est facile de se tromper et d'aller chercher requests. Le script d'installation de ce dernier installe un petit logiciel de espion.

Il explique que requests s'est fait éjecter de pip avant d'avoir le temps d'installer en prod. Donc il a eu une erreur (la dépendance n'existant plus) plutôt qu'une faille.

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

Pour le Rust ils créent une fondation dédiée, on verra si ça le sécurise.

Cela fait un an que rust réfléchis à passer à une fondation dédiée, même si l'annonce est concomitante ce n'est plus lié que ça. Il s'agit pour eux de montrer que Mozilla n'a pas la main mise sur rust.

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

Super nouvelle ! Tu aurais pu en parler dans la dépêche :-)

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

N'étant pas un "gamer" je ne saisis pas pourquoi les souris standard ne conviennent pas. Qu'est-ce que ces souris ont de plus ?

Moi c'est par récupération que je l'ai. Mais globalement les souris pour les jeux ont quelques caractéristiques :

• un dpi plus élevé
• une fréquence de polling plus élevée ça aide à mieux transcrire les mouvements très brusques
• plus de boutons pour pouvoir mettre de action sur le pouce par exemple
• des profils pour avoir de résolution et des configurations différentes par jeux
• de résolution dynamique pour passer rapidement d'un dpi bas à un dpi très élevé pour gagner en précision

Bien sûr pour chaque trucs, tu va avoir des outrances : des dpi debilement élevés, des fréquences de polling qui n'ont plus de sens, etc

La gestion des led n'est que de la cosmétique, mais ça peut plaire.

Certaines permettent de personnaliser la forme et le poids de sa souris. Ça me paraît gadget.

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

J'ai une SteelSeries 100 moi aussi et au branchement j'avais état déçu d'avoir une couleur différente de celle du rétro éclairage de mon clavier... Je suis tombé sur ton logiciel qui a superbement fonctionné.

Je vais essayer celui-là. Encore merci :)

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

Rust c'est leur seule solution. Ils ont essayé ce qu'ils ont trouvé pour gérer les threads en s'interfacant avec le reste de leur code et en ayant pas de race condition. Ils ont pas trouvé.

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

J'ai du mal à voir comment les HashMap et les HashSet pouvaient être implémenter pour ne pas s'appuyer sur la correspondance. J'imagine qu'ils refaisait un equals systématiquement.

Pour la fonction de hash des string peut-être que java a changé en 1.2, mais il n'a pas changé ensuite pour passer à murmur3 contrairement à tout les autres langages.

Si tu as un code qui s'appuyer massivement sur substring ton code a pu avoir un problème quand ils ont changé son comportement.

Oui il y a eu des changements, mais le fais que sur 25 ans, on puisse les lister et qu'une partie étaient des bugs sous-jacent, montre que c'est plutôt stable.

J'ai pas compris ta remarque sur template ? Ça n'a rien à voir avec la stabilité et ce ne sont pas vraiment des outils comparables.

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

Je ne trouve pas trace et la javadoc de 1.5 expliquait déjà qu'il fallait que ce soit cohérent. Je serait intéressé de trouver plus de détail si quelqu'un a.

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

Tu fais bien d'indiquer la langue parce qu'avec un nom comme ça on pourrait se tromper

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

il produit des diffs bruités

Ce n'est pas ce que j'ai observé (du peu que je m'en suis servi) et c'est l'un des principaux objectifs du projets. Tu aurais un exemple en tête ?

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

Eclipse pas Oracle.

Tout à fait Jarkata EE c'est eclipse.

Si Graal est techniquement extrêmement intéressant, Oracle semble aussi profiter du mouvement pour casser le statuquo du tout libre & gratuit.

En créant un projet libre & gratuit ? Aujourd'hui graal est microscopique et ne pourra jamais se faire une place sans quarkus de Red Hat. Je ne suis pas sûr qu'il supporte un jour l'ensemble de java et a 1 ans et demi de retard sur son support de java. C'est vraiment s'embêter beaucoup pour pas grand chose. D'autant qu'ils continuent de libérer leurs outils maisons inclus dans leur distribution de java.

Pour moi le risque est là.

Hotspot est effectivement en fin de course, mais OpenJ9 est là et a l'avantage d'être accessible en remplacement directe. Graal n'est intéressant pour le CPU bound et est moins bon que hotspot en mémoire. Il est très peu probable que Java passe à graal.

Ce ne serait même pas intéressant pour Oracle qui ne pourrait plus vendre ses licences OSB, weblogic, etc et ça c'est du cash qu'ils font aujourd'hui pas de l'hypothétique dans 5 ans.

[...] soit que Graal ne prenne pas et que la plateforme ait perdue beaucoup d'efforts.

Dans le monde des techno (voir scientifique) un travail n'est jamais perdu. Le truc qui arrivera après pourra s'appuyer de l'expérience en question (si c'est un échec). PHP6 n'a pas tué PHP par exemple alors qu'il a consommé en proportion beaucoup plus d'énergie.

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

Tout le monde se fout du besoin réel, [...]

J'adore cette hypothèse. C'est un joli exemple de doublepensée 🙂

Sérieusement CSS 3 apporte beaucoup de de choses très utiles par exemple pour le positionnement ou les web components.

Tu parles de problème de support de standard. Vous en voyez encore ? C'est vraiment minime pour ce que je vois sur les navigateurs qui représentent plus de 90% du marché. On peut voir des problèmes sur les fonctionnalités récentes et pointues comme récemment pour Firefox avec jitsi, mais c'est plus un temps de prise en compte qu'un mauvais support comme on a pu le connaître à une époque.

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

Par ailleurs Oracle ayant un passif sur la segmentation/fermeture de trucs ouvert (coucou MySql), java est désormais un langage appartenant au passé.

Ils ont passé la main au projet OpenJDK ce qui met le JDK Oracle sur un pied d'égalité (organisationnel en tout cas) avec tout ceux qui veulent fournir un JDK que ce soit ta distribution, adopt openjdk, amzon ou autre.

Même l'une des partie les plus fermées, JavaEE s'est organisé au sein d'Apache et est aujourd'hui émancipé d'Oracle.

Oracle reste un très gros acteur de Java (il fourni de l'infra, de la main d'œuvre, ils ont sorti des projets comme graal,...), mais il le fait au même titre que RedHat, Google ou IBM pour parler de très grosses boites.

Je ne vois pas comment on peut sous-entendre que Java prend le même chemin que MySQL si on s'est un peu intéressé au sujet.

Bien sûr on peut parler du procès Oracle/Google, c'est pas le premier et ce ne sera pas le dernier procès du genre, on a eu AT&T, on à celui-ci, on en aura d'autres.

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

j'ai largement modifié le xmx; par contre je suis intéressé pour savoir si y'a d'autre paramètres existants;

Les gc java ont des quantités folles d'options ! Le problème va plus être dans le temps que tu veux y accorder. Il faut regarder quel GC est utiliser et chercher ses options (voir activer les logs du gc). À minima jouer sur les tailles des générations peut pas mal jouer.

car y a des fois il le blo (en même temps l'antivirus à tendance à me geler les IHM de manière complètement aléatoire, et de me faire un segfault avec dump de ram (c'est ça qui gèle tout j'imagine));

Pourquoi ne pas désactiver les coredump ? Je crois qu'il est possible de les désactiver de manière général et ne les activier que ponctuellement.

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

Je doute que des utilisateurs qui gardent des semaines des logiciels ouverts en préférant se plaindre plutôt que se demander si le logiciel qu'ils utilisent est fait pour être utilisé comme ça et est-ce qu'il y a des configuration à appliquer pour cet usage, ils seront malheureux quelque soit le logiciel que tu leur met entre les mains.

En théorie, pour que ce soit rapide je suis d'accord qu'il faudrait tout écrire en C++ ou mieux en Rust mais ce n'est pas le même taf...

On parle de consommation mémoire (comme ça avait l'air d'être question plus haut) ou de vitesse ? Faut se demander ce qu'il fait et voir comment le configurer peut être (les historiques, le filewatch, les indexes,...), il y a même de quoi surveiller ce qui consomme au sein de vscode.

Pour être économe en mémoire avec des langages comme C++ ou rust¹ , il va falloir éviter de fragmenter la mémoire et je ne crois pas que soit inclus dans ces langages et cette gestion va aussi avoir un overhead mémoire (probablement inférieur à celle d'un gc je suis d'accord).

Si on ne connaît pas la cause du problème, comment proposer une solution ?

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

C'est probablement pas à europython qu'il aurait fallu en parler. Il n'existe pas de gestionnaire de paquets pour les 2 langages qui s'interfacent avec le reste du mondeC et C++. C'est probablement par là qu'il faudrait commencer. La communauté python n'a probablement pas envie de se convertir à la maintenance de paquets systèmes.

Ça tombe bien, des gens qui font de l'empaquetage de ce type de bibliothèque, il y en a pleins. Le seul problème c'est qu'ils sont tellement qu'ils n'arrivent pas à se mettre d'accord sur un format de paquet... pkgsrc, nix et guix comme ils sont utilisables par un simple utilisateur peuvent probablement faire le travail.

Mais la plupart des utilisateurs d'un langage s'en foutent. Ils regroupent ça dans les prérequis systèmes qui inclus aussi la présent de telle base de données par exemple et vont gérer ça avec soit les de l'infra automation (ansible, salt, puppet,...) ou des images systèmes prêtes et réutilisables (vagrant ou docker).

Du coup le problème est adressé autrement.

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

Quasiment tous les projets java utilisent ce principe.

Et python et les projets qui utilisent doxygen et julia et ocaml et golang...

Cela dit, avec asciidoctor par exemple, on devrait pouvoir externaliser cette documentation.

Ça ne fais pas la même chose. Tu ne peux associer cette documentation à ton code. Donc aucun éditeur ne pourra t'aider. C'est pas inutile pour autant, mais ce n'est pas la même chose.

Ça fait sens si on veut la traduire et même documenter à partir des tests, des exemples de code tiré du git, présent dans d'autres fichiers.

Tout à fait beaucoup font vraiment leur tambouille pour ça que ce soit avec de la doc inline ou des trucs comme asciidoctor. Il y a même un langage dont la doc inline peut contenir une portion de code qui sera exécutable, mais j'ai pas pu retrouver où j'avais vu ça.

Je veux bien documenter une classe, au dessus du code de celle-ci, car ça ne gêne pas la lecture du code.

La plupart des éditeurs permettent de la cacher et les linters te fournissent un minimum de vérification de la correspondance.

Par contre documenter toutes les méthodes est une perte de temps, surtout lorsque ça paraît triviale.

Je n'ai pas dû être claire. Il s'agit de documenter l'API. La complexité du code sous-jacent n'a rien à voir. Si ça peut être plus clair, imagine le cas d'une bibliothèque C ou C++ qui décrit ça avec doxygen dans ses entêtes. L'écriture de cette documentation peut être antérieure à l'écriture du code qui l'implémente. Par exemple tu peut aller jusqu'à indiquer la complexité de l'implémentation et c'est alors judicieux de documenter aussi ce qui te paraît trivial. C'est un contrat de l'API.

Ah et ça ça concerne l'API et non tout le code (à moins que tout ton code soit une API). Généralement une faible portion du code d'une bibliothèque fait partie de l'API, sinon ça devient complexe à maintenir. On peut voir un exemple avec rxjava pour une classe qui fait partie de l'API et une qui n'en fait pas parti.

La doc inline qui explique un passage complexe est bien sûr primordial.

Encore une fois ça n'a rien à voir. Documenter une API et commenter un code sont 2 choses qui n'ont rien à voir et sont régulièrement faites par des personnes différentes (c'est celui qui implémente qui documente son code alors que rien ne l'oblige pour la documentation d'une API).

Je trouve important de la doc non associée à l'API qui décrit plus les concepts et qui ne soit pas organisée par rapport au code, mais l'un empêche pas l'autre et ils ont des objectifs bien différents.

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

Là il s'agit de créer une fondation ce qui n'est pas la même chose.

Clairement l'objectif est de se sortir de l'organisation de Mozilla, mais je pense que rust a passé le cap du langage de niche et peut effectivement voler de ses propres ailes, même si Mozilla laisse tomber.

Par contre j'aime beaucoup le premier draft : https://smallcultfollowing.com/babysteps/blog/2020/01/09/towards-a-rust-foundation/

Perso je suis pas fan de l'idée de créer des fondations à tour de bras. Peut être que les US n'ont pas d'équivalent de nos associations de loi de 1901. Mais quitte à je trouve bien plus sain de s'intégrer dans des fondations comme Apache, Eclipse ou Linux qui ont des moyens bien plus important pour fournir un cadre juridique, organisationnel, une visibilité et une série de garanties bien plus claires au près des contributeurs.

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

Ce n'est pas du commentaire de code, mais de la documentation d'API.

Un commentaire de code est là pour aider à celui qui lis le code. Il lui indique pourquoi les choses sont faites de cette façon (quand le code ne peux pas l'indiquer de lui même).

La documentation d'une API décris ce que fait l'API sans avoir besoin d'aller en lire le code. Pas mal d'éditeurs ter permettent d'y accéder sans aller voir le code. Très pratique quand tu veux entrer les paramètres d'une méthode en gardant la doc sous les yeux (ça évite les sauts qui, aussi rapides et efficaces qu'ils soient, obliger à repositionner ton regard.

Donc moi ça me choc pas.

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

Un serveur Web n’est donc plus nécessaire. De plus, vous pourrez bénéficier des mises à jour automatiques via votre navigateur.

Il en faut bien un pour l'autre coté de la websocket, non ?

Quand tu parle d'instance tu fais référence à quoi ? Tu peux avoir une grappe de serveur et balancer une tâche sur la grappe sans te soucier de qui la lance ?

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

Tu dira ça à Tux qui s'est honteusement fait voler la vedette par Tuz ! :)

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