barmic 🦦 a écrit 5800 commentaires

Je pense que la différence entre le fosdem et un développeur lambda, c'est que dans le premier cas, tu as du sponsoring avec une grosse communauté, donc le prix se justifie. Un développeur lambda, il ne va pas avoir la même aura ou alors il faut qu'il monte une structure et ça va lui demander du boulot.

Je ne suis pas organisateur du FOSDEM, la conférence que j'organise est bien plus petite et j'en ai vu la création. Le fait de faire toute les démarches semble être un acte technique. Pas amusant, plus ou moins long ou laborieux, mais ça a une influence limité sur l'acte d’achat.

Sincèrement j'ai l'impression que c'est se monter beaucoup le bourrichon pour juste répondre à la question "est-ce que c'est légal ou pas ?" et les boites qui y apportent un grand soin on l'habitude de le vérifier justement.

Il manque le lien de subordination qui est nécessaire pour qualifier un emploi la plupart du temps.

Ça me parait discutable. Si je clos un ticket qu'ils ont créé par exemple.

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

Mais je n'ai pas dit "une interdiction", j'ai parlé de "c'est pas si simple". C'est rien d'insurmontable, vu qu'on arrive à faire le sponsoring.

Tu parlais de contournement de loi et de sanction.

L'exemple du FOSDEM est aussi un bon exemple parce que le FOSDEM est une assoce, c'est établi et le sponsoring est tout les ans. Donc tu fais la paperasse une fois, et ça parait pas louche, et ça va.

Bof pour discuter avec les gens qui s'en occupe ça n'a pas l'air d'être un souci.

Tu donne l'impression que les entreprises ne peuvent pas payer et que c'est une paperasse incommensurable digne des travaux d'Hercule, ce n'est vraiment pas le ressenti que j'ai de la part des personnes qui font ces démarches.

Et je ne parle pas de la question du travail déguisé, parce qu'il y a aussi ce coté intéressant (à savoir que si une boite file de l'argent à X pour faire du travail sur un logiciel Y qui est vendu/utilisé, je comprends que les impôts regardent ça d'un œil bizarre car c'est comme une presta sans payer d’impôts, et les impôts, ils aiment pas ça)

Boh ça tu as pleins de cas louche. Si je contribue à un logiciel libre disons gitlab, est-ce que ça n'est pas du travail déguisé pour une entreprise qui va profiter de mon travail comme produit d'appel ? Je suis curieux de savoir comment la DGCCRF voit ce genre de choses.

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

Basé sur un profil, ça veut dire que ça se base sur les exécutions précédentes du programme. Il y a des patterns d'exécution qui sont les mêmes d'une exécution à une autre, donc autant optimiser ces parties-là. Surtout pour des programmes batch.

De ce que je comprends il faut comprendre profil comme dans profiling. La page wikipedia anglaise de PGO semble expliquer que c'est bien ce que fait hotspot.

Si je comprends bien. Le fait de le faire dynamiquement c'est ce que font hotspot et maintenant le .Net6 en pouvant revenir en arrière sur la compilation. Et tu peut le faire statiquement avec des compilateurs plus classiques si tu leur fournir une trace du profile (tu peux aussi le faire avec grallvm native image d'ailleurs).

Pour WSL (Windows Subsystem for Linux), du PGO est aussi à l'ordre du jour pour le kernel Linux. On verra donc peut-être ça débarquer dans certaines distribs Linux classiques :-)

Hum je comprends l'intérêt pour WSL ils doivent vouloir améliorer les performance et ont un usage un peu particulier de linux donc le binaire doit pouvoir être simplifié. Autant pour des distributions linux je vois pas.

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

Je comprends, mais c'est pas le problème. Une association ou une auto-entreprise peut très bien éditer des factures tout à fait légal au vu du droit français/européen/américain, par contre oui à la boite qui paie de s'assurer qu'elle a le droit de payer. Tu parle du FOSDEM j'imagine que c'est organisé par une association qui facture a des entreprises le sponsoring (dont au moins une grosse boite américaine de ce que je vois). Le fait qu'il faille faire des vérifications du côté de celui qui paie ne devrait pas s'interdire de le faire.

Pour être dans le cas d'une association qui facture des entreprises dont certaines américaines, je ne vois pas de problème particulier. Ils ont des protocoles qui peuvent prendre un peu de temps (les boites françaises aussi d'ailleurs), mais qui ne constitue pas une interdiction totale de le faire.

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

Je suis surpris pour le PGO je pensais que c'était le cas depuis longtemps. Si j'ai bien compris c'est ce qu'on trouve sur java depuis… 22 ans (j'ai dû chercher).

Comment ça fonctionnait ? En java la compilation est séparée en 2 parties C1 et C2.

• C1 est une compilation de java vers le bytecode de la jvm. C'est exécuté par le développeur (c'est le bytecode qui est livré)
• C2 se déclenche après le début de l'exécution du programme. Après avoir eu suffisamment de stats venant de l'interprétation du bytecode, hotspot choisi ce qu'il va compiler (en natif) et comment. Il peut ensuite revenir sur ses choix de compilation pour recompiler autrement. C'est l'étape d'interprétation du bytecode qu'on appel la chauffe de la jvm.

Si j'ai bien compris pour C# c'est au démarrage que tu as une compilation native ? Et maintenant il peut choisir de recompiler autrement des parties en fonction d'informations qu'il aura collecté à l’exécution ?

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

Perso je suis ravi de voir enfin une techno qui s'inspire fortement de Java en retirer enfin les bénéfices qui aurait dû être gardés dès le début -> être multiplateforme.

Ce n'est vraiment pas du troll, je ne suis pas d'assez prêt .Net pour être au courant. Il n'y a plus de petite astérisques là-dessus ? Genre WPF ou autre partie du SDK qui sont très couplés à Windows ?

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

D'acc merci pour l'explication

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

Hum je connais pas bien istio, il va rediriger les requètes vers lui via la résolution de nom ? Si oui il faut une network policies tout de même pour empêcher de le by pass par des requêtes direct sur les API c'est ça ?

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

Le projet étant née en 2003 ils ont clairement l'antériorité. C'est pas suffisant pour gagner un procès on est d'accord, mais en 20 ans ils n'ont jamais dérangé google à moins qu'ils ai un succès fulgurant soudain ça ne devrait pas poser plus de problème que ça.

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

Tu veux restraindre le FS par application, tu as systemd, avec ProtectHome et tout ce qui va avec (InaccessiblePaths, ReadOnlyPaths, etc, cf systemd.exec

Merci je connaissais pas.

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

Euh tu peux expliciter le problème ?

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

Je connais pas archive mais glacier c'est particulier. C'est vraiment pour de l'archivage (écriture quasi uniquement, la lecture et la suppression sont lents et chère).

C'est très bien pour certains usages, mais par exemple pour du backup incremental avec durée de retention c'est tout de suite moins sympa.

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

C'est moins une question de trivialité que d'exhaustivité.

Le niveau d'abstraction que tu cherche n'est pas toujours le même. Plus tu es abstrait plus tu gère de cas, mais ça peut être au détriment de l'évolution (tu as moins d'hypothèse sur ton type d'entrée, tu sais moins de choses sur lui) ou de l'utilisabilité (ton utilisateur peu moins se baser sur les types pour comprendre ce que tu attends). Dans un programme, tu es seul utilisateur, tu peux généralement énumérer tous les cas d'usages. Ça change drastiquement la donne.

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

Unix est un ultime indépassable et non modifiable ? Plan9 et GNU proposent des évolutions ils ne sont pas Unix ? (je n'ai jamais bien compris ce qui fais que linux n'est pas un Unix) Linux a déjà pas mal de choses, mais ça peut être simplifié. Comme les cgroup, avant lxc, docker et systemd (entre autre) ça n'était presque pas utilisé.

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

On a encore un bel exemple bien récent, illustrant en pratique ce à quoi s'exposent les naïfs qui se confient dans les mains de puissances pour lesquelles ils ne sont guère plus que des outils quand ils ne sont pas vus comme des parasites.

Ils avaient des explications et ont écouté leur communauté. Des problèmes de gouvernance tu en a aussi dans des projets libres tu sais. On a des exemples encore plus récents et qui n'est pas encore terminé (mais on peut en citer d'autres encore, hein ? regarde tzdata toujours pour cette année). Sachant que la critique qui a était faite à .Net on l'a déjà entendu pour Firefox ce dangereux navigateur qui voit les linuxiens comme des parasites.

Sérieusement, n'y a-t-il pas pléthore d'outils de programmation aux écosystèmes moins dangereux, voire libres[…]

Dont .Net ;)

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

Toujours a émettre des hypothèses sur les personnes qui te répondent.

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

Je ne sais pas trop comment on peut annoncer ça.

Ça demande aux parties prenantes de se mettre d'accord sur la façon de travailler, en choisissant des méthodes qui minimisent l'inventaire (développement non livré).

Ça veut aussi dire que tu n'a aucune fonctionnalité qui demande une semaine de travail ? Je trouve ça fou et il n'y a pas que l'héritage qui peut l'expliquer. Nous on déploie des incrément chaque semaine mais la fonctionnalité de bout en bout tu peut avoir quelques semaines/mois pour l'obtenir (d'autant plus si tu as des incidents à gérer et d'autres qui peuvent arriver avec de hautes priorités).

Pour le 1, même si cela semble assez basique il y a toujours des voix pour s'opposer (parceque c'est “cher”) mais j'ai toujours pensé que c'était important d'avoir ce genre d'environnement à disposition, notamment pour pouvoir faire du ”disaster recovery” et pouvoir garantir à son client qu'on peut recréer toute l'infra en temps fini si besoin.

Je suis d'accord mais chacun met le sens qu'il veut derrière les mots et fais sa tambouille. Sur mon projet on est capable de remonter toute l'infra, c'est à dire déballer les machines, les connecter, installer les OS, plus tout ce dont on a besoin et on connait les prérequis de la salle où installer les machines en alimentation électrique et en connectivité réseau entre autre (on est pas encore multi site). Je ne crois pas que c'est ce que tu entendais par recréer "toute l'infra" et du coup il y a pas mal de choses qui ne sont pas automatisées.

Je le vois un peu comme le fullstack où le côté full de la stack est variable selon à qui tu demande.

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

Bref, perso, je vais m'arrêter là parce que ça ne m'intéresse pas trop d'avoir des conversations avec gens qui cherchent la petite bête plutôt que d'essayer de comprendre le raisonnement de l'autre (ce qui n'empêche pas de ne pas être d'accord par ailleurs).

Dommage que tu le prenne ainsi. Ça faisait réellement plusieurs commentaires que je te pointé un paragraphe qui m'a intrigué et que je ne comprenais pas en te disant que je ne devais pas l'avoir compris.

Mon point c'est que quelque chose de dangereux est devenu super fluide, naturel, sans aucune vérification et sans aucune prise de recul de la part des développeurs.

C'est intéressant de le mettre en lumière comme l'avait fait Ken Thompson dans Reflexions on trusting trust qui est une référence encore aujourd'hui. C'est le jusque boutisme que j'ai cru comprendre qui m'avait fait tiquer.

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

Dans ton premier donc ce n'est plus ce que tu fais ?

Dans mon équipe (une petite vingtaine)

Une vingtaine je trouve ça énorme par contre, je n'ai jamais travaillé dans une équipe de plus de 10 personnes et ça n'a pas duré longtemps.

Tout toujours testé et un time to market de quelques jours à peine (il faut quand-même concevoir et programmer.)

Je ne sais pas trop comment on peut annoncer ça. Nous on est entre 20 minutes et 3 mois parce que faire un petit changement dans un graphique et permettre de l'AB testing dans une fonctionnalité existante qui du coup impacte tout un pan de ton logiciel, de faire des aller-retours avec les utilisateurs, etc ça n'est pas la même chose.

Dans mon dernier projet (pas exactement “petit”) on avait une chaîne de livraison continue et chaque “push” menait à une exécutions de toute la chaîne de tests (unitaires, intégration, et tout ce qu'on veut).

Les tests d'intégration je trouve ça compliqué.

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

Pour arriver au résultat, j’ai utilisé l’extension pour Firefox Save as eBook dont j’avais touché deux mots ici-même en septembre 2020 et sélectionné le texte (dépêches plus commentaires) pour chaque dépêche.

Pourquoi ne pas avoir téléchargé les versions epub des dépêches ? C'est une fonctionnalité de linuxfr. Je présume que tu n'aurais pas eu les décorations du site (je n'ai pas de lecteur epub et flemme de lire le source pour vérifier).

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

Donc ta prochaine faille c'est jackson ou gson ?

PS: il me semble que System.out est synchronisé ce qui va pas faire du bien aux performances de ton application

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

J'ai du vérifié si c'était la même personne qui avait écrit ça :

Mais pour chaque composant utilisé, il faut être sûr du code existant, sûr de l'équipe et sûr du futur du composant et que l'équipe ne sera jamais gangrénée (on a vu quelques attaques côté npm, où quelqu'un qui paraissait de bonne volonté a repris la maintenance d'un composant largement utilisé pour finalement y inclure une faille volontairement bien après), d'autant qu'on met de plus en plus les composants à jour automatiquement (Dependabot, Renovate).

Puis ça

Ca veut juste dire que certaines pratiques ne sont pas souhaitables et qu'il faut qu'on fasse un peu plus attention à ce qu'on fait en tant que développeurs de composants réutilisés.

Les 2 postés le même jour. Donc on ne fait plus rien tant qu'on est pas sûr du code, des dépendances, des toolchain et que tous les développeurs impliqués sont et seront toujours fiables ou on se contente d'appliquer des bonnes pratiques ?

Je ne comprends vraiment pas ta position. Quant au github actions, tu avais déjà ça avec des plug-ins maven ou de ton IDE (vim et emacs inclus). Les problèmes sont pas fondamentalement nouveau. Ça ne veut pas dire qu'on ne peut rien faire mais qu'on a déjà de la lecture sur le sujet, qu'il y a des contre mesures qui sont mise en place (vscode et intelij par exemple distinguent un code au quel tu fais confiance ou pas). On avait eu un retour ici même de quelqu'un touché par le faux paquet requests sur pip. Après oui ceux qui font n'importe quoi dont n'importe quoi. Maintenant leur responsabilité peut être jugé au tribunal.

Mon point à la base, c'est que :

• des choses sont faites (c'est médiatisé, c'est peu aller en justice, certaines entités soutiennent des efforts de sécurité, beaucoup de bug bounty sont mis en place, les plate-formes font des efforts dans ce sens)
• la mises en place de certaines bonnes pratiques permettent de colmater des pans entiers de brèches avant qu'on ne les imagines

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

J'ai rien compris au paragraphe que j'ai cité plus haut du coup.

Accepter qu'il y ait un risque ne veut pas dire courir comme un poulet sans tête en espérant ne pas taper un mur. Si chacun sur son projet est un peu plus conscient des enjeux, ça améliore de beaucoup la résilience de l'ensemble.

Tu as toujours et tu aura toujours des gens qui font n'importe quoi. C'est pas lié à l'informatique ni à aujourd'hui. La médiatisation de faille comme log4shell et la responsabilisation légale en cas d'incident vont dans ce sens.

Que tout ne soit pas parfait je suis d'accord. Affirmer que rien est fait me semble verser dans l'émotion du moment.

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

Mais pour chaque composant utilisé, il faut être sûr du code existant, sûr de l'équipe et sûr du futur du composant et que l'équipe ne sera jamais gangrénée (on a vu quelques attaques côté npm, où quelqu'un qui paraissait de bonne volonté a repris la maintenance d'un composant largement utilisé pour finalement y inclure une faille volontairement bien après), d'autant qu'on met de plus en plus les composants à jour automatiquement (Dependabot, Renovate).

Non 1000 fois non ! Jamais ! Tu appel de tes veux à la construction d'une cathédrale, mais ce n'est pas comme ça que ça fonctionne. Ça n'a jamais fonctionner comme ça et ça ne peut pas fonctionner ainsi. Ce que tu souhaite "s'assurer que toutes nouvelles fonctionnalités n'ai aucune faille de sécurité", même allégée parce qu'il est impossible de garantir l'absence de faille, ce serait quoi ? 3 à 5 fois plus d'effort ? Et qui peut le faire les 20 à 30% des développeurs les plus connaisseurs en sécurité ?

Il faut apprendre à vivre avec le fait que ton code, ta toolchain, ton matériel et les gens qui utilisent ton logiciel sont peut être tes ennemis. Le travail c'est de savoir quel est l'enjeu (qu'est-ce que ça implique ?) et d'avoir des contremesures pour (qui auront elles-même des problèmes potentielles, mais qui modifient les probabilités de problèmes ou leur impact).

Il y a pleins de choses qui sont faites, la CI est quelque chose qui s'est extrêmement démocratisé et qui permet la prise en compte rapide, les bug bounty prolifèrent, les systèmes et plateformes se durcissent avec le temps (c'est le cas de java entre autre)…

Ce que tu cherche est délirant :

• parce que ça demande un effort qui est exponentiel avec le temps
• parce que si tu veux une garantie, il faut que tu face confiance à celui qui te donne une garanti, mais comment tu garanti que cette entité ?
• je ne retrouve plus la source mais je suis sûr d'avoir déjà lu un papier expliquant que pour tout système informatique il existe un code malveillant capable de l'attaquer

Il faut faire le deuil de tout cela et accepter que l'informatique n'est pas une science capable de fournir ce niveau de garanti.

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

Un point qui me chagrine est que chaque fois qu'il y a une faille, on dirige plein d'argent et plein de recherche sur le projet qui a posé souci et on perd de vue que c'est un problème général. Tous les jours, on utilise du code Open Source dont on a absolument aucune idée du contenu (le problème est le même pour le code proprio mais on l'utilise moins facilement). On espère que les gens qui le développent savent ce qu'ils font et sont sérieux et honnêtes. Ben pour l'instant, on a eu globalement du bol. Est-ce que ça va durer ?

Je ne suis pas d'accord. Après heartbleed il y a des choses qui ont était faites de manière plus général (il y a FOSSA dont je parlais plus haut, mais la linux fondation aussi avait fais des choses). La question c'est quel projets n'est pas critique pour la sécurité ? Il faut faire des choix.

Par contre ça montre je trouve que des politiques de sécurité drastiques (règle réseau, droits au niveau du système) peuvent être mises en place et peuvent annihiler la dangerosité de nombreuses attaques.

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