1 points par GN⁺ 5 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Lors de la revue des soumissions Flathub, l’augmentation des soumissions de faible qualité basées sur des LLM a accru la charge des relecteurs bénévoles, ce qui a motivé la clarification de la politique
  • Des exceptions devraient vraisemblablement s’appliquer aux projets montrant des signes de participation de la communauté, de cycle de publication, de CI, et qui ne ressemblent pas à des résultats bâclés produits en peu de temps
  • Les critères existants fondés sur l’historique de développement et la santé du projet n’ont pas permis de réduire la charge de revue, et n’ont fait qu’augmenter les conflits d’interprétation des règles
  • La nouvelle politique ne vise pas à interdire les applications FOSS matures ayant utilisé partiellement des LLM, ni l’ensemble des applications propriétaires existantes, mais se concentre sur les soumissions à faible effort
  • Certains craignent un retour de la fragmentation de la distribution dans l’écosystème Flatpak et l’évitement de Flathub par les entreprises, et proposent de facturer des frais plutôt qu’une interdiction totale

Changement de politique de Flathub sur les soumissions liées aux LLM

  • Lors de la revue des soumissions Flathub, l’augmentation des soumissions de faible qualité basées sur des LLM a fortement accru la charge des relecteurs bénévoles, ce qui constitue le principal motif du changement de politique
  • Sjoerd Stendahl estime qu’il y avait beaucoup de soumissions de type « AI-slop » dans la liste des PR Flathub, et qu’au vu de leur volume, cette mesure pourrait être le meilleur choix
  • Bart Piotrowski a indiqué qu’un projet a de fortes chances d’obtenir une exception s’il montre une participation de la communauté, un cycle de publication, de la CI, et des traces montrant qu’il ne s’agit pas d’un résultat de faible qualité produit rapidement
  • Flathub essayait déjà de bloquer les soumissions de faible qualité à partir de critères comme un historique de développement suffisant et la santé générale du projet, mais cela n’a pas réduit la charge de revue et a surtout créé des conflits autour de l’interprétation des règles

Exceptions et critères de maturité

  • Nexi estime que le problème des soumissions Flathub à faible effort est réel, mais qu’une interdiction globale de tout code généré ou assisté par IA serait excessive
  • Si même des projets existants comme Firefox, VSCode ou Chromium pouvaient être supprimés sans exception, Nexi propose qu’un indicateur objectif de maturité du projet soit plus approprié pour filtrer les soumissions de faible qualité
  • Bart Piotrowski a répondu que des critères de maturité existaient déjà de fait, mais qu’ils n’avaient finalement pas permis de réduire la charge de revue
  • Nexi estime aussi que les critères d’exception devraient être clairement intégrés à la politique, avec la possibilité d’un rejet sans explication supplémentaire si la qualité du code est trop faible
  • Sjoerd Stendahl considère que la nouvelle politique prévoit des exceptions pour les projets matures et bien maintenus, et qu’elle ne vise pas à interdire les applications FOSS éprouvées ayant utilisé en partie des LLM, ni l’ensemble des applications propriétaires existantes

Effets sur l’écosystème et inquiétudes sur les canaux de distribution

  • Dmitry Mantis craint que cette politique ne recrée la fragmentation de la distribution Linux que Flatpak cherche justement à résoudre
  • Le fait que des applications propriétaires comme Slack et Spotify soient proposées sur Flathub sous forme sandboxée est un avantage, et il s’interroge sur le fait que le code fermé puisse au contraire être avantagé puisqu’on ne peut pas savoir comment il a été écrit
  • Certains répondent qu’il vaut de toute façon mieux ne pas publier immédiatement sur Flathub les applications propriétaires de développeurs nouveaux et inconnus, même en l’absence de cette politique
  • La tendance de certaines applications jusque-là distribuées uniquement en AppImage à commencer à proposer un Flatpak officiel est positive, mais certains craignent qu’après une telle politique, des entreprises évitent d’entrer sur Flathub
  • Une autre proposition consiste à imposer des frais aux soumissions basées sur l’IA pour financer les coûts de revue, plutôt qu’à les interdire totalement
  • Cela pourrait aussi être perçu comme un signal indiquant qu’il faut d’abord distribuer ailleurs avant d’atteindre un certain niveau d’utilisateurs, et si des applications bien maintenues utilisant des LLM pour certains tests ou pour automatiser une partie de la documentation s’installent sur d’autres canaux de distribution, leur motivation à migrer vers Flathub pourrait diminuer

Évaluations opposées autour des outils LLM

  • Thomas Fuchs estime que le problème des LLM tient davantage aux personnes et au marketing qu’à la technologie elle-même
  • Il souligne que les entreprises de LLM vendent ces outils comme de la magie ou comme des esclaves personnels pour le travail, et que de nombreux utilisateurs croient ces promesses telles quelles
  • Utilisés par des personnes expérimentées qui en connaissent les forces et les faiblesses pour des usages limités, ils peuvent être d’excellents outils, mais il décrit la promotion du secteur comme le fait de « distribuer gratuitement des tronçonneuses en feu pour faire du jonglage »
  • Wolkensteine ne considère pas que les LLM soient totalement inutiles, mais estime qu’ils sont peu utiles dans la plupart des cas et qu’il n’existe pas encore de modèle utile construit d’une manière qu’il souhaiterait soutenir sur le plan éthique
  • Les modèles on-device peuvent aider pour la correction orthographique ou la prédiction de mots dans l’autocorrection des claviers de téléphone, mais les tâches qu’ils peuvent accomplir sans erreur sont généralement aussi des choses que les humains peuvent faire facilement tout en apprenant
  • Ember estime que même ces usages potentiels étaient déjà possibles avec des outils antérieurs à l’IA générative, et que dans de rares cas un ML spécialisé entraîné sur des données précises serait préférable
  • Kroc Camen affirme que les LLM n’ont nulle part d’usage valable à cause du pillage de code, des biais intégrés et de leur impact environnemental

Culture communautaire et polarisation du débat

  • trisweb estime que la culture entourant le code généré par LLM et ses utilisateurs est souvent incompatible avec l’approche bienveillante et coopérative nécessaire au maintien des communautés open source
  • ragectl estime qu’une philosophie de type période de refroidissement pourrait être nécessaire pour les nouvelles applications, qui resteraient potentiellement risquées jusqu’à plusieurs versions publiées et l’arrivée d’un deuxième contributeur humain
  • Sjoerd Stendahl estime qu’il faut se méfier des chasses aux sorcières, mais que la poussée agressive des LLM par les Big Tech alimente la réaction de rejet
  • Certains employeurs exigent l’usage des LLM au travail sous menace de licenciement, même des fonctions simples comme la recherche ont été dégradées, et il décrit l’« Agentic future » comme une demande extrêmement étroite alors que de nombreux produits deviennent des sortes de résidus imitant le travail humain
  • razze estime que les problèmes liés à l’usage des LLM pour la recherche ou les chatbots sont distincts de leur usage pour le code, car le code peut être vérifié et les compromis y sont plus clairs, ce qui justifie une évaluation séparée
  • Zeeshan Ali Khan a pointé l’agressivité du camp anti-LLM, et Bart Piotrowski a répondu que la polarisation est forte aussi bien du côté pro-LLM que du côté anti-LLM, ajoutant que les « vibecoders » se posent eux aussi en victimes dès qu’on les critique

1 commentaires

 
GN⁺ 5 시간 전
Avis sur Lobste.rs
  • Le fait de dire que « les applications contenant du code, de la documentation ou d’autres contenus générés ou assistés par l’IA ne sont pas autorisées » paraît assez radical.
    Flathub est un endroit extrêmement populaire où les utilisateurs de bureaux Linux récupèrent leurs applications, il se présente comme un « app store pour Linux » et propose plus de 1 000 applications.
    Est-ce que cela signifie vraiment qu’aucune de ces applications ne doit utiliser de code assisté par IA ? Est-ce réaliste ? N’est-il pas déjà trop tard ?

    • La formule « des exceptions peuvent être accordées aux projets matures et bien maintenus » donne plutôt l’impression que l’objectif est d’empêcher qu’on publie un projet entièrement fait en vibe coding puis abandonné
    • Il n’est jamais trop tard.
      Même les projets déjà présents sur Flathub peuvent être retirés s’il s’avère qu’ils ont été faits en vibe coding, et cela permet aussi d’envoyer un message clair
    • Cette règle semble devoir être appliquée avec une certaine discrétion.
      Certaines applications importantes déjà existantes seront probablement reconnues comme des exceptions et, même dans ce cas, la restriction s’appliquera sans doute davantage au packaging flatpak indépendant qu’au code de l’application elle-même
  • Cette approche très ferme ne sera sans doute pas applicable à 100 %, mais dans une situation où les entreprises poussent de force l’adoption des LLM, une position aussi forte semble être le minimum de résistance que la communauté puisse opposer

  • Quand on pense aux récents incidents liés à la supply chain, cela paraît être une décision assez justifiée

  • Qu’un projet interdise les LLM, les personnes aux cheveux blancs ou celles qui mesurent exactement 160 cm, je soutiens à 100 % sa liberté de fixer ses propres règles.
    Je ne dis pas qu’il faudrait limiter cette liberté, mais la gestion de paquets est un travail typiquement répétitif qui peut énormément bénéficier de l’aide des LLM.
    Je peux comprendre dans une certaine mesure ceux qui considèrent leur code comme le produit des beaux-arts ou de l’artisanat, mais pourquoi empêcher l’automatisation des tâches les plus ennuyeuses ?

    Je me souviens qu’au début de l’AUR d’Arch Linux, certaines personnes maintenaient avec succès des centaines de paquets.
    Tout était toujours à jour et ne cassait presque jamais, donc elles automatisaient évidemment les mises à jour.
    Faire la même chose aujourd’hui avec une assistance LLM pourrait presque certainement rendre le tout encore plus robuste

    Peut-être qu’il faudrait interdire les humains pendant qu’on y est.
    À part les attaques de supply chain, qu’est-ce que les humains apportent au juste ? Il faudra bien que je crée un LLM distro un jour pour prouver si j’ai raison ou tort.
    Mais avant ça, il faut déjà que je termine ce langage de programmation, haha