Tu as précisé est cool. Je connais mal la recherche récente (et je pense que le manque de recul n'aide pas) mais je suis fasciné de comment le 19ème et le début du 20ème donne l'impression d'une effervescence au point où dire qu'une découverte a été faite par quelqu'un semble presque arbitraire.
Même dans des cas de mauvaises pratiques le second facteurs protège de certains problèmes.
Imaginons que je descende dans ton monde réel pleins de gens qui utilisent 1234 comme mot de passe partout et ben le second facteur va protéger en cas de vol de base de données. C'est à mon avis l'attaque de loin la plus répandu car la plus lucrative. Voler plusieurs milliers de couples email / mot de passe sans prendre de risque physique plutôt que d'aller chercher un à un des téléphones en bas de ta rue.
Les différents éléments de sécurité (mot de passe fort, non réutilisation, stockage sûr, second facteurs,…) s'additionnent dans n'importe quel sens. Donc il n'y a pas à faire tout le reste avant. Il n'y a pas d'ordre (certains apportent plus que d'autres, mais les uns ne s'appuient pas sur les autres).
D'une autre manière si après des décennies, les utilisateurs n'arrivent toujours pas à appliquer ce qui paraît être les principes de base, il va falloir se rendre compte que ben le mot de passe c'est de la merde et qu'il va falloir trouver autre chose. L'utilisation d'un autre facteur que les mots de passe peut être un début de réponse.
Il me semble qu'on utilise souvent l'expression "la découverte de l'atome" pour décrire la course à l'énergie atomique. Il est difficile de dater une découverte de l'atome tant ce fut un processus long est progressif. De plus imputer la bombe atomique à la découverte de l'atome contrairement à ce que le nom laisse penser n'est pas si simple. Dans la culture populaire (et pas tout à fait sans raison) on associe Albert Einstein à cet arme alors qu'il n'a pas travaillé sur les atomes mais sur le lien entre vitesse, matière et énergie (pour ce qui concerne la bombe).
Bref je suis d'accord avec toi, mais je trouve le lien artificiel à plus d'un titre
Je pense aussi que l'approche est bien trop grossière pour donner une information pertinente. Entre un programme à durée de vie courte et un à durée de vie longue ça va changer beaucoup les résultats pour les langages qui utilisent du JIT par exemple.
on a besoin de plus de code de qualité quelque soit le langage
Plus sécurisé ? Avec moins de bug ? Qui utilise moins de mémoire ? Moins de CPU ? Dont l'exécutable est plus petit ? Qui a du code dédié à chaque architecture ou gpu disponible ? Qui résiste à du fuzzing ? Qui est capable de traiter pleins de choses en parallèle ou une seule chose en un minimum de temps ?… La moitié de ces critères vont demander des choix pour faire plus l'un que l'autre.
Et tous demandent des tests, tu l'inclus comment dans le calcul ? Parce que les tests ont eux même un coût énergétiques. En plus des tests unitaires, faire des tests de performance seront particulièrement coûteux. Évidemment l'architecture de l'intégration continue sera primordiale pour la consommation énergétique.
Dernier point tu as un équilibre entre la facilité dans un langage d'écrire du code performant (quelque soit ce que tu met derrière le mot performant) et le coût de la compilation ou du runtime du langage. Dis autrement il peut être plus simple d'arriver à un code performant en python qu'en fortran. Tu as aussi des langages qui te poussent à écrire plus de tests car moins de choses sont vérifiées dans le langage.
Bref cela me paraît impossible de donner un tableau de valeur générique et de s'en contenter. Il serait plus intéressant de créer des méthodologies pour évaluer sont coût énergétique et pouvoir en faire une métrique optimisable au même titre qu'une autre.
Stocker ces mots de passe de manière non chiffrée n'est pas une bonne pratique. Si les bases ne sont pas appliquées oui ça ne sert à rien. Mais c'est comme dire qu'utiliser 1234 comme mot de passe c'est pas très sûr. Tout le monde répète à tut tête d'utiliser des gestionnaires de mot de passe de ne mémoriser qu'un seul mot de passe fort et de ne pas réutiliser ses mots de passe. On dit juste en plus que c'est bien d'avoir en plus un second facteur. Personne de sérieux ne dit que c'est le graal, personne ne dit que ça permet d'utiliser azerty comme mot de passe.
Pour Twitter et beaucoup de cas où ça dure longtemps sans bénéfices, il me semble que c'est basé sur une croyance que ça va fonctionner et rapporter. Le phénomène est probablement d'autant plus fort pour des trucs un peu viraux / de grande ampleur comme Twitter.
Tu ne peux pas dire que le système est mécaniquement court-termiste alors qu'ils acceptent de financer 10 ans une boite. Je ne dis pas que le modèle est bon, mais qu'il ne faut pas verser dans la facilité d'une critique qui serait trop légère (à la limite de l'emporte pièce).
Mais bref, c'est une discussion à part ça à mon humble avis.
C'était la moitié du commentaire au quel je répondais. Tu affirme qu'investisseur implique coutermisme qui implique une obligation de résultat rapide. Je pense que la critique est simpliste et montre que l'assertion me parait fragile.
Je ne comprends pas les attaques. On peut discuter calmement. (je suppose que tu voulais dire "sophisme", faire des syllogismes est une manière habituelle et solide de raisonner - On sait que A => B, or B => C, donc A => C). Je m'oppose particulièrement au qualificatif "puéril", déjà pas sympa de base et qui sous-entend peut-être une accusation d'être malhonnête. Je peux me tromper mais je suis de bonne foi. Perso, je ne suis pas là pour enfumer les gens. Parenthèse fermée, reprenons sereinement ?
Que tu le fasse consciemment ou non, ton argument est une répétition qu'on voit arriver systématiquement : la critique d'un projet qui sort d'un modèle open source pour faire de l'argent en expliquant que d'autres projets qui n'ont rien de comparable y arrivent bien. Effectivement je me suis trompé, je voulais parler de paralogisme.
Personne n'a dit que l'open source ne peut pas générer de l'argent, mais il semble que ceux qui tentent de faire de l'argent avec ce logiciel là n'arrivent à le faire. C'est bien pour ça que Jean Gabes parlait de modèle économique plus haut.
Si tu veux parler de sophisme ce serait celui de la généralisation, mais là j'aurais vraiment considéré que tu étais malhonnête.
Je répondais à la question "est-ce possible ?" (l'énoncé était "Y a-t-il", équivalent à "existe-t-il ?), pas à la question "Est-ce que ça marche pour tout le monde ?".
Je présenterais un biais du survivant si j'affirmais "Regardez, ça marche à chaque fois ! X et Y ont bien réussi !".
Tu présente pourtant une liste à la Prévert sans expliquer quel est le lien, la ressemble ou en quoi leur situation serait comparable. Tu montre juste que des projets libres y arrivent bien.
En fait non, j'avais affirmé "des modèles économiques basé sur l'open source ça existe", je n'avais pas mis la contrainte "sans investisseurs".
Le modèle économique ce n'est pas une question d'investisseur ou pas, c'est une question de est-ce que tu arrive à valoriser économiquement le travail que tu produit et ça ne s'analyse pas simplement sur investisseur ou pas, mais aussi par exemple qu'est-ce que tu as comme concurrence ? Qu'elle est la taille de ton marché ? etc
Balancer à la gueule de ceux qui ne réussissent pas que tel autre qui n'a aucun rapport y arrive n'a pas de sens.
Et je vais me permettre d'élargir mon propos. Je n'ai aucune idée de qui est derrière Kong et de s'ils sont cyniques ou pas, mais je vois systématiquement dans ce genre de cas des cris d’orfraie plus ou moins véhéments expliquant le fait de quitter le logiciel libre par l'incompétence, l’appât du gain, l'absence de valeurs, la volonté de nuire ou la malhonnêteté des développeurs. Et c'est l'une des choses que je trouve le plus détestable dans le libre : cette volonté de punir celui qui a échoué. Je ne vois jamais d'empathie. Si tu veux pas finir persona non gratta il faut saborder ton projet plutôt que de faire ce que tu peux. Non seulement je trouve que c'est inhumain, mais en plus ça ignore complètement le fait que la réussite ou l'échec est avant tout une question de chance et que ce genre de comportement ne peux qu'amener à se détourner du libre.
Le libre ne devrait être appliqué par crainte de se faire harceler par une communauté toxique, mais par adhésion à l'idéal1. Un projet qui échoue à rester libre comme celui-ci devrait être étudier pour savoir ce qui a pêcher de manière plus sérieuse qu'avec des poncifs qui ne font avancer personne (c'est les investisseurs, les développeurs sont des vendus, etc). Ça peut même donner des enseignements, plus général pour mieux repérer ce qui pose ou qui ne peu poser problème dans d'autres projets. Oui c'est plus de travail que de dire que Mediainfo y arrive bien lui, mais l'un n'est que du commentaire peut utile, alors que le second serait enrichissant.
idéal qui peut être différent d'une personne à l'autre, mais qui se rejoins à minima sur une base en principe ↩
Une réalité économique quand on choisit d'avoir des investisseurs. Le problème des investisseurs, c'est que simplement rentrer dans ses frais n'est pas suffisant. Il faut aussi faire le max pour payer les investisseurs.
Pourtant ce même modèle d'investissement maintiens en fonctionnement à perte des entreprises. Twitter a passé plus de 10 ans sans dégager de bénéfice par exemple.
La course au profit sur du court terme n'a pas l'air de faire très bon ménage avec l'open source sans "gotcha".
L'analyse me paraît simpliste vu comme il est facile de trouver des contre exemple.
Si la question est "y a-t-il un modèle économique qui supporte un modèle de développement open source", c'est oui. Des exemples : Nextcloud, WordPress, XWiki. MediaInfo (Zenitram) aussi ? Rien n'est parfait, et ce n'est pas forcément facile, mais c'est possible. (si ce n'était pas la question, désolé ! Je n'étais pas trop sûr d'avoir compris correctement)
Tu noie le poisson. C'est puéril de faire ce genre de syllogisme. Il existe des entreprises qui marchent donc toutes entreprises peut fonctionner ? C'est un syndrome du survivant que tu présente ici. Le fait que certains logiciels libres arrivent à en vivre ne veut pas dire que tout logiciel libre le peu. Le modèle économique dans le quel on se trouve ne sait pas correctement financer les choses selon moi. Il sur finance des choses qui ne sont pas souhaitables (toute l'économie de l'attention par exemple avec toutes les pubs) et n'arrive pas à financer des choses qui me paraissent nécessaires (l'aide à la personne de manière générale par exemple).
J'ai jamais entendu parler de "chiffrement à connaissance nulle", généralement on parle d'un terme que je trouve beaucoup plus clair : chiffrement côté client.
C'est simple, ça se comprend et ça ne donne pas l'impression que c'est un truc de fou par contre.
Par contre même si j'ai entendu dire que ça a beaucoup évolué, les chiffrements homomorphiques ont leur limite (et on a pas encore le recul sur les dernières innovations pour dire que c'est aussi solide que ce qui est mis sur le devant de la scène et pentester en profondeur par beaucoup de gens dans le monde).
peut-être ai-je mal compris l'idée à la base mais il me semblait que l'idée était du pas cher pas consommateur et là on s'éloigne pas mal de cette idée pour une course à la perf, déjà que le 4 était dans cette direction?
Je n'ai pas l'impression qu'il s'agisse de remplacement mais plutôt d'un étoffement de la gamme. Leur site parle toujours de vendre les Pi 4, Pi 3 et P1.
Ensuite ils ont clairement plusieurs marchés distinct :
l'IoT avec Pi Pico, les différents Pi Zero voir le RP2040
de toutes petites machines avec les premiers Pi
des machines de bureau pas chères avec le Pi4, le Pi400 et maintenant le Pi5
Il y a clairement rien à voir entre celui qui achète son Pi Zero pour hacker sa machine à laver et celui qui va acheter un Pi5 pour se faire un home cinéma (même si en soit le Pi5 doit permettre de faire des bornes d'arcade moins limités en émulation), mais ce n'est pas un changement de cap, mais plutôt une offre diversifiée.
Je suis très curieux ce qu'ils semblent faire me semble demander à manipuler l'AST de python depuis python lui-même, je ne savais pas que python pouvait faire ça
Comment un mot qui a était créé pour traduire underflow pourrait ne pas en être la traduction correcte ? Il n'ya pas encore eu de glissement sémantique. Qu'un néologisme soit surprenant et paraisse bizarre c'est assez logique, je crois pas que ce soit suffisant pour le disqualifier.
Du coup tu as souscrit à un abonnement, mis en place chez toi l'alarme, fait toute l'analyse, la remontée de la faille, le tout sur plusieurs mois voir année,… Tout ça pour pouvoir faire la blague dans le titre ?
C'est impossible s'il travaille au niveau de l'AST. Ce n'est pas une probabilité ou comme si ça marche hors des cas complexes.
C'est tout le principe de clang-format, il réutilise les premières pass du compilateur pour avoir la sémantique et ne pas la modifie, (pareil pour go fmt). Black, le formatteur python qui avait beaucoup fait parler, fonctionne aussi comme ça.
Un formatteur qui n'aurait pas ces garanties me ferait plutôt peur et j'éviterais de m'en servir à fortiori sans revu du code qu'il produit.
Pour moi ce que tu décris est un problème d'outil pas très bien fait et pas un problème de processus.
Beaucoup d'outils de diff sont capables d'ignorer les caractères d'espacement.
Mais par contre ce serait génial que pour les malvoyants (et les autres mais ça me paraît une nécessité pour les malvoyants) qu'ils ne lisent pas des fichiers textes mais des AST. C'est pas complètement trivial car c'est pas un AST complètement fini, mais pas mal d'outils savent déjà faire ce travail pour indiquer des erreurs ou colorer les mots en fonction de leur type
Reformater a toujours permis de foutre le boxon les doigts dans le nez.
Faut vraiment avoir un formateur codé avec le cul pour que ça arrive. Prendre une source, en extraire l'AST et générer des fichiers avec des règles de formatage souhaiter est une compilation comme une autre. Rien dans ce processus ne devrait avoir la moindre chance de modifier la sémantique du programme.
[^] # Re: c'est un peu dire que l'outil est neutre, ça encore
Posté par barmic 🦦 . En réponse au lien M Surman: "Il faut se préoccuper des gens qui détournent l'IA plutôt que de la technologie elle-même. Évalué à 2.
Tu as précisé est cool. Je connais mal la recherche récente (et je pense que le manque de recul n'aide pas) mais je suis fasciné de comment le 19ème et le début du 20ème donne l'impression d'une effervescence au point où dire qu'une découverte a été faite par quelqu'un semble presque arbitraire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: MFA sans téléphone
Posté par barmic 🦦 . En réponse au journal Importer des "issues" GitHub dans des "tickets" Trac. Évalué à 2.
Même dans des cas de mauvaises pratiques le second facteurs protège de certains problèmes.
Imaginons que je descende dans ton monde réel pleins de gens qui utilisent 1234 comme mot de passe partout et ben le second facteur va protéger en cas de vol de base de données. C'est à mon avis l'attaque de loin la plus répandu car la plus lucrative. Voler plusieurs milliers de couples email / mot de passe sans prendre de risque physique plutôt que d'aller chercher un à un des téléphones en bas de ta rue.
Les différents éléments de sécurité (mot de passe fort, non réutilisation, stockage sûr, second facteurs,…) s'additionnent dans n'importe quel sens. Donc il n'y a pas à faire tout le reste avant. Il n'y a pas d'ordre (certains apportent plus que d'autres, mais les uns ne s'appuient pas sur les autres).
D'une autre manière si après des décennies, les utilisateurs n'arrivent toujours pas à appliquer ce qui paraît être les principes de base, il va falloir se rendre compte que ben le mot de passe c'est de la merde et qu'il va falloir trouver autre chose. L'utilisation d'un autre facteur que les mots de passe peut être un début de réponse.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: c'est un peu dire que l'outil est neutre, ça encore
Posté par barmic 🦦 . En réponse au lien M Surman: "Il faut se préoccuper des gens qui détournent l'IA plutôt que de la technologie elle-même. Évalué à 2.
C'était le sous entendu de la parenthèse :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: c'est un peu dire que l'outil est neutre, ça encore
Posté par barmic 🦦 . En réponse au lien M Surman: "Il faut se préoccuper des gens qui détournent l'IA plutôt que de la technologie elle-même. Évalué à 3.
Il me semble qu'on utilise souvent l'expression "la découverte de l'atome" pour décrire la course à l'énergie atomique. Il est difficile de dater une découverte de l'atome tant ce fut un processus long est progressif. De plus imputer la bombe atomique à la découverte de l'atome contrairement à ce que le nom laisse penser n'est pas si simple. Dans la culture populaire (et pas tout à fait sans raison) on associe Albert Einstein à cet arme alors qu'il n'a pas travaillé sur les atomes mais sur le lien entre vitesse, matière et énergie (pour ce qui concerne la bombe).
Bref je suis d'accord avec toi, mais je trouve le lien artificiel à plus d'un titre
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je ne suis pas sûr que les logiciels libres soient moins consommateurs de ressources CPU/Mém
Posté par barmic 🦦 . En réponse au journal Cailloux, joujoux, bijoux. Évalué à 2.
Je pense aussi que l'approche est bien trop grossière pour donner une information pertinente. Entre un programme à durée de vie courte et un à durée de vie longue ça va changer beaucoup les résultats pour les langages qui utilisent du JIT par exemple.
Plus sécurisé ? Avec moins de bug ? Qui utilise moins de mémoire ? Moins de CPU ? Dont l'exécutable est plus petit ? Qui a du code dédié à chaque architecture ou gpu disponible ? Qui résiste à du fuzzing ? Qui est capable de traiter pleins de choses en parallèle ou une seule chose en un minimum de temps ?… La moitié de ces critères vont demander des choix pour faire plus l'un que l'autre.
Et tous demandent des tests, tu l'inclus comment dans le calcul ? Parce que les tests ont eux même un coût énergétiques. En plus des tests unitaires, faire des tests de performance seront particulièrement coûteux. Évidemment l'architecture de l'intégration continue sera primordiale pour la consommation énergétique.
Dernier point tu as un équilibre entre la facilité dans un langage d'écrire du code performant (quelque soit ce que tu met derrière le mot performant) et le coût de la compilation ou du runtime du langage. Dis autrement il peut être plus simple d'arriver à un code performant en python qu'en fortran. Tu as aussi des langages qui te poussent à écrire plus de tests car moins de choses sont vérifiées dans le langage.
Bref cela me paraît impossible de donner un tableau de valeur générique et de s'en contenter. Il serait plus intéressant de créer des méthodologies pour évaluer sont coût énergétique et pouvoir en faire une métrique optimisable au même titre qu'une autre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: MFA sans téléphone
Posté par barmic 🦦 . En réponse au journal Importer des "issues" GitHub dans des "tickets" Trac. Évalué à 4.
Stocker ces mots de passe de manière non chiffrée n'est pas une bonne pratique. Si les bases ne sont pas appliquées oui ça ne sert à rien. Mais c'est comme dire qu'utiliser 1234 comme mot de passe c'est pas très sûr. Tout le monde répète à tut tête d'utiliser des gestionnaires de mot de passe de ne mémoriser qu'un seul mot de passe fort et de ne pas réutiliser ses mots de passe. On dit juste en plus que c'est bien d'avoir en plus un second facteur. Personne de sérieux ne dit que c'est le graal, personne ne dit que ça permet d'utiliser azerty comme mot de passe.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: MFA sans téléphone
Posté par barmic 🦦 . En réponse au journal Importer des "issues" GitHub dans des "tickets" Trac. Évalué à 2.
Tu veut dire que comme ça n'est pas inviolable c'est uniquement une impression de sécurité ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: il est ou le problème ?
Posté par barmic 🦦 . En réponse au journal Guide d'openwashing : comment passer d'un projet opensource à un logiciel bridé et privateur ?. Évalué à 2.
Tu ne peux pas dire que le système est mécaniquement court-termiste alors qu'ils acceptent de financer 10 ans une boite. Je ne dis pas que le modèle est bon, mais qu'il ne faut pas verser dans la facilité d'une critique qui serait trop légère (à la limite de l'emporte pièce).
C'était la moitié du commentaire au quel je répondais. Tu affirme qu'investisseur implique coutermisme qui implique une obligation de résultat rapide. Je pense que la critique est simpliste et montre que l'assertion me parait fragile.
Que tu le fasse consciemment ou non, ton argument est une répétition qu'on voit arriver systématiquement : la critique d'un projet qui sort d'un modèle open source pour faire de l'argent en expliquant que d'autres projets qui n'ont rien de comparable y arrivent bien. Effectivement je me suis trompé, je voulais parler de paralogisme.
Personne n'a dit que l'open source ne peut pas générer de l'argent, mais il semble que ceux qui tentent de faire de l'argent avec ce logiciel là n'arrivent à le faire. C'est bien pour ça que Jean Gabes parlait de modèle économique plus haut.
Si tu veux parler de sophisme ce serait celui de la généralisation, mais là j'aurais vraiment considéré que tu étais malhonnête.
Tu présente pourtant une liste à la Prévert sans expliquer quel est le lien, la ressemble ou en quoi leur situation serait comparable. Tu montre juste que des projets libres y arrivent bien.
Le modèle économique ce n'est pas une question d'investisseur ou pas, c'est une question de est-ce que tu arrive à valoriser économiquement le travail que tu produit et ça ne s'analyse pas simplement sur investisseur ou pas, mais aussi par exemple qu'est-ce que tu as comme concurrence ? Qu'elle est la taille de ton marché ? etc
Balancer à la gueule de ceux qui ne réussissent pas que tel autre qui n'a aucun rapport y arrive n'a pas de sens.
Et je vais me permettre d'élargir mon propos. Je n'ai aucune idée de qui est derrière Kong et de s'ils sont cyniques ou pas, mais je vois systématiquement dans ce genre de cas des cris d’orfraie plus ou moins véhéments expliquant le fait de quitter le logiciel libre par l'incompétence, l’appât du gain, l'absence de valeurs, la volonté de nuire ou la malhonnêteté des développeurs. Et c'est l'une des choses que je trouve le plus détestable dans le libre : cette volonté de punir celui qui a échoué. Je ne vois jamais d'empathie. Si tu veux pas finir persona non gratta il faut saborder ton projet plutôt que de faire ce que tu peux. Non seulement je trouve que c'est inhumain, mais en plus ça ignore complètement le fait que la réussite ou l'échec est avant tout une question de chance et que ce genre de comportement ne peux qu'amener à se détourner du libre.
Le libre ne devrait être appliqué par crainte de se faire harceler par une communauté toxique, mais par adhésion à l'idéal1. Un projet qui échoue à rester libre comme celui-ci devrait être étudier pour savoir ce qui a pêcher de manière plus sérieuse qu'avec des poncifs qui ne font avancer personne (c'est les investisseurs, les développeurs sont des vendus, etc). Ça peut même donner des enseignements, plus général pour mieux repérer ce qui pose ou qui ne peu poser problème dans d'autres projets. Oui c'est plus de travail que de dire que Mediainfo y arrive bien lui, mais l'un n'est que du commentaire peut utile, alors que le second serait enrichissant.
idéal qui peut être différent d'une personne à l'autre, mais qui se rejoins à minima sur une base en principe ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chiffrement à connaissance nulle
Posté par barmic 🦦 . En réponse au lien You Can't Control Your Data in the Cloud. Évalué à 3.
Je ne le connaissait pas, mais je l'ai vite compris par comparaison avec BOYD évidement. J'aime bien le bring your own key.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: il est ou le problème ?
Posté par barmic 🦦 . En réponse au journal Guide d'openwashing : comment passer d'un projet opensource à un logiciel bridé et privateur ?. Évalué à 3.
Pourtant ce même modèle d'investissement maintiens en fonctionnement à perte des entreprises. Twitter a passé plus de 10 ans sans dégager de bénéfice par exemple.
L'analyse me paraît simpliste vu comme il est facile de trouver des contre exemple.
Tu noie le poisson. C'est puéril de faire ce genre de syllogisme. Il existe des entreprises qui marchent donc toutes entreprises peut fonctionner ? C'est un syndrome du survivant que tu présente ici. Le fait que certains logiciels libres arrivent à en vivre ne veut pas dire que tout logiciel libre le peu. Le modèle économique dans le quel on se trouve ne sait pas correctement financer les choses selon moi. Il sur finance des choses qui ne sont pas souhaitables (toute l'économie de l'attention par exemple avec toutes les pubs) et n'arrive pas à financer des choses qui me paraissent nécessaires (l'aide à la personne de manière générale par exemple).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chiffrement à connaissance nulle
Posté par barmic 🦦 . En réponse au lien You Can't Control Your Data in the Cloud. Évalué à 7. Dernière modification le 30 septembre 2023 à 09:18.
J'ai jamais entendu parler de "chiffrement à connaissance nulle", généralement on parle d'un terme que je trouve beaucoup plus clair : chiffrement côté client.
C'est simple, ça se comprend et ça ne donne pas l'impression que c'est un truc de fou par contre.
Par contre même si j'ai entendu dire que ça a beaucoup évolué, les chiffrements homomorphiques ont leur limite (et on a pas encore le recul sur les dernières innovations pour dire que c'est aussi solide que ce qui est mis sur le devant de la scène et pentester en profondeur par beaucoup de gens dans le monde).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Une revue détaillée ici:
Posté par barmic 🦦 . En réponse au lien Et voilà le Raspberry Pi 5. Évalué à 3.
Je n'ai pas l'impression qu'il s'agisse de remplacement mais plutôt d'un étoffement de la gamme. Leur site parle toujours de vendre les Pi 4, Pi 3 et P1.
Ensuite ils ont clairement plusieurs marchés distinct :
Il y a clairement rien à voir entre celui qui achète son Pi Zero pour hacker sa machine à laver et celui qui va acheter un Pi5 pour se faire un home cinéma (même si en soit le Pi5 doit permettre de faire des bornes d'arcade moins limités en émulation), mais ce n'est pas un changement de cap, mais plutôt une offre diversifiée.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Il vaut mieux utiliser un alarme organique
Posté par barmic 🦦 . En réponse au journal Avoir l'alarme à l'oeil. Évalué à 5.
Ne faut-il pas partir dans le même sens si l'objectif est d'augmenter ou au moins de maintenir une distance avec l'animal ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Curieux
Posté par barmic 🦦 . En réponse au lien Pony is a Python ORM with beautiful query syntax. Évalué à 2.
OK je comprends mieux, c'est un gros hack (comme ça en donne l'impression) ou c'est relativement prévu par les développeurs de python ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Curieux
Posté par barmic 🦦 . En réponse au lien Pony is a Python ORM with beautiful query syntax. Évalué à 2.
Je suis très curieux ce qu'ils semblent faire me semble demander à manipuler l'AST de python depuis python lui-même, je ne savais pas que python pouvait faire ça
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Un peu de poésie :-)
Posté par barmic 🦦 . En réponse au lien Firefox 118 : avec une version de décalage la traduction locale respectueuse de la vie privée est là. Évalué à 4.
Comment un mot qui a était créé pour traduire underflow pourrait ne pas en être la traduction correcte ? Il n'ya pas encore eu de glissement sémantique. Qu'un néologisme soit surprenant et paraisse bizarre c'est assez logique, je crois pas que ce soit suffisant pour le disqualifier.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Sur le fond
Posté par barmic 🦦 . En réponse au journal Du rififi chez les rubyistes qui font du JavaScript. Évalué à 2.
Les constantes sont devenues immutables ou elles produisent juste des warning ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Blague
Posté par barmic 🦦 . En réponse au journal Avoir l'alarme à l'oeil. Évalué à 10.
Du coup tu as souscrit à un abonnement, mis en place chez toi l'alarme, fait toute l'analyse, la remontée de la faille, le tout sur plusieurs mois voir année,… Tout ça pour pouvoir faire la blague dans le titre ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: iot
Posté par barmic 🦦 . En réponse au journal Avoir l'alarme à l'oeil. Évalué à 5.
Ça ne devrait pas se faire tuer en une ou deux amendes au RGPD, ça ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Rien de folichon
Posté par barmic 🦦 . En réponse au lien L’IA a-t-elle généré cette photo ? Voici comment le déterminer (via sebsauvage) - foundation mozilla. Évalué à 6.
Comme la plupart des messages de prévention
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'IDE fait le travail
Posté par barmic 🦦 . En réponse au lien Tabs are objectively better than spaces. Évalué à 2.
Ah oui je n'avais pas du tout compris ça.
Du coup je vois pae vers quoi il réindente si c'est pas ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'IDE fait le travail
Posté par barmic 🦦 . En réponse au lien Tabs are objectively better than spaces. Évalué à 3.
C'est impossible s'il travaille au niveau de l'AST. Ce n'est pas une probabilité ou comme si ça marche hors des cas complexes.
C'est tout le principe de clang-format, il réutilise les premières pass du compilateur pour avoir la sémantique et ne pas la modifie, (pareil pour go fmt). Black, le formatteur python qui avait beaucoup fait parler, fonctionne aussi comme ça.
Un formatteur qui n'aurait pas ces garanties me ferait plutôt peur et j'éviterais de m'en servir à fortiori sans revu du code qu'il produit.
Pour moi ce que tu décris est un problème d'outil pas très bien fait et pas un problème de processus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'IDE fait le travail
Posté par barmic 🦦 . En réponse au lien Tabs are objectively better than spaces. Évalué à 3.
Désolé je ne pensais pas que c'était un acronyme à définir dans une discussion sur du code
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Nothing is objectively better than spaces and tabs
Posté par barmic 🦦 . En réponse au lien Tabs are objectively better than spaces. Évalué à 2.
Beaucoup d'outils de diff sont capables d'ignorer les caractères d'espacement.
Mais par contre ce serait génial que pour les malvoyants (et les autres mais ça me paraît une nécessité pour les malvoyants) qu'ils ne lisent pas des fichiers textes mais des AST. C'est pas complètement trivial car c'est pas un AST complètement fini, mais pas mal d'outils savent déjà faire ce travail pour indiquer des erreurs ou colorer les mots en fonction de leur type
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'IDE fait le travail
Posté par barmic 🦦 . En réponse au lien Tabs are objectively better than spaces. Évalué à 2.
Faut vraiment avoir un formateur codé avec le cul pour que ça arrive. Prendre une source, en extraire l'AST et générer des fichiers avec des règles de formatage souhaiter est une compilation comme une autre. Rien dans ce processus ne devrait avoir la moindre chance de modifier la sémantique du programme.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll