Christophe a écrit 668 commentaires

Rappelons ici le lien direct vers la pétition: https://petitions.assemblee-nationale.fr/initiatives/i-3014

C'est la suite du fork qui a été décrit dans ce journal: https://linuxfr.org/users/ploum/journaux/fork-d-organic-map-et-applis-de-navigation

Apparemment ils ont réussi à fédérer une communauté, le fork semble très actif. Bonne continuation !

Ça a l'air sympa !

Mais je suis un peu déçu qu'il y ait besoin de créer des fichiers temporaires juste pour ça. Du coup il faut faire très attention à la façon dont le shell se termine, sinon on risque de laisser des traces derrières. N'y a-t-il pas moyen de s'en passer ?

bah quand même, on n'est pas sur le même niveau de séparation…

systemd:
- les libs de base
- resolvconf (pourquoi en faire un cas particulier ? je l'ignore)
- quasi tout le reste de systemd
- les tests
- ukify, dont j'ignorais l'existence même dans systemd jusqu'à aujourd'hui

vlc:
- les libs de base
- la partie CLI
- les GUIs, une par paquet
- chaque plugin a sont petit paquet
- des groupes de plugins sont aussi proposés pour simplifier

Il n'y a pas photo: dans un cas on installe quasiment tout chez tout le monde, dans l'autre on peut piocher selon les besoins.

NB: je viens de découvrir que Debian fait une séparation assez sympa des paquets systemd:
- une base commune pour la gestion des services,timers,sockets,etc
- gestion du boot (UEFI)
- gestion des containers
- gestion des HOME "portables" (systemd-homed)
- repartitionnement (systemd-repart)
- DNS resolver
- userdb
- NTP
- gestion du chiffrement
Voilà, là on a un effort de séparation, on pioche dans ce qu'on a besoin. J'aimerais que Archlinux s'en inspire !

Un problème de systemd dans l'embarqué, c'est que sur du très vieux matos où on n'a qu'un très vieux Linux, on ne peut pas utiliser de systemd récent, ou du moins ça peut devenir assez compliqué.

Sur cette question là, en effet, l'article botte en touche avec un "chez moi ça marche, donc c'est super".

C'est quand même fou que le packaging de systemd soit aussi monolithique, alors que pour des projets comme vlc ou qemu—du moins sur Archlinux—on trouve des dizaines de paquets…

En lisant l'article, bien des points restent dans le flou. Déjà une exigeance de départ est l'utilisation d'Oracle: on sait donc qu'on continuera à dépendre de cette belle entreprise, donc la souveraineté s'arrête dès le cahier des charges.

Ensuite, il ne s'agit que d'un duplicata de la base principale; son rôle n'est pas bien clair, mais j'ai la vague impression que son but serait d'anonymiser les données et de les refiler à des outils de big data comme l'IA…

Et puis il se pourrait bien que le résultat de ce grand chantier soit de choisir "Bleu", et donc… Microsoft.

Bref, je ne suis pas très optimiste quant à ce projet, qui ressemble à un écran de fumée.

J'avoue, pour Nextcloud, je n'ai jamais vraiment essayé la synchro fichier, j'ai donc parlé un peu vite.

Apparemment ils vont essayer de changer un peu de formule pour la maintenance.

Si je lis entre les lignes, ils vont partiellement déléguer la maintenance à la communauté… Cela reste assez flou, je ne vois pas bien comment cela va marcher.

En fait pour Pass, c'est un fork Bitwarden derrière. Le plugin Bitwarden officiel marche d'ailleurs très bien avec Pass.
L'intégration dans Cozy n'apporte pas grand chose en soi, à part le portail cozy unique.

Pour Drive, je suis aussi chez pCloud, et ils font ça bien. Infomaniak propose aussi l'équivalent avec kDrive & co.

Ensuite si on veut un truc hébergé strictement en France, oui, le choix est plus limité. Il faut regarder du côté des CHATONS, trouver un bon Nextcloud, configurer de la synchro WebDAV, etc… C'est plus compliqué. Mais pas impossible.

Alors que les connecteurs, là, c'est le désert complet. Ils sont quasi seuls sur le créneau. La valeur ajoutée est très intéressante, mais derrière il y a un sacré boulot de maintenance à faire…

J'espère que Linagora a bien compris que le principal intérêt de Cozy Cloud, c'est son système de connecteurs, qui permet de synchroniser en local les documents administratifs venant de plein d'entreprises différentes, y compris les banques.

Si seul les parties "Drive" et "Pass" de Cozy Cloud sont récupérées, ça n'a que peu d'intérêt de rester chez eux, il y a aussi bien ailleurs.

Pour moi la « moins pire » reste la biométrie digitale.

Recopier une empreinte est plus compliqué, car la reconnaissance est plus précise. Une empreinte bouge peu, contrairement à un visage (mouvements, lunettes, ombres, etc), ce qui permet d'avoir des capteurs plus exigeants.

Aussi, s'autentifier avec une empreinte est un acte volontaire (on met le doigt à un endroit précis). Pour le visage, on est juste devant la machine, c'est bien plus passif.

De toutes façons la pertinence de la biométrie se fait au cas par cas. Par exemple sur un gestionnaire de mots de passe sur smartphone: vaut-il mieux:

1. s'en passer et donc entrer le mot de passe maître bien plus souvent
2. s'en passer et laisser le coffre déverrouillé la plupart du temps
3. l'utiliser pour verrouiller/déverrouiller le coffre à chaque usage

Je pense que l'option 3 est la meilleure. En gros, je l'utilise pour des déverrouillages fréquents du quotidien, couplé à un mot de passe pour le déverrouillage « initial ».

Je n'ai jamais compris l'engouement pour cette méthode là. Elle est facile à tromper (une bonne photo du visage), la donnée biométrique (l'image du visage) est facile à récupérer, et bien sûr on ne peut pas changer de visage.

Bref, c'est un projet amusant et intéressant, qui montre la souplesse de PAM, mais ça s'arrête là.

Sinon c'est le Conseil de l'IA et des Moomins, par exemple.

Oui, mais l'Indre sera-t-elle encore là pour refroidir ledit DC ?

D'habitude les gens se moquent de Google pour ça mais Mozilla est encore pire.

Oh, non, les projets abandonnés par Google se comptent en centaines, pas en dizaines. Il ne font absolument pas mieux que Mozilla, et je ne leur fais absolument pas confiance pour garder un projet sur la durée. Surtout que Google, avec son navigateur en position très dominante, est capable de fortement favoriser/saboter les technos de demain (hello JPEG-XL !).

Euh ça fait un bon moment que la confiance en Mozilla est abîmée.

Entre les projets sans avenir, ceux basés sur la mode en cours, les sujets importants mais sous-financés, la direction sur-financée, il faut vraiment se rappeler régulièrement que Google est pire encore pour rester avec Firefox.

Tu coupes l'accès à AWS et Google Cloud pour l'Europe: tu as 90% du web par terre, sans compter tout ce qui se base dessus. Mitigation: pas grand chose.

En fait, une partie du problème est là: Wayland est juste un protocole. Les besoins sont divers, les implémentations aussi.

A l'autre bout, une application comme KiCad ne peut que constater la lenteur d'évolution, et la fragmentation des implémentations.

Oui, lentement… trèès lentement…

D'ailleurs, je remarque qu'ils ont implémenté "xx_session_management_v1", et non "xdg_session_v1", car ce dernier n'est même pas encore fusionné dans Wayland, malgré 5 ans (!) de discussions autour de ce petit morceau de protocole.

Oui, ça tombe bien, c'est à peu près comme ça que ça marche aujourd'hui avec les popups (menu contextuel par exemple). Sur desktop, ça s'affiche sur le lieu du clic, comme demandé par l'appli. Et sur mobile, le compositeur va l'afficher au centre de l'écran, ignorant la demande de l'appli.

L'application peut très bien demander à ce qu'une de ses fenêtres soit traitée d'une façon particulière. Ensuite le mot final revient au gestionnaire de fenêtres, oui.

C'est déjà le cas pour les popups, et pour toutes les actions de fenêtrage lorsqu'on utilise un "Client Side Decoration" (coucou les apps GTK !). Par exemple il y a une extension spécifique KDE pour ça, et probablement un équivalent chez les autres compositeurs.

En fait pour couper court à la critique, il suffirait de faire des paquets séparés pour les différentes thématiques du projet systemd: boot, init, session, container… Ici, Gnome utilise plus de modules liés à la gestion d'une session, ce qu'on peut comprendre. Ce qui est déjà plus frustrant, c'est que ça implique d'utiliser tout le reste de systemd.

Et il a répondu à cela:

• Il fait une première grosse étape de nettoyage/refactoring pour préparer le terrain pour de nouvelles fonctionnalités. Donc, oui, il y a du boulot, et ça n'apporte rien de concret et ça comporte des risques de régression.
• Il fait tourner les tests sur sa branche comportant tous ses changements en cours, pas seulement ceux de la MR. Là il y a clairement un problème de méthodo. Mais il est également réactif lorsqu'on lui signale un problème, et me semble bien moins agressif dans ses réponses que les autres "devs" de xorg.

Au final des quelques échanges que j'ai lu, j'ai l'impression que tout est fait pour que xorg soit abandonné:

• pas de nouvelle version, donc la branche "main" devient critique, mais il n'y a aucun autre process pour intégrer des changement un peu ambitieux
• tout cleanup est finalement vu comme une perte de temps car ça n'apporte rien [aux devs historiques démotivés]
• la moindre erreur et c'est le pilori

Je remarque que le dernier commentaire du deuxième lien se termine (venant d'un dev xorg) par

So it would be reasonable to retract the accusation :-)

Bien sûr, rien de tel n'a été fait. Je trouve cet environnement de dev assez toxique en fait, et il a bien fait de plier bagages.

Je ne suis pas convaincu pour l'instant. Sur le plan technique, sur les deux liens fournis:

• sur le premier lien, on lui reproche grosso-modo de casser l'ABI du code présent dans la branch main, parce que des gens utilisent directement cette branche, faute de nouvelle version de Xorg depuis 3 ans. Alors si on ne peut pas modifier l'ABI dans cette branche, on le fait où ?
• sur le deuxième lien, la première réponse à ce commentaire est, je cite:

This is a totally unfounded accusation. I say this as the user who reported the bug.

J'ai l'impression que ça défrise un peu les dinosaures que quelqu'un cherche activement à faire bouger la bête…
Ensuite s'il arrive à faire avancer son fork, tant mieux, mais je pense que maintenant c'est un peu tard et tout le monde a tourné la page, de gré ou de force, donc il aura du mal à fédérer autour de son projet. Et puis ses opinions complotistes ne donnent pas trop envie de s'attacher au personnage.