Ils parlent dans cette page même de casser le système d'extension, je leur suggérerait le système WebExtension pour les prochaines, quitte à faire du JavaScript et du CSS :)
Si je comprend bien le problème d'architecture est pour Gnome Shell 3 et non pas l'architecture de Wayland, ouf !
De ce que j'ai survolé dans le lien Gnome Shell 4, ils ont les mêmes problèmes que Firefox Quantum est en train de résoudre : il faut absolument alléger au maximum le process principal pour être toujours réactif. Plusieurs solutions existent, notamment, en créant un process de composition dédié, en utilisant encore plus le GPU pour les graphismes et en utilisant au mieux les multiples cœurs du CPU.
Ça va demander d'utiliser un langage tel que Rust pour assurer un code sûr pour le multi process…
Donc, finalement, il faudrait finalement remplacer Gnome Shell 4 par un Firefox Quantum :D On pourrait même l'appeler Firefox Quantum OS !
En résumé, il faut que tu fasses cette correction sur la dernière ligne:
@ 10800 IN A XXX.XX.XXX.XX (surement IP serveur name gandi)
@ 10800 IN MX 10 spool.mail.gandi.net.
@ 10800 IN MX 50 fb.mail.gandi.net.
@ 10800 IN SOA ns1.gandi.net. hostmaster.gandi.net. 1519241627 10800 3600 604800 10800
blog 10800 IN CNAME blogs.vip.gandi.net.
imap 10800 IN CNAME access.mail.gandi.net.
pop 10800 IN CNAME access.mail.gandi.net.
srvX 10800 IN A XXX.XX.XXX.XX (IP maison)
smtp 10800 IN CNAME relay.mail.gandi.net.
webmail 10800 IN CNAME webmail.gandi.net.
www.srvX 10800 IN CNAME srvX.domaine.org.
Dans la première colonne de la ligne www.srvX est un raccourcis pour dire www.srvX.domaine.org..
Quand on définit une entrée DNS, on utilise des noms de domaines complet qui se terminent par un ..
Pour simplifier, les logiciels considèrent que si tu ne mets pas de . à la fin de ton entrée, alors c'est une entrée relative à l'origine du DNS.
En supposant que ton origine est bien domaine.org, alors pour définir une entrée sur www.srvX.domaine.org., tu peux l'écrire de 2 manières:
en utilisant l'origine implicite: www.srvX 10800 IN CNAME srvX
en précisant l'origine complète: www.srvX.domain.org. 10800 IN CNAME srvX.domaine.org.
Il me semble que si un site donne l'indication hsts, alors le navigateur doit vérifier la chaine de certificat complète avec son magasin de certificats racines.
Du coup, quand un site avec hsts actif se retrouve avec un certificat auto signé (ou sur le mauvais domaine), alors l'utilisateur doit voir son accès refusé et il ne peut pas faire d'exception manuelle.
Je ne suis pas sûr que ce comportement est obligatoire, mais c'est bien ce que j'ai vu avec Firefox.
Tu peux techniquement faire autant de certificat que tu veux, même avec des clés privées différentes si tu veux mieux isoler les 2 serveurs/services.
La seule restriction que tu peux trouver proviendrait de ton fournisseur de certificat. Et encore, tu pourrais le feinter en demandant un autre certificat à un autre CA.
Si tu as besoin de deux certificats juste pour changer le format de la chaîne (selon les logiciels, ils ont soit plusieurs fichiers à définir soit un seul avec tout dedans)*, tu peux juste te créer un deuxième fichier à partir de la chaîne et de la clé privée pour se conformer à la configuration de tes services.
J'utilise par exemple un deuxième certificat pour mon serveur SMTP avec le même nom de domaine. Ainsi il peut utiliser un certificat créé à partir d'une clé RSA au lieu de la clé ECDSA que j'utilise d'habitude: ça me permet d'être plus compatible avec les autres serveurs de mail.
*: je pense à ejabberd par exemple qui a besoin que la chaine et la clé privée soient dans le même fichier, si je me souviens bien
Si je me souvuens bien, la commande systemctl daemon-reload demande juste à systemd de relire les fichiers de configuration.
Le plus souvent, il faut juste redémarrer le service ensuite. Mais comme tu modifies les dépendances de démarrage, il faudrait aussi faire un systemctl disable et systemctl enable.
En effet, ce sont ces 2 dernières commandes qui gèrent les liens entre services en créant les répertoires "services.wants" dans /etc/systemd/system.
Ce que je ne comprends pas vraiment, c'est pourquoi tu insistes pour utiliser wedav1 ?
De mon expérience avec le module mod_dav d'Apache2 et aussi le module d'Owncloud à l'époque (vers 2013, en utilisant Nautilus et/ou un montage dav2fs pour la partie client), ça ne marche pas hyper bien, les clients donnent des erreurs incompréhensibles au bout d'un moment (style, "Serveur indisponible", "verrou actif sur le fichier", alors que j'étais juste en train de naviguer à travers les dossiers et que je suis le seul à utiliser ces dossiers; maintenant que j'y pense, il faut sûrement donner des instructions spéciales au serveur web pour la gestion du protocole HTTP dans ce cas, car il va y avoir beaucoup de requêtes et que ce n'est pas vraiment le comportement par défaut attendu pour des clients HTTP).
Le client de synchronisation quant à lui est clairement intéressant, puisqu'il ne surcharge pas le serveur web avec des requêtes HTTP fréquentes pour simplement naviguer à travers les fichiers. Le système de fichier local est efficace pour rechercher à travers les méta-données des fichiers et, si tu utilises des logiciels comme Tracker/Baloo, ils sont complètement fonctionnels (à l’exception du fait que Nextcloud ne synchronise pas les extended attributes).
Le client est capable d'écouter les modifications sur le poste local pour les envoyer au serveur. Dans l'autre sens, il retrouve automatiquement les modifications du serveur pour les appliquer en local. Seul les données modifiées passent à travers le réseau et donc la bande passante, la RAM et le CPU du serveur sont largement moins utilisées qu'avec le webdav.
Pour le chiffrement côté serveur, c'est bien écrit dans la documentation que son seul intérêt est pour l'envoi des données sur des "Remote Share" (style Google Docs, Dropbox, …):
The primary purpose of the Nextcloud server-side encryption is to protect users’ files on remote storage, such as Dropbox and Google Drive, and to do it easily and seamlessly from within Nextcloud.
Or souvent, le but est d'utiliser Nextcloud est de se détacher de ces services, donc ça ne me surprend pas que peu de monde active ce chiffrement.
Sans ajouter que la majorité semble déléguer l'hébergement à OVH (qui utilise des VM) et donc n'ont aucune idée de la puissance machine requise par Nextcloud pour les auto-hébergés adeptes de machines de récupération.
J'utilise Nextcloud sur un laptop Acer acheté à l'époque de Windows Vista: Nextcloud ne consomme quasiment rien sur mon serveur (mais bon, évidemment, il n'est pas constamment en train de gratter les disques et envoyer des données puisque je n'utilise la fonctionnalité webdav qu’occasionnellement). C'est surtout Gitlab qui se goinfre de CPU et de RAM chez moi, mais c'est gérable grâce aux limitations de ressources par service proposées par les slice de systemd.
1 Note bien que je ne parle que de webdav, car c'est lui qui utilise le plus de ressources pour communiquer (CPU, RAM, bande passante) à cause de la nature et de la quantité de données: caldav et carddav ont beaucoup moins d'impact sur ces ressources, car les données finales à transmettre sont beaucoup plus petites que des milliers de fichiers.
Si je me souviens bien, XFCE n'a pas de gestionnaire de compte centralisé commme gnome-online-account qui se cache derrière gnome-control-center). Il te faudra donc trouver des outils qui connaissent caldav, carddav, webdav et tous les configurer à la main.
Pour caldav et carddav, Evolution sait gérer, mais tu devras configurer chaque calendrier et chaque carnet d'adresse à la main. Il y a aussi Thunderbird, mais il faut utiliser l'extension SoGo.
Pour webdav, c'est géré par gnome-vfs qui est utilisé par Thunar si mes souvenirs sont bon.
D'ailleurs en passant, sur pc (ubuntu/debian) on sait synchroniser les contactes, calendriers, etc?
Pour l'environnement GNOME 3 (donc Debian et Ubuntu récentes), oui, il suffit d'ajouter un compte "Owncloud" ou "Nextcloud" (les 2 systèmes sont compatibles) dans les paramètres "Comptes en ligne". Ça configure automatiquement le backend d'Evolution pour synchroniser les calendriers par caldav et les contacts par carddav.
Comme c'est le backend Evolution, tu peux ensuite utiliser en frontend soit Evolution, soit Gnome Calendar, soit Gnome Contact pour accéder à tes infos (voir même California qui était développé par Yorba, mais dont je ne sais pas si des mainteneurs ont repris le projet).
PS: même que le racourci webdav est automatiquement ajouté à Nautilus et Gnome Documents peut faire des recherches directement avec les mineur en ligne de Tracker.
Pour le terme "vrai streaming" : je ne vois pas bien de quoi tu veux parler. Toutes les vidéos YouTube sont lues en direct dans les navigateurs, donc streamée. Est-ce que tu voulais parler de streamer sur UDP directement ?
Si je me souviens bien, la barre de recherche reste après une mise à jour. C'est l'interface par défaut de Firefox qui ne la présente plus, mais elle reste présente dans les outils de personnalisation.
Solution proposée : dans le flux atom des dépêches, faire pointer le lien « lire les commentaires » vers des url atom plutôt que html. Idem avec les journaux et les forums.
Je garderai le texte « Lire les commentaires » pour la lecture direct sur le web et j'ajouterai un second bouton « Suivre les commentaires » pointant vers le flux atom.
Ça reflétera mieux à mon avis l'action exécutée par le lien, non ?
J'ai l'ai eu avant le 16/11 (windows et os x). Mais cette inexactitude est sûrement du à un timing très serré entre l'écriture de cet article (et sa publication) et la publication du logiciel.
C'est juste que l'article anglophone est très long et qu'il nous a fallu pas mal de temps pour la finaliser.
Ceci dit je trouve cette version (57)
Cette dépêche ne parle pas d'amélioration de la version 57, mais de prochaines améliorations.
Firefox 57 a le nouveau moteur CSS Stylo et les prochaines versions verront arriver le nouveau moteur de rendu WebRender.
En effet, dans la dernière section, c'est écrit:
Nous avons hâte d'intégrer WebRender à Firefox dans le cadre de Quantum Render en 2018, quelques versions après la sortie initiale de Firefox Quantum.
En effet ça fait un peu bizarre, mais je vois mal comment on pourrait garder un outil simple pour calculer où couper le code HTML et comprendre en même temps la langue française et/ou anglaise :)
Si tu regardes un peu les détails du patch, tu verras que je n'ai rien inventé de nouveau: j'ai juste demander d'appliquer les mêmes règles que sur les autres contenus (journeaux et forum si je me souviens bien).
Le code est assez nouveau pour moi, mais à mon avis c'est que parser du HTML pour retrouver les 80 mots affichables et le tronquer correctement est assez couteux pour le serveur.
Je vois donc cette colonne comme un cache pour le contenu tronqué.
En plus, comme le contenu bouge peu une fois publié, c'est quand même plus efficace de faire ce calcul une seule fois au lieu de le calculer à la volée pour tous les utilisateurs, visiteurs et robots.
Une autre solution serait de tronquer côté client avec du CSS (ou au pire JavaScript), mais ça me semble moins efficace en bande passante et plus difficile à maîtriser pour retrouver le 80ieme mot à afficher.
J'ai trouvé comment faire une solution en réutilisant le code existant déjà pour les journaux.
Ça demande une modification en base de donnée de la table wiki_pages pour ajouter une colonne avec un contenu tronqué à 80 mots (ce contenu est calculé automatiquement à chaque modification du contenu principal).
Le résultat donne assez bien, pour dire que je n'ai quasiment rien crée de nouveau:
Il y a juste une truc marrant, c'est que les liens vers linuxfr dans les contenus de wiki contiennent le favicon de linuxfr à côté. Du coup, ici on se retrouve avec ce favicon à côté du lien (...).
Personnellement, ça ne me dérange pas, mais pensez-vous que ça va créer une entrée de suivi pour corriger ça ?
Pour la configuration des fichiers, tu seras forcé de les mettre à jour avec les évolutions des différents programmes. En effet, des options apparaissent/disparaissent… Debian n'y peut rien.
C'est quelque chose de très chronophage. Par contre, si tu as de la chance comme moi, certains de tes logiciels critiques seront déjà disponibles dans une version proche de Stretch grâce aux dépôts de jessie-backports et/ou jessie-backports-sloppy (sloppy est un backports qui évolue encore pour old-stable).
Ces dépôts te permettent de mettre à jour un logiciel après l'autre sans devoir modifier toutes les configurations de tous les logiciels en même temps.
Par exemple, grâce à Backports, ma migration du serveur XMPP ejabberd et du serveur mail Exim ont été très simple, puisque j'avais déjà les versions de Stretch sur mon serveur Jessie.
Tu noteras dans mon poste, que même si ça simplifie, ça ne suffit pas pour t'assurer que tout se passera bien: même si ejabberd avait la même version, une de ses dépendances a été mise à jour sur Stretch: openssl est passé à la version 1.1, ce qui a cassé le lien entre ejabberd et openssl avec l'utilisation de certificats ECC.1
En fait, le plus simple, si tu en as les moyens, c'est d'avoir une machine de test pour tester la mise à jour et déjà prévoir les changements de configuration que tu devras faire.
Bonne chance !
1 : évidemment j'ai fait un rapport de bug à Debian, j'ai proposé un rétro-portage du patch upstream et le fix est intégré à Debian depuis la mise à jour de Septembre <3
Désolé pour le dérangement avec cette nouvelle version de Ruby…
Il faudrait peut-être modifier le fichier README pour ne pas conseiller d'installer la version stable de Ruby, mais plutôt une version exacte ?
Ça va un peu mieux, mais l'exception est toujours là:
adrien@bureau-ado:~/code/linuxfr.org$ bin/rake db:setup
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/therubyracer-0.12.2/lib/v8/conversion.rb:21: warning: constant ::Fixnum is deprecated
/home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:85:in `rescue in block (2 levels) in require': There was an error while trying to load the gem 'coffee-rails'.
Gem Load Error is: wrong argument type Class (expected Module)
Backtrace for gem load error is:
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/therubyracer-0.12.2/lib/v8/conversion.rb:23:in `include'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/therubyracer-0.12.2/lib/v8/conversion.rb:23:in `block (2 levels) in <top (required)>'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/therubyracer-0.12.2/lib/v8/conversion.rb:22:in `class_eval'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/therubyracer-0.12.2/lib/v8/conversion.rb:22:in `block in <top (required)>'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/therubyracer-0.12.2/lib/v8/conversion.rb:21:in `each'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/therubyracer-0.12.2/lib/v8/conversion.rb:21:in `<top (required)>'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `block in require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:240:in `load_dependency'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/therubyracer-0.12.2/lib/v8.rb:22:in `<top (required)>'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `block in require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:240:in `load_dependency'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/execjs-2.5.0/lib/execjs/ruby_racer_runtime.rb:108:in `available?'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/execjs-2.5.0/lib/execjs/runtimes.rb:53:in `each'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/execjs-2.5.0/lib/execjs/runtimes.rb:53:in `find'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/execjs-2.5.0/lib/execjs/runtimes.rb:53:in `best_available'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/execjs-2.5.0/lib/execjs/runtimes.rb:47:in `autodetect'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/execjs-2.5.0/lib/execjs.rb:5:in `<module:ExecJS>'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/execjs-2.5.0/lib/execjs.rb:4:in `<top (required)>'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `block in require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:240:in `load_dependency'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/coffee-script-2.4.1/lib/coffee_script.rb:1:in `<top (required)>'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `block in require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:240:in `load_dependency'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/coffee-script-2.4.1/lib/coffee-script.rb:1:in `<top (required)>'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `block in require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:240:in `load_dependency'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/coffee-rails-4.1.0/lib/coffee-rails.rb:1:in `<top (required)>'
/home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:82:in `require'
/home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:82:in `block (2 levels) in require'
/home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:77:in `each'
/home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:77:in `block in require'
/home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:66:in `each'
/home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:66:in `require'
/home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler.rb:108:in `require'
/home/adrien/code/linuxfr.org/config/application.rb:6:in `<top (required)>'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:82:in `require'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:82:in `preload'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:143:in `serve'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:131:in `block in run'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:125:in `loop'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:125:in `run'
/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application/boot.rb:18:in `<top (required)>'
/home/adrien/.rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/home/adrien/.rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
-e:1:in `<main>'
Bundler Error Backtrace:
(Bundler::GemRequireError)
from /home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:81:in `block (2 levels) in require'
from /home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:77:in `each'
from /home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:77:in `block in require'
from /home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:66:in `each'
from /home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler/runtime.rb:66:in `require'
from /home/adrien/.rvm/gems/ruby-2.4.1/gems/bundler-1.15.4/lib/bundler.rb:108:in `require'
from /home/adrien/code/linuxfr.org/config/application.rb:6:in `<top (required)>'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:82:in `require'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:82:in `preload'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:143:in `serve'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:131:in `block in run'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:125:in `loop'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application.rb:125:in `run'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/application/boot.rb:18:in `<top (required)>'
from /home/adrien/.rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /home/adrien/.rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from -e:1:in `<main>'
Ah, cette fois-ci, j'ai trouvé le coupable: au début je pensais que c'était coffee-rails, mais comme indiqué dans leur rapport de bug, c'est en fait therubyracer qui doit être en version 0.12.3 pour avoir le support de Ruby 2.4.0.
Maintenant, cette exception n'est plus levée, mais la commande bin/rake db:setup tourne dans le vide.
Quand je l'arrête manuellement, il me donne ces informations:
adrien@bureau-ado:~/code/linuxfr.org$ bin/rake db:setup
^C/home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/client/run.rb:99:in `gets': Interrupt
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/client/run.rb:99:in `verify_server_version'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/client/run.rb:56:in `run'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/client/run.rb:37:in `warm_run'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/client/run.rb:26:in `call'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/client/command.rb:7:in `call'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/client.rb:26:in `run'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/bin/spring:48:in `<top (required)>'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/binstub.rb:11:in `load'
from /home/adrien/code/linuxfr.org/vendor/ruby/2.4.0/gems/spring-1.3.4/lib/spring/binstub.rb:11:in `<top (required)>'
from /home/adrien/.rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /home/adrien/.rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /home/adrien/code/linuxfr.org/bin/spring:13:in `<top (required)>'
from bin/rake:3:in `load'
from bin/rake:3:in `<main>'
Je confirme que c'est assez compliqué pour un développeur qui n'a jamais touché à rails/ruby, même en utilisation l'installation de ruby par rvm indépendamment de la distribution (et le fichier des Gem pour avoir un environnement de modules externes précis).
J'avais réussi à le mettre en place sur une machine avec Debian Stretch cet été, ce qui m'a permis de proposer le patch d'ajout des norloges dans le nouveau design des tribunes (on peut la voir dans l'espace rédaction ; ça a été fusionné à la main, sans utiliser Github). Seulement, je n'ai plus accès à cette machine depuis.
Le weekend dernier j'ai essayé à nouveau d'installer un environnement de développement sur une autre machine avec Debian Buster et j'ai échoué malgré la réussite sur la première machine: la « simple » configuration de la base de donnée tombe déjà en échec avec des exceptions ruby assez incompréhensible pour un néophyte. Je vais tenter encore une installation sur une machine virtuelle Stretch, mais je pense que ça ne résoudra pas le problème.
Mon avis est que Ruby/Rails bouge trop vite pour ne pas décider d'un environnement plus précis que "stable" et un Gemfile.
PS: Oui, un fichier Docker avait été proposé il y a quelques temps, mais il tombe en erreur également et je pense que c'est à cause de cet environnement trop mouvementé.
[^] # Re: Pour Wayland
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Apports de Fedora à l’écosystème du logiciel libre. Évalué à 2.
Ils parlent dans cette page même de casser le système d'extension, je leur suggérerait le système WebExtension pour les prochaines, quitte à faire du JavaScript et du CSS :)
[^] # Re: Pour Wayland
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Apports de Fedora à l’écosystème du logiciel libre. Évalué à 4. Dernière modification le 03 mars 2018 à 08:49.
Si je comprend bien le problème d'architecture est pour Gnome Shell 3 et non pas l'architecture de Wayland, ouf !
De ce que j'ai survolé dans le lien Gnome Shell 4, ils ont les mêmes problèmes que Firefox Quantum est en train de résoudre : il faut absolument alléger au maximum le process principal pour être toujours réactif. Plusieurs solutions existent, notamment, en créant un process de composition dédié, en utilisant encore plus le GPU pour les graphismes et en utilisant au mieux les multiples cœurs du CPU.
Ça va demander d'utiliser un langage tel que Rust pour assurer un code sûr pour le multi process…
Donc, finalement, il faudrait finalement remplacer Gnome Shell 4 par un Firefox Quantum :D On pourrait même l'appeler Firefox Quantum OS !
[^] # Re: differencier un sous domaine du domaine principale
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Modifier ma zone DNS : avoir www.sous-domaine.org. Évalué à 3.
Hello,
En résumé, il faut que tu fasses cette correction sur la dernière ligne:
Dans la première colonne de la ligne
www.srvXest un raccourcis pour direwww.srvX.domaine.org..Quand on définit une entrée DNS, on utilise des noms de domaines complet qui se terminent par un
..Pour simplifier, les logiciels considèrent que si tu ne mets pas de
.à la fin de ton entrée, alors c'est une entrée relative à l'origine du DNS.En supposant que ton origine est bien
domaine.org, alors pour définir une entrée surwww.srvX.domaine.org., tu peux l'écrire de 2 manières:www.srvX 10800 IN CNAME srvXwww.srvX.domain.org. 10800 IN CNAME srvX.domaine.org.[^] # Re: regardes ton certificat
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message SQUID/SQUIDGUARD HTTP Strict Transport Security (HSTS). Évalué à 2.
Il me semble que si un site donne l'indication hsts, alors le navigateur doit vérifier la chaine de certificat complète avec son magasin de certificats racines.
Du coup, quand un site avec hsts actif se retrouve avec un certificat auto signé (ou sur le mauvais domaine), alors l'utilisateur doit voir son accès refusé et il ne peut pas faire d'exception manuelle.
Je ne suis pas sûr que ce comportement est obligatoire, mais c'est bien ce que j'ai vu avec Firefox.
# Ça dépend de ton CA et encore...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Certificat. Évalué à 2.
Hello,
Tu peux techniquement faire autant de certificat que tu veux, même avec des clés privées différentes si tu veux mieux isoler les 2 serveurs/services.
La seule restriction que tu peux trouver proviendrait de ton fournisseur de certificat. Et encore, tu pourrais le feinter en demandant un autre certificat à un autre CA.
Si tu as besoin de deux certificats juste pour changer le format de la chaîne (selon les logiciels, ils ont soit plusieurs fichiers à définir soit un seul avec tout dedans)*, tu peux juste te créer un deuxième fichier à partir de la chaîne et de la clé privée pour se conformer à la configuration de tes services.
J'utilise par exemple un deuxième certificat pour mon serveur SMTP avec le même nom de domaine. Ainsi il peut utiliser un certificat créé à partir d'une clé RSA au lieu de la clé ECDSA que j'utilise d'habitude: ça me permet d'être plus compatible avec les autres serveurs de mail.
*: je pense à ejabberd par exemple qui a besoin que la chaine et la clé privée soient dans le même fichier, si je me souviens bien
# Mettre à jour la procédure de démarrage
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message systemd et ordre de démarrage. Évalué à 0.
Hello,
Si je me souvuens bien, la commande systemctl daemon-reload demande juste à systemd de relire les fichiers de configuration.
Le plus souvent, il faut juste redémarrer le service ensuite. Mais comme tu modifies les dépendances de démarrage, il faudrait aussi faire un systemctl disable et systemctl enable.
En effet, ce sont ces 2 dernières commandes qui gèrent les liens entre services en créant les répertoires "services.wants" dans /etc/systemd/system.
[^] # Re: vocabulaire
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Retour d'expérience Nextcloud. Évalué à 4.
Ce que je ne comprends pas vraiment, c'est pourquoi tu insistes pour utiliser wedav1 ?
De mon expérience avec le module mod_dav d'Apache2 et aussi le module d'Owncloud à l'époque (vers 2013, en utilisant Nautilus et/ou un montage dav2fs pour la partie client), ça ne marche pas hyper bien, les clients donnent des erreurs incompréhensibles au bout d'un moment (style, "Serveur indisponible", "verrou actif sur le fichier", alors que j'étais juste en train de naviguer à travers les dossiers et que je suis le seul à utiliser ces dossiers; maintenant que j'y pense, il faut sûrement donner des instructions spéciales au serveur web pour la gestion du protocole HTTP dans ce cas, car il va y avoir beaucoup de requêtes et que ce n'est pas vraiment le comportement par défaut attendu pour des clients HTTP).
Le client de synchronisation quant à lui est clairement intéressant, puisqu'il ne surcharge pas le serveur web avec des requêtes HTTP fréquentes pour simplement naviguer à travers les fichiers. Le système de fichier local est efficace pour rechercher à travers les méta-données des fichiers et, si tu utilises des logiciels comme Tracker/Baloo, ils sont complètement fonctionnels (à l’exception du fait que Nextcloud ne synchronise pas les extended attributes).
Le client est capable d'écouter les modifications sur le poste local pour les envoyer au serveur. Dans l'autre sens, il retrouve automatiquement les modifications du serveur pour les appliquer en local. Seul les données modifiées passent à travers le réseau et donc la bande passante, la RAM et le CPU du serveur sont largement moins utilisées qu'avec le webdav.
En plus, seul le client est compatible avec le nouveau chiffrement end-to-end (E2E, client-à-client) annoncé en fin d'année 2017: https://nextcloud.com/blog/nextcloud-introducing-native-integrated-end-to-end-encryption/ (voir les commentaires).
Pour le chiffrement côté serveur, c'est bien écrit dans la documentation que son seul intérêt est pour l'envoi des données sur des "Remote Share" (style Google Docs, Dropbox, …):
Or souvent, le but est d'utiliser Nextcloud est de se détacher de ces services, donc ça ne me surprend pas que peu de monde active ce chiffrement.
J'utilise Nextcloud sur un laptop Acer acheté à l'époque de Windows Vista: Nextcloud ne consomme quasiment rien sur mon serveur (mais bon, évidemment, il n'est pas constamment en train de gratter les disques et envoyer des données puisque je n'utilise la fonctionnalité webdav qu’occasionnellement). C'est surtout Gitlab qui se goinfre de CPU et de RAM chez moi, mais c'est gérable grâce aux limitations de ressources par service proposées par les slice de systemd.
1 Note bien que je ne parle que de webdav, car c'est lui qui utilise le plus de ressources pour communiquer (CPU, RAM, bande passante) à cause de la nature et de la quantité de données: caldav et carddav ont beaucoup moins d'impact sur ces ressources, car les données finales à transmettre sont beaucoup plus petites que des milliers de fichiers.
[^] # Re: Montage webdav/davfs2
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Retour d'expérience Nextcloud. Évalué à 3.
Si je me souviens bien, XFCE n'a pas de gestionnaire de compte centralisé commme gnome-online-account qui se cache derrière gnome-control-center). Il te faudra donc trouver des outils qui connaissent caldav, carddav, webdav et tous les configurer à la main.
Pour caldav et carddav, Evolution sait gérer, mais tu devras configurer chaque calendrier et chaque carnet d'adresse à la main. Il y a aussi Thunderbird, mais il faut utiliser l'extension SoGo.
Pour webdav, c'est géré par gnome-vfs qui est utilisé par Thunar si mes souvenirs sont bon.
[^] # Re: Montage webdav/davfs2
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Retour d'expérience Nextcloud. Évalué à 4. Dernière modification le 30 décembre 2017 à 00:19.
Pour l'environnement GNOME 3 (donc Debian et Ubuntu récentes), oui, il suffit d'ajouter un compte "Owncloud" ou "Nextcloud" (les 2 systèmes sont compatibles) dans les paramètres "Comptes en ligne". Ça configure automatiquement le backend d'Evolution pour synchroniser les calendriers par caldav et les contacts par carddav.
Comme c'est le backend Evolution, tu peux ensuite utiliser en frontend soit Evolution, soit Gnome Calendar, soit Gnome Contact pour accéder à tes infos (voir même California qui était développé par Yorba, mais dont je ne sais pas si des mainteneurs ont repris le projet).
PS: même que le racourci webdav est automatiquement ajouté à Nautilus et Gnome Documents peut faire des recherches directement avec les mineur en ligne de Tracker.
[^] # Re: Liens d'après-streaming
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal ZeMarmot lance un petit programme de streaming régulier!. Évalué à 2.
Ce commentaire donne les liens des sauvegardes des premiers streams.
Le streaming en direct est apparemment dispo ici : https://www.youtube.com/c/LibreArtInfo/live
Pour le terme "vrai streaming" : je ne vois pas bien de quoi tu veux parler. Toutes les vidéos YouTube sont lues en direct dans les navigateurs, donc streamée. Est-ce que tu voulais parler de streamer sur UDP directement ?
[^] # Re: Failles de sécurités connes pour Firefox 57
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Firefox Quantum, première partie du projet Quantum de Mozilla, est disponible. Évalué à 3. Dernière modification le 10 décembre 2017 à 05:56.
Ahaha, bien vu, je n'ai pas relu les titres des liens :)
[^] # Re: Version spéciale Google ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Firefox Quantum, première partie du projet Quantum de Mozilla, est disponible. Évalué à 4.
Si je me souviens bien, la barre de recherche reste après une mise à jour. C'est l'interface par défaut de Firefox qui ne la présente plus, mais elle reste présente dans les outils de personnalisation.
# Proposer 2 liens ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Lien vers les commentaires depuis le flux atom. Évalué à 2 (+0/-0).
Je garderai le texte « Lire les commentaires » pour la lecture direct sur le web et j'ajouterai un second bouton « Suivre les commentaires » pointant vers le flux atom.
Ça reflétera mieux à mon avis l'action exécutée par le lien, non ?
[^] # Re: Ca change !
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Un nouveau moteur de rendu ultra‐rapide pour Firefox : Quantum Render. Évalué à 10. Dernière modification le 17 novembre 2017 à 15:43.
C'est juste que l'article anglophone est très long et qu'il nous a fallu pas mal de temps pour la finaliser.
Cette dépêche ne parle pas d'amélioration de la version 57, mais de prochaines améliorations.
Firefox 57 a le nouveau moteur CSS Stylo et les prochaines versions verront arriver le nouveau moteur de rendu WebRender.
En effet, dans la dernière section, c'est écrit:
[^] # Re: Bug
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Afficher de manière réduite les pages wiki sur le système d'accueil. Évalué à 3 (+0/-0).
En effet ça fait un peu bizarre, mais je vois mal comment on pourrait garder un outil simple pour calculer où couper le code HTML et comprendre en même temps la langue française et/ou anglaise :)
Si tu regardes un peu les détails du patch, tu verras que je n'ai rien inventé de nouveau: j'ai juste demander d'appliquer les mêmes règles que sur les autres contenus (journeaux et forum si je me souviens bien).
[^] # Re: Pull request crée sur Github
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Afficher de manière réduite les pages wiki sur le système d'accueil. Évalué à 2 (+0/-0).
Cool, merci pour la réactivité :-)
[^] # Re: Pull request crée sur Github
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Afficher de manière réduite les pages wiki sur le système d'accueil. Évalué à 2 (+0/-0).
Oups, j'ai oublié le lien Github: https://github.com/linuxfrorg/linuxfr.org/pull/216
[^] # Re: Pull request crée sur Github
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Afficher de manière réduite les pages wiki sur le système d'accueil. Évalué à 3 (+0/-0).
Le code est assez nouveau pour moi, mais à mon avis c'est que parser du HTML pour retrouver les 80 mots affichables et le tronquer correctement est assez couteux pour le serveur.
Je vois donc cette colonne comme un cache pour le contenu tronqué.
En plus, comme le contenu bouge peu une fois publié, c'est quand même plus efficace de faire ce calcul une seule fois au lieu de le calculer à la volée pour tous les utilisateurs, visiteurs et robots.
Une autre solution serait de tronquer côté client avec du CSS (ou au pire JavaScript), mais ça me semble moins efficace en bande passante et plus difficile à maîtriser pour retrouver le 80ieme mot à afficher.
# Pull request crée sur Github
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Afficher de manière réduite les pages wiki sur le système d'accueil. Évalué à 3 (+0/-0).
Hello,
J'ai trouvé comment faire une solution en réutilisant le code existant déjà pour les journaux.
Ça demande une modification en base de donnée de la table wiki_pages pour ajouter une colonne avec un contenu tronqué à 80 mots (ce contenu est calculé automatiquement à chaque modification du contenu principal).
Le résultat donne assez bien, pour dire que je n'ai quasiment rien crée de nouveau:
Il y a juste une truc marrant, c'est que les liens vers linuxfr dans les contenus de wiki contiennent le favicon de linuxfr à côté. Du coup, ici on se retrouve avec ce favicon à côté du lien
(...).Personnellement, ça ne me dérange pas, mais pensez-vous que ça va créer une entrée de suivi pour corriger ça ?
# Faire une mise à jour étape par étape avec jessie-backports et jessie-backports-sloppy
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Upgrade de debian jessie à stretch. Évalué à 2.
Hello,
Pour la configuration des fichiers, tu seras forcé de les mettre à jour avec les évolutions des différents programmes. En effet, des options apparaissent/disparaissent… Debian n'y peut rien.
C'est quelque chose de très chronophage. Par contre, si tu as de la chance comme moi, certains de tes logiciels critiques seront déjà disponibles dans une version proche de Stretch grâce aux dépôts de jessie-backports et/ou jessie-backports-sloppy (sloppy est un backports qui évolue encore pour old-stable).
Ces dépôts te permettent de mettre à jour un logiciel après l'autre sans devoir modifier toutes les configurations de tous les logiciels en même temps.
Par exemple, grâce à Backports, ma migration du serveur XMPP ejabberd et du serveur mail Exim ont été très simple, puisque j'avais déjà les versions de Stretch sur mon serveur Jessie.
Tu noteras dans mon poste, que même si ça simplifie, ça ne suffit pas pour t'assurer que tout se passera bien: même si ejabberd avait la même version, une de ses dépendances a été mise à jour sur Stretch: openssl est passé à la version 1.1, ce qui a cassé le lien entre ejabberd et openssl avec l'utilisation de certificats ECC.1
En fait, le plus simple, si tu en as les moyens, c'est d'avoir une machine de test pour tester la mise à jour et déjà prévoir les changements de configuration que tu devras faire.
Bonne chance !
1 : évidemment j'ai fait un rapport de bug à Debian, j'ai proposé un rétro-portage du patch upstream et le fix est intégré à Debian depuis la mise à jour de Septembre <3
[^] # Re: Et maintenant ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Exceptions lors de la création d'un environnement de développement. Évalué à 2 (+0/-0).
Chouette, ça a marché, merci !
Désolé pour le dérangement avec cette nouvelle version de Ruby…
Il faudrait peut-être modifier le fichier README pour ne pas conseiller d'installer la version stable de Ruby, mais plutôt une version exacte ?
[^] # Re: Et maintenant ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Exceptions lors de la création d'un environnement de développement. Évalué à 3 (+0/-0).
Ça va un peu mieux, mais l'exception est toujours là:
Ah, cette fois-ci, j'ai trouvé le coupable: au début je pensais que c'était coffee-rails, mais comme indiqué dans leur rapport de bug, c'est en fait therubyracer qui doit être en version 0.12.3 pour avoir le support de Ruby 2.4.0.
Je viens de faire un pull request sur la branche before-redesign pour appliquer cette modification au Gemfile et au Gemfile.lock: https://github.com/linuxfrorg/linuxfr.org/pull/215
Maintenant, cette exception n'est plus levée, mais la commande
bin/rake db:setuptourne dans le vide.Quand je l'arrête manuellement, il me donne ces informations:
[^] # Re: LinuxFR.org semble développé par ~1 personne, des impacts ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 7.
Je confirme que c'est assez compliqué pour un développeur qui n'a jamais touché à rails/ruby, même en utilisation l'installation de ruby par rvm indépendamment de la distribution (et le fichier des Gem pour avoir un environnement de modules externes précis).
J'avais réussi à le mettre en place sur une machine avec Debian Stretch cet été, ce qui m'a permis de proposer le patch d'ajout des norloges dans le nouveau design des tribunes (on peut la voir dans l'espace rédaction ; ça a été fusionné à la main, sans utiliser Github). Seulement, je n'ai plus accès à cette machine depuis.
Le weekend dernier j'ai essayé à nouveau d'installer un environnement de développement sur une autre machine avec Debian Buster et j'ai échoué malgré la réussite sur la première machine: la « simple » configuration de la base de donnée tombe déjà en échec avec des exceptions ruby assez incompréhensible pour un néophyte. Je vais tenter encore une installation sur une machine virtuelle Stretch, mais je pense que ça ne résoudra pas le problème.
Mon avis est que Ruby/Rails bouge trop vite pour ne pas décider d'un environnement plus précis que "stable" et un Gemfile.
PS: Oui, un fichier Docker avait été proposé il y a quelques temps, mais il tombe en erreur également et je pense que c'est à cause de cet environnement trop mouvementé.
[^] # Re: Coquille
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Firefox fait des vannes pour sa version 56. Évalué à 3. Dernière modification le 15 octobre 2017 à 22:13.
Oui, mais c'est aussi de ma faute, car j'ai fait beaucoup de changements hier soir avant de relire et publier.
La prochaine fois, j'attendrai d'être le lendemain à tête reposée pour faire la relecture, désolé pour les désagréments.
[^] # Re: Capture de page
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Firefox fait des vannes pour sa version 56. Évalué à 9.
Pour faire, une capture complète, je fais ça: