Si une brique/dépendance de ton logiciel libre n'est pas libre, alors tu n'as toutes les libertés garanties par le libre sur l'ensemble. C'est le fond de la remarque de devnewton. C'est difficile à formuler parce que c'est presque une tautologie.
Plus spécifiquement et pire encore dans le cas de MongoDB : la clause spécifique de la SSPL sur devoir fournir tout le code nécessaire à faire tourner le service qui s'appuie sur MongoDB sous licence SSPL est très contraignante, voire impossible à réaliser parce que fatalement, ton service va s'appuyer sur d'autre logiciels libres distribués sous d'autres licences ((A)GPL par exemple) incompatibles avec la SSPL, et donc impossible à redistribuer sous cette licence.
Donc concrètement : potentiellement, tu ne peux juste pas utiliser la version SSPL de MongoDB. C'est impossible. Tu dois utiliser la version propriétaire, obtenue avec un accord commercial avec la société derrière MongoDB. En fait, je ne sais pas qui utilise légalement la version SSPL de MongoDB, je ne vois pas comment c'est possible, à part en tordant les interprétations et en saupoudrant abondamment de laisser-faire.
Maintenant, s'il existe une alternative compatible à MongoDB, c'est tout bon.
Ensuite, du libre dans le milieu de la santé, c'est une excellente nouvelle. Cette ouverture ne peut être qu'applaudie, c'est une superbe démarche, même si elle est imparfaite. Je suppose que ça peut se corriger.
D'ailleurs, il me semble bien que Jitsi Meet fait du pair à pair quand il n'y a que 2 personnes dans un salon.
Lors de la mise en place d'une instance à l'aube du confinement de 2020, la configuration du service qui s'occupe de transmettre les flux n'était pas encore correcte, lors des tests on pouvait discuter à 2 et la visio sautait quand une 3ème personne nous rejoignait. À priori parce que la visio à 2 était pair à pair, et à 3 Jitsi bascule vers le serveur central. D'ailleurs même quand on avait correctement mis les choses en place, on observait une breve coupure au passage de 2 à 3 ou de 3 à 2 qu'on n'observait pas lors d'un passage de 3 à 4.
Signal fait aussi passer les appels à 2 (ou plus ? je ne sais pas) en pair à pair par défaut (mais propose une option de passer systématiquement par leur serveur pour que le contact ne connaisse pas notre IP).
Ces deux logiciels reposent effectivement sur un service au milieu, au moins pour la mise en relation. On pourrait imaginer une mise en relation sans service au milieu, mais c'est quand même un peu compliqué. Pour que deux ordinateurs communiquent entre eux, il faut qu'ils connaissent leurs adresse ip respectives, c'est vaguement possible si les gens se sont échangés leurs adresses ip au préalable mais c'est supposer que leurs adresses ne changent pas, ce qui suppose :
pas de changement de FAI
pas de déplacement / mobilité (les gens restent chez eux)
C'est quand même une grosse supposition aujourd'hui. Avec la supposition, l'UX est quand même pas top. C'est un peu comme le téléphone mais une IPv6, c'est quand même vaguement long, en comparaison avec un numéro de téléphone à 10 chiffres (qui lui, ne change pas quand on change de fournisseur ; ou si on bouge d'endroit pour les téléphones mobile… grâce au fournisseur au milieu). On pourrait utiliser des QR codes maintenant, ou alors utiliser un autre moyen de communication pour se transmettre les adresses, mais cet autre moyen de communication s'appuie certainement sur un service au milieu.
Donc au moins pour la mise en relation, un service au milieu semble difficilement dispensable.
Donc Fairphone peut fournir 8-10 ans de mises à jour simplement en demandant à Qualcomm ? (via un contrat de support approprié)
Ma réaction à chaud : les fabricants de téléphones, ils se foutent quand même sacrément bien de notre gueule.
Mais Qualcomm aussi, hein, ils se foutent bien de notre gueule. S'ils faisaient un petit effort de ne pas forker comme des porcs et de plutôt upstreamer leurs dev, en fait ces problèmes n'existent pas.
Je suis sûr que si les fabricants de téléphone en avaient quelque chose à foutre, ils pourraient se regrouper et faire pression sur Qualcomm.
Concernant Fairphone, ça va dans le bon sens, c'est top.
Le téléphone est cher, mais si on arrive à le garder 8 ans, on passe d'un budget pour matériel haut de gamme à un budget premier prix.
J'ai hésité entre deux titres de commentaire alors j'ai mis les deux.
Je ne sais pas ce qu'ils essaient de bloquer donc c'est difficile de juger.
Un des nombreux avantages de meet.jit.si c'était de pouvoir éviter d'utiliser des GAFAM, justement. D'éviter de devoir accepter leurs conditions d'utilisations.
Malheureusement, ce n'est maintenant plus possible. En tout cas tant qu'ils n'ajoutent pas d'autres méthodes d'identification.
D'autant que Google a ses solutions de visio dont Google Meet ; Facebook a aussi plusieurs solutions de visio. Microsoft (qui a GitHub) aussi avec Teams. Donc on va se retrouver à utiliser le système d'authentification des concurrents, super.
Heureusement, ça ne concerne que la création de salon, donc si on est invité·e à une visio sur meet.jit.si, on n'est pas concerné·e. C'est déjà pas mal.
De plus, la restriction n'existe pas sur le logiciel lui-même et d'autres instances existent.
Utilisateur occasionnel de meet.jit.si pour mes besoins persos ou associatifs, je vais devoir trouver une alternative. Je vois 2 possibilités :
Auto-hébergement pour mes besoins
Utiliser une des autres instances en place, et pourquoi pas https://visiocall.com/, un Jitsi Meet à la sauce Algoo.
Mon employeur a aussi son instance dédiée au travail d'équipe, même s'il est possible de l'utiliser pour autre chose je ne pense pas que ça soit approprié.
Mais globalement je suis plus convaincu par BigBlueButton. Plus compliqué mais aussi beaucoup plus fiable d'expérience. Donc peut-être auto-héberger BBB.
Le problème de l'auto hébergement, c'est que j'aimerais vraiment pouvoir suggérer / proposer quelque chose que n'importe qui peut utiliser. Ce qui m'intéresse, ce n'est pas une solution pour juste moi, mais bien pour les autres aussi.
Et je ne pense pas pouvoir mettre le fric nécessaire à faire tourner une instance qui peut accueillir un grand nombre d'utilisateurs et d'utilisatrices. Et évidemment, à un moment on se heurte probablement à ces questions de modérations qui mènent au genre de mesures qu'on est en train de discuter.
je ne sais pas bien ce que ca vaut, mais ca semble marcher, dans l'ensemble.
Aïe aïe aïe. Désolé mais je vais être un peu rude. Ce n'est pas du tout contre toi, c'était une bonne idée de mettre un résumé en français. Merci pour la démarche mais du coup il y a besoin de rectifier le tir. Je n'ai malheureusement pas le temps juste maintenant de faire une traduction propre et compréhensible, j'en propose une à l'arrache à la fin de mon commentaire. Je suggère de ne pas poster des textes générés par des IA à l'avenir (sans beaucoup de vérifications), elles bullshittent, ne sont pas fiables et c'en est un exemple flagrant.
J'ai lu ce résumé auto et j'ai eu beaucoup de mal à le comprendre. Je suis allé voir l'article initial qui est lui clair comme de l'eau de roche (j'aime beaucoup l'écriture de Daniel). En revenant sur ce texte, je me rend compte que tout est faux, en plus d'être difficilement compréhensible.
Par exemple :
Il prend l'exemple de la CVE-2020-19909,
Non. Il vient d'apprendre son existence, et c'est le cœur du sujet de l'article
une vulnérabilité critique dans l'outil curl
Non. L'article explique bien que justement, ce n'est pas une vulnérabilité, ni une critique
qui a été découverte en 2020.
Non. Elle vient d'être rapportée, et il se demande justement pourquoi elle a été attribuée avec ce numéro contenant 2020. De son côté, quelqu'un lui avait déjà soumis le problème
La description de la vulnérabilité est longue et complexe, ce qui la rend difficile à comprendre pour les utilisateurs non experts.
Non. Elle fait 100 caractères, 15 mots. On ne peut plus concis. Elle est incompréhensible par des utilisateurs non experts mais Daniel ne parle pas du tout de ça parce que ce n'est pas le problème.
Stenberg propose plusieurs solutions pour améliorer la gestion des CVE. Il suggère notamment de réduire le temps nécessaire pour l'attribution d'une CVE, d'étendre la documentation des vulnérabilités et de rendre le processus d'attribution plus transparent.
Non, rien de tout ça.
Voici un résumé des principales critiques de Stenberg :
Rien des deux premiers points qui suit n'est vrai. Le 3 ème, vaguement.
Stenberg espère que ses critiques contribueront à améliorer la gestion des CVE
Il critique en particulier NVD, sont trop grand pouvoir dans l'attribution des numéros CVEs et son incompétence.
et à protéger les utilisateurs contre les vulnérabilités de sécurité.
Pas du tout. Ce n'est pas le sujet.
Bref, si je comprends bien, on a affaire à Bard, le LLM de Google. J'espère pour eux que l'outil qu'ils proposent depuis quelque jours pour résumer les page web s'en sort mieux que ça.
Grosso modo, NVD (National Vulnerability Database, une agence américaine déjà critiquée par Daniel par le passé) a attribué une CVE avec un niveau de sévérité quasi maximale (9,8 / 10) il y a quelques jours à un problème mineur sans implication sur la sécurité dans curl corrigé en 2019. On ne sait pas d'où ça sort, pourquoi le numéro de cette CVE contient 2020, pourquoi ce niveau sévérité, mais du coup la CVE est là et plein d'outils automatisés vont récupérer cette CVE et transmettre la fausse information. Il va objecter, et Ubuntu a déjà pris la peine d'affirmer dans leur suivi de sécurité qu'il n'y avait pas de problème et qu'ils étaient non affectés.
C'est un peu fou d'annoncer 8 à 20 % de perf en plus, et quand on mesure proprement, en fait les résultats sont à peu près les mêmes. Comment ont-ils obtenu ces nombres ? On voit bien les captures d'écran des tests, j'imagine qu'il suffit de lancer les tests un petit nombre de fois, ne rien lisser, ne faire aucune moyenne / médiane / min et de choisir les résultats qui arrangent. J'espère qu'ils n'ont pas fait ça. Il y a aussi au moins une explication sur pourquoi des meilleurs perfs seront attendue.
Mais ma première réaction a été que s'il y avait eu 8 à 20 % de perf à gagner, les dev Firefox l'aurait probablement su et aurait fait ce qu'il fallait. 8 à 20 %, c'est énorme. Et les tests Phoronix a l'air d'aller dans ce sens finalement (noter la présence des incertitudes sur les graphes, etc - on voit qu'il y a pas mal de variabilité, suffisamment pour que 8% soit dans les différences possibles).
De l'importance de faire des mesures et d'interpréter les résultats avec une méthodologie et des stats un peu robustes ! Là, la conséquence pratique pour le projet est existentielle.
Après, on peut se douter que la distribution principale de Firefox doit être un peu conservatrice au niveau optimisations processeurs pour tourner partout. Ça aurait du sens d'avoir un Firefox plus rapide en compilant pour des processeurs plus récent. Mais je suppose que Firefox est également capable de détecter les fonctionnalités processeurs et les utiliser là où ça compte le plus.
Plus généralement, même s'il y avait des gains, on ne sait pas combien de temps va durer le fork, ça semble un peu bancal.
Par contre, les améliorations constantes par les version de Firefox futures soulevées par les tests Phoronix, ça c'est cool. Finalement, si on veut un navigateur plus rapide, il suffit d'attendre la prochaine version :-)
Ici on voit bien un travail d'enquête utile de la part de Phoronix.
La semaine est un peu difficile (mais ça n'excuse pas). Ça n'a pas du aider la rédaction et j'aurais pu la fermer du coup. Je plaide coupable, vaut mieux écrire quand on y est disposé.
Et je reconnais que la réaction de barmic est tout à fait logique aussi du coup.
# If you happen to meet one of the copyright holders in a bar you are obligated
# to buy them one pint of beer.
Arf. Désolé de faire les rabats-joie, et je comprend que c'est pour le fun, mais du coup, ton code durement travaillé ne peut tout simplement pas être réutilisé sérieusement dans un projet libre. Si on réfléchit sérieusement aux conséquences d'une telle licence, quelqu'un qui utilise ce code se voit forcé, jusqu'à la fin de ses jours, de demander à tous les gens croisés dans n'importe quel bar si un bout de ce code est à eux et d'avoir l'argent pour leur payer une bière. En espérant que le service est toujours ouvert.
Je ne vais pas étudier ton code, et si un jour je devais me retrouver devant le problème, je vais devoir refaire le boulot. Tu as l'air d'être dans une optique de partage, du coup les conséquences de cette licence un peu farfelue pour le fun sont un peu regrettables.
Ce serait bien que les licences reste sérieuses pour qu'elles restent des outils sur lesquels on peut compter. "Ça va, ce n'est pas sérieux, on rigole" n'est pas vraiment une option de cet outil légal. Au pire il y a la licence WTFPL qui joue le rôle de licence fun mais suffisamment robuste. À la limite la licence Beerware, qui n'impose rien de spécial devrait fonctionner aussi.
Ces licences amusantes… ne le sont pas du tout quand elles sont utilisées pour de vrai.
C'est vrai, et en même temps en pratique sur le modèle que j'ai conseillé à quelqu'un il y a plus de 10 ans (un Asus C200) - qui l'utilise d'ailleurs toujours, il est méga rentabilisé ce truc ! On a remplacé ChromeOS par une distribution linux classique. Le support matériel a toujours été un point faible, en particulier le son qui n'arrête pas de déconner et qui demande d'installer des pilotes spécifiques. Heureusement que cette personne est patiente. Par contre je crois que maintenant, le noyau linux de base "upstream" qui vient avec la distribution fonctionne et qu'on n'est plus obligés de passer par le noyau spécifique fournit avec GalliumOS. Donc ça valide un peu. Peut-être que c'est ce qui sauve cet ordinateur en particulier d'ailleurs.
Oui et non du coup, ça peut rester quand même spécifique ChromeOS et ce n'est pas toujours super transposable vers les distributions plus classiques, et parfois oui.
On peut aussi espérer que Google a travaillé sur l'autonomie / l'efficacité énergétique du noyau et a remonté les patches et là, ça rentre bien dans le cadre que tu exposes.
c'est une version propriétaire de ChromiumOS, qui lui est libre. En particulier, c'est Chrome qui est dedans et pas Chromium.
C'est peut-être basé sur Gentoo, mais il n'est pas vraiment question d'utiliser ça comme une Gentoo, avec toute la puissance de son gestionnaire de paquets (oui, j'ai essayé, et oui, en pratique on est limité aux binaires installés - oui, on finit par faire fonctionner crouton et avoir une distro linux classique bancale par dessus mais la base Gentoo, ben…). À tel point que la prise en charge des applications de bureau GNU/Linux sous ChromeOS est récente, et passe par des conteneurs Debian. Des conteneurs Linux, on peut en lancer sous Mac et Windows aussi.
La durée de vie du Chromebook est fortement limitée par la durée pendant laquelle il reçoit des mises à jour. Rien à voir avec une distribution classique qui peut être mise à jour ad vitam eternam.
Dans l'esprit, l'idée de ChromeOS c'est de faire passer toute la vie informatique de l'utilisateur / l'utilisatrice par, et la cantonner au navigateur Chrome, idéalement les services Google. C'est loin de l'ouverture des horizons qu'on attend d'une distribution libre classique.
La base Gentoo ou même Linux de ChromeOS, c'est comme pour Android : malheureusement un détail technique quand il s'agit de parler de liberté des utilisateurs / trices (évidemment, dans une discussion technique, voire open source dans certains aspects, ça a sa place).
J'aimerais bien affirmer que le desktop c'est aujourd'hui 10% d'OS libres grâce à Chrome OS, mais ce serait déformer la réalité à un point inconfortable pour moi.
Et ce serait franchement dissonant avec le reste de mon discours qui consiste à pousser les gens à se dégoogliser.
Donc oui, 10% de noyaux Linux sur le desktop. Mais attention avec ce nombre selon le message que vous voulez faire passer.
La réalité c'est qu'on reste peu à utiliser des systèmes libres au quotidien et que tordre les proportions comme ça n'aide pas trop.
Sur une note plus positive, il faut aussi bien noter qu'il y a de plus en plus de gens pas du tout techniques qu'on soupçonnerait pas qui utilisent une distribution Linux classique par choix maintenant. Vous pourriez mentionner Linux, la personne en face, en plus de comprendre de quoi vous parlez, en fait l'utilise. Dernier exemple en date pour moi : avant-hier. Linux, c'est relativement mainstream maintenant. Les gens comprennent qu'il y a Windows, Mac, et aussi Linux (bon, et non, ils ne connaissent généralement pas *BSD).
RedHat serait alors tenue de distribuer les sources des logiciels sous GPL (pas forcément de toute la distribution, juste la partie qui a été reçue par les utilisateurs).
[^] # Re: Alternative à MongoDB
Posté par raphj (site web personnel) . En réponse à la dépêche HCW@Home : le logiciel open-source de téléconsultation. Évalué à 3.
Wow ! Comment avez-vous trouvé cet article du coup ?
How did you find this post since you don't speak French?
[^] # Re: Opensource mais...
Posté par raphj (site web personnel) . En réponse à la dépêche HCW@Home : le logiciel open-source de téléconsultation. Évalué à 8. Dernière modification le 06 septembre 2023 à 12:43.
Si une brique/dépendance de ton logiciel libre n'est pas libre, alors tu n'as toutes les libertés garanties par le libre sur l'ensemble. C'est le fond de la remarque de devnewton. C'est difficile à formuler parce que c'est presque une tautologie.
Plus spécifiquement et pire encore dans le cas de MongoDB : la clause spécifique de la SSPL sur devoir fournir tout le code nécessaire à faire tourner le service qui s'appuie sur MongoDB sous licence SSPL est très contraignante, voire impossible à réaliser parce que fatalement, ton service va s'appuyer sur d'autre logiciels libres distribués sous d'autres licences ((A)GPL par exemple) incompatibles avec la SSPL, et donc impossible à redistribuer sous cette licence.
Donc concrètement : potentiellement, tu ne peux juste pas utiliser la version SSPL de MongoDB. C'est impossible. Tu dois utiliser la version propriétaire, obtenue avec un accord commercial avec la société derrière MongoDB. En fait, je ne sais pas qui utilise légalement la version SSPL de MongoDB, je ne vois pas comment c'est possible, à part en tordant les interprétations et en saupoudrant abondamment de laisser-faire.
Maintenant, s'il existe une alternative compatible à MongoDB, c'est tout bon.
Ensuite, du libre dans le milieu de la santé, c'est une excellente nouvelle. Cette ouverture ne peut être qu'applaudie, c'est une superbe démarche, même si elle est imparfaite. Je suppose que ça peut se corriger.
[^] # Re: Vive IPv6
Posté par raphj (site web personnel) . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 6. Dernière modification le 06 septembre 2023 à 12:03.
D'ailleurs, il me semble bien que Jitsi Meet fait du pair à pair quand il n'y a que 2 personnes dans un salon.
Lors de la mise en place d'une instance à l'aube du confinement de 2020, la configuration du service qui s'occupe de transmettre les flux n'était pas encore correcte, lors des tests on pouvait discuter à 2 et la visio sautait quand une 3ème personne nous rejoignait. À priori parce que la visio à 2 était pair à pair, et à 3 Jitsi bascule vers le serveur central. D'ailleurs même quand on avait correctement mis les choses en place, on observait une breve coupure au passage de 2 à 3 ou de 3 à 2 qu'on n'observait pas lors d'un passage de 3 à 4.
Signal fait aussi passer les appels à 2 (ou plus ? je ne sais pas) en pair à pair par défaut (mais propose une option de passer systématiquement par leur serveur pour que le contact ne connaisse pas notre IP).
Ces deux logiciels reposent effectivement sur un service au milieu, au moins pour la mise en relation. On pourrait imaginer une mise en relation sans service au milieu, mais c'est quand même un peu compliqué. Pour que deux ordinateurs communiquent entre eux, il faut qu'ils connaissent leurs adresse ip respectives, c'est vaguement possible si les gens se sont échangés leurs adresses ip au préalable mais c'est supposer que leurs adresses ne changent pas, ce qui suppose :
C'est quand même une grosse supposition aujourd'hui. Avec la supposition, l'UX est quand même pas top. C'est un peu comme le téléphone mais une IPv6, c'est quand même vaguement long, en comparaison avec un numéro de téléphone à 10 chiffres (qui lui, ne change pas quand on change de fournisseur ; ou si on bouge d'endroit pour les téléphones mobile… grâce au fournisseur au milieu). On pourrait utiliser des QR codes maintenant, ou alors utiliser un autre moyen de communication pour se transmettre les adresses, mais cet autre moyen de communication s'appuie certainement sur un service au milieu.
Donc au moins pour la mise en relation, un service au milieu semble difficilement dispensable.
# Pourquoi c'est inutilé ?
Posté par raphj (site web personnel) . En réponse au lien Get a Cable Modem... Go to Jail. Évalué à 6.
J'ai lu cette page hier, c'était divertissant. Qu'est-ce qui ne va pas avec ce lien ? Au moment où je commente, il est évalué à -2 ici.
[^] # Re: Attention à la confusion
Posté par raphj (site web personnel) . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 2.
Super, merci :-)
[^] # Re: Attention à la confusion
Posté par raphj (site web personnel) . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 8.
Hello ! Ce serait plus meet.jit.si (l'instance en question) qu'il faudrait mettre, jitsi.org étant le site web du projet logiciel.
# lien récent à ce sujet
Posté par raphj (site web personnel) . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 10.
Un peu de discussion récente à ce propos : https://linuxfr.org/users/slubman/liens/jitsi-va-demander-un-compte-google-github-ou-facebook-pour-son-service-meet-jit-si
Pour ma part, je vais considérer l'utilisation de l'une de ces deux instances :
# Il suffit de demander à Qualcomm ?
Posté par raphj (site web personnel) . En réponse au lien Fairphone 5 sets a new standard with 8-10 years of Android support - OSnews. Évalué à 7. Dernière modification le 01 septembre 2023 à 11:30.
Donc Fairphone peut fournir 8-10 ans de mises à jour simplement en demandant à Qualcomm ? (via un contrat de support approprié)
Ma réaction à chaud : les fabricants de téléphones, ils se foutent quand même sacrément bien de notre gueule.
Mais Qualcomm aussi, hein, ils se foutent bien de notre gueule. S'ils faisaient un petit effort de ne pas forker comme des porcs et de plutôt upstreamer leurs dev, en fait ces problèmes n'existent pas.
Je suis sûr que si les fabricants de téléphone en avaient quelque chose à foutre, ils pourraient se regrouper et faire pression sur Qualcomm.
Concernant Fairphone, ça va dans le bon sens, c'est top.
Le téléphone est cher, mais si on arrive à le garder 8 ans, on passe d'un budget pour matériel haut de gamme à un budget premier prix.
# Jitsi Meet et GAFAM / Un triste jour
Posté par raphj (site web personnel) . En réponse au lien Jitsi va demander un compte google, github ou facebook pour son service meet.jit.si. Évalué à 7. Dernière modification le 28 août 2023 à 14:18.
J'ai hésité entre deux titres de commentaire alors j'ai mis les deux.
Je ne sais pas ce qu'ils essaient de bloquer donc c'est difficile de juger.
Un des nombreux avantages de meet.jit.si c'était de pouvoir éviter d'utiliser des GAFAM, justement. D'éviter de devoir accepter leurs conditions d'utilisations.
Malheureusement, ce n'est maintenant plus possible. En tout cas tant qu'ils n'ajoutent pas d'autres méthodes d'identification.
D'autant que Google a ses solutions de visio dont Google Meet ; Facebook a aussi plusieurs solutions de visio. Microsoft (qui a GitHub) aussi avec Teams. Donc on va se retrouver à utiliser le système d'authentification des concurrents, super.
Heureusement, ça ne concerne que la création de salon, donc si on est invité·e à une visio sur meet.jit.si, on n'est pas concerné·e. C'est déjà pas mal.
De plus, la restriction n'existe pas sur le logiciel lui-même et d'autres instances existent.
Utilisateur occasionnel de meet.jit.si pour mes besoins persos ou associatifs, je vais devoir trouver une alternative. Je vois 2 possibilités :
Auto-hébergement pour mes besoins
Utiliser une des autres instances en place, et pourquoi pas https://visiocall.com/, un Jitsi Meet à la sauce Algoo.
Mon employeur a aussi son instance dédiée au travail d'équipe, même s'il est possible de l'utiliser pour autre chose je ne pense pas que ça soit approprié.
Mais globalement je suis plus convaincu par BigBlueButton. Plus compliqué mais aussi beaucoup plus fiable d'expérience. Donc peut-être auto-héberger BBB.
Le problème de l'auto hébergement, c'est que j'aimerais vraiment pouvoir suggérer / proposer quelque chose que n'importe qui peut utiliser. Ce qui m'intéresse, ce n'est pas une solution pour juste moi, mais bien pour les autres aussi.
Et je ne pense pas pouvoir mettre le fric nécessaire à faire tourner une instance qui peut accueillir un grand nombre d'utilisateurs et d'utilisatrices. Et évidemment, à un moment on se heurte probablement à ces questions de modérations qui mènent au genre de mesures qu'on est en train de discuter.
[^] # Cette traduction et résumé auto montre tout ce qui ne va pas avec les modèles de langues
Posté par raphj (site web personnel) . En réponse au lien [curl] CVE-2020-19909 is everything that is wrong with CVEs. Évalué à 10.
Aïe aïe aïe. Désolé mais je vais être un peu rude. Ce n'est pas du tout contre toi, c'était une bonne idée de mettre un résumé en français. Merci pour la démarche mais du coup il y a besoin de rectifier le tir. Je n'ai malheureusement pas le temps juste maintenant de faire une traduction propre et compréhensible, j'en propose une à l'arrache à la fin de mon commentaire. Je suggère de ne pas poster des textes générés par des IA à l'avenir (sans beaucoup de vérifications), elles bullshittent, ne sont pas fiables et c'en est un exemple flagrant.
J'ai lu ce résumé auto et j'ai eu beaucoup de mal à le comprendre. Je suis allé voir l'article initial qui est lui clair comme de l'eau de roche (j'aime beaucoup l'écriture de Daniel). En revenant sur ce texte, je me rend compte que tout est faux, en plus d'être difficilement compréhensible.
Par exemple :
Non. Il vient d'apprendre son existence, et c'est le cœur du sujet de l'article
Non. L'article explique bien que justement, ce n'est pas une vulnérabilité, ni une critique
Non. Elle vient d'être rapportée, et il se demande justement pourquoi elle a été attribuée avec ce numéro contenant 2020. De son côté, quelqu'un lui avait déjà soumis le problème
Non. Elle fait 100 caractères, 15 mots. On ne peut plus concis. Elle est incompréhensible par des utilisateurs non experts mais Daniel ne parle pas du tout de ça parce que ce n'est pas le problème.
Non, rien de tout ça.
Rien des deux premiers points qui suit n'est vrai. Le 3 ème, vaguement.
Il critique en particulier NVD, sont trop grand pouvoir dans l'attribution des numéros CVEs et son incompétence.
Pas du tout. Ce n'est pas le sujet.
Bref, si je comprends bien, on a affaire à Bard, le LLM de Google. J'espère pour eux que l'outil qu'ils proposent depuis quelque jours pour résumer les page web s'en sort mieux que ça.
Grosso modo, NVD (National Vulnerability Database, une agence américaine déjà critiquée par Daniel par le passé) a attribué une CVE avec un niveau de sévérité quasi maximale (9,8 / 10) il y a quelques jours à un problème mineur sans implication sur la sécurité dans curl corrigé en 2019. On ne sait pas d'où ça sort, pourquoi le numéro de cette CVE contient 2020, pourquoi ce niveau sévérité, mais du coup la CVE est là et plein d'outils automatisés vont récupérer cette CVE et transmettre la fausse information. Il va objecter, et Ubuntu a déjà pris la peine d'affirmer dans leur suivi de sécurité qu'il n'y avait pas de problème et qu'ils étaient non affectés.
# Conclusion : circulez, il n'y a rien à voir ?
Posté par raphj (site web personnel) . En réponse au lien Mercury, un Firefox sous stéroïdes (ou pas). Évalué à 6. Dernière modification le 23 août 2023 à 09:56.
C'est un peu fou d'annoncer 8 à 20 % de perf en plus, et quand on mesure proprement, en fait les résultats sont à peu près les mêmes. Comment ont-ils obtenu ces nombres ? On voit bien les captures d'écran des tests, j'imagine qu'il suffit de lancer les tests un petit nombre de fois, ne rien lisser, ne faire aucune moyenne / médiane / min et de choisir les résultats qui arrangent. J'espère qu'ils n'ont pas fait ça. Il y a aussi au moins une explication sur pourquoi des meilleurs perfs seront attendue.
Mais ma première réaction a été que s'il y avait eu 8 à 20 % de perf à gagner, les dev Firefox l'aurait probablement su et aurait fait ce qu'il fallait. 8 à 20 %, c'est énorme. Et les tests Phoronix a l'air d'aller dans ce sens finalement (noter la présence des incertitudes sur les graphes, etc - on voit qu'il y a pas mal de variabilité, suffisamment pour que 8% soit dans les différences possibles).
De l'importance de faire des mesures et d'interpréter les résultats avec une méthodologie et des stats un peu robustes ! Là, la conséquence pratique pour le projet est existentielle.
Après, on peut se douter que la distribution principale de Firefox doit être un peu conservatrice au niveau optimisations processeurs pour tourner partout. Ça aurait du sens d'avoir un Firefox plus rapide en compilant pour des processeurs plus récent. Mais je suppose que Firefox est également capable de détecter les fonctionnalités processeurs et les utiliser là où ça compte le plus.
Plus généralement, même s'il y avait des gains, on ne sait pas combien de temps va durer le fork, ça semble un peu bancal.
Par contre, les améliorations constantes par les version de Firefox futures soulevées par les tests Phoronix, ça c'est cool. Finalement, si on veut un navigateur plus rapide, il suffit d'attendre la prochaine version :-)
Ici on voit bien un travail d'enquête utile de la part de Phoronix.
[^] # Re: Ai-je bien compris
Posté par raphj (site web personnel) . En réponse au lien Fabrice Bellard : Text Compression using Large Language Models. Évalué à 2.
Wat? Et du coup, est-ce vrai pour la version du pilote aussi ? Pourquoi ça influe ?
Si quelqu'un a des idées…
[^] # Re: ça dépend
Posté par raphj (site web personnel) . En réponse au journal Ah la SNCF!. Évalué à 2.
Ouais. Pas besoin d'imprimer, et on peut aussi les montrer sur un écran d'ordinateur. Pas besoin de l'appli SNCF non plus.
[^] # Re: Je sais que...
Posté par raphj (site web personnel) . En réponse au lien Thème Windows 95 pour Linux. Évalué à 8.
Un retour d'expérience s'impose :-)
[^] # Re: Dommage cette licence non libre
Posté par raphj (site web personnel) . En réponse au journal Django + Jupyter Lab = ❤️. Évalué à 2.
Chouette :-) Merci !
[^] # Re: Dommage cette licence non libre
Posté par raphj (site web personnel) . En réponse au journal Django + Jupyter Lab = ❤️. Évalué à 3. Dernière modification le 20 juillet 2023 à 17:50.
Arf, toutes mes plus plates excuses alors !
La semaine est un peu difficile (mais ça n'excuse pas). Ça n'a pas du aider la rédaction et j'aurais pu la fermer du coup. Je plaide coupable, vaut mieux écrire quand on y est disposé.
Et je reconnais que la réaction de barmic est tout à fait logique aussi du coup.
[^] # Re: Dommage cette licence non libre
Posté par raphj (site web personnel) . En réponse au journal Django + Jupyter Lab = ❤️. Évalué à 2.
Top !
J'espère que mon commentaire t'a paru moins "grands chevaux" qu'à barmic, ce n'était clairement pas l'intention.
[^] # Re: Dommage cette licence non libre
Posté par raphj (site web personnel) . En réponse au journal Django + Jupyter Lab = ❤️. Évalué à 3. Dernière modification le 20 juillet 2023 à 10:23.
Si j'ajoute "potentielles" après "réfléchir sérieusement aux conséquences", ça te plaît mieux ?
Sinon, on dirait que tu m'as volé mes grands chevaux, et qu'en plus tu as ajouté les tiens…
Ton argumentaire repose sur :
Mais alors, pourquoi compliquer les choses avec une licence douteuse, et aussi es-tu vraiment sûr de ce que tu avances ?
[^] # Re: Dommage cette licence non libre
Posté par raphj (site web personnel) . En réponse au journal Django + Jupyter Lab = ❤️. Évalué à 2. Dernière modification le 19 juillet 2023 à 17:28.
Ah oui, et tu penses que si un·e dev part aux toilettes et revient, ça compte comme une nouvelle rencontre et donc :
# Dommage cette licence non libre
Posté par raphj (site web personnel) . En réponse au journal Django + Jupyter Lab = ❤️. Évalué à 4. Dernière modification le 19 juillet 2023 à 15:07.
Arf. Désolé de faire les rabats-joie, et je comprend que c'est pour le fun, mais du coup, ton code durement travaillé ne peut tout simplement pas être réutilisé sérieusement dans un projet libre. Si on réfléchit sérieusement aux conséquences d'une telle licence, quelqu'un qui utilise ce code se voit forcé, jusqu'à la fin de ses jours, de demander à tous les gens croisés dans n'importe quel bar si un bout de ce code est à eux et d'avoir l'argent pour leur payer une bière. En espérant que le service est toujours ouvert.
Je ne vais pas étudier ton code, et si un jour je devais me retrouver devant le problème, je vais devoir refaire le boulot. Tu as l'air d'être dans une optique de partage, du coup les conséquences de cette licence un peu farfelue pour le fun sont un peu regrettables.
Ce serait bien que les licences reste sérieuses pour qu'elles restent des outils sur lesquels on peut compter. "Ça va, ce n'est pas sérieux, on rigole" n'est pas vraiment une option de cet outil légal. Au pire il y a la licence WTFPL qui joue le rôle de licence fun mais suffisamment robuste. À la limite la licence Beerware, qui n'impose rien de spécial devrait fonctionner aussi.
Ces licences amusantes… ne le sont pas du tout quand elles sont utilisées pour de vrai.
[^] # Re: What is ChromeOS
Posté par raphj (site web personnel) . En réponse au lien Linux a près de la moitié des parts de marché du desktop sous Linux 😎. Évalué à 4. Dernière modification le 18 juillet 2023 à 18:13.
C'est vrai, et en même temps en pratique sur le modèle que j'ai conseillé à quelqu'un il y a plus de 10 ans (un Asus C200) - qui l'utilise d'ailleurs toujours, il est méga rentabilisé ce truc ! On a remplacé ChromeOS par une distribution linux classique. Le support matériel a toujours été un point faible, en particulier le son qui n'arrête pas de déconner et qui demande d'installer des pilotes spécifiques. Heureusement que cette personne est patiente. Par contre je crois que maintenant, le noyau linux de base "upstream" qui vient avec la distribution fonctionne et qu'on n'est plus obligés de passer par le noyau spécifique fournit avec GalliumOS. Donc ça valide un peu. Peut-être que c'est ce qui sauve cet ordinateur en particulier d'ailleurs.
Oui et non du coup, ça peut rester quand même spécifique ChromeOS et ce n'est pas toujours super transposable vers les distributions plus classiques, et parfois oui.
On peut aussi espérer que Google a travaillé sur l'autonomie / l'efficacité énergétique du noyau et a remonté les patches et là, ça rentre bien dans le cadre que tu exposes.
[^] # Re: What is ChromeOS
Posté par raphj (site web personnel) . En réponse au lien Linux a près de la moitié des parts de marché du desktop sous Linux 😎. Évalué à 10. Dernière modification le 18 juillet 2023 à 17:27.
Bof, ChromeOS n'est pas vraiment une victoire.
Oui, c'est beaucoup de code libre, mais :
La base Gentoo ou même Linux de ChromeOS, c'est comme pour Android : malheureusement un détail technique quand il s'agit de parler de liberté des utilisateurs / trices (évidemment, dans une discussion technique, voire open source dans certains aspects, ça a sa place).
J'aimerais bien affirmer que le desktop c'est aujourd'hui 10% d'OS libres grâce à Chrome OS, mais ce serait déformer la réalité à un point inconfortable pour moi.
Et ce serait franchement dissonant avec le reste de mon discours qui consiste à pousser les gens à se dégoogliser.
Donc oui, 10% de noyaux Linux sur le desktop. Mais attention avec ce nombre selon le message que vous voulez faire passer.
La réalité c'est qu'on reste peu à utiliser des systèmes libres au quotidien et que tordre les proportions comme ça n'aide pas trop.
Sur une note plus positive, il faut aussi bien noter qu'il y a de plus en plus de gens pas du tout techniques qu'on soupçonnerait pas qui utilisent une distribution Linux classique par choix maintenant. Vous pourriez mentionner Linux, la personne en face, en plus de comprendre de quoi vous parlez, en fait l'utilise. Dernier exemple en date pour moi : avant-hier. Linux, c'est relativement mainstream maintenant. Les gens comprennent qu'il y a Windows, Mac, et aussi Linux (bon, et non, ils ne connaissent généralement pas *BSD).
[^] # Re: ça bouge, ça évolue
Posté par raphj (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 3. Dernière modification le 17 juillet 2023 à 09:01.
RedHat serait alors tenue de distribuer les sources des logiciels sous GPL (pas forcément de toute la distribution, juste la partie qui a été reçue par les utilisateurs).
[^] # Re: que chercher à faire Suse ?
Posté par raphj (site web personnel) . En réponse au lien SUSE Preserves Choice in Enterprise Linux by Forking RHEL with a $10+ Million Investment . Évalué à 3.
À mon avis, la différence c'est l'offre de support que Rocky et Alma ne vont probablement pas fournir.
[^] # Re: Et du coup pour DLFP
Posté par raphj (site web personnel) . En réponse au journal Les mineurs privés de télécommunication, les majeurs traqués. Évalué à 2.
Oui, j'ai clairement commencé à fréquenter LinuxFr vers 12-13 ans. (et j'ai ouvert un compte bien plus tard)