Adrien Dorsaz a écrit 889 commentaires

J’allais demander si tu avais reproduit les spécifications du markdown de linuxfr mais je vois que sur ton blog le HTML intégré suivant n’a pas été viré.

Pour chaque article de mon blog, j'écris du HTML directement avec l'aide de prettier dans vim.

En fait, si tu regardes la source de la page d'un article, c'est quasiment le fichier qui se trouve sur mon git: https://gitlab.adorsaz.ch/adrien/adorsaz.ch/-/blob/bf2aa989380be32f99d51e1520d8ce1b99e92854/src/articles/decouvertes-logiciels-libres-ete-2023.html

J'avais à cœur que le fichier HTML codé soit un fichier complet et donc auto-suffisant si JavaScript n'est pas activé. C'est très pratique car je peux dire à Firefox d'ouvrir le fichier directement pour prévisualiser sans avoir besoin d'étape supplémentaire ou de serveur web.

Seulement, je ne voulais pas non plus répéter l'en-tête du blog dans chaque page d'article. Comme je n'ai pas de moteur de template, ce que j'ai fait, c'est que le code JavaScript d'article.js injecte l'en-tête du blog dans l'article.

C’est sympa les méta et leur rendu.

Merci :) C'est justement dans la suite de cette idée: je voulais donner les méta dans le fichier HTML directement sans avoir besoin de me répéter. Donc pour les lecteurs qui activent JavaScript je leur en fait une présentation sous le titre et pour les autres je leur avertit que c'est disponible dans les balises meta du code source.

J’allais demander si tu avais reproduit les spécifications du markdown de linuxfr

Pour écrire le journal, j'ai donc du traduire l'HTML vers son markdown. Ça se fait assez bien à la main, l'article n'est pas trop long. Effectivement, le markdown ne permet pas de tout avoir, j'ai dû laissé tombé l'exemple du form et j'ai juste référé à l'exemple de la documentation de Mozilla.

Hello,

Je suis tombé hier soir sur la page d'informations de licence dans les menus de la Nintendo Switch suite à une mise à jour hier.

Eh ben, ils ont juste fait une immense page défilable avec toutes les mentions et licences.

J'ai commencé à lire le début (il y a curl, c'est peut-être pour ça la mise à jour ?), mais j'ai assez vite abandonné quand j'ai vu la taille de l'ascenseur de la scrollbar 😅

J'imagine que Nintendo a contrôlé que c'était une solution suffisante avant de le faire…

Après il serait peut être envisageable d'ajouter un index des projets ou un système de recherche par nom. Ça serait plus sympa pour rendre plus visible les projets (bon ça restera un index avec 1200 entrées 😬).

Hello,

J'étais tombé sur cet article quand je cherchais des couleurs pour les graphes:

https://thenode.biologists.com/data-visualization-with-flying-colors/research/

L'article étudie 4 possibilités de palette et y explique qu'il faisait éviter de faire des graphes avec plus de huits couleurs différentes.

Comme dit dans les commentaires plus haut, il y a des simulateurs qui peuvent aider à vérifier le résultat.

Enfin, j'avais aussi lu ailleurs qu'une bonne stratégie si on veut aussi aider les personnes avec peu de perception de couleurs (vision quasiment en nuances de gris), ça serait d'utiliser les formes ou trame de fonds au lieu de faire des aplats.

Merci pour le lien. C'est dommage qu'il y ait autant de texte anti-systemd et "c'était mieux avant", parce qu'il y a une remarque qui me semble pertinente :

En gros, il dit que les développeurs d'applications s'attendent à toujours avoir un OS de moins de deux ans et que les OS eux-mêmes s'attendent à avoir du matériel de moins de deux.

Sur ce premier point, je pense qu'il force le trait et que des solutions existent déjà pour utiliser des logiciels récents sur des vieux OS: flatpak et snap.

Ensuite, il écrit que les OS ne font même plus de paquets pour certains logiciels important : Ubuntu n'a plus de paquet pour naviguer sur le web (Firefox et Chromium sont des snap fournis par Mozilla et Canonical) et RedHat ne propose plus de traitement de texte WYSIWYG (LibreOffice ne sera disponible que via le flatpak de la communauté LibreOffice).

De nouveau, il exagère un peu, car son argument ne tient pas pour Chromium vu que le paquet snap est créé par Canonical.

Mais quand même, comment Canonical va pouvoir proposer un version Ubuntu supportée sur 10 ans avec Firefox si les développeurs de Firefox arrêtent le support de ces vieilles version d'Ubuntu ?

Pour moi en personnel, ce n'est pas grave car je peux mettre à jour mes PCs. Mais pour ceux qui ont besoin d'une distribution Linux sur 10 ans, est-ce que ça remplit encore leurs besoins si de plus en plus de logiciels seront fournis directement par les développeurs du logiciel ?

Finalement à qui se destine ce support sur 10 ans et pour quels besoins ?

En fait, je doute que ces gros logiciels (Firefox, Chrome et LibreOffice) aient été couverts par le support LTS d'Ubuntu et de Redhat. Vous avez des infos ?

Si ce n'était déjà pas supporté, alors la situation s'est juste améliorée: plutôt que d'avoir une version figée de Firefox sur 10 ans, il sera possible de garder une version à jour plus longtemps (jusqu'à ce que Mozilla décide que l'OS est trop vieux).

pour mon OS (Mac OS 10.11.6, là ok ça commence à dater, juillet 2018 mais mon matériel date lui de 2011)

Si Apple a arrêté le support du matériel, ce n'est pas la faute des développeurs de Firefox / Chrome ni de ceux des applications web.

Heureusement, les logiciels libres comme Linux et Freebsd permettent de faire un pied de nez à Apple et continuer à utiliser du matériel qui fonctionne encore bien malgré son âge.

En plus ces solutions permettent souvent d'utiliser un système d'exploitation à jour sur ce genre de matériel avec les derniers correctifs de sécurité disponibles.

Hello,

Merci je n'avais pas remarqué, tu as raison c'est bien mieux 😅

(Source https://mastodon.adorsaz.ch/@adrien , qui a bon goût et dont je recommande aussi le pouet qui précède)

Merci, c'est chouette de voir que les partages peuvent intéresser d'autres :)

En lisant en vitesse le rapport de bug, je n'avais pas bien compris de quoi il en retournait. Depuis, Gee a fait un article sur le blog de Superflu qui explique très bien ce qui se passe (en français): https://studios.ptilouk.net/superflu-riteurnz/blog/2023-08-11_bug323.html

Wayland qui me semble venir par défaut avec la 12…

Je pense qu'il y a confusion: Wayland n'est pas un serveur mais un protocole qui doit être implémenté par les environnements graphiques.

Les trois implémentations dont j'ai le plus entendu parlés sont GNOME Shell, KDE Plasma et Sway par exemple.

Debian a choisi d'installer par défaut GNOME si on lui demande d'installer un environnement graphique. Et GNOME Shell propose lui même par défaut d'utiliser son implémentation de Wayland a la place d'utiliser le serveur X.

Pour raccourcir certains disent que Debian installe Wayland par défaut, mais en réalité ça dépend du choix de l'environnement graphique à l'installation.

Tu peux très bien continuer d'utiliser le serveur X comme d'habitude, il n'y a pas de plans pour le supprimer actuellement il me semble.

Hello!

J'avais vu passer dans le forum de GNOME une question sur le sujet.

En gros, depuis Nautilus 43 le panneau de côté est caché automatiquement s'il n'y a plus assez de place pour afficher assez d'icones. Il n'y a plus de moyen de le forcer quand la taille de la fenêtre est assez grande.

Dès lors que le panneau est caché, l'utilisateur peut forcer son affichage avec F9.

Je vois qu'ils parlent d'un contournement en demandant d'afficher la taille des icônes en plus grand pour forcer à faire disparaître le panneau. Mais je doute que ça permettra d'afficher plus d'icones dans ton cas.

Enfin, j'avais juste vu cette discussion à propos de Nautilus 43, je ne sais pas s'il y a eu des changements depuis.

J'avais regardé en fin d'année dernière. Il faut savoir que l'application desktop de Teams est en réalité une application web déployée avec Electron.

L'application web pourrait rececoir les mises à jour sans avoir besoin de passer par le gestionnaire de paquets Linux (je parlerai d'apt après pour simplifier), mais je ne sais pas si Microsoft le fait.

Ce qui est sûr, c'est que, pour mettre à jour Electron (autrement-dit Chrome), il faut passer par les mises à jour apt.

Pour réussir une bonne intégration avec Linux, Wayland, Pipewire / Pulseaudio… il faut avoir Electron/Chrome bien à jour car c'est là que toute l'intégration se passe.

Or, quand j'ai regardé en fin d'année dernière, apt n'avait pas reçu de mise à jour de Teams depuis environ 2 ans.

Ce qui fait qu'Electron/Chrome était trop vieux pour s'intégrer avec Wayland et pipewire et donc je ne pouvais ni faire fonctionner le partage d'écran, ni utiliser correctement mon casque audio.

En cherchant des solutions, j'ai trouvé plusieurs utilisateurs qui expliquaient que la meilleur expérience est faite avec l'installation de Teams via Chrome: Chrome propose d'installer Teams dans la barre d'url quand tu navigues sur l'application web de Teams.

Et ils avaient raison, puisque tu te retrouves avec un Chrome toujours à jour, tu peux avoir une bonne intégration. Tu peux même activer les fonctionnalités expérimentales de Chrome pour activer le partage d'écran via pipewire et donc avoir le partage d'écran fonctionnel avec Wayland. Ce qui était impossible avec la distribution Electron.

Finalement, Microsoft eux même recommandent cette méthode (PWA) pour les utilisateurs Linux:

We encourage our Teams Linux users to switch over to the PWA to get the latest Linux features and a desktop-like experience. Stay tuned for the latest news on the Microsoft Teams blog.

Quand je vois comment les utilisateurs de LibreOffice sont amer face à l'existence même d'Apache OpenOffice

Ben en fait, justement, ça n'«existe» plus vraiment, c'est tout le problème… Si le développement d'OpenOffice était actif, il pourrait y avoir des synergies, mais là, il n'y a juste rien.

Supernova, c'est juste le nom de la prochaine version majeur qui sortira cet été.

Ils vont proposer beaucoup de changement d'interface d'où cette hyperbole pour le nom:

• Nouveau panneau de dossiers
• Nouveau design pour le calendrier
• etc

Pour Android, Thunderbird ne sera pas développé de zéro : ils ont engagés le développeur de k9 mail pour ajouter des fonctionnalités nécessaires aux utilisateurs de Thundetbird et, quand ce sera prêt, k9 mail sera renommée "Thunderbird on Android": https://blog.thunderbird.net/2022/06/revealed-thunderbird-on-android-plans-k9/

C'est vrai, un changement de logo n'est pas utile en soit. Mais dans le cas de Thunderbird, il n'a pas changé depuis 19 ans et il marque une reprise du développement plus active depuis une année : des développeurs sont engagés pour développer la version Android et la version Supernova qui apportera beaucoup de nouveautés cet été.

Si il y a d'autres avantages techniques, je suis preneur.

Il y a aussi le protocol DAP qui uniformise les debuggers (de la même manière aue LSP uniformise l'aide au développement).

Grâce à LSP et DAP, j'ai par exemple pu transformer vim en IDE: https://linuxfr.org/users/trim/journaux/transformer-vim-en-ide-avec-lsp-et-dap

Ce n'était pas facile à trouver: passer par le plan du site de Mediapart (en pied de page), pour trouver la FAQ et chercher "don", donne la page: https://www.mediapart.fr/aide?question=faire-un-don

Et là on retrouve bien le lien que vous avez mentionné 👍

Si je reprends la conversation que l'on avait eu au sujet de l'attaque par homoglyphe, l'intention est bien de cacher les identifiants numériques pour ne rendre visible que les slugs:

Oui on a fait disparaître la plupart des identifiants des 'accounts' et des 'users', ce n'est pas pour les remettre maintenant.

D'ailleurs la redirection semble bien faire ça: si tu essaies de trouver un utilisateur par un identifiant numérique, alors tu es redirigé vers son url avec slug.

Donc, je dirai que ce comportement est voulu puisque l'on ne veut pas spécialement rendre publique les ids de la base de donnée.

Pour aller (presque¹ ) au bout de cette idée de cacher les ids de base de donnée, on pourrait remplacer la redirection par une erreur 404 et n'autoriser l'accès que via les slugs.

On risque d'être un site moins cool, puisque ça va casser les vielles urls comme https://linuxfr.org/users/4, mais bon ça fait depuis 2011 que linuxfr.org répond avec des redirections permanentes (HTTP 301) vers les slugs :)

---

1: presque, parce que les identifiants sont visibles lors de l'upload de l'avatar et de la feuille CSS si on connaît l'algorithme de création des dossiers.

Faut-il mettre à jour la gem qui gère la production du slug et/OU le routage suivant le slug ? Changer la règle de production du slug (même si on change la production de slug pour ajouter XXX123 quand on ouvre le compte id 123, on aura toujours une collision si on ouvre un compte login XXX123 de toute façon…) ?

Alors la documentation de friendly_id stipule clairement qu'elle ne gère que la partie base de donnée. Le routage est géré manuellement.

Avec LinuxFr, par exemple pour le controlleur de user, c'est géré comme ça:

# encoding: utf-8
class UsersController < ApplicationController
  before_action :find_user

  def show
    path = user_path(id: @user, format: params[:format])
    redirect_to path, status: 301 and return if request.path != path
    find_nodes([News, Diary])
    respond_to do |wants|
      wants.html
      wants.atom
    end
  end

[...]

protected

  def find_user
    @user = User.find(params[:id])
    raise ActiveRecord::RecordNotFound.new unless @user
    @contents = @user.nodes.visible.by_date.limit(20)
  end

[...]

end

Depuis le paramètre id qui vient du path de l'url (/users/:id), on cherche l'utilisateur qui correspond avec User.find (id peut être soit un slug, soit un l'identifiant numérique de l'utilisateur).

Si le path de l'utilisateur trouvé ne correspond pas au path courant, alors on redirige. Je ne connais pas assez Ruby On Rails pour savoir comment est géré la fonction user_path, mais j’admets qu'elle fonctionne correctement.

La gem friendly_id modifie la fonction find (parce que l'addon :finders est activé dans friendly_id.rb):

FriendlyId offers enhanced finders which will search for your record by friendly id, and fall back to the numeric id if necessary.

C'est pour ça que l'utilisateur avec un slug numérique aura la priorité sur l'utilisateur qui a l'identifiant qui correspond au slug.

Voilà, j'ai préparé une pull request ici pour ajouter une colonne "last_seen_on": https://github.com/linuxfrorg/linuxfr.org/pull/370

La valeur est NULL tant que le compte n'a pas été confirmé (et donc aussi pour Anonyme et Collectif). Si non, ce sera la date de la migration, parce qu'on ne peut pas savoir précisément la bonne date à mettre.

Là, j'ai l'impression de perdre tous les avantages de Silverblue et de devoir gérer une distribution finalement comme si j'utilisais Fedora Workstation.

Je ne vois pas trop des avantages dont tu parles en fait, tu peux étayer ?

Si jamais, je n'ai pas beaucoup de recul, car ça fais moins d'une semaine que j'essaie Silverblue et toolbox. C'est justement pour ça que je demandais des retours :)

Je pose comme hypothèse que Fedora Silverblue amène plus de stabilité et de facilité pour les mises à jours par rapport à Fedora Workstation. Fedora Workstation amène plus de flexibilité et moins d'assurance pour la QA.

Si j'installe des outils dans toolbox, alors ceux-ci seront installés dans une distribution de type Fedora Workstation: beaucoup de flexibilité, mais moins de stabilité.

Comme j'utilise tous les jours ces outils, de mon point de vue, c'est comme si j'avais installé Fedora Workstation sur ma machine: mes outils quotidiens ne bénéficient pas de la stabilité et des mises à jour de Fedora Silverblue.

En y réfléchissant, je serai dans la même situation avec rpm-ostree finalement, puisque l'ajout d'overlays de paquets RPM réduit aussi la stabilité du système.

En conclusion, je pense qu'il serait mieux que j'utilise toolbox, parce qu'il permet au moins de garder mon système principale stable et, en plus, il délie la mise à jour de ma machine de la mise à jour de mes outils.

Pour mes outils de base, je peux faire un Dockerfile pour simplifier les mises à jours.

J'aime bien aussi l'idée de pouvoir ponctuellement créer des environnements de développement jetable quand je donne un coup de main sur d'autres projets, comme expliqué par Psychofox plus haut.

Merci tout le monde pour les éclairages :)

Merci, je comprend l'idée, mais j'ai l'impression que si je suis vraiment ces conseils, je vais me retrouver avec beaucoup de logiciels installés dans mon toolbox.

Typiquement dans le toolbox que j'ai fais durant mes tests, j'ai: zsh, powerline, vim-X11, shellcheck, nodejs, git… La plupart de ces outils n'auront pas de Flatpak disponible et du coup il me reste le choix soit d'utiliser rpm-ostree, soit toolbox.

Si j'utilise toolbox, alors je vais devoir faire moi-même les mises à jour avec dnf ou la création d'un nouveau toolbox de zéro et donc réappliquer un script qui installe mes outils.

Là, j'ai l'impression de perdre tous les avantages de Silverblue et de devoir gérer une distribution finalement comme si j'utilisais Fedora Workstation. Bien que mon système principale fasse parti de la QA prévue par Fedora Silverblue, la plupart de mes outils ne seront pas couverts par cette QA.

Si j'utilise rpm-ostree, alors les mises à jours sont gérées directement par Fedora Silverblue et mes paquets sont réinstallés en tant que surcouche par dessus le système de base.

Comme dit plus bas, si je me limite à installer des paquets distribués par Fedora, mon système se retrouve finalement aussi dans un état prévu par Fedora, non ?

Ce n'est pas une très bonne idée d'utiliser rpm-ostree pour autre chose que des paquets obligatoires (drivers, …)

Donc distrobox ou toolbox, ça permet d'avoir un environnement pas en lecture seul justement.

J'avais entendu ça aussi au début, mais en lisant l'article de Colin Walters, je me suis rendu compte que le terme "en lecture seule" veut seulement dire que le répertoire "/usr" doit être considéré comme dossier géré par Fedora et non pas que le système entier doit être en lecture seule.

Or, pour les RPMs distribués par Fedora, je pense qu'il n'y a pas de problème de les ajouter par dessus l'image de base fournie aussi par Fedora, non ?

Je pense ça, parce que même si mon installation s'éloigne effectivement un peu de la distribution de base, elle reste dans un état prévu par Fedora.

Avec la sortie de Fedora 38, j'ai aussi essayé d'installer Silverblue.

Je n'avais pas bien compris ce que c'était vraiment et j'ai cru que tout le système d'exploitation serait en lecture seule.

Heureusement, j'ai essayé et j'ai appris que "/etc" est toujours modifiable, ouf !

Finalement, c'est surtout /usr qui est en lecture seule: ça permet de laisser la gestion de ces données exclusivement à la distribution Linux et de permettre des mises à jour plus fiable, car personne ne touche à ce répertoire.

Colin Walters a bien expliqué sur son blog pourquoi cette propriété est intéressante.

Notamment, parce que, même si personnellement je ne touche pas à /usr, je ne suis pas à l'abri qu'un script d'installation y touche malgré moi.

Au début, j'avais aussi un peu peur par rapport à l'installation de service système: par exemple, j'ai besoin de pouvoir connecter mon ordinateur à un service VPN. Eh bien, avec rpm-ostree, on peut encore ajouter des composants systèmes via les RPM de Fedora.

Si j'ai bien compris le système ce n'est pas un soucis, car lors d'une mise à jour majeur, rpm-ostree fera un rebase des paquets RPMs installés à la main sur la nouvelle version de Fedora. Autrement dit, ça ressemble exactement aux rebases quotidiens que je fais avec git durant mes développement, ça me plaît :)

L'utilisation des Flatpak de Flathub ça me plaît bien également, je l'utilisais déjà avec Debian et Fedora Workstation.

Il me reste enfin l'utilisation de toolbox dont je ne suis toujours pas trop sûr de l'intérêt. Vous avez des retours ?

J'ai installé mon environnement de développement dans toolbox comme conseillé. Mais je me dis que, quand je vais devoir mettre à jour le container toolbox, eh bien, j'aurai perdu tout l'intérêt de Silverblue : je vais repasser par les mises à jours via dnf avec un /usr potentiellement plein de modifications. Je ne ferais pas mieux d'utiliser les packages Fedora avec rpm-ostree ?

Est-ce que l'idée est de pouvoir juste délier la mise à jour de l'hôte et des containers ? Par exemple, ça me permettrait d'activer les mises à jour automatique de Fedora Silverblue sur l'hôte sans prendre de risque de casser mes outils de développement tout le temps ?

Bon, j'ai essayé et j'ai compris que timeoutable semble tracker l'activité avec des données directement dans le cookie et non pas en base de donnée. Ça ne serait donc pas si utile que ça.

J'ai testé avec un timeout par exemple d'une minute et, en fait, tant que je navigue sur le site, le cookie reste valable et la base de donnée n'est pas mise à jour. C'est parce qu'il détruit la session seulement si l'utilisateur est inactif un certain temps et non pas après une certaine durée de session.

Devise ne semble pas proposer de forcer un temps maximal de session, du coup, je pense que ça ne sert pas à grand chose de changer sa configuration et il vaut mieux implémenter la proposition de nud.

L'initiative peut venir d'un peuple directement à condition de récolter un nombre suffisant de signatures en faveur de l'initiative dans un certain temps. Je ne me souviens plus des chiffres exacts.