barmic 🦦 a écrit 5800 commentaires

Ça me paraît compréhensible de vouloir un même rendu quelque soit la langue choisie à l'installation. Ça permet aussi d'uniformiser ton installation initiale. Tu réduits les chances de bugs dans une langue données. C'est probablement aussi bien plus confortable pour les japonais, coréens et chinois d'avoir moins de sauts qu'une police à l'autre avec des paquets qui semblent pour le moment avoir une dépendance en dure sur djvu.

Il est toujours possible d'installer et de configurer le système pour retourner sur djvu (vu les 2 je ne remarquerai probablement pas la différence dans les voir l'une à côté de l'autre).

Je ne sais pas en quoi mais en plus fedora parle d'une meilleure qualité.

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

Face au traitement d'un grand nombre de taches répétitives, il y a deux profils : ceux qui font l'effort de développer des outils afin que les taches soient traitées facilement, et ceux qui ne font pas d'outils et répètent les taches le plus efficacement possible. J'ai appris que je fais partie de la deuxième catégorie.

Il y a une troisième catégorie qui créé des outils pour que pleins de gens le fasse. C'est d'ailleurs ce que fait wikipédia.

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

Et aussi pour 4 = 4. Pour moi ça donne 4 = 5.

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

L'un empêche pas l'autre, mais l'importance me semble différente. Tu peux très bien avoir des TMS avec du bépo. Parce que la meilleure disposition ne remplacera pas le fait que c'est la répétition qui flingue les articulations et abimes les tendons.

J'en parle parce que souvent on place la discussion sur des aspects un peu techniques (des fois on approche la pseudo science avec des claviers ergonomiques dont l'ergonomie n'est pas prouvée) en omettant que la première règle c'est de bouger, de quitter son poste de faire des pauses, etc.

C'est pareil pour les caissières et caissiers c'est très bien qu'on ameliore leurs postes de travail, mais ça ne doit pas faire oublier les conditions de travail dans leur ensemble. C'est justement un truc qu'on voit beaucoup les employeurs qui leur donne de bons fauteuils et permettent à tout moment de passer d'une position assise à debout, mais les pauses c'est 4 minutes et si pendant que tu va en salle de pauses tu peux faire un peu de mise en rayon ce n'est pas plus mal.

J'ai dis osef pour mettre les pieds dans le plat, mais c'est une vérité. Il ne faut pas trop se focaliser sur un point précis et perdre de vue l'ensemble. Tu corrige bien plus en évitant de rester dans la même positions des heures qu'en t'imposant tel clavier, telle disposition, avec tel fauteuil.

La question est moins de revenir en arrière que de prioriser les choses.

Si je voulais être taquin :-P je te dirais même que tes tendinites sont peut-être parties non pas dû à l'ergonomie du bépo, mais au fait d'avoir changé de disposition donc d'avoir réappris à taper en gardant une meilleure position.

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

Par contre, de tous les témoignages que j'ai pu lire, ceux qui l'ont fait sont très content de l'avoir fait (malgré la courbe d'apprentissage) et ont eu un gain dans leur écriture.

Ceux où ça n'est pas le cas n'ont pas continuer et son revenu en AZERTY. Donc c'est évident que tous ceux qui sont passé en bépo sont contents. Il peu même y avoir un biais dont j'ai oublié le nom : j'ai trop investi dedans pour que ça ne me plaise pas donc ça doit me plaire.

Que bépo soit mieux ou pas je n'en sais rien et en soit on s'en fou un peu, mais l'argument est assez faible. En soit taper sur un clavier 12h/jour 7 jours par semaine te flingue les doigts que tu sois en AZERTY, en Dvorak ou en QWERTY. Il vaut mieux apprendre en faire des pauses et des exercises que de changer de disposition.

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

C'est rarement des linguistes qui sont normatifs des langues leur sciences consiste à la décrire et non à la faire évoluer. J'ai retrouvé un truc ministériel parler de frimousse. C'est pas très clair qui est derrière mais il n'est jamais fait mention de linguistes plutôt d'académitiens et d'experts probablement des professeurs de français ou de littérature.

Après tu dis bien comme tu veux frimousse ça se comprend parfaitement et je trouve personnellement que c'est effectivement élégant.

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

Ça aurait mérité un journal :-)

Il demande encore si des gens ont des remarques, c'est mergé mais pas releasé ?

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

Oui mais pour le coup c'est toi qui reproche l'absence de de recherche de variations sur une faille 0 day. Ça peut être totalement assumé pour limiter la faille le plus tôt possible au plus grand nombre quitte à avoir une série de corrections qui suivent. Sachant que la faille était activement exploitée ça ne me paraît pas un choix déconnant.

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

La question revient au même le jour où tu dois modifier le test.

Je ne comprends pas. Ce que je veux dire c'est que tu me dis que le gars va modifier le code puis se rendre compte dans les tests que ça invalide un test. Je suis que c'est une question de méthode s'il commence par les tests (en fait même pas une question de TDD juste du test first) ce ne sera pas le cas.

Tout le monde n'a pas la même notion de WTF mais oui, il me semble que vu les points précédents, il n'est pas question de commenter le code si le comportement est attendu

Alors qu'un défaut c'est bien plus objectif donc. Écrire un test pour chaque défaut (le développeur précédent est passé à côté du cas donc ça mérite un cas de test) et un commentaire dans certains cas (et ça peut se décider au second qui passe dessus et qui trouve que finalement ça mérite un commentaire).

Mais ce dernier point n'est pas nécessairement lié à un bug. La règle serait plus : un code wtf (parce qu'on doit se caler sur un comportement bizarre ou parce qu'on arrive pas à rendre le code plus clair) mérite un commentaire.

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

Que ce soit sur cette page ou ailleurs ne change pas drastiquement la pratique de ses challenges. Et je présume qu'il y a plus de victimes sur tiktok que via alexa

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

Si le commentaire était à jour, s'il avait été lu, s'il avait été mis au bon niveau, s'il avait été compris,… Oui.

Mais c'est une question de documentation par les tests, c'est aussi une question de méthodologie, si tu applique le TDD tu n'aura pas touché au code de production.

L'un n'interdit pas complètement l'autre, mais l'un est obligatoire l'autre est optionnel et induit un coup qui me paraît bien plus important que son gain (on ne passe pas des heures sans lire les tests ou les lancer).

Généralement on le met quand le bug appel à un code vraiment WTF.

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

Je dirais que c'est complémentaire.

Et moi que c'est redondant. Représenter la même chose 2 fois est le meilleur moyen de créer des incohérences.

les tests seront toujours exécutés.

Ah, tiens. On m'aurait menti ? :p

Notre outillage lance les tests avant de construire le binaire final (sauf si tu lui demande). Notre intégration continue les lance elle aussi et vérifie la couverture des branches. Déjouer toutes les vérification s'apparente plus à du sabotage.

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

D'après le wiki qui est pointé l'objectif premier c'est la cohérence du rendu entre le maximum de langues. Puis ils parlent de meilleure qualité. Ensuite effectivement ils parlent de gagner 6Mio, mais c'est plus un effet de bord il semble. Et comme c'est décrit il semble que noto est déjà installée par défaut.

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

À priori j'écris plutôt un test. C'est plus vivant et ça documente mieux je trouve. Et puis un commentaire, tu peux trouver des gens qui ne les lisent pas, les tests seront toujours exécutés.

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

Est-ce que le bug c'est pas aussi de voir se propager sur internet des "challenges" du genre "tranche-toi la carotide sans salir ta chambre" ?

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

On créé les IA à notre image. Ni plus ni moins.

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

Si par Red Hat, tu veux pointer sur les donations faites en décembre pour curl, plot twist, le virement a été fait par quelqu'un de mon équipe (à savoir Ruth).

Non je pense à quand ils ont était sponsors d'une petite conférence à Grenoble donc facturé par un petit JUG français.

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

Je pense qu'on peut dire que Youtube (ou assimilés) a une portée plus grande que la télé, et que la télé a une portée plus grande que les livres.

Le dernier Josephine Ange gardien a fait 4.6 millions de vue. Tu a peu de vidéos qui font autant sur youtube fr. Youtube est tout autre vidéo sur internet est relativement petit et l'on est biaisé en côtoyant que des personnes qui sont de la même bulle de média.

Il y a peu être un effet boule de neige qui voudrait que ceux qui regarde ça sont plus influenceurs que les autres, mais c'est toujours intéressant de se rappeler ces chiffres. La plus grosse audience monde sur twitch c'est 2.5 million de vues par exemple.

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

Bien sûr, on peut toujours viser un sous-ensemble de ces tests à tourner sur chaque commit, mais extraire et maintenir ce sous-ensemble demande un savoir-faire et une expertise sur nos bases de tests qui n'est pas forcément disponible. C'est surtout l'aspect maintenance de ce type de suite qui est délicat.

Vraiment sans chercher à te dire comment tu dois travailler ne l'ayant moi-même jamais mis en place, une technique pour ça est de gérer cette liste dynamiquement en fonction des statistiques de réussite et d'échec.

Ça part de 2 hypothèses :

• un test qui plante très rarement est moins utile qu'un test qui plante fréquemment (grosso modo ça veut dire que la fonctionnalité testée est plus simple à maintenir et échoue rarement)
• certains tests ont tendance à planter ensemble (si c'est une première étape commune à plusieurs tests qui est en erreur)

L'idée c'est donc d'alimenter un algo qui va lancer une base de tests qui plante plus souvent que les autres et qui limite la redondance.

Ça ne dit pas qu'on détruit tous les autres juste qu'on les exécute moins souvent.

Perso j'adore l'idée, même si je n'ai jamais eu l'occasion de le mettre en place.

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

J'ai posté une grosse réponse juste au dessus en pensant à vos 2 commentaires :) Je te réponds en direct juste pour que tu ai la notification.

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

Je ne sais pas si tu m'a classé dans les anti abstraction. Tout est une abstraction et ne pas décider de quel niveau d'abstraction on utilise ne veut pas dire que l'on en utilise pas juste que ce sera probablement mal fait.

Bref, quand tu dis que l'abstraction se fait au détriment de l'évolution ou de l'utilisabilité, je pense personnellement qu'à minima, on ne parle pas de la même chose car la création d'une abstraction n'à qu'un seul but détecter une situation problématique récurrente bien cadrée et déterminée pour proposer une solution ouverte et non enfermante.

Je pense qu'on parle de la même chose, mais qu'on ne le décrit pas de la même façon.

Je vais donner des exemples pour que ce que soit plus clair.

Un typage "trop" large

En java, la bibliothèque de collection décrit ArrayList ← List ← Collection ← Iterable.

Si tu as une fonction comme ceci :

boolean result = false;
for (var toto : totos) {
    if (this.predicate(toto)) {
        result = true;
    }
}
return result;

L'important n'est pas tant l'utilité du code, mais que le paramètre titi peut ici être typé en Iterable. C'est l'interface la plus ouverte que tu peux faire à cette fonction. Mais tu ne pourra alors pas la rééacrire pour tirer partie des stream de java 8 et plus (ou alors il faut que tu crée ton stream à la main) si tu avais gardé une collection tu pourrais écrire quelque chose comme :

return totos.stream().anyMatch(this::predicate);

Ce que je vois par là c'est que lorsque tu choisi tes types pour élargir l'utilisabilité, tu peux facilement te retrouver à retirer une propriété de ton contrat d'entrée qui n'a pas d'intérêt dans ton implémentation actuelle mais qui a tout de même son utilité.

L'utilisabilité d'un typage restrictif

L'autre direction c'est le classique des types cachés que tu peux trouver en ocaml par exemple. Tu peux définir un type encrypted qui est une string cachée (c'est à dire un alias sur le type string, mais qui n'est pas vu comme une string dans le système de type) et avoir des fonctions qui ne prennent que des données encrypted. Ça permet d'avoir des garanties supplémentaires, même si en soit ta fonction pourrait très bien prendre n'importe quelle chaîne de caractère.

Les problèmes d'un typage pas assez restrictif

Si j'écris en java:

List<Integer> ints = Stream.of(1, 2, 3).toList();
ints.put(4);

J'obtiens une exception parce que les List produites par toList() sont immutables. Donc aujourd'hui les développeurs d'openjdk sont coincés avec une interface List qui se considère mutable alors qu'ils aimeraient avoir des list immutables (oui oui c'est moche).

Là je donne des exemples sur des structures de données, mais tu peux avoir la même chose sur ton type générique (si tu es habitué à java : les T extends Bidule).

---

Des personnes influentes comme "Joel On Software" ont d'ailleurs parlé avec justesse du concept de "Leaky Abstraction" [1] pour dénoncer à l'époque et mettre en garde contre les dérives potentiels d'une utilisation abusive et non maitrisée des abstractions. Mais ce constat s'applique aussi à d'autre pratique par exemple l'optimisation prématurée [2] qui va conduire à des problématiques inutiles et couteuses à résoudre.

Faut que je retrouve j'avais suivi une discussion intéressante sur twitter où quelqu'un donnait un autre terme de "prémature optimization" bien plus clair pour ne pas invalider toute forme de discussion sur les performances.

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

Ensuite, encore une fois, pour une boite plus petite, je ne doute pas que c'est beaucoup plus simple. Une PME va juste faire le virement et basta.

Les boites auquel je pense c'est RedHat, Microsoft et Salesforce. C'est pas Amazon ou Apple mais il y a tout de même un GAFAM dans le lot.

Ton exemple me parait plus équitable que les histoires autour de Facebook, car Gitlab va aussi contribuer au pot commun, même si, comme tu le pointes, c'est un produit d'appel.

Il y a des cas qui sont de vrais problèmes. Je ne sais pas trop pour Facebook, mais prends un streamer twitch qui a des modérateurs qui n'ont aucune rémunération pour quelque chose qui constitue un véritable travail. Lorsque l'on parle de tout petits streamers qui ne vivent clairement pas de ça le bénévolat peu avoir du sens (c'est un peu comme les vidéastes qui film leur potes et connaissances pour faire des courtmétrages) mais quand il s'agit de streamers qui commencent à gagner leur vie, ça devient tout de suite discutable. Surtout que la relation avec des streamers n'est vraiment pas d'égale à égale (ils sont facilement mis sur un piédestal). Il est difficile pour notre code du travail d'à la fois s'assouplir pour permettre le travail indépendant et une flexibilité que certains demandent (et je pense ici à des travailleurs qui veulent être indépendant et pas à une remise en cause du contrat de travail que l'on connaît tous) tout en protégeant les conducteur uber.

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

Une cinquième vient d'être publiée. Toujours lié à jndi, mais uniquement si on utilise l'appender jdbc (c'est pour envoyer ses logs dans une base de données relationnelles pour ceux qui ne savent pas).

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

Sur une faille 0day tu travail forcément dans l'urgence. Vaut-il mieux fournir une correction partielle au plus vite ou une correction parfaite quelques jours plus tard.

Ils sont 4 (ce qui n'a rien à voir avec le fais que le code soit libre ou non) c'est forcément pas la même ambiance qu'une boîte énorme qui s'est déjà mangé des CVE dont des 0 day à foison (ce qui n'a toujours pas de rapport avec le libre).

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

Bon ils n'ont fait aucune recherche de variantes ce qui fait qu'on en est au 3 ou 4eme patch de suite a installer en deux semaines mais tout va bien !

C'est mesquin d'entretenir le flou pour les pourrir. Ils ont eu 4 CVE :

• la première concernait log4j 1.2 considéré comme une version obsolète depuis 6 ans
• la seconde c'est log4shell, ils ont viré la fonctionnalité pour 2.17 et sortie une micro pour toutes les autres versions impactées (pour continuer à maintenir des versions pour java 6 & 7 qui ne sont plus supportées hors peut être contrat avec red hat, je suis même pas sûr)
• la troisième est effectivement un cas mal géré dans les micro en question
• la quatrième n'a rien à voir et concerne la manière de gérer les variables, il ne permet pas d'ouvrir un accès mais de faire un déni de service

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