Christophe a écrit 624 commentaires

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.

En théorie oui bien sûr

Non, c'est vrai en pratique aussi, et c'est très concret:

Un DNS qui ne filtre rien du tout mais refile ses logs à tous les partenaires commerciaux ne fait pas de censure tout en s'asseyant sur ta vie privée.

Inversement, pour un DNS qui filtre ce qui l'arrange mais ne diffuse aucune info sur les requêtes DNS, ta vie privée est bien protégée mais il y a une jolie censure.

Non pas au sens technique mais au sens philosophique

Alors finalement, ce serait deux choses liées en théorie aussi ?… C'est assez contradictoire tout ça.

Si tu cherche la vie privée, forcément, tu cherches la liberté

Certes, mais c'est une des nombreuses formes de liberté, qui est un terme très vague.

Qui dit liberté, dit non-censure.

Non, pas forcément. Déjà, ce n'est pas la même liberté que celle évoqué précédemment. Ensuite, la censure peut aussi apporter plus de liberté, si elle est adaptée (et choisie).

Ou alors, si je veux être libre je ne peux pas utiliser un bloqueur de pub ?

Le logiciel PiGallery2 est plutôt orienté album photo que blog, mais il permet aussi d'ajouter du texte, ainsi que des traces GPX, à un album donné.

Pour rajouter du texte, cela se fait en rajoutant un fichier Markdown dans le même répertoire que les photos. Dans ce fichier on peut alors insérer des marqueurs pour dire où le texte doit se trouver par rapport aux photos.

Si un fichier GPX est trouvé dans le répertoire, une trace sera ajoutée à la carte des emplacements des photos.

Donc au final, cela peut constituer une autre approche de présentation que celle présentée dans la dépêche, avec ses propre avantages et inconvénients.

Oui enfin maintenant on a tellement de boutons derrière le volant qu'il faut aller regarder les manettes avec une lampe torche pour savoir comment fonctionne la voiture de location…

Heureusement les commandes principales (clignotant, essuies-glace) sont à peu près standard.

Je suis d'accord avec la complexité du Yaml, il y a des pièges un peu partout dont on n'a pas conscience. Et puis les syntaxes où les caractères invisibles (l'indentation) changent la signification du contenu, très peu pour moi…

Donc vive le format Toml, en effet. La seule chose que je regrette un peu dans le Toml, ce sont les sous-sections: l'arboresence est très peu visible au premier coup d'oeil sur le document.

C'est bien la première fois que je vois employer "logiciel libre" pour dire "logiciel libre de droits".

Quand c'est libre de droit on dit qu'il est "libre de droit", voire "dans le domaine public", on ne dit pas "libre". Un logiciel libre, en français, tout le monde (enfin, quasiment, apparemment) comprend qu'on fait référence aux 4 libertés.
Donc, non, personne ne dira d'un Freeware qu'il est libre, car personne ne comprendrait qu'on parle du domaine public.

Pour open source, on est d'accord qu'il y a ambiguïté, et que dans l'absolu ça n'implique que l'accès au code, rien d'autre. Mais dans ce cas, en Français, on parle de "code ouvert" ou autre nommage, mais pas de "libre", car il n'y a pas ambiguïté sur ce mot en français.

Oui, ActivityPub me semble être une bonne voie à explorer pour résoudre ce problème, heureux de voir que des gens se penchent déjà sur le problème :)

En fait ce qui est gênant avec les multiples forges, c'est le manque d'interopérabilité. Aujourd'hui, si je veux faire 3 petits patchs sur 3 projets hébergés par Github, Gitlab et Sourcehut, je dois me créer un compte par forge juste pour leur proposer chaque patch ou même ouvrir un ticket.

J'aimerais bien avoir la possibilité d'avoir mon fork sur la forge de mon choix, et envoyer mes changements upstream inter-forge.
Git propose l'envoi par email, mais franchement pour collaborer sur un patch c'est très peu ergonomique.

Il manque donc un protocole de collaboration inter-forges pour que la décentralisation devienne une réalité. Mais même pour une même forge, je ne crois pas qu'on puisse collaborer entre les différentes instances… Ce serait déjà un bon début !

Ça ressemble à une "victoire" pour Trump: il coupe les fonds, les gens prennent sur leur temps libre pour continuer le projet, l'impact négatif est minimisé…

Bien sûr, mais souvent, cette personne, c'est soi-même…

Vous me direz que je sors du sujet, puisque les télécommandes ont (encore) une floppée de boutons. …

Je te demanderais surtout pourquoi acheter une télé au lieu d'un simple moniteur, en fait. C'est ce que j'ai à la maison (puisqu'elle est branchée à la box, la fonction TV ne sert à rien), et ça marche bien comme ça.
Comme un moniteur n'a pas de télécommande, il y a toujours des boutons dispos sur l'écran.

Sur mon Fairphone, il y a un bouton physique de marche / arrêt qui sert également à ouvrir le mode photo et allumer la torche.

Du coup, ça éteint le téléphone après avoir pris une photo de l'intérieur de ta poche bien éclairée ?

--> []

En auto-hébergement, l'historique se retrouve dans l'historique des sauvegardes de la base de données de Vaultwarden, donc ça permet de se sortir d'une situation critique. Bien sûr je fais l'hypothèse qu'un tel historique existe :)

Cependant c'est loin d'être idéal: il faut basculer toute la base de données, récupérer le secret perdu, et rebasculer sur la dernière version pour avoir les dernières modifs…

Il existe plusieurs apps qui bloquent les préfixes officiels de télémarchage. Parfois, l'appli de base "Contact" permet de faire l'équivalent sans rien installer du tout, c'est encore mieux.

Sur FreeMobile, on peut aussi bloquer ces préfixes depuis l'interface d'administration, peu importe le modèle du téléphone.

Le lien auquel tu penses est peut-être https://linuxfr.org/users/julien_jorge/journaux/gerer-les-demarcheurs-telephoniques ? C'est exactement comme pour iOS: on installe une appli, elle bloque les préfixes, point.

Bon, ils se sont rendus compte de leur erreur car, un peu après, un bouton "remplir" a fait son apparition. Mais cela reste nettement moins pratique.

As-tu remarqué qu'il existe une option, un peu cachée, pour revenir partiellement au comportement d'avant ?
Paramètres > Saisie automatique > Click items to autofill

Je suis d'accord que globalement, la nouvelle version de l'UI de l'extension est une régression ergonomique.

Non, le souci, c'est juste que le programme est de mauvaise qualité. Il y a un warning très clair, dès la première ligne:

PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '4.0') before import to ensure that the right version gets loaded.

Donc le programme utilise Gtk, mais ne précise pas quelle version… La version la plus récente du système est chargée: pas de bol, ici ce n'est pas la bonne.

Comment ça, "tous les commits" ? Ils peuvent très bien pousser un énorme commit, avec comme message un laconique "nouvelle version Android". Aucun historique, rien, et bonne chance pour le rebase de LineageOS.

À mon avis ça ne les intéresse plus du tout d'avoir des contributions externes. Le projet est mûr, on ne voit plus de grandes avancées au fil des versions.

Donc pour eux c'est le bon moment pour verrouiller complètement les choix techniques et stratégiques dans Android.

Pas sûr, d'ailleurs, qu'un projet comme LineageOS survive à ce changement. Intégrer des énormes dump de code, c'est un travail titanesque, presque infaisable à l'échelle de l'OS Android.

Personnellement j'utilise un gestionnaire de mots de passe. Ainsi je peux utiliser un truc long, sans me soucier de le retenir. Si l'app associée est bien faite, remplir le champ de saisie devient quasi automatique.

Je crois que tu t'emballes un peu, de ce que je comprends c'est seulement celui qui va fournir le document qui devra inclure le QR code. Ca ne changera rien pour le patient.

L'app pour la carte de sécu, une perte de temps à mon avis (je ne vois pas le soucis avec la carte à puce, qui est très pratique), ne sera jamais obligatoire. Espérons…