Renault a écrit 7156 commentaires

Simple utilisateur de Fedora (depuis presque 10 ans !), je me demande à quel point cette proposition a des chances d'aboutir ? Est-ce qu'il y a une personne familière de ce process qui pourrait nous en dire plus ?

Pour info c'est une proposition, certes émise manifestement par le groupe de travail de KDE de Fedora mais c'est libre. Demain je peux proposer qu'on abandonne le noyau Linux pour celui de FreeBSD par exemple, une proposition n'engage rien et personne tant que le FESCo (l'équipe technique) n'a pas approuvé ce changement.

Quand on lit les échanges, la nature de ce changement et leur justification me semblent un peu bizarres. On dirait surtout que le but poursuivi n'est pas d'être le bureau par défaut mais d'avoir plus de visibilité pour KDE qui est à ce jour une Spins et donc un peu caché par rapport aux éditions telles que Workstation, Server, etc. Mais du coup la solution à ce problème n'est pas forcément la voie choisie.

Il semble peu probable que cela change rapidement car :

• KDE c'est gros et même si KDE SIG fait un beau travail ces dernières années, ça reste plus complexe à fiabiliser que GNOME qui a aussi sans doute une équipe plus grosse derrière ce dernier à ce jour ;
• KDE a des atouts mais GNOME est fiable et n'a pas de manques qui justifient un tel changement à ce jour ;
• Changer un tel composant par défaut est une rupture fondamentale qui doit être justifiée, on ne doit pas le faire sur un coup de tête ou avec des gains faibles. Et 1 an cela me semble court (c'est Fedora Linux 42, donc avril 2025 en théorie).
• L'équipe Workstation travaille upstream avec GNOME pour améliorer l'expérience utilisateur globale (j'ai plusieurs dépêches publiés ici même où j'expose cela) : est-ce que KDE accepterait les changements suggérés par cette équipe ? Est-ce que les gens de cette équipe ont les compétences pour travailler avec l'écosystème KDE ?
• KDE est orienté "très personnalisable" ce qui rend cet écosystème riche et puissant mais cela implique aussi une plus grande difficulté à fiabiliser et l'expérience utilisateur peut être plus complexe qu'avec un environnement plus simpliste tel que GNOME.

Je suis moyennement convaincu par les arguments avancés pour justifier cela étant données les implications.

Dans les échanges il semble clairement qu'il y a une réflexion pour éventuellement donner une plus grande visibilité à KDE à la place d'être un Spin perdu dans un site web annexe. Mais cela signifie :

• Plus compliqué sans doute niveau communication, chaque choix que l'utilisateur doit faire peut être perturbant, d'où l'intérêt d'un choix par défaut très visible avec des options possibles mais "cachées". L'intérêt de Workstation tout ça c'est de travailler à améliorer la communication autour de ces produits.
• Quelle place lui donner exactement ?
• Remise en cause de Fedora.next adopté il y a 10 ans ?

En tout cas, je ne trouve pas la proposition aberrante en tant que telle. C'est sain qu'un projet puisse remettre en question ce genre de choses. Il faut évoluer et ne pas être bloqué par des choix faits il y a 10 ans. Et au niveau Fedora faire une proposition comme celle-ci est le meilleur moyen d'ouvrir le débat et éventuellement que cela aboutisse à quelque chose.

Cependant je doute que ce soit accepté en l'état à ce jour. Il est plus probable de trouver un compromis pour que KDE soit mieux mis en avant. Cela permet aussi d'ouvrir le débat de savoir ce qu'on peut reconsidérer dans la politique Fedora.next qui a adopté la notion d'éditions comme Workstation.

Mais peut être qu'un jour les conditions seront réunions, KDE aurait une telle avance et GNOME aurait trop de problèmes qu'il n'y aurait pas le choix que de considérer un tel changement. Et si ce jour arrive, c'est sain que le projet puisse adopter ce changement ou en tout cas le discuter.

Admettons que le logiciel soit libre, ça changerait quoi ?

Il faudra peut être changer le code source à la main pour le permettre car cette option est inscrite en dur dans le code ou qu'il n'y a pas d'outil distant pour changer ce paramètre pour le médecin ou l'utilisateur. Ce n'est pas à la portée de tous, que ce soit du patient comme du médecin.

Puis une fois le code source est modifié, il faut pouvoir installer cette nouvelle version :

• Le dispositif le permet-il matériellement ?
• Est-ce qu'il y a des protections matérielles qui rendent obligatoire une signature par l'entreprise au préalable ?
• En cas d'accident avec la nouvelle version perso qui est le responsable ?

Bref, ce n'est pas trivial, le mettre sous licence libre ne règle absolument pas par magie le problème. Car la licence libre n'empêche pas certains verrouillages ou des problèmes de conception qui rendent ces modifications inopérantes ou difficiles.

Le problème est que le système est privateur : les chirurgiens cardiologues n'ont pas la possibilité de régler le seuil, celui-ci est fixé en dur dans l'algorithme et son implémentation qui ne sont donc modifiables que par le fabricant.

Je trouve qu'il y a un amalgame dans le podcast comme ton journal entre privateur au sens définition du LL et personnalisable. Pourtant la bonne raison du problème est donnée par le podcast : la règlementation.

On peut faire un logiciel proprio qui offre accès à beaucoup de paramètres librement et facilement tout comme on peut faire un logiciel libre et un produit ouvert qui finalement est difficile à personnaliser. L'accès au code source ne garantie pas que le code permet de simplement changer des valeurs internes depuis l'extérieur, ni de mettre à jour le logiciel sur la machine (même si la machine est openhardware).

Le réel soucis ils le disent : il y a une règlementation, pour que le produit puisse être utilisé dans un pays dans ce contexte il doit être certifié et changer le produit peut remettre en cause cette certification. De plus il faut aussi s'assurer que l'utilisateur ou les médecins ou une personne malveillante ne puisse pas abuser de certaines options pour mettre en danger la vie des patients. Donc le fabricant est frileux, ce n'est pas facile car s'ils changent un truc il faut potentiellement le certifier à nouveau (cher et complexe) et cela prendra de toute façon du temps.

La règlementation est rigide, il y a de bonnes raisons à cela aussi, ce qu'il faudrait c'est sans doute que la règlementation impose (si ce n'est pas déjà fait) certaines possibilités pour éviter des cas problématiques comme ça par design (genre désactivation d'une alarme pour plusieurs heures, mise à jour toujours possible, accès à certains paramètres non vitaux directement mais utiles pour les médecins comme la configuration des alarmes). On pourrait rêver de libérer aussi les composants logiciels comme matériels mais dans le fond sans les mesures précédentes cela n'empêcherait pas des problèmes de conception qui rendent cela tout aussi pénible malgré la liberté légale de jouer avec.

Très souvent complètement absente.

Je ne sais pas sur quels sites d'actualité tu traines, mais je trouve cette information la quasi totalité du temps.
Cela n'est pas toujours évident à l'identifier mais ça se trouve en général.

Quand elle est là, elle est parfois en petit tout en bas.

Oui.

Quand elle est là, elle n’est généralement pas fiable : certaines dates sont automatiques pour afficher le jour (ça améliore le SEO). D’autres réflètent visiblement la dernière mise à jour (parfois des années après le post initial, sans doute pour corriger une typo).

De même, je ne trouve pas cette pratique très souvent sur les sites d'actus. Ou alors c'est clairement identifiable en mode "mise à jour le, publié le".

Pour moi le principal problème sur les sites d'actu c'est sa mise en valeur plus que sa présence.

(perso, c’est d’ailleurs pour ça que je mets la date en grand et gras au début de chaque article de mon blog)

Et c'est bien car je pense que c'est important.

Je crois que le truc qui est le plus dérangeant avec Internet c’est surtout qu’on ne lit pas forcément un article le jour de sa parution. Avec les journaux papiers, t’achetais le journal du jour et tu le lisais très rarement le lendemain. Sur le web, est un article peut être lu complètement hors contexte des années plus tard.

Lire la date d'un article est pourtant un réflexe à acquérir.
Même en mettant de côté l'aspect du 1er avril, un article peut être vieux (et donc faux ou trop daté pour être pertinent dans ce qu'on cherche), ou manquer de recul par rapport à un événement en cours à l'époque (ce qui peut être ce qu'on recherche par ailleurs).

Pour information, Lennart explique bien que le protocole de notification est trivial pour justement être géré à la main plutôt que de dépendre de libsystemd pour juste cette fonction : https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VIC24J7M46BW2QSQDXBNGNUS4QXH4ZBB/

Donc en gros c'est le choix de xz ici d'avoir privilégié une dépendance en plus pour si peu plutôt que de "refaire à la main".

de cmake en plus de make & autotools ;

Car bizarrement les systèmes de builds des distros, systèmes embarqués et autres composants sont variés, diversifier les prises en charge permet de s'assurer une bonne compatibilité d'intégration tout en ayant une compatibilité ascendante avec les projets utilisant des outils plus anciens.

C'est un choix qui se défend même si un jour se passer de autotools pourrait être la solution.

de m4 de la mort ?

m4 est nécessaire avec autotools. Malheureusement.

de tests avec des scripts shell au lieu d'un cadriciel de test unitaire ? ;

Il n'y a pas que les tests unitaires dans la vie et utiliser des scripts pour ça n'a rien de sale même si avoir une intégration avec le code comme on peut le faire avec gtest en C++ est appréciable.

Bref, c'est plus compliqué que tu ne sembles le penser. Après on peut souhaiter un nettoyage pour supprimer les vieux bouts mais bon ne sous estime pas la capacité des utilisateurs à râler car on a supprimé leur prise en charge de leur vieillerie aussi et qu'on accuserait vite d'être de "l'obsolescence programmée".

Surtout qu'ici avoir ou non la porte dérobée revient à inclure ou non une version spécifique d'un logiciel.
C'est donc du hasard, parfois la distribution aura la bonne version parfois pas. On ne peut pas le prédire et aucune politique de distribution n'est bonne à cet égard. Donc en effet fanfaronner que X n'a pas la faille est ridicule dans ce contexte.

Là où la distribution peut jouer c'est en compilant et en intégrant le composant avec d'autres mesures de sortes que une faille ou une porte dérobée n'ait pas d'effets. C'est là où une distribution peut faire la différence à ce sujet, mais ce n'est pas ce qui nous intéresse ici.

Et je ne crois pas que la politique de Mageia soit justement très pro-sécurité. En même temps c'est un sujet complexe et même de grosses distributions avec plus de moyens peuvent faire mieux.

Ou pour la sécurité sociale.

Oui bien sûr, mais au delà de ça, des mises à jour classiques qui rendent le boot non fonctionnel chez Fedora sans que cela ne soit sous le contrôle de l'utilisateur car tout est allé au bout de la procédure, cela arrive, ce ne sont pas les rapports de bogues ou les questions sur le forum qui diront le contraire. Car il y a toujours des configurations logicielles et matérielles qui rendent ces étapes difficiles à garantir pour tout le monde, et avec suffisamment d'utilisateur il y en a toujours qui de temps en temps ont un pépin.

Donc avoir la possibilité de revenir à un état stable de manière immédiate c'est vraiment cool.

En moyenne c'est assez stable, mais des problèmes il y en a toujours. En particulier lors des mises à niveau.

Cela ne m'étonnerait pas que dans le futur on ajoute une couche de plus pour apporter la flexibilité manquante, avoir quelque chose du genre :

• Système minimal avec rpm-ostree : chargeur de démarrage, noyau, systemd, bibliothèques de base, environnement de bureau et écran de login (pas plus) ;
• Système classique pour installer des paquets en plus, plutôt orientés utilitaires ou outils bas niveaux pour le développement ou les systèmes qui à priori ne compromettent pas le boot et pour qui l'isolation ne fonctionne pas bien ;
• Flatpak pour les applications graphiques ;
• Conteneurs avec toolbox pour ceux qui veulent des environnements de développement plus flexibles que ce qui est proposé par Fedora, notamment concernant les versions des langages de programmations et des outils associés.

Cela serait cohérent avec la conception derrière et dans la continuité de Fedora.next en un sens. Si jamais du moins aucune solution satisfaisante n'est trouvée autrement.

Pour un truc comme Copilot, il faut donc prouver que le code issu du logiciel est dérivé d'un bout de code de la base de données.

Même pas dans la BDD.

Copilot reproduit par accident un bout de code identique qui n'était pas dans son apprentissage, cela violerait la loi. De la même façon que si par hasard Midjourney reproduit une oeuvre de pop culture sans pour autant l'avoir dans son entrainement aurait le même problème. C'est peu probable, mais ça montre qu'on n'a pas besoin d'avoir les données d'apprentissage pour faire condamner. Le fait que ce soit dans l'apprentissage ou non pourrait influer probablement la sanction mais ne change pas la violation de la loi.

Ça me semble impossible avec un LLM correctement paramétré.

Je te trouve bien confiant sur ce point quand on voit justement ce que tous les LLM font à ce sujet jusqu'à aujourd'hui. En dehors de supprimer toute référence lors de l'apprentissage c'est difficile à éviter en tout cas à ce jour.

Encore une fois, la propriété intellectuelle ne se dilue pas, la contrefaçon est binaire : 1% de contrefaçon, ça n'existe pas; il existe un seuil de divergence au-delà duquel l'auteur initial n'a plus de droits à faire valoir.

Si si.
Prends une image couverte par le droit d'auteur, prends en 50% à l'identique ou presque et change le reste. Tu tomberas sous le coup de la loi même si 50% est de toi. De même pour un morceau de films, livres, musique, etc.

Le code n'est pas différent, si tu prends quelques fonctions non triviales directement d'ailleurs, tu peux avoir des problèmes même si le reste de ton code est fait maison.

Au passage, il y a aussi une bizarrerie à résoudre : dans oeuvre dérivée, il y a "oeuvre". Or, il est admis que la sortie d'un LLM n'ouvre pas de droits d'auteurs parce que ça n'est pas une oeuvre de l'esprit. Il n'y a donc pas d'appropriation des droits d'auteurs par quiconque.

Il n'y a pas besoin, cela n'autorise pas les LLM à générer tout ce qu'ils veulent et on le voit bien avec les affaires en cours.

Cela ne veut rien dire ;)

Ils utilisent sans doute une techno qui permet de coder l'application mobile et son versant web avec un minimum de duplication. Ce genre d'outils ne génère pas un code HTML particulièrement léger.

Beaucoup de politiques sont des brutes en économie,

Certains, probablement, beaucoup ça reste à démontrer.

C'est le point principal et je pense que cela passera. Si c'est possible de le faire en fair use toute la culture incluse dans les IA sera anglo-saxonne.

Le fair use pour s'entrainer c'est une chose, le fair use dans le résultat c'est beaucoup moins probable et ça va être un peu le nerf de la guerre.

Si les IA débitent facilement des œuvres contrefaites cela peut poser un problème dans le cas où la justice considère que l'entreprise doit mettre en place des mesures sous peine de sanctions. Et ce n'est pas un sujet trivial. Cela pourrait totalement mettre à mal le fonctionnement de ces IA justement.

C'est donc à voir, la justice va se pencher dessus mais j'ai de gros doute que ça passera crème sans efforts de la part des entreprises concernées.

Les violations de copyright c'est pas vraiment dépendant du moyen technique utilisé pour fabriquer l'œuvre je crois.

Oui.

Je pense que si tu reproduit à l'identique une grande part d'un code il y a de toute façon question à se poser, ça n'a aucune chance de se produire au hasard hors de toutes petites portions.

C'est l'idée oui.

Après si tu donnes un prompt assez précis pour que ça se reproduise, on peut soupçonner que le prompt avait pour but de reproduire l’œuvre …

Pas besoin, il y a eu des cas où des termes pourtant vagues et génériques permettait de ressortir des visuels de la pop culture. On peut imaginer le cas où tu demandes un générateur de labyrinthe et il te ressort un code proche (voire identique) à un code existant.

Et puis pour démontrer que le modèle est bel et bien généré par le jeu d'apprentissage prétendu ça doit pas être si simple, faut un apprentissage qui soit reproductible, c'est un challenge https://neptune.ai/blog/how-to-solve-reproducibility-in-ml Pas dit que ce soit la priorité des industriels d'avoir une reproductibilité digne d'une science ouverte et reproductible, c'est pas leur objectif numéro 1.

Ici pas besoin, si quelqu'un identifie une correspondance, il y a violation. Pas besoin de prouver que c'était dans le jeu d'apprentissage. Après à l'entreprise de dire si c'était présent ou non dans l'apprentissage, on peut supposer que la justice ne traite pas les cas de manière identique.

Ce qui est sûr c'est que si le modèle recrache tel quel du contenu sous copyright, alors il y a violation de droit d'auteur même si la phase d'entrainement est valide juridiquement (en admettant qu'elle le soit).

C'est une grosse limitation pour ces outils qui vont devoir y mettre des moyens de dingue pour s'assurer qu'ils ne violent pas le droit d'auteur dans ces conditions. Le plus simple est effectivement de limiter les données d'entrainement à ce qui est permis, cela limite les risques et en cas de coïncidence (sortir un code protégé mais qui n'est pas dans les données d'entrainement) ils pourraient démontrer que c'est une coïncidence et non une violation de copyright.

Euh tu sais que la configuration de NetworkManager que tu l'édites à la main, que tu utilises la GUI de GNOME ou nmcli cela revient au même ? Les fichiers sont stockés au même endroit et de la même façon, la conf est identique… Et heureusement, ce ne sont que des interfaces utilisateurs différents, le reste de l'outil est le même.

Notons que la TV en direct utilise du multicast pour être distribué sur le territoire national. C'est bien moins coûteux et gourmand que des flux individuels pour la même qualité d'image.

Écrire un algo en pseudo code ne me semble pas très pertinent dans un cadre pro. Dans un contexte scolaire je pense que ça peut avoir du sens car tu apprends.

Par contre faire la conception sur papier, poser les idées, passer du temps à réfléchir dessus, etc. cela a du sens dans un contexte pro. Après chacun son outil mais je trouve la papier pratique pour cela.

Je trouve, oui. En quoi ça ne serait pas pertinent selon toi ?

Je veux dire, tout le monde ne connaît pas le sujet, l'article est assez trompeur sur les capacités (je trouve), le manque de recul sur l'IA est assez important en ce moment dans l'esprit de beaucoup de gens, rappeler concrètement les limites ne me paraît pas inutile.

Peut être, cela n'est cependant pas trivial et ne peut être déduit avec ce qui a été publié.

Mon propos n'est pas de dire que l'approche ne mènera à rien dans tous les cas. Je dis juste que ce qui est présenté pour l'instant ne montre rien de si extraordinaire pour justifier un article aussi dithyrambique.

C'est une preuve de concept, faut creuser la question et pourquoi pas, ça peut donner des résultats intéressants (ou pas).

C'est un peu comme lire les articles scientifiques de certains présentant des nouveaux matériaux ou traitements médicaux révolutionnaires alors qu'en vrai la plupart n'iront pas plus loin que le labo où la découverte a été publié car finalement c'était une mauvaise piste. Ce n'est pas un mal de communiquer dessus mais je trouve la forme souvent excessive.

Après c'est Korben, ce n'est pas la première fois qu'il fait ça et typiquement je ne le lis pas pour cette raison.

Le seul ajout est celui de tests automatiques mais le taux d'échecs même dans un cas simple est encore très faible.

Et encore très élevé, pardon.