Pour moi, c'est trop compliqué à gérer si tu veux vraiment un exemple d'utilisateur qui fuit les mailing listes.
Déjà, il n'y a pas 1 liste de mail, mais 1 par projet. Donc si tu veux suivre un projet comme GNOME tu dois t'inscrire à celles de glib, gtk, libsoup, webkit2gtk, nautilus, evolution, gnome-design, gnome-shell…
Et là tu recois par défaut tout dans ta boîte de réception en quelques jours c'est le bordel.
C'est invivable pour moi, j'ai besoin d'organisation. Avec Discourse, c'est déjà organisé via les catégories et les tags.
Il faut configurer ton client mail pour faire des redirections automatique dans des dossiers séparés, ok je l'ai eu fait. Ça se passe bien en général.
Ah pas de chance, si tu as plusieurs périphérique, tu peux déjà recommencer ta configuration pour faire tes redirections côtés serveur avec IMAP et Sieve, je l'ai eu fait aussi sur mon propre serveur de mail.
Je serais surpris que Gmail, Yahoo, Outlook et autres services gratuits proposent la configuration des règles Sieve.
Voilà, il n'y a déjà plus personne qui suit techniquement et je n'ai même pas commencé à envoyer un mail.
En plus, comme dit par Emmanuele, l'envoi de mail via la mailing list a un taux très élevé de probabilité de passer en SPAM, car le serveur est une sorte de service de relais très mal vu par les algorithmes de détection de spam.
Je me suis inscrit sur le Discourse de GNOME, il y a quelques mois. Résultat: depuis 1 interface j'ai accès à l'entier des discussions autour de GNOME sans avoir à faire la moindre configuration et c'est organisé par catégories et tags.
Je vois passer des conversations intéressantes sur des sujets auxquels je n'aurai pas pensé à m'inscrire.
J'ai accès à l'historique complet via juste 1 champ de recherche.
Avec les mailing list, c'est impossible de chercher car pour chaque mailing list tu dois trouver le bon lien vers l'archive (elles ne sont pas toutes indexées par les moteurs de recherche) et la recherche est moisie, car par défaut, tu navigues, par année puis par mois puis par jour et enfin par thread. Bien sûr, les threads s'étalent sur plusieurs jours/mois, c'est compliqué de s'y retrouver.
Et encore, je suis informaticien, tous ces désagréments de configuration ne m'ont pas fais peur au début, mais je suis sûr que ce n'est pas le cas pour tous les utilisateurs.
On ne parle ici pas uniquement de discussions techniques entre développeurs (elles sont plutôt sur Gitlab), mais de discussions plus simples entre membres de la communauté de tous niveaux.
Pour être vraiment inclusif, je pense que les applications webs genre forum et Discourse sont clairement bien plus facile à utiliser pour les nouveaux venus par défaut.
C'est vraiment structurel, parce que ces systèmes sont centralisés, ce qui facilite l'implémentation d'outils vraiment utiles comme la recherche globale.
Apparemment, ça devenait ingérable entre: le manque d'outils de modération, le fait qu'un grand serveur de mailing list agisse comme un serveur de spams et que la barrière technique pour les nouveaux utilisateurs était trop élevée.
Ces explications et l'historique de la migration viennent de cette réponse détaillée d'Emmanuele Bassi.
Ensuite il faut bien se rendre compte qu'il y a une industrie énorme autour de ces logiciels métier, que ce soit dans l'image, le son, ou d'autres. Et c'est eux qui pour l'instant sont coincés dans X11, avec effectivement presque plus de développement parce que les dévs ont changé et tout le monde dit "Wayland est presque prêt" (sauf qu'il l'est pas pour ceux là, ces gens de ces industries).
Si l'industrie est si énorme et souhaite vraiment utiliser les distributions Linux, je ne comprend pas pourquoi elle reste uniquement concentrée sur X11 et attende que, magiquement, les communautés Wayland, FreeDesktop, Flatpak… comprennent leurs besoins et développent de nouvelles APIs prête à être utilisées par l'industrie ?
La production spontanée de code, je n'en ai pas encore vu, quoique peut être que Github Copilot peut aider ;)
Blague à part, c'est pas comme si Wayland était un nouveau projet très récent, ça fait quand même longtemps que l'on sait que c'est l'avenir, puisque les mainteneurs même de Xorg ont démarré le développement de cette nouvelle pile graphique.
Pour éviter les bugs pour chaque implémentation faite par les différents desktop, la communauté FreeDesktop est justement là pour établir des APIs standards à utiliser comme référence. Quand les implémentations des desktops ne le suivent pas, un rapport de bug en pointant vers le standard devrait aider.
Mais, de nouveau, il ne faut pas attendre que FreeDesktop comprenne les besoins s'ils ne sont pas exprimés et il faudra sûrement que les nouvelles APIs (ou leur brouillons) soit d'abord apportés par les personnes concernées (donc, l'industrie énorme autour de l'image, du son et autre).
Après, je comprends très bien qu'en tant que mainteneur bénévole de GIMP tu ne puisses pas faire plus que quelques semaines par années d'essai de Wayland, ne t'en fait pas :) C'est juste que le reste des acteurs, mêmes de logiciels privateurs, peuvent faire un pas vers les communautés…
Pour la question "pourquoi plus de sécurité si c'est pour utiliser le code des mêmes développeurs ?", c'est simplement que de plus en plus de logiciels privateurs sont distribués pour Linux (VSCode, Edge, Skype, Teams de Microsoft ou encore Spotify, Zoom et bien d'autres) et que l'utilisateur n'a aucun moyen de vérifier si tout se passe bien pour lui et sa vie privée.
Donc, les sécurités proposées par Flatpak, Wayland et consorts deviennent de plus en plus primordiales pour assurer la vie privée des utilisateurs tout en leur permettant d'utiliser leurs logiciels nécessaires (qui peuvent aussi provenir de l'industrie du son et du graphisme).
Qq1 trouve t-il ce bouton utile ? (vraie question)
Je n'avais même pas compris que c'était un bouton… et je ne savais pas que l'on pouvait mettre des boutons là haut.
J'ai souvent un onglet épinglé (genre une radio ou spotify…) et du coup j'ai cru qu'au dernier démarrage qu'un de mes vieux onglets épinglés c'était ouvert sur cette page à cause de la mise à jour.
À première vue, je ne comprends pas bien la différence entre les "onglets récemment fermés" et l'historique. Je n'ai que rarement besoin de naviguer dans l'historique, c'est assez rare que je me souvienne que j'ai visité un site récemment.
En plus la barre d'adresse est très pratique pour chercher dans l'historique grâce aux titres des pages.
En fait, j'ai l'impression que c'est la même fonctionnalité que sur la page d'accueil de Firefox pour Android. Seulement, sur Android c'est utile, parce que le navigateur peut se faire tuer par Android ou parce que le téléphone peut redémarrer facilement (bug ou batterie vide). Sur PC, en général, je maîtrise quand je ferme mon navigateur et si j'ai besoin de retrouver mes onglets après, j'ai l'option de sauver ma session à la fermeture.
Donc, ça ressemble à une tentative d'unifier Firefox et Firefox pour Android, mais je trouve ça raté, parce que les 2 plateformes n'ont pas les mêmes contraintes imposées par leur environnement (PC ou Android).
Un avantage ? Ça affiche le logo de Firefox, comme ça on ne pourra plus dire "je ne vois même pas la différence entre Chrome et Firefox" :)
Ça me plaît bien dans le principe, mais leurs pages d'exemple n'ont pas l'aire d'être de l'HTML valide : par exemple le click-to-edit qui utilise un attribut hx-ext non-autorisé sur le body.
Est-ce que htmx peut produire du contenu HTML valide ? C'est peut être juste leur site qui n'est pas valide ?
J'ai l'impression que c'est tout ce que tu as à faire.
Dans la section Pulseaudio juste à la suite du paragraphe pointé par ton lien, ils proposent de vérifier si ta session utilise bien pipewire à la place de pulseaudio:
LANG=C pactl info | grep '^Server Name'
Si tu utilises bien pipewire, tu devrais avoir une réponse comme Server Name: PulseAudio (on PipeWire 0.3.XX).
Si non, ils disent qu'il faut regarder la partie Pulseaudio pour Debian 11 dans cette même page de wiki (là-bas, il y a une commande systemctl pour désactiver le service pulseaudio).
Maintenant, tu utilises déjà pipewire à la place du pulseaudio.
Si tu veux l'utiliser aussi pour remplacer Alsa et Jack, il faut lire les sections dédiées dans le wiki. Je n'ai jamais utilisé Alsa directement, ni eu besoin de la faible latence de Jack, donc je ne l'ai pas fait.
Si tu as des périphériques sonores connectés en bluetooth avec ton ordinateur, alors tu pourrais être intéressé par la section Bluetooth. Personnellement, c'est ce qui m'intéressait pour avoir plus de choix de profiles sonores pour mon casque+micro bluetooth.
C'est pour cette dernière partie, que j'ai eu besoin d'enlever un paquet de pulseaudio. D'après la section Bluetooth, on ne peut pas avoir pulseaudio et pipewire qui gèrent en même temps les périphériques bluetooth.
Tu as tout à fait raison, le paquet pulseaudio peut rester.
En fait, j'ai dû supprimer pulseaudio-module-bluetooth pour installer la fonctionnalité correspondante de pipewire, comme indiqué sur le wiki de Debian.
C'est à cause de cette suppression que j'ai dû ensuite désinstaller gnome-core à cause de ça :)
J'ai l'impression que l'utilisateur sera mieux informé : si je me souviens bien, avant Debian 6 c'était le paquet linux-image qui contenait directement les firmware.
Pour les prochains installateurs, d'après phoronix, l'utilisateur sera informé de la liste des firmware qui seront installés et il aura des options de démarrage pour les désactiver.
En plus, les firmware seront dans une source list dédiée nommée non-free-firmware pour recevoir leurs mises à jour de sécurité.
Par contre, dans Debian Bullseye, le paquet gnome-core dépend de pulseaudio, j'ai donc dû le désinstaller ainsi que task-gnome-desktop. Ce n'est rien de grave parce que ces paquets sont juste utiles pour rassembler les dépendances pour avoir un bureau GNOME.
Pour les périphériques bluetooth, il faut bien suivre la page de wiki pour utiliser pipewire: il faut désinstaller le module bluetooth de pulseaudio pour que ça marche.
Par contre, je n'avais pas de casque bluetooth sans fil avec moi: je n'ai pas pu testé la qualité du son quand je veux utiliser le micro du casque. En théorie, wireplumber et pipewire sont les bons outils pour ça…
J'ai appris qur depuis le 14 septembre environ, wireplumber et une version assez récente de pipewire sont disponibles pour Debian 11 Bullseye grâce aux dépôts bullseye-backports.
Pour l'installation à la place de pulseaudio/jack et pour les modules bluetooth (pour avoir plus de profils sonores pour les casques bluetooth), Debian propose une page de wiki.
Merci pour la précision, j'avais en tête l'article Thunderbird's New Home et, effectivement, ils parlent bien de la MZLA Technologies Corporation et non pas d'une fondation.
Rust a bien été fondé par Mozilla, mais Thunderbird n'est plus développé par Mozilla depuis des années (10 ans peut être ?).
Si je me souviens bien, la communauté Thunderbird s'est prise en main il y a quelques années en montant leur propre fondation (avant ils étaient encore lié fiscalement et avec les outils de développement à la fondation Mozilla).
Personnellement, l'utilisation du JavaScript ne me choque pas: ils ont déjà dû remplacer toutes les définitions XUL/XML de l'interface graphique par du JavaScript pour pouvoir continuer à utiliser la plateforme Gecko.
La petite équipe de Thunderbird a donc déjà des connaissances en JavaScript et continuera d'en avoir besoin encore pendant longtemps.
Pour les add-ons, ils doivent également suivre la plateforme Gecko et donc suivre le nouveau système avec les API en JavaScript (manifest v2 et v3).
Je pense en particulier à la partie agenda qui était l'add-on Ligthning auparavant. Il y a d'ailleurs déjà une bonne partie des fonctionnalités en JavaScript pour la gestion des agendas.
La programmation asynchrone avec JavaScript est vraiment agréable et permet facilement de faire des interactions en gardant la fluidité visuelle et un code de bonne qualité. C'est vraiment efficaces pour avoir en même temps des interactions réseaux lentes et une interface graphique fluide malgré cette lenteur.
Je vois leur utilisation de la plateforme Gecko un peu comme les autres utilisent Electron, mais avec les technologies de Mozilla. C'est donc il me semble naturel de privilégier le JavaScript dans cette situation.
Regarder l'utilisation mémoire brute est une mauvaise mesure, puisque JavaScript a aussi son garbage collector et qu'il peut être plus efficace de garder les objets en mémoire plutôt que de constamment la vider.
Bien sûr, si l'environnement mémoire est restreint le Garbage Collector nettoyera plus souvent la mémoire, mais ça implique que le processeur commence a passer plus de temps à faire des choses inutiles pour l'utilisateur…
Ensuite, je cherche une solution avec très peu de maintenance. Je suis prêt à passer pas mal de temps pour la mise en place. Mais une fois que ça tourne, j'aimerais que ça tourne tout seul pendant des années sans que je ne fasse grand chose.
Malheureusement, même si l'installation se passe bien, j'ai horreur des mises à jour de Nextcloud: il faut vraiment suivre leur rythme car il ne faut pas faire de saut de version important, c'est donc chronophage :(
Oui, première réponse de mon lien (l'emphase est de moi)
Before there was ASCII, there was BCDIC. BCDIC (not EBCDIC) was a 6 bit code with 64 combinations. This was enough to represent the upper case alphabet, numbers and common punctuation. When ASCII was adopted, another bit was added to include the lower case character set, but there was not seen to be a need for an eighth bit, since there were no teleprinters that could handle a larger character set. So the eighth bit became an optional parity bit.
Readers of a certain age may remember that back when memory was expensive, video terminals and personal computers very often only supported the first 64 ASCII characters that fit into 6 bits, because that allowed you to use a 1k ROM for a character generator.
C'est facile en regardant l'histoire avec sa vue de maintenant, mais à une époque on pariait sur :
Oui, c'est facile maintenant… Et alors ? Mon point était que ce document m'a confirmé qu'aujourd'hui, il n'y a pas besoin de wchar pour moi.
Pour des utilisateurs humains, oui mais du coup on est plus vraiment sur du webservice mais plutôt de la webapp. En webservice, on va plutôt utiliser des API keys, des tokens.
OAuth2 est une norme très générique et tu peux l'employer pour faire du webservice de backend à backend :)
La norme UMA 2.0 est justement prévue pour utiliser OAuth2 pour permettre à des tiers d'accéder aux données d'un utilisateur et tout ceci de manière asynchrone (le tiers peut demander l'accès et recevoir l'autorisation de l'utilisateur bien plus tard).
Malheureusement, la norme est assez complexe puis qu'elle définit beaucoup d'acteurs: un utilisateur avec son application, un service d'autorisation et un tiers avec une autre application.
En réalité, tous les acteurs ne sont pas nécessaires dans toutes les implémentations et donc des simplifications peuvent avoir lieu dans les interactions.
Je comprend bien que la norme doit pouvoir gérer les cas les plus complexes (comme l'accès aux dossiers médicaux par des médecins tiers), mais ça je pense que ça la dessert un peu, puisqu'elle est difficile à lire.
Ce que je trouve intéressant avec UMA 2.0 + OAuth 2.0, c'est que les backends sont enregistrés comme Client de OAuth2 (en tout cas avec l'implémentation de Keycloak). Du coup, si un des backends tiers n'est plus de confiance, tu peux juste le désactiver et il n'a plus accès à aucune donnée utilisateur de ton backend.
En plus, il y a un système de "Permission Ticket" qui détermine ce que tu as besoin comme droit pour faire ton action, qui vérifie si ta demande est conforme aux politiques de sécurités actuelles et qui te donne un token d'accès pour une durée limitée. Les politiques de sécurité sont configurables et protègent les ressources et/ou les "scopes".
Pour lier ton backend avec le serveur d'autorisation, il y a la norme UMAFedAuth qui permet de faire vérifier concrètement que les permissions ticket sont valides.
J'ai eu l'occasion de configurer un Keycloak avec tout ça. Grâce à UMA, j'ai évité de ré-inventer un système d'API token et j'ai eu pas mal d'avantages en plus:
Un API token est comme un mot de passe avec une durée illimitée de validité. Je préfère les token d'UMA qui sont limités dans le temps.
Un API token est généré par les utilisateurs. Avec UMA 2.0, si l'utilisateur interagit avec le service d'autorisation, alors il a juste à configurer les accès qu'il donne sans avoir besoin de créer de "mot de passe à copier dans la configuration de l'autre application". Le service d'autorisation se charge lui-même de faire le lien entre les applications tierces et le backend à protéger.
Un API token a une configuration fixe des droits associés. Avec les Permissions Ticket et les Policy, je peux ajuster les droits nécessaires ou les politiques de sécurités avec un peu plus de souplesse: je n'ai pas besoin de refaire générer des tokens à tous les tiers. Je n'ai pas essayé, mais l'utilisateur lui-même doit pouvoir ajuster ses politiques de sécurités.
Un même tiers aura X API tocken et si je veux interdire ce tiers, alors je dois retrouver tous ses API tocken. Avec les systèmes que j'ai vu (chez Github et Gitlab par exemple), il n'y a aucun moyen de désactiver un tiers. Avec Keycloak, j'ai juste à désactiver son Client OAuth.
J'y ai réfléchis à nouveau et effectivement, on va avoir un problème si on veut pouvoir être protégé du visual spoofing du login: pour pouvoir appliqué facilement la contrainte d'unicité, il faudrait pouvoir normaliser (avec l'algorithme NKFC) les logins.
Mais si on fait ça, alors on change les identifiants de connexion des utilisateurs !
Pour être transparent pour l'utilisateur, Ruby devra normaliser l'identifiant entré avant de le comparer à la base de donnée (mysql ne connaît pas unicode normalize() alors que postgres 13).
Le plus sage serait je pense de passer par une étape intermédiaire:
on ajoute une nouvelle colone "normalized_login" et on y stock les logins normalizés
dans le contrôleur de Ruby on a joute un validateur qui contrôle l'unicité sur cette colonne à la création du compte
les comptes existants en conflits devront être traités à la main: si on a un email, on peut les contacter pour leur donner un nouveau login; si non, je ne sais pas ce que l'on peut faire.
Si on n'arrive pas à nettoyer les comptes existants, on devra rester comme ça et trouver un autre moyen de contourner le visual spoofing.
On a bien un identifiant unique sur la table accounts (ou users), mais ça commence à être difficile à identifier.
Au final, peut être que le plus simple est de directement afficher le numéro de account à la place du login et de ne pas essayer de normaliser les logins.
Il faut aussi que j'essaie de voir ce que donne le slug du user (généré à partir du login) quand on essaie de l'attaquer par visual spoofing.
Si jamais, vous voulez tester, utilisez plutôt le site https://alpha.linuxfr.org au lieu de la production svp ;)
Je suis en train d'essayer d'afficher le login après le nom, puisque lui est unique.
C'est l'occasion de trouver un moyen également pour améliorer la lisibilité de la ligne "Posté par xxx, Édité par yy, zzz, aaa, Modéré par vvvv", parce que ça va vraiment être très long comme texte si on affiche les logins de tout le monde !
Je fais des essais avec la balise HTML <details> que je laisserai par défaut fermé sur la liste des articles et ouvert sur l'article lui même.
Aïe, je viens de voir qu'il n'y a même pas besoin de faire de "visual spoofing" sur le nom affiché, puisqu'il n'y a même pas de contrainte d'unicité: vous pouvez tous mettre la valeur Adrien Dorsaz si ça vous chante :(
C'est une "fonctionnalité" déjà employée: j'ai déjà vu des utilisateurs réutiliser le même nom affiché quand ils créent un nouveau compte plusieurs mois / années après avoir supprimé leur ancien compte.
[^] # Re: Unity ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message environnement de bureau menubar?. Évalué à 3. Dernière modification le 24 octobre 2022 à 19:56.
Ah voilà, UBports a renommé son bureau Lomiri et est stable pour smartphone, mais vraiment expérimental pour Desktop:
# Unity ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message environnement de bureau menubar?. Évalué à 3. Dernière modification le 24 octobre 2022 à 19:48.
Il me semble qu'Unity faisait ça chez Ubuntu avant qu'ils utilisent à nouveau GNOME.
Il y a une variante officielle d'Ubuntu qui est justement ressortie cette année avec ce bureau : Ubuntu Unity.
Ils disent qu'ils fournissent Unity 7.
Sache qu'il existe aussi Unity 8 qui n'a jamais était livrés par Ubuntu, mais dont le développement a été repris par la communauté UBports.
Ils visent plutôt les smartphones, mais il me semble qu'Unity 8 était aussi disponible de manière expérimentale pour Desktop.
[^] # Re: Discourse :(
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal La communauté GNOME remplace ses mailing lists par Discourse. Évalué à 6.
Votre gouvernement utilise des mailing lists accessibles à tout le monde ?
Désolé, j'ai clairement un biais avec le mien qui ne propose pas ca.
[^] # Re: Discourse :(
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal La communauté GNOME remplace ses mailing lists par Discourse. Évalué à 10. Dernière modification le 23 octobre 2022 à 13:37.
Pour moi, c'est trop compliqué à gérer si tu veux vraiment un exemple d'utilisateur qui fuit les mailing listes.
Déjà, il n'y a pas 1 liste de mail, mais 1 par projet. Donc si tu veux suivre un projet comme GNOME tu dois t'inscrire à celles de glib, gtk, libsoup, webkit2gtk, nautilus, evolution, gnome-design, gnome-shell…
Et là tu recois par défaut tout dans ta boîte de réception en quelques jours c'est le bordel.
C'est invivable pour moi, j'ai besoin d'organisation. Avec Discourse, c'est déjà organisé via les catégories et les tags.
Il faut configurer ton client mail pour faire des redirections automatique dans des dossiers séparés, ok je l'ai eu fait. Ça se passe bien en général.
Ah pas de chance, si tu as plusieurs périphérique, tu peux déjà recommencer ta configuration pour faire tes redirections côtés serveur avec IMAP et Sieve, je l'ai eu fait aussi sur mon propre serveur de mail.
Je serais surpris que Gmail, Yahoo, Outlook et autres services gratuits proposent la configuration des règles Sieve.
Voilà, il n'y a déjà plus personne qui suit techniquement et je n'ai même pas commencé à envoyer un mail.
En plus, comme dit par Emmanuele, l'envoi de mail via la mailing list a un taux très élevé de probabilité de passer en SPAM, car le serveur est une sorte de service de relais très mal vu par les algorithmes de détection de spam.
Je me suis inscrit sur le Discourse de GNOME, il y a quelques mois. Résultat: depuis 1 interface j'ai accès à l'entier des discussions autour de GNOME sans avoir à faire la moindre configuration et c'est organisé par catégories et tags.
Je vois passer des conversations intéressantes sur des sujets auxquels je n'aurai pas pensé à m'inscrire.
J'ai accès à l'historique complet via juste 1 champ de recherche.
Avec les mailing list, c'est impossible de chercher car pour chaque mailing list tu dois trouver le bon lien vers l'archive (elles ne sont pas toutes indexées par les moteurs de recherche) et la recherche est moisie, car par défaut, tu navigues, par année puis par mois puis par jour et enfin par thread. Bien sûr, les threads s'étalent sur plusieurs jours/mois, c'est compliqué de s'y retrouver.
Et encore, je suis informaticien, tous ces désagréments de configuration ne m'ont pas fais peur au début, mais je suis sûr que ce n'est pas le cas pour tous les utilisateurs.
On ne parle ici pas uniquement de discussions techniques entre développeurs (elles sont plutôt sur Gitlab), mais de discussions plus simples entre membres de la communauté de tous niveaux.
Pour être vraiment inclusif, je pense que les applications webs genre forum et Discourse sont clairement bien plus facile à utiliser pour les nouveaux venus par défaut.
C'est vraiment structurel, parce que ces systèmes sont centralisés, ce qui facilite l'implémentation d'outils vraiment utiles comme la recherche globale.
[^] # Re: Discourse :(
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal La communauté GNOME remplace ses mailing lists par Discourse. Évalué à 5.
Apparemment, ça devenait ingérable entre: le manque d'outils de modération, le fait qu'un grand serveur de mailing list agisse comme un serveur de spams et que la barrière technique pour les nouveaux utilisateurs était trop élevée.
Ces explications et l'historique de la migration viennent de cette réponse détaillée d'Emmanuele Bassi.
[^] # Re: Discourse ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal La communauté GNOME remplace ses mailing lists par Discourse. Évalué à 9.
Ah ben oui, il me semblait que j'avais oublié un truc dans ce journal 😅
Discourse, c'est un forum en ligne sur le web.
Ce n'est pas vraiment révolutionnaire, mais c'est, je trouve, plus facile d'accès qu'une mailing list pour la consultation et la recherche.
L'adresse de celui de GNOME: https://discourse.gnome.org/
[^] # Re: Avis d'un dév GIMP (moi), pas forcément déçu mais un peu blasé peut-être
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien "Wayland ne sauvera pas le bureau Linux", par un dev Wayland déçu. Évalué à 2. Dernière modification le 22 octobre 2022 à 14:03.
Si l'industrie est si énorme et souhaite vraiment utiliser les distributions Linux, je ne comprend pas pourquoi elle reste uniquement concentrée sur X11 et attende que, magiquement, les communautés Wayland, FreeDesktop, Flatpak… comprennent leurs besoins et développent de nouvelles APIs prête à être utilisées par l'industrie ?
La production spontanée de code, je n'en ai pas encore vu, quoique peut être que Github Copilot peut aider ;)
Blague à part, c'est pas comme si Wayland était un nouveau projet très récent, ça fait quand même longtemps que l'on sait que c'est l'avenir, puisque les mainteneurs même de Xorg ont démarré le développement de cette nouvelle pile graphique.
Pour éviter les bugs pour chaque implémentation faite par les différents desktop, la communauté FreeDesktop est justement là pour établir des APIs standards à utiliser comme référence. Quand les implémentations des desktops ne le suivent pas, un rapport de bug en pointant vers le standard devrait aider.
Mais, de nouveau, il ne faut pas attendre que FreeDesktop comprenne les besoins s'ils ne sont pas exprimés et il faudra sûrement que les nouvelles APIs (ou leur brouillons) soit d'abord apportés par les personnes concernées (donc, l'industrie énorme autour de l'image, du son et autre).
Après, je comprends très bien qu'en tant que mainteneur bénévole de GIMP tu ne puisses pas faire plus que quelques semaines par années d'essai de Wayland, ne t'en fait pas :) C'est juste que le reste des acteurs, mêmes de logiciels privateurs, peuvent faire un pas vers les communautés…
Pour la question "pourquoi plus de sécurité si c'est pour utiliser le code des mêmes développeurs ?", c'est simplement que de plus en plus de logiciels privateurs sont distribués pour Linux (VSCode, Edge, Skype, Teams de Microsoft ou encore Spotify, Zoom et bien d'autres) et que l'utilisateur n'a aucun moyen de vérifier si tout se passe bien pour lui et sa vie privée.
Donc, les sécurités proposées par Flatpak, Wayland et consorts deviennent de plus en plus primordiales pour assurer la vie privée des utilisateurs tout en leur permettant d'utiliser leurs logiciels nécessaires (qui peuvent aussi provenir de l'industrie du son et du graphisme).
[^] # Re: Plus
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Que pensez-vous du nouveau bouton dans Firefox 106 ?. Évalué à 5.
Je n'avais même pas compris que c'était un bouton… et je ne savais pas que l'on pouvait mettre des boutons là haut.
J'ai souvent un onglet épinglé (genre une radio ou spotify…) et du coup j'ai cru qu'au dernier démarrage qu'un de mes vieux onglets épinglés c'était ouvert sur cette page à cause de la mise à jour.
À première vue, je ne comprends pas bien la différence entre les "onglets récemment fermés" et l'historique. Je n'ai que rarement besoin de naviguer dans l'historique, c'est assez rare que je me souvienne que j'ai visité un site récemment.
En plus la barre d'adresse est très pratique pour chercher dans l'historique grâce aux titres des pages.
En fait, j'ai l'impression que c'est la même fonctionnalité que sur la page d'accueil de Firefox pour Android. Seulement, sur Android c'est utile, parce que le navigateur peut se faire tuer par Android ou parce que le téléphone peut redémarrer facilement (bug ou batterie vide). Sur PC, en général, je maîtrise quand je ferme mon navigateur et si j'ai besoin de retrouver mes onglets après, j'ai l'option de sauver ma session à la fermeture.
Donc, ça ressemble à une tentative d'unifier Firefox et Firefox pour Android, mais je trouve ça raté, parce que les 2 plateformes n'ont pas les mêmes contraintes imposées par leur environnement (PC ou Android).
Un avantage ? Ça affiche le logo de Firefox, comme ça on ne pourra plus dire "je ne vois même pas la différence entre Chrome et Firefox" :)
# Validité de l'HTML ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Migration de react vers htmx. Évalué à 3.
Ça me plaît bien dans le principe, mais leurs pages d'exemple n'ont pas l'aire d'être de l'HTML valide : par exemple le click-to-edit qui utilise un attribut
hx-extnon-autorisé sur lebody.Est-ce que htmx peut produire du contenu HTML valide ? C'est peut être juste leur site qui n'est pas valide ?
[^] # Re: Disponible pour Debian 11 Bullseye également.
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Ubuntu 22.10 et la prochaine Debian 12 GNOME embrassent PipeWire et WirePlumber - phoronix. Évalué à 3.
J'ai l'impression que c'est tout ce que tu as à faire.
Dans la section Pulseaudio juste à la suite du paragraphe pointé par ton lien, ils proposent de vérifier si ta session utilise bien pipewire à la place de pulseaudio:
Si tu utilises bien pipewire, tu devrais avoir une réponse comme
Server Name: PulseAudio (on PipeWire 0.3.XX).Si non, ils disent qu'il faut regarder la partie Pulseaudio pour Debian 11 dans cette même page de wiki (là-bas, il y a une commande systemctl pour désactiver le service pulseaudio).
Maintenant, tu utilises déjà pipewire à la place du pulseaudio.
Si tu veux l'utiliser aussi pour remplacer Alsa et Jack, il faut lire les sections dédiées dans le wiki. Je n'ai jamais utilisé Alsa directement, ni eu besoin de la faible latence de Jack, donc je ne l'ai pas fait.
Si tu as des périphériques sonores connectés en bluetooth avec ton ordinateur, alors tu pourrais être intéressé par la section Bluetooth. Personnellement, c'est ce qui m'intéressait pour avoir plus de choix de profiles sonores pour mon casque+micro bluetooth.
C'est pour cette dernière partie, que j'ai eu besoin d'enlever un paquet de pulseaudio. D'après la section Bluetooth, on ne peut pas avoir pulseaudio et pipewire qui gèrent en même temps les périphériques bluetooth.
[^] # Re: Disponible pour Debian 11 Bullseye également.
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Ubuntu 22.10 et la prochaine Debian 12 GNOME embrassent PipeWire et WirePlumber - phoronix. Évalué à 3.
Tu as tout à fait raison, le paquet pulseaudio peut rester.
En fait, j'ai dû supprimer pulseaudio-module-bluetooth pour installer la fonctionnalité correspondante de pipewire, comme indiqué sur le wiki de Debian.
C'est à cause de cette suppression que j'ai dû ensuite désinstaller gnome-core à cause de ça :)
[^] # Re: Retour en arrière
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Debian va inclure des binaires non-libres de firmwares dans ses images d'installation. Évalué à 6.
J'ai l'impression que l'utilisateur sera mieux informé : si je me souviens bien, avant Debian 6 c'était le paquet
linux-imagequi contenait directement les firmware.Pour les prochains installateurs, d'après phoronix, l'utilisateur sera informé de la liste des firmware qui seront installés et il aura des options de démarrage pour les désactiver.
En plus, les firmware seront dans une source list dédiée nommée
non-free-firmwarepour recevoir leurs mises à jour de sécurité.[^] # Re: Disponible pour Debian 11 Bullseye également.
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Ubuntu 22.10 et la prochaine Debian 12 GNOME embrassent PipeWire et WirePlumber - phoronix. Évalué à 3.
Oui, pour l'instant, je n'ai pas eu de soucis.
Par contre, dans Debian Bullseye, le paquet
gnome-coredépend de pulseaudio, j'ai donc dû le désinstaller ainsi quetask-gnome-desktop. Ce n'est rien de grave parce que ces paquets sont juste utiles pour rassembler les dépendances pour avoir un bureau GNOME.Pour les périphériques bluetooth, il faut bien suivre la page de wiki pour utiliser pipewire: il faut désinstaller le module bluetooth de pulseaudio pour que ça marche.
Par contre, je n'avais pas de casque bluetooth sans fil avec moi: je n'ai pas pu testé la qualité du son quand je veux utiliser le micro du casque. En théorie, wireplumber et pipewire sont les bons outils pour ça…
# Disponible pour Debian 11 Bullseye également.
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Ubuntu 22.10 et la prochaine Debian 12 GNOME embrassent PipeWire et WirePlumber - phoronix. Évalué à 6.
J'ai appris qur depuis le 14 septembre environ, wireplumber et une version assez récente de pipewire sont disponibles pour Debian 11 Bullseye grâce aux dépôts
bullseye-backports.Pour l'installation à la place de pulseaudio/jack et pour les modules bluetooth (pour avoir plus de profils sonores pour les casques bluetooth), Debian propose une page de wiki.
[^] # Re: Pour des raisons de sécurité
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Dernières avancées du côté de Thunderbird. Évalué à 5.
Merci pour la précision, j'avais en tête l'article Thunderbird's New Home et, effectivement, ils parlent bien de la MZLA Technologies Corporation et non pas d'une fondation.
[^] # Re: Pour des raisons de sécurité
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Dernières avancées du côté de Thunderbird. Évalué à 10.
Rust a bien été fondé par Mozilla, mais Thunderbird n'est plus développé par Mozilla depuis des années (10 ans peut être ?).
Si je me souviens bien, la communauté Thunderbird s'est prise en main il y a quelques années en montant leur propre fondation (avant ils étaient encore lié fiscalement et avec les outils de développement à la fondation Mozilla).
Personnellement, l'utilisation du JavaScript ne me choque pas: ils ont déjà dû remplacer toutes les définitions XUL/XML de l'interface graphique par du JavaScript pour pouvoir continuer à utiliser la plateforme Gecko.
La petite équipe de Thunderbird a donc déjà des connaissances en JavaScript et continuera d'en avoir besoin encore pendant longtemps.
Pour les add-ons, ils doivent également suivre la plateforme Gecko et donc suivre le nouveau système avec les API en JavaScript (manifest v2 et v3).
Je pense en particulier à la partie agenda qui était l'add-on Ligthning auparavant. Il y a d'ailleurs déjà une bonne partie des fonctionnalités en JavaScript pour la gestion des agendas.
La programmation asynchrone avec JavaScript est vraiment agréable et permet facilement de faire des interactions en gardant la fluidité visuelle et un code de bonne qualité. C'est vraiment efficaces pour avoir en même temps des interactions réseaux lentes et une interface graphique fluide malgré cette lenteur.
Je vois leur utilisation de la plateforme Gecko un peu comme les autres utilisent Electron, mais avec les technologies de Mozilla. C'est donc il me semble naturel de privilégier le JavaScript dans cette situation.
Regarder l'utilisation mémoire brute est une mauvaise mesure, puisque JavaScript a aussi son garbage collector et qu'il peut être plus efficace de garder les objets en mémoire plutôt que de constamment la vider.
Bien sûr, si l'environnement mémoire est restreint le Garbage Collector nettoyera plus souvent la mémoire, mais ça implique que le processeur commence a passer plus de temps à faire des choses inutiles pour l'utilisateur…
On en a parlé ici même et aussi là pour le fait d'utiliser la mémoire disponible.
[^] # Re: Owncloud ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YunoHost 11.0 (Bullseye). Évalué à 4.
Malheureusement, même si l'installation se passe bien, j'ai horreur des mises à jour de Nextcloud: il faut vraiment suivre leur rythme car il ne faut pas faire de saut de version important, c'est donc chronophage :(
[^] # Re: Petite déception
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche LibreOffice 7.4, un maître numéro de version. Évalué à 9. Dernière modification le 10 septembre 2022 à 14:10.
Si je n me trompe pas, ce que tu cherches est le Formatage Conditionnel > Barre de donnée ou Echelle de couleur et ça existe déjà 😀
Edit: grillé à 2 minutes près :)
[^] # Re: Hum...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Vous avez dit "caractère" ?. Évalué à 4.
Oui, première réponse de mon lien (l'emphase est de moi)
Oui, c'est facile maintenant… Et alors ? Mon point était que ce document m'a confirmé qu'aujourd'hui, il n'y a pas besoin de wchar pour moi.
[^] # Re: Si je puis me permettre ...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 4.
OAuth2 est une norme très générique et tu peux l'employer pour faire du webservice de backend à backend :)
La norme UMA 2.0 est justement prévue pour utiliser OAuth2 pour permettre à des tiers d'accéder aux données d'un utilisateur et tout ceci de manière asynchrone (le tiers peut demander l'accès et recevoir l'autorisation de l'utilisateur bien plus tard).
Malheureusement, la norme est assez complexe puis qu'elle définit beaucoup d'acteurs: un utilisateur avec son application, un service d'autorisation et un tiers avec une autre application.
En réalité, tous les acteurs ne sont pas nécessaires dans toutes les implémentations et donc des simplifications peuvent avoir lieu dans les interactions.
Je comprend bien que la norme doit pouvoir gérer les cas les plus complexes (comme l'accès aux dossiers médicaux par des médecins tiers), mais ça je pense que ça la dessert un peu, puisqu'elle est difficile à lire.
Ce que je trouve intéressant avec UMA 2.0 + OAuth 2.0, c'est que les backends sont enregistrés comme Client de OAuth2 (en tout cas avec l'implémentation de Keycloak). Du coup, si un des backends tiers n'est plus de confiance, tu peux juste le désactiver et il n'a plus accès à aucune donnée utilisateur de ton backend.
En plus, il y a un système de "Permission Ticket" qui détermine ce que tu as besoin comme droit pour faire ton action, qui vérifie si ta demande est conforme aux politiques de sécurités actuelles et qui te donne un token d'accès pour une durée limitée. Les politiques de sécurité sont configurables et protègent les ressources et/ou les "scopes".
Pour lier ton backend avec le serveur d'autorisation, il y a la norme UMAFedAuth qui permet de faire vérifier concrètement que les permissions ticket sont valides.
J'ai eu l'occasion de configurer un Keycloak avec tout ça. Grâce à UMA, j'ai évité de ré-inventer un système d'API token et j'ai eu pas mal d'avantages en plus:
[^] # Re: Sur les autres contenus également
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Notifier les nouveaux commentaire sur ses messages du forum. Évalué à 2 (+0/-0).
Dans cette entrée de suivi, SpaceFox propose aussi d'afficher pour les journaux, dépêches et liens.
Il faudrait regarder comment ajouter ces contenus dans le tableau de bord.
# Doublon
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Être automatiquement notifié de tous les commentaires lors d’une publication. Évalué à 3 (+0/-0).
En effet, c'est un bug qui a déjà été rapporté ici.
J'y ai proposé un patch pour les contenus qui sont actuellement affichés dans le tableau de bord.
[^] # Re: nomenclature et mitigation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi falsification d'identité par unicode. Évalué à 4 (+0/-0). Dernière modification le 26 août 2022 à 23:21.
J'y ai réfléchis à nouveau et effectivement, on va avoir un problème si on veut pouvoir être protégé du visual spoofing du login: pour pouvoir appliqué facilement la contrainte d'unicité, il faudrait pouvoir normaliser (avec l'algorithme NKFC) les logins.
Mais si on fait ça, alors on change les identifiants de connexion des utilisateurs !
Pour être transparent pour l'utilisateur, Ruby devra normaliser l'identifiant entré avant de le comparer à la base de donnée (mysql ne connaît pas unicode normalize() alors que postgres 13).
Le plus sage serait je pense de passer par une étape intermédiaire:
Si on n'arrive pas à nettoyer les comptes existants, on devra rester comme ça et trouver un autre moyen de contourner le visual spoofing.
On a bien un identifiant unique sur la table
accounts(ouusers), mais ça commence à être difficile à identifier.Au final, peut être que le plus simple est de directement afficher le numéro de account à la place du login et de ne pas essayer de normaliser les logins.
Il faut aussi que j'essaie de voir ce que donne le
slugdu user (généré à partir du login) quand on essaie de l'attaquer par visual spoofing.Si jamais, vous voulez tester, utilisez plutôt le site https://alpha.linuxfr.org au lieu de la production svp ;)
[^] # Re: nomenclature et mitigation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi falsification d'identité par unicode. Évalué à 2 (+0/-0). Dernière modification le 26 août 2022 à 12:35.
Tu as tout à fait raison :)
Je suis en train d'essayer d'afficher le login après le nom, puisque lui est unique.
C'est l'occasion de trouver un moyen également pour améliorer la lisibilité de la ligne "Posté par xxx, Édité par yy, zzz, aaa, Modéré par vvvv", parce que ça va vraiment être très long comme texte si on affiche les logins de tout le monde !
Je fais des essais avec la balise HTML
<details>que je laisserai par défaut fermé sur la liste des articles et ouvert sur l'article lui même.[^] # Re: nomenclature et mitigation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi falsification d'identité par unicode. Évalué à 4 (+0/-0).
Aïe, je viens de voir qu'il n'y a même pas besoin de faire de "visual spoofing" sur le nom affiché, puisqu'il n'y a même pas de contrainte d'unicité: vous pouvez tous mettre la valeur Adrien Dorsaz si ça vous chante :(
C'est une "fonctionnalité" déjà employée: j'ai déjà vu des utilisateurs réutiliser le même nom affiché quand ils créent un nouveau compte plusieurs mois / années après avoir supprimé leur ancien compte.