barmic 🦦 a écrit 5920 commentaires

Je comprendrais ta critique pour une traduction par défaut où il faudrait aller chercher la version originale, mais là c'est une facilité pour l'anglophone. Ça fait le job pour tout ce qui n'est pas un texte véritablement littéraire.

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

C'est vrai ils ont pu mettre à jour une fois ou 2 depuis :p

C'est une blague, je ne doute pas que ça s'est amélioré. Et ça montre qu'il faut prendre soin des projets qu'on aime.

Et c'est toujours bien de ne pas trop fanfaronner en sécurité, on rarement à l'abri de faire les mêmes erreurs voir de faire pire. À minima c'est une piqûre de rappel pour tout le monde

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

L'exception des quelques boites qui respectent ce genre de processus ne peut pas être pris comme une vérité générale. Même Boeing est loin de faire ça bien…

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

Tu devoir lancer des commandes arbitraires pour divers étapes[…]

Je ne le crois pas. La majorité des projets sont globalement la même chose, je ne crois pas qu'il soit nécessaire de lancer doom dans son système de build. Réinventer un build pour chaque bibliothèque est un échec d'ingénieure.

Je suis d'accord qu'on peut faire mieux, mais tu as le risque de multiplier les DSL si tu limites trop, ce qui est déjà aussi un probléme, on a un DSL pour le Makefile, un DSL pour générer le fichier configure, basé sur un autre DSL via M4, le tout qui produit un script avec des idiomes spécifique pour être portable.

Multiplier les DSL n'est pas fondamentalement problématique à mon humble avis. S'ils restent simples ça n'est pas un coût si important. Là M4 est capable de muter le système de build.

[…] je ne pense pas que la dite levée de bouclier était une question d'ego ou d'état d'esprit.

Je n'en ai pas la preuve, mais j'en suis convaincu. Une standardisation du build (comme on peut le voir avec maven qui décrit l'arborescence d'un projet, les étapes d'un build, etc) est souvent mal vu parce que ça fait 50 ans qu'il y a des dizaines/centaines de manières de faire qui perdurent de génération en génération. L'intérêt de cette standardisation n'est pas perçu par des développeurs qui ont l'habitude de faire leur petits tricks pour ajouter tel cache ou faire de la précompilation des en-têtes, alors que c'est vécu comme un affront de faire autrement (pour un choix qui n'est pas fondamentalement mieux qui est juste une règle).

C'est pareil pour les gestionnaires de paquets pour distro, sauf erreur de ma part, y en a aucun qui n'a de possibilité de faire des scripts.

C'est vrai, je ne sais pas à quel point c'est utilisé dans debian, la plupart des paquets ne devraient pas en avoir besoin du tout (dès maintenant) et pour les autres cartographier les cas (ajout de modules dans le noyau, ajout d'une police,…) pourrait réduire à peau de chagrin les cas où c'est utile.

Et un dernier souci, c'est à mon avis la difficulté à imposer une norme dans certaines écosystèmes comme le C. C'est en effet bien mieux dans Rust ou Go, mais même la, tu as des échappatoires comme le build.rs (et rien en Go, que je sache).

Tout à fait et "convention over configuration" ça n'a pas infusé partout malheureusement.

Après chacun fais bien ce qu'il veut, mais j'évite autant que possible de complexifier le build.

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

Il faut soit trouver des particuliers et pour cela jouer les influenceurs Twitter 20 fois par jours tous les jours, éventuellement streamer son développement, développer une communauté de fans, ne présenter qu’un profil cool et jovial et éventuellement se retenir de donner son avis publiquement sur autre chose que l’objet du financement, se construire éventuellement un personnage, et susciter des dons de la part de sa fanbase.

Je me permet une remarque. Je comprends tout à fait que se mettre en avant n'est pas une option pour toi, ça ne le serait pas pour moi. Mais le fait de s'effacer derrière son travail, si c'est noble, n'aide pas du tout à faire prendre conscience aux gens que tu existe, que tu es une personne seule sur ton temps libre, etc. On peut difficilement demander à ce que des gens qui n'ont que peu d’interaction avec toi connaissent ta situation alors que tu fais tout pour ne pas la mettre en avant. Avant les problèmes d'OpenSSL combien de gens savaient comment était développé la bibliothèque ? Combien de gens se rendent compte de la différence de moyens qu'il y a Gimp et Blender ?

Ce n'est pas pour dire qu'il faut se vendre, se mettre en scène, etc, mais que ce n'est pas une question de starlette

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

Pour moi tu as besoin que chaque brique ai une vocation spécifique de la quelle elle ne peut pas sortir. Ça réduit considérablement ton scope et rend l'analyse bien plus simple.

Avoir un fonctionnement déclaratif est parfait pour ça. Je suis intimement convaincu que l'énorme majorité des projets pourraient utiliser un paradigme déclaratif pour leur buil, mais soit n'ont pas le bon état d'esprit soit ont une forme d'ego pensent que leur projet a une spécificité.

On gagne aussi beaucoup de temps à ne pas reconstruire tout à chaque projet.

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

L'unique solution que je vois à ça et à pleins d'autres cas c'est le revenu universel. Il y a beaucoup de travail que l'économie actuelle ne sait pas financer indépendamment de l'utilité publique incontestable (et à contrario il y a pleins de choses qu'elle ne finance que trop bien malgré l'impact négatif sur la société).

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

Autoconf n'est pas complexe parce qu'il veut gérer pleins de choses, mais parce qu'il ne veut pas prendre de décision. Les outils opiniated sont drastiquement plus simples (et peuvent avoir la souplesse pour gérer tout ce dont on a besoin). Avoir 25 langages turing-complet dans son build c'est avoir une complexité démentielle (et énormément de moyens d'ajouter des failles comme on le voit ici).

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

Il y a aussi des entreprises qui font des prestations pro-bono pour les petites structures ou des assos qui ne pourraient pas payer la prestation, genre des audits de sécurité.

Quand c'est une entreprise c'est gratuit, mais pas du bénévolat. Soit les employés sont payé, soit ils ne le sont pas et hors truc du genre auto-entreprises, c'est… illégale ?

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

Dans le cas général, il faut pour ça avoir compromis un dépôt et t'être débrouillé pour signer des paquets. Sauf que si tu a fais ça, tu n'a plus besoin de xz pour faire ce que tu veux des machines ciblées.

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

Histoire d'ajouter mon troll à l'édifice le système de build complexe n'y est pas pour rien et a rendu possible la compromission et difficile l'analyse. Garder un build aussi simple que possible me paraît être encore plus une bonne idée.

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

Et combien de codes propriétaires sont compromis depuis des années ?

Je suis d'accord que ce n'est pas parce que du code est public qu'il est revu ou audité, mais l'inverse n'est pas vrai pour autant.

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

Ça fonctionne si tu accepte de n'avoir aucune sécurité et que tu ne regarde pas les détails. Les encodages hors ascii étendu ça fait ce que ça peut, les envoi de groupe c'est bon an mal an, les SMS long ça marche pas sur les téléphones un peu vieux,… Et c'est une souffrance à implémenter et à maintenir.

Le tout pour un truc qui a tous les défauts des solutions pas terribles sur internet : relié au numéro de téléphone, géré par des entreprises privées sans possibilité d'accès public,…

Je me fou du réseau. On peut implémenter un truc mieux sur SS7, mais ce truc est un enfer sur Terre. Ça vous convient parce que vous ne regardez pas comment ça fonctionne, vous ne voulais pas voir les problèmes et vous écrivez avec de l'ASCII étendu.

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

Je pense que la confiance envers xz est rompue, […]

La question n'est pas de savoir s'ils ont eu ou non une faille, mais de comment le projet se comporte et je ne vois pas d'erreur. Ils vont en plus réaliser un audit.

Je ne vois pas ce qui me permet de leur faire moins confiance qu'un projet dans le quel je ne sais pas.

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

Tu connu d'utiliser SSL, MD4 et tu stock des mots de passe avec la célèbre méthode du décalage de césar ?

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

Je parle d'obsolescence des protocoles pas des devices (pour énième fois). Tous les protocoles utilisés dans le cadre de l'envoi d'SMS sont cassés et oui quand quelque chose est cassé à sa fondation (qu'il se base sur des hypothèses fausses autour de lui) alors corriger le problème c'est le refaire sur une base seine.

Quand les fondations sont en carton, je n'espère pas que la maison va tenir sous prétexte que le portail a l'air solide.

Mais si tu veux continuer à utiliser MD4 pour t'assurer que tes téléchargements sont sûr personne ne t'en empêche.

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

Et il faudrait que ça meurt parce que c'est chiant à maintenir ?

Oui. Pour l'énième fois. Que tu puisse toujours utiliser ton téléphone aussi vieux que tu le souhaite (bon si tu prends un téléphone vraiment vieux tu peut déjà avoir des surprises avec les SMS longs, les encodages de SMS ou les SMS de groupes par exemple) via une passerelle et quand tu aura besoin d'un nouveau téléphone ce dernier devrait être compatible avec le nouveau et tu pourra continuer de contacter tous tes anciens contact en utilisant cette passerelle de l'opérateur. C'est 1000 fois plus simple, moins couteux, ça pourrait permettre d'améliorer à terme la sécurité des utilisateurs, ça permettrait d'avoir un fonctionnement bien plus efficient,…

La difficulté ce n'est pas de tuer le SMS (les protocoles qui le soustendent actuellement, pas l'usage du SMS) en ayant un gracefull shutdown pour te permettre de garder ton téléphone mais de faire bouger ceux qui font SS7 et qui gèrent ça vraiment comme des pieds (et ne veulent rien entendre).

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

Je comprends, mais je pense que c'est plus que l'on met beaucoup beaucoup de choses derrière un même mot (ou 2). Le libre a tellement gagné que pour certains "libre" implique "bien" et "bien" implique "libre".

Du code libre il y a pleins de façon d'en faire et sans plus d'information tu as globalement 2 garanties :

• tu peux utiliser le logiciel comme tu le souhaite
• tu peux forker le logiciel

et ça s'applique au code qui vient d'être publié l'avenir est toujours incertains. C'est globalement ce que décrivent avec plus de mots les 4 libertés fondamentales de la FSF ou les principes du logiciel libre selon Debian.

Le fait de trouver cool des projets communautaires qui sont libres produits une métonymie. C'est dommage parce que ça ne contribue pas à augmenter le vocabulaire et à avoir des mots pour décrire des concepts différents. Je parlais l'autre jour de commun pour des logiciels libres ouverts aux contributions avec partage de la propriété intellectuelle et diversité effectives des contributions.

En y réfléchissant c'est un problème qu'on retrouve en politique. Si tu parle de fascisme, tu rentre dans une discussion complexe sur qu'est-ce que le fascisme, alors que si tu parle de xénophobie, ça peut être bien plus factuel et sans problème d'interprétation.

Nommer les choses de manière pertinente n'est pas simple, mais c'est très utile (désolé j'ai un peu digressé).

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

J'en ai aucune idée pour le nom, j'avoue que je m'en fou un peu. C'est un terme très polarisant particulièrement ici, mais c'est un nom commercial.

S'il y avait une différence à faire je dirais que c'est moins la technologie d'écran que le fait de considérer que le système dessus est un OS polyvalent avec des logiciels plus ou moins variés à installer. Mais du coup c'est un continum et mon Nokia a clapet permettait certaines choses déjà et le smart des smartphone serait alors un téléphone rooté voir ceux en open hardware.

(quelque part ce serait la distinction entre console/micro ordinateur/compatible)

Pour l'usage je ne saurait pas te dire, je ne me permet pas d'essayer le téléphone de mon neveux.

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

Si si il faut et c'est grâce à ça qu'on dégomme toutes les versions de SSL par exemple. Ensuite il faut créer des passerelles pour ceux qui n'ont pas de possibilité de faire autrement et quand les passerelles n'auront plus d'utilisateurs on pourra leur dire au revoir.

Dans l'informatique (comme dans d'autres domaines) ne pas vouloir ou savoir gérer la conduite de changement c'est un vrai problème. C'est un élément vital pour pouvoir éponger sa dette technique. Ne pas le faire c'est épuiser les personnes en charge, avoir des temps toujours plus long et une qualité toujours plus mauvaise. Et ça ne nécessite pas de rendre obsolète du matériel, très souvent tu peux proposer une frontière pour cloisonner et donc surveiller l'ancien.

C'est pas marrant, ça prend du temps, mais c'est le travail. Faire des études terrain dans le BTP, c'est pas fun mais faut le faire, il y a pas le choix.

J'imagine que tu va me dire que ce n'est jamais fait ou un truc du genre, mais :

• quand c'est bien fait tu n'es pas au courant
• ce n'est pas parce que d'autres font mal qu'il faut niveler par le bas, tout le monde fait du jeux vidéos closed source ça n'est pas ce qui t'empêche d'en faire des libres

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

SS7 est l'une des plus belles démonstrations que la sécurité périmètrique c'est pour les clowns.

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

et je vois pas en quoi c'est un problème (sauf chez les fanatiques du tout-data)

Je dis que le SMS c'est de la merde techniquement. Si tu trouve que SS7 c'est génial et que internet c'est le mal très bien. Parce que j'imagine que c'est le réseau internet qui pose problème ? Parce que si c'est une question de vie privée tu expose bien plus de choses avec le SMS qu'avec certaines autres solutions internet. Mais je n'ai pas pointer de remplaçant en vrai je m'en fou, je trouve qu'il n'y a pas beaucoup de travail pour faire mieux, la difficulté se situe plus dans le fait de remplacer l'existant. Et pour ça je trouve qu'il y a déjà assez à faire pour simplement que attendre que le parc se renouvèle, créer des passerelles etc pour ne pas en plus avoir une sorte d'adoration parce qu'il véhicule une image qui est loin de ce qu'il fait en réalité (il n'est pas énergétiquement, efficace, très complexe, très peu sécurisé et exposant beaucoup de données personnelles. Et il y a une différence entre l'utiliser parce qu'il est pratique et considérer ceux qui pointent les problèmes qu'il pose sont des fanatiques.

le téléphone et les sms survivent pour une raison simple : tout le monde n'a pas de malinphone, et n'en veut pas forcément
ou n'a simplement pas la situation à l'instant T pour avoir internet mobile

Tu sais qu'une grande proportion des téléphones vendus aujourd'hui qui ne sont pas des smartphones ont whatsapp ? Par exemple tous les téléphones Nokia dis classiques sous KaiOS.

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

Je veux bien dire du mal d'Amazon,

Je me permet, mon point n'est pas qu'Amazon est mal ou pas (il est mal à mon avis pour d'autres raisons bien plus problématique), mais de savoir comment des super structures comme Amazon (et ses amis de l'acronyme) impact l'écosystème qui les entoure. Ce que fait Amazon est normal dans sa situation, comme ce que faisait AT&T était normal. Cela n'empêche pas de questionner son impact et d'en tirer des conclusions.

Simplifier le problème à "dire du mal" ou "aimer" tel ou tel truc c'est passer à côté de la question. Le fait que les entités l'entourant ont fait des choix à problèmes ne change pas foncièrement les choses d'autant qu'il est facile de faire le procès 10 ans plus tard.

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

S'ils n'ont pas prévu de rotation des clefs, il me semble qu'il y a un gros problème dans la méthodologie.

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

Pour autant MySQL résiste peu à son fork MariaDB packagé dans toutes les bonnes distros Linux, OpenOffice.org est resté sur place — avec 4-5 développeurs qui se battent en duel — là où plus de 500 personnes ont contribué à LibreOffice et avancé plus vite que OOo + Go-OOo à l'époque qui ramait à rajouter ses patchs sur une nouvelle version sortie inopinément après dévs en interne…

Ce que tu décris c'est surtout que lorsqu'Oracle abandonne des logiciels, leurs forks libres marchent mieux.

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