Portail Ezvan

Fin du service RSS

Paul — Mon, 10 Nov 2025 20:00:00 +0100

J'ai décidé de suspendre le service RSS proposé sur Ezvan.fr par le biais de Tiny Tiny RSS. En effet le paquet Debian n'est plus à jour et a été supprimé de la dernière version stable de Debian "Trixie", rendant la maintenance compliquée.

Je compte désactiver le service dans un mois environ.

Vous pouvez exporter votre liste d'abonnement RSS en allant dans "Configuration/OPML" et en cliquant sur "Exporter en OPML". Cela permet d'exporter votre liste d'abonnement vers d'autres lecteurs RSS.

Firefox, économiseur d'écran et Xfce

Paul — Sun, 08 Jan 2023 18:00:00 +0100

Comment un bogue énervant m'a conduit à contribuer à Firefox.

Contexte

J'ai la fâcheuse manie de changer l'environnement de bureau de mon ordinateur tous les 6 mois à peu près. À cette occasion, j'utilise régulièrement Xfce dont la simplicité et légèreté me plaisent.

Lors de mon dernier essai, je remarque un comportement fâcheux : l'écran se met en veille lorsque je visionne une vidéo Youtube avec Firefox. Encore une fâcheuse manie !

On creuse

Je profite de l'occasion pour creuser le problème et voir si je peux le résoudre. Après quelques recherches, je trouve un rapport de bogue similaire à mon problème, lié au composant xfce4-power-manager.

Le mainteneur de projet suggère que Firefox n'appelle pas la bonne interface D-Bus lorsqu'il veut inhiber la mise en veille de l'écran. D-Bus est un démon qui permet de faire communiquer différents programmes entre eux, via des interfaces pré-définies. Le problème n'apparait pas avec Chromium, qui doit certainement faire quelque chose de différent !

Hacker Firefox

Je plonge donc dans les entrailles de Firefox. Je trouve le fichier qui s'occupe de cette fonctionnalité : WakeLockListener.cpp. Je compare avec le code qui remplit la même fonction chez Chromium pour avoir une meilleure idée de ce qui peut mal fonctionner : power_save_blocker_x11.cc.

Je remarque que Chromium appelle toutes les fonctions D-Bus connues comme désactivant la mise en veille en même temps. Par contre, Firefox les appelle dans l'ordre, et s'arrête dès qu'un appel est concluant.

De plus, Firefox n'appelle pas l'interface utilisée par le composant xfce4-power-manager, celle-ci étant : org.freedesktop.PowerManagement.Inhibit.

J'essaie donc de modifier le comportement de Firefox pour ajouter cet appel. Comme changer le comportement de Firefox pour suivre celui de Chromium me semble un trop grand changement, j'essaie plus simplement d'ajouter le bon appel.

J'arrive à faire fonctionner et tester la modification sur mon ordinateur. Je soumets un rapport de bogue à Firefox ainsi qu'une pull request avec ma modification.

Un des mainteneurs de Firefox demande quelques modifications, que j'effectue. Il valide ensuite mon changement et l'intègre dans la branche principale. Hourra !

Déception

J'attends que la version 95 de Firefox soit publiée, qui contiendra alors mon changement. Et là, patatras ! Il manque quelque chose, mon écran s'éteint toujours lorsque je regarde une vidéo. J'ai raté quelque chose lors de mes tests !

Je me replonge dans le problème. Il me semble qu'il manque quelque chose dans xfce4-power-manager. En effet, le démon reçoit bien la demande d'inhibition de l'écran. Mais il manque l'appel pour inhiber l'écran dans la fonction qui gère la demande !

Je crée donc une nouvelle pull request, cette fois pour xfce4-power-manager, afin d'ajouter cet appel manquant.

Tout est bien qui finit bien

Finalement tout fonctionne chez moi ! Mais encore faut-il attendre que ma pull request soit acceptée et une nouvelle version de Xfce soit publiée avec le correctif.

Après quelques modifications, la pull request est acceptée. Elle est intégrée dans la version 4.18 de Xfce, qui sortira 11 mois plus tard.

Tout semble fonctionner dorénavant, et il ne semble pas avoir cassé quelque chose. Quelqu'un se serait plaint sinon !

Interpréteur BASIC

Dominique — Sun, 02 Jan 2022 22:00:00 +0100

Papa a profité de sa retraite pour porter sous Windows l’interpréteur BASIC, dénommé SBASIC, qui était fourni avec les ordinateurs GOUPIL sous FLEX et MS/DOS. Si la plupart des BASIC sont devenus des compilateurs, SBASIC est resté un interpréteur très performant.

SBASIC profite des avantages d’un interpréteur : mode immédiat (exécution immédiate des instructions saisies au clavier) et mode programme, édition d’un programme durant son exécution, exécution d’instructions définies dynamiquement dans des chaines de caractères, auto-modification du programme, mise au point interactive, etc.

La compatibilité avec les programmes existants est conservée. Ainsi les fonctionnalités avancées du SBASIC, comme les tableaux à dimensions multiples, les tableaux virtuels, les étiquettes, les appels de fonctions avec paramètres, les variables locales sont supportés. SBASIC sous Windows profite cependant des apports du 32 bits avec : variables entières sur 32 bits, taille mémoire programme et données jusqu’à 2 Giga-octets, nombre d’éléments d’un tableau et nombre d’enregistrements dans un fichier jusqu’à 2^31, longueur chaines de caractères limitée par la mémoire disponible.

Sous Windows, SBASIC profite de nouvelles fonctionnalités : dimensionnement des fenêtres texte et graphique, copie d’un rectangle graphique en format BMP depuis et vers une chaine de caractères, sauvegarde et restauration d’une chaine de caractères dans un fichier, appel de fonctions dans une librairie dynamique (DLL), exécution en pas à pas.

SBASIC est disponible en deux versions : fenêtre Windows ou ligne de commande. Sur le site sbasic.org vous trouverez la documentation, les exécutables, des exemples, des jeux ainsi que des DLLs avec leur source.

Utiliser pg_dump avec Docker

Paul — Sun, 02 Jan 2022 19:00:00 +0100

Je suis en train de migrer Tiny Tiny RSS depuis AWS vers un serveur dédié. Pour ce faire j'essaie d'effectuer un dump de la base de donnée (stockée dans RDS) depuis une machine Debian Buster. Malheureusement pg_dump échoue car la version fournie par Debian est trop ancienne !

% pg_dump -h db2.ezvan.fr -U ttrss -W ttrss > ttrss-20220102.sql
Password: 
pg_dump: server version: 12.7; pg_dump version: 11.14 (Debian 11.14-0+deb10u1)
pg_dump: aborting because of server version mismatch
zsh: exit 1     pg_dump -h db2.ezvan.fr -U ttrss -W ttrss > ttrss-20220102.sql

Docker à la rescousse

Je pourrais mettre à jour ma version de Debian pour obtenir un version plus récente de pg_dump, mais une telle migration serait chronophage. Une solution plus simple est d'utiliser Docker pour exécuter la version de pg_dump qui convient.

Installation de Docker

Attention sous Debian le nom du paquet Docker est docker.io !

sudo apt install docker.io

J'ajoute mon utilisateur au groupe docker. Je me reconnecte ensuite afin d'utiliser les nouvelles permissions.

sudo usermod -aG docker user

Je démarre le démon Docker.

sudo systemctl start docker

Lancer pg_dump

Je lance pg_dump dans un conteneur Docker. J'utilise l'image postgres en spécifiant la version 12. Vous pouvez trouver la documentation de l'image sur Docker Hub.

docker run -i --rm postgres:12 pg_dump -h db2.ezvan.fr -U ttrss -W ttrss > ttrss-20220102.sql

J'utilise le paramètre -i pour pouvoir entrer un mot de passe si nécessaire. Attention, ne pas utiliser le paramètre -t, car cela peut faire échouer le dump car les caractères fin de ligne (EOL) sont interprétés et bloquent la commande.

Podman, volume et SELinux

Paul — Mon, 26 Apr 2021 20:00:00 +0200

En ce moment j’expérimente avec Rust, le langage de programmation à la mode. Ayant compilé mon programme expérimental sur mon système Fedora, je l’envoie à un ami. Quelle déception quand il me dit que mon programme répond mal :

/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not `found

Rust compile avec la version de la librairie glibc de mon système, qui est trop récente et pas compatible avec Ubuntu. Je dois donc compiler avec un système plus ancien. Pas de panique les conteneurs sont parfaits pour ça !

Comme je travaille avec Fedora, j’utilise Podman qui est un équivalent à Docker pour créer mon conteneur.

Je tente ainsi, mais c’est l’échec :

% podman run --rm -v "$PWD":/usr/src/ -w /usr/src/ rust cargo build --release 
error: could not find `Cargo.toml` in `/usr/src` or any parent directory
zsh: exit 101   podman run --rm -v "$PWD":/usr/src/ -w /usr/src/ rust cargo build --release

D’où vient cette erreur ? Je tente de lire le répertoire depuis le conteneur :

% podman run --rm -v "$PWD":/usr/src/ rust ls /usr/src
ls: cannot open directory '/usr/src': Permission denied
zsh: exit 2     podman run --rm -v "$PWD":/usr/src/ rust ls /usr/src

Je ne peux pas lire le répertoire partagé dans un volume par Podman.

Mais pourquoi donc ? J’utilise Fedora, et donc SELinux est activé par défaut. SELinux est un module de sécurité qui permet de définir des politiques de contrôle d’accès aux éléments du système. Il peut, entre autre, restreindre les accès au système du fichier en fonction du contexte. Il faut donc donner permission au conteneur d’accéder au volume !

Pour ce faire il suffit d’ajouter une option :z ou :Z à la configuration du volume. L’option z permet à plusieurs conteneurs de partager le volume. L’option Z ne permet l’accès qu’à un seul conteneur. Tous les détails sont donnés dans man podman-run !

Je n’ai pas besoin de partager le volume, j’opte donc pour :Z.

Voici le résultat:

% podman run --rm -v "$PWD":/usr/src/:Z -w /usr/src/ rust cargo build --release
    Updating crates.io index
 Downloading crates ...
    Finished release [optimized] target(s) in 24.60s

Cette fois cela fonctionne, j’ai bien compilé mon programme à l’aide du conteneur rust !

Date d’expiration du certificat SSL d’un serveur XMPP

Paul — Wed, 31 Mar 2021 09:00:00 +0200

Voici une astuce rapide pour vérifier la date d’expiration du certificat SSL d’un serveur XMPP. On utilise le client openssl en lançant openssl s_client pour initier une connexion TLS au serveur, pour cela on lui donne -starttls xmpp comme paramètre pour lui indiquer le protocole à utiliser.

On transmet le résultat via un pipe | à la commande openssl x509 qui permet d’analyser le certificat fourni. X.509 est en effet la norme établissant le format de ces certificats. Le paramètre -dates indique spécifiquement d’afficher les dates de validité du certificat.

~% openssl s_client -connect mail.ezvan.fr:5222 -starttls xmpp -xmpphost ezvan.fr | openssl x509 -noout -dates
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = ezvan.fr
verify return:1
notBefore=Mar 31 07:08:59 2021 GMT
notAfter=Jun 29 07:08:59 2021 GMT

Apple, ARM and open platforms

Paul — Thu, 19 Nov 2020 21:00:00 +0100

New Apple M1 based computers are getting reviewed by hardware websites. There is no doubt: it is a big slap in the face of their venerable x86 competitors in terms of performance and efficiency.

A revolution

Is it the beginning of a new era in which our smartphones and personal computers would use the same ARM technology, which has powered smartphones since their beginnings?

Smartphones have taken over our world. They are everywhere, and required by more and more operations : validating banking transactions, payments, private and public transportation, etc.

It is a bigger revolution than the personal computer, which brought Internet and computing to mostly everybody.

History repeats

However there is a major difference in how they get there to what happened with personal computers.

At their beginnings many companies, such as Amiga, Apple or Atari, were competing with different operating systems and processor architectures. Platforms were not compatible with each other, you couldn't run an Amstrad program on an Apple computer. Then the PC platform started to take off.

PC strength was that it is an open platform. An operating system and its software, running on a given PC compatible computer, would run on any other PC computer. Today the majority of personal computers are PC compatible, with the big exception of Apple hardware.

This enabled the success of Windows and then Linux. Other less common PC systems are able to run on wide range of PC computers, such as various Unix and BSDs.

A closed world...

ARM is a different world in which there is no platform definition. It is difficult if not impossible to run an Iphone's system on an Android phone, or vice versa. It is even difficult to run a Samsung phone system on another brand's phone, even if both are Android based.

This makes it very challenging to build alternative smartphone operating systems. Projects such as LineageOS are trying to provide alternatives to the manufacturer ones, but they require a large porting work for each device.

As well initiatives such as postmarketOS, which allows running a real Linux system on a smartphone exist, but the porting challenge is so huge that only a handful of devices are supported.

For a locked future ?

Apple went down the same road with its Macbooks, providing hardware and software in an integrated platform. Installing something else than MacOS on a recent Macbook is possible, but requires a lot of effort.

Iphones are completely locked. You can't install any other system on them. There is even no way you can install apps which are not approved by Apple on an Iphone. Will Apple take advantage of the ARM transition on its Macbooks to impose the same restrictions?

If it does, will we trade the freedom of running the software we want with much better performance and efficiency? Will the fully locked down smartphone model overtake the open PC platform one?

Will we allow only fully locked systems become essential tools of our lives?

ARM is the future

Paul — Thu, 19 Nov 2020 20:00:00 +0100

ARM processors are everywhere! There are the heart of the smartphones, TVs, Wifi routers, 5G networks, etc.

However in our personal computers, x86 based processor still largely prevail, even if x86 was invented more than fifty years ago. It is also the case in the datacenter world, nicely called cloud nowadays.

Times are changing. Major actors such as Amazon and Apple are embracing ARM to put their dependency on Intel to an end. As ARM only defines the architecture of the CPU, many companies are competing in building ARM powered chips. That allows breaking Intel's near monopoly on personal and datacenter computers.

Are we at the dawn of a new era, where ARM would fully replace the good old x86?

An another precursor has joined the game, as Ezvan.fr was migrated to ARM recently. Faster and cheaper, is there more to ask for?

Apple, ARM et plateforme ouverte

Paul — Tue, 17 Nov 2020 20:00:00 +0100

Les nouveaux ordinateurs Apple basés sur le processeur M1 commencent à être testés par différents sites spécialisés en hardware. Le verdict est sans appel : c'est une claque de performance et efficacité sans précédent pour ses vénérables concurrents.

Une révolution ?

Est-ce l'avènement d'une nouvelle ère où nos smartphones et ordinateurs personnels utiliseront tous la même technologie ARM, que les smartphones utilisent depuis leurs débuts ?

Les smartphones ont envahi notre monde. Ils sont partout, et nécessaires pour de plus en plus d'opérations : validation d'opérations bancaires, paiements, tickets de transport, services de transport urbain, etc.

C'est une révolution encore plus forte que celle de l'ordinateur personnel, qui a généralisé l'accès à l'informatique et à Internet.

L'histoire bégaie

Il y a pourtant une différence majeure avec les ordinateurs personnels.

Au début de ceux-ci, de nombreux fabricants étaient en compétition, comme Amiga, Apple et Atari, avec des architectures et systèmes différents. Il n'y avait que peu d'interopérabilité entre les différents ordinateurs disponibles. Puis a emergé la plateforme PC, qui devint rapidement un standard de facto.

La grosse force de cette plateforme est son ouverture. Un système fonctionnant sur PC peut fonctionner sur tous les ordinateurs compatibles PC. La majorité des ordinateurs sont compatibles PC à l'exception notable des machines Apple.

Cela a permis le succès de Windows puis Linux. D'autres systèmes compatibles PC pourtant moins répandus peuvent ainsi fonctionner sur de nombreux ordinateurs, comme les différents Unix et BSD.

Un monde fermé

Le monde ARM est très différent, car il n'y a pas de plateforme définie. Il est très difficile voire impossible de faire fonctionner le système d'un iPhone sur un téléphone Android, et vice-versa. Il est de même très difficile de faire fonctionner le système d'un téléphone Samsung sur un téléphone d'une autre marque.

C'est une grande difficulté pour créer des systèmes alternatifs fonctionnant sur des smartphones. Il existe des projets comme LineageOS proposant des systèmes Android alternatifs pouvant remplacer celui fourni par le constructeur, mais ils nécessitent un important travail de portage pour chaque téléphone.

De même il existe des initiatives telles que postmarketOS permettant de faire fonctionner un vrai système Linux sur son smartphone, mais de grandes difficultés de portage ne permettent de le faire que sur une liste réduite de téléphones pour lesquels un long travail a été nécessaire.

Pour un futur verrouillé ?

Apple avec ses Macbook s'est engagé dans la même voie, fournissant matériel et logiciel dans une plateforme liée. Installer un autre système sur un Macbook récent est possible, mais requiert beaucoup d'efforts.

Ses Iphones sont complètements verrouillés. Impossible d'y installer un autre système. Impossible d'y installer des applications non autorisées par Apple. Apple va-t-il profiter du passage à ARM sur ses Macbook pour y imposer les mêmes contraintes ?

S'il le fait, échangerons-nous de meilleures performances contre la liberté de choisir ses logiciels ? Le modèle du smartphone fermé finira-t-il par vaincre celui du PC ouvert ?

Laisserons-nous des systèmes complètement fermés être des outils indispensables à nos vies ?

ARM le futur

Paul — Sat, 14 Nov 2020 00:00:00 +0100

Les processeurs ARM sont partout ! Ils sont au cœur de nos smartphones, télévisions, box Internet, antennes 5G, etc.

Pourtant dans nos ordinateurs personnels, ils sont toujours largement dominés par le bon vieux x86, inventé par Intel il y a plus de cinquante ans. C'est également le cas dans le monde des serveurs, joliment appelé cloud de nos jours.

Mais les temps changent. De très gros acteurs comme Amazon et Apple embrassent l'ARM pour ne plus dépendre d'Intel. En effet ARM ne définit que l'architecture du processeur, de nombreux constructeurs produisent des puces l'utilisant. Cela permet donc de s'affranchir du quasi monopole d'Intel sur les processeurs de PC et serveurs.

Serait-on à l'aube d'une nouvelle ère, où ARM remplacerait totalement le vénérable x86 ?

Signe avant-coureur, un autre acteur majeur, Ezvan.fr a effectué sa migration vers ARM récemment. Plus rapide et moins cher, que demander de plus ?