↩ Accueil

Vue normale

Reçu aujourd’hui — 28 mai 2025

Un serveur musical pour mon salon

28 mai 2025 à 11:08

Aujourd’hui, on va mettre en place un serveur musical pilotable à distance en utilisant MPD. Il sera notamment capable de jouer de la musique stockée dessus ou des radios Internet. Il sera aussi capable de se comporter comme une enceinte Bluetooth.

On va parler de récup de vieux matos, de Debian, MPD, PipeWire, Samba, d’agent Bluetooth, de systemd (-analyze, -logind), de Powertop et de vbetool.

Serveur musical - les clients MPD se connectent à MPD, les clients Bluetooth peuvent jouer de la musique, les clients SMB peuvent envoyer des fichier, et le serveur est relié à des enceintes en Jack

Cet article au ton très « administration système » s’adresse à :

  • des gens qui voudraient mettre en place un système plus ou moins similaire, même pour faire autre chose dans le même esprit (en mode tutoriel) ;
  • des gens qui aiment les détails techniques et voir les trucs cools qu’on peut faire avec les logiciels libres ;
  • toute autre personne curieuse pour d’autres raisons.

Il est probablement trop technique pour quelqu’un qui ne manipule pas la ligne de commande, qui pourra peut-être malgré tout, avec suffisamment de motivation, se laisser porter par la démarche.

Sommaire

Introduction

Note de lecture : cette dépêche est très détaillée, je vous conseille de passer les sections qui vous intéressent moins.

Motivation

Dans mon salon, j’ai des petites enceintes toutes bêtes qui sonnent plutôt bien. Mettre de la musique implique de s’embêter à brancher un ordinateur, sur lequel je suis le seul avoir le contrôle. Ce serait bien d’avoir un système prêt à l’emploi et que tout le monde peut contrôler.

Objectifs

  • Pas d’achat : on fait avec de la récup
  • Peu gourmand en énergie
  • Silencieux (à part la musique, bien sûr)
  • Facile à utiliser pour une personne non technique
  • Pouvoir mettre de la musique sans que ça soit pénible, en utilisant ma bibliothèque musicale locale, ou des radios internet
  • Pouvoir laisser n’importe qui se connecter en Bluetooth et lancer sa propre musique

Nous allons, ensemble, remplir ces objectifs. On va rentrer dans les détails, qui peuvent être utiles dans d’autres applications, et parce que je sais que certaines personnes ici aiment ça, bande de geeks :-)

Matériel à disposition

  • des enceintes parfaitement fonctionnelles mais sans fonctionnalité Bluetooth
  • un appareil style netbook du début des années 2010 (dans mon cas, c’est une vieille tablette Airis Kira Slimpad plus vraiment adaptée au web moderne, dotée d’un processeur Intel Atom un peu lent, d’un peu de stockage assez lent, d’un Wifi plutôt lent, du Bluetooth, d’1 Giga de mémoire vive)

Note sur les interférences Wifi et Bluetooth. Le Wifi de cette tablette est en 2,4 GHz, pareil que le Bluetooth. Tout échange wifi cause des perturbations sur le Bluetooth et tout transfert intensif rend le Bluetooth inutilisable. Du grand classique. Un Wifi 5, 6 ou 7 aurait été appréciable. Il serait possible d’utiliser une carte Wifi USB, mais je n’en ai pas donc on fera sans.

Ce qu’on va faire dans les grandes lignes

  • Installer une Debian minimale
  • La configurer pour qu’elle soit accessible par le réseau, la plus rapide et légère possible en utilisation mémoire, en temps de démarrage et en consommation énergétique
  • Installer et configurer MPD
  • Installer et configurer Samba
  • Configurer en mode « enceinte Bluetooth »

Installation standard minimaliste de Debian

Par souci de concision, on ne va pas détailler l’installation de Debian, il existe d’autres ressources au besoin.

En résumé :

  • Debian classique en 32 bits (ça consomme moins de mémoire que du 64 bits)
  • j’ai laissé l’installateur faire le partitionnement (une partition principale en ext4, et une partition swap de 1G)
  • j’ai ajouté l’option noatime sur la partition principale pour éviter d’écrire inutilement lors des accès, ce qui use le SSD et ralentit le système (d’autant que le SSD est lent)
  • lors de l’étape Tasksel, choisir console, serveur ssh et utilitaires standard, et en particulier pas d’environnement de bureau
  • on installe sudo et on ajoute l’utilisateur au groupe sudo, ou alors on se donne accès à root en ssh avec une clé SSH
  • on installe iwd (le remplaçant moderne de wpa_supplicant, supposé plus performant et plus stable permettant également de se passer de NetworkManager assez facilement) et on connecte l’appareil en wifi avec
  • on identifie et désactive ou on désinstalle le superflu avec systemd-analyze critical-chain et systemd-analyze blame (typiquement, si vous avez installé NetworkManager, ModemManager a peut-être été installé alors que vous n’avez pas de modem à gérer)
  • on peut configurer le menu de Grub pour moins attendre au démarrage

Note : sur cette tablette, l’installateur Debian n’arrive pas à se connecter en Wifi, j’ai donc utilisé la version DVD (le premier suffit).

Gains énergétiques potentiels

Éteindre l’écran

L’écran est potentiellement une des plus grosses sources de consommation électrique. On n’en a pas besoin, donc on va l’éteindre au démarrage et à la sortie de veille.

Pour cela, on va installer vbetool (sources : outils pour éteindre l’écran, lancer une commande au démarrage, lancer une commande après la veille):

sudo apt install vbetool
cat << EOF | sudo tee /etc/systemd/system/screenoff.service
[Unit]
Description=Screen off
After=suspend.target

[Service]
ExecStart=vbetool dpms off

[Install]
WantedBy=multi-user.target suspend.target
EOF

Attention : ça peut compliquer grandement l’usage de l’appareil, on peut vouloir appliquer un délai avant extinction pour se faciliter la vie.

Powertop pour améliorer la consommation électrique

Powertop permet de voir ce qui utilise le CPU et les diverses ressources, et d’ajuster un peu les paramètres de mise en veille de différents périphériques.

On va l’installer :

sudo apt install powertop

Ensuite, ça peut être cool de lancer l’outil pour constater un peu ce qui tourne et consomme des ressources, de se déplacer dans les onglets, et de tenter des trucs dans l’onglet « Tunables » :

sudo powertop

Si passer tout à Good ne cause pas de problème d’instabilité évidente, alors on peut appliquer la configuration de Powertop à chaque démarrage (source) :

cat << EOF | sudo tee /etc/systemd/system/powertop.service
[Unit]
Description=PowerTOP auto tune

[Service]
Type=oneshot
Environment="TERM=dumb"
RemainAfterExit=true
ExecStart=/usr/sbin/powertop --auto-tune

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable powertop.service

Sinon, il y a des solutions mentionnées dans la source pour désactiver certains changements (si vous observez des dysfonctionnements avec certains périphériques par exemple, et notamment si vous avez des problèmes de Wifi ou Bluetooth)

Perso, je sais que sur cette tablette, passer tout à Good fait (faisait il y a 10 ans en tout cas) qu’après un délai la première frappe sur le clavier ou le premier clic de la souris était ignoré, et aussi était nécessaire pour réveiller l’USB – clairement je m’en fiche ici, mais si votre wifi ou votre Bluetooth est en USB et que les paramètres causent une extinction après un délai, clairement ce n’est pas bon).

Bonus : Configurer le bouton power pour mettre en veille

Sur ma tablette, un appui court sur le bouton power éteint la tablette (et ensuite on la rallume en appuyant 3 longues secondes). Si on souhaite qu’un appui court mette en veille l’appareil et un appui long l’éteigne, comme ça on fait un compromis énergétique supposément raisonnable pour rendre l’ensemble un poil plus pratique, c’est facile avec systemd.

Ajoutez ces deux lignes au fichier /etc/systemd/logind.conf :

HandlePowerKey=suspend
HandlePowerKeyLongPress=poweroff

Rechargez les paramètres :

sudo systemctl restart systemd-logind

MPD : Music Player Deamon

Ok, passons au cœur du sujet : mpd.

Késako

Simplement, c’est un lecteur de musique pilotable à distance qui est capable de :

  • lire de la musique que vous mettez dans son dossier de travail ;
  • lire des playlists que vous mettez dans son dossier de travail ;
  • lire des flux radio, qui sont par exemple définis dans des playlists.

Entre autres.

Certains clients MPD, comme Cantata (une application Qt5 plus ou moins abandonnée mais encore dans les dépôts), sont même capables de lire de la musique sur votre serveur MPD que vous avez localement sur votre ordinateur, ou de gérer les playlists. Ça rend d’ailleurs la constitution de playlists vaguement confortable. Vous n’avez pas besoin d’écrire des playlists M3U à la main, quoi.

Les avantages sont multiples :

  • c’est méga léger, une machine épuisée peut faire tourner MPD à l’aise
  • si vous lisez la musique stockée sur le serveur, le réseau n’est pas engorgé
  • on peut être plusieurs à contrôler la musique, ce n’est pas une personne qui contrôle tout, et on peut le faire depuis le canapé
  • il existe toute une flopée de clients, il y en a pour tous les goûts pourvu que vous aimiez les logiciels abandonnés ou en ligne de commande / en ncurses (ouais, c’est quand même un problème que j’identifie et qui a largement retardé mon adoption de MPD)
    • les gens non techniques apprécieront les applications mobiles telles que M.A.L.P pour gérer la musique et le volume sonore.

C’est parti pour l’installation

sudo apt install mpd

On va modifier sa configuration :

sudo nano /etc/mpd.conf

On peut laisser les paramètres par défaut suivants :

music_directory         "/var/lib/mpd/music"
playlist_directory              "/var/lib/mpd/playlists"

Vous l’aurez compris, c’est là où on stocke les musiques et les playlists. Dans la section suivante, on verra comment rendre le dépôt de morceaux simple et convivial.

On va laisser la plupart des autres paramètres par défaut.

On va changer bind_to_address, qui est par défaut à localhost, mais on veut que n’importe quel appareil sur le réseau soit capable de s'y connecter. On va aussi explicitement mettre le port à la valeur par défaut (ce n’est probablement pas nécessaire, mais c’est ce que j’ai fait) :

bind_to_address                 "0.0.0.0"
port                            "6600"

On veut aussi que quand des fichiers sont changés dans les dossiers music et playlists, mpd se mette à jour tout seul pour ne pas avoir à le baby-sitter :

auto_update     "yes"

J’ai tenté d’activer zeroconf pour que les clients MPD puissent le trouver tout seul :

zeroconf_enabled                "yes"
zeroconf_name                   "Music Player @ %h"

Mais en vrai, je n’ai pas réussi à faire fonctionner ça. En tout cas, un prérequis est d’avoir installé et activé avahi-daemon, on verra ça plus tard dans la partie Samba du coup.

Vous aurez peut-être envie de mettre un mot de passe voire de changer les permissions par défaut en décommentant et adaptant les paramètres suivants, mais c’est optionnel :

#password                        "password@read,add,control,admin"

#default_permissions             "read,add,control,admin"

Ensuite, la partie critique, la sortie audio. Pour l’instant, on va dire à mpd d’utiliser Alsa directement. C’est le plus direct et le plus léger (on passera à PipeWire plus tard, pour gérer l’aspect récepteur Bluetooth)

audio_output {
       type            "alsa"
       name            "My ALSA Device"
       device          "hw:0,0"        # optional
       mixer_type      "hardware"      # optional
     # mixer_device    "default"       # optional
       mixer_control   "Master"        # optional
       mixer_index     "0"             # optional
}

Pour une de mes installations, j’ai commenté mixer_device parce que ce n’est manifestement pas la bonne valeur chez moi, et que ça marche bien sans.

Vous pouvez vous passer des autres valeurs optionnelles, mais vous n’aurez pas le contrôle du volume sonore depuis les clients MPD si vous faites ça. Vous allez donc devoir trouver les bonnes valeurs pour les paramètres mixer_*, et pour device. ainsi que mixer_control et mixer_index.

Quelques indices :

  • hw:0,0 est probablement la bonne valeur pour device, et 0 pour mixer_index aussi. Vous pouvez lister vos cartes son avec aplay -L. Vous aurez peut-être besoin d’installer le paquet alsa-utils.
  • la valeur de mixer_control est le nom du contrôle que vous utiliserez pour changer le volume dans alsamixer, du paquet alsamixergui que vous aurez probablement besoin d’installer.

Si vous galérez trop avec les valeurs de mixer-*, vous pouvez simplement utiliser mixer_type "software", c’est moins propre mais ça devrait faire le taf. Et sinon, vous pouvez toujours sortir l’artillerie lourde et passer directement à PipeWire.

Pour appliquer vos modifications :

systemctl enable --now mpd # À partir de Debian Trixie, mpd n’est plus activé par défaut au niveau du système
systemctl restart mpd # Si MPD tournait déjà

Vous pouvez déboguer vos changements avec la commande suivante, qui suit les logs en temps réel :

journalctl -fu mpd

Vous avez plusieurs options pour essayer de lire des choses avec mpd :

  • installer l’application M.A.L.P sur votre téléphone Android, ou une autre application cliente MPD, et ajouter un profil avec la bonne adresse, le bon port et le bon mot de passe ;
  • installer un client comme Cantata sur votre ordinateur, avec la bonne adresse, le bon port et le bon mot de passe ;
  • installer mpc directement sur le serveur. Normalement mpc play permet de lancer la lecture.

Moi, j’ai testé avec une webradio dans une playlist (/var/lib/mpd/playlists/radio-paradise-main-mix.m3u avec le contenu http://stream.radioparadise.com/ogg-192m), mais on peut aussi évidemment placer un morceau dans /var/lib/mpd/music/.

ReplayGain

Le niveau sonore de mes morceaux n’est pas homogène, donc il faut sans cesse adapter le volume d’un morceau à l’autre. C’est pénible, voire inutilisable en l’état. Une solution pour ça est replay gain : on analyse et on enregistre le niveau sonore d’une piste dans ses métadonnées.

Il existe plein d’outils pour faire ça, dont https://github.com/complexlogic/rsgain

On peut le faire avant d’envoyer les fichiers sur l’appareil. Pour ma part, je l’ai fait sur la tablette, et il n’existe pas de paquet Debian 32 bits, donc je l’ai compilé :

sudo apt install cmake build-essential pkd-config git libavcodec-dev libavformat-dev libtag1-dev libebur128 libinih-dev libfmt-dev
git clone --depth=1 https://github.com/complexlogic/rsgain
cd rsgain
mkdir build
cd build
cmake ..
make -j2
sudo make install

Il faudra s'assurer que les morceaux au format Opus sont étiquetés avec le tag R128_TRACK_GAIN et pas REPLAYGAIN_TRACK_GAIN, parce que c'est ce que MPD s’attend à avoir. Pour ça, on va convaincre rsgain de suivre les standards (que certains lecteurs de musiques ne comprennent pas) en créant un preset qui contient :

[Opus]
OpusMode=s
``


Mes morceaux ne sont pas organisés par albums, donc je désactive l’analyse par album. Je vais donc partir du [preset no_album](https://github.com/complexlogic/rsgain/blob/master/config/presets/no_album.ini) :

mkdir -p ~/.config/rsgain/presets; cat << EOF > ~/.config/rsgain/presets/no_album_standard_opus.ini
[Global]
TagMode=i
Album=false
TargetLoudness=-18
ClipMode=p
MaxPeakLevel=0.0
TruePeak=false
Lowercase=false
ID3v2Version=keep
PreserveMtimes=false
DualMono=false
OpusMode=s
EOF
```

Ensuite, on peut le rsgain sur le dossier de musiques avec ce preset. Mes morceaux ne sont pas organisés par albums, donc je désactive l’analyse par album.

rsgain easy -p no_album_standard_opus -m MAX /var/lib/mpd/music

Note : l'option --skip-existing permet d'ignorer les fichiers déjà taggés :

rsgain easy --skip-existing -p no_album_standard_opus -m MAX /var/lib/mpd/music

Avec cette option, on peut exécuter cette tâche régulièrement, par exemple dans un cron, pour calculer le ReplayGain pour les nouveaux fichiers. Pour la première exécution, il vaut certainement mieux ne pas l’utiliser, sinon, si vous aviez déjà des fichiers qui avaient l'information, il se peut que le résultat ne soit pas uniforme.

Il faut dire à MPD d’utiliser le ReplayGain dans /etc/mpd.conf :

replaygain                      "track"

Vous aurez peut-être besoin de jouer avec les autres paramètres liés au volume et au ReplayGain.

Voici les miens :

# Ce paramètre définit la pré-amplification à appliquer pour les morceaux qui ont l'information du ReplayGain
replaygain_preamp              "0"

# Ce paramètre définit la pré-amplification à appliquer pour les morceaux qui ne l'ont pas
replaygain_missing_preamp      "0"

# Faut-il interdire à MPD de dépasser le niveau original d'amplification en appliquant le ReplayGain?
replaygain_limit                "no"

# Faut-il permettre à MPD d'ajuster le volume pendant la lecture pour normaliser ?
volume_normalization            "no"

Un autre paramètre qu’on peut régler, c'est la manière dont MPD règle le volume dynamiquement pour ReplayGain. Dans votre bloc audio_output, vous pouvez ajouter replay_gain_handler et la valeur "software" (c'est la valeur par défaut) ou "mixer". En théorique, les traitements software dégradent le son, mais en pratique, avec "mixer", je tombe sur ce bug qui met le volume à 100% après chaque changement de piste.

Note : je ne suis pas encore convaincu d’avoir réussi à trouver les réglages parfaits, n’hésitez pas à expérimenter.

Les clients MPD

À ce stade, vous devriez avoir un serveur MPD fonctionnel et configuré. Si applicable, vous pouvez commencer à suggérer aux gens de votre foyer d’installer l’application M.A.L.P sur leur appareil Android ; elle est libre et disponible sur F-Droid et sur le Play Store. Avec un peu de chance, votre enthousiasme était communicatif et c’est eux qui vous demanderont :-)

Pour les autres types d’appareils, vous allez devoir faire vos recherches vous-même je n’ai pas étudié les options sous Windows, Mac ou iPhone, mais il y en a. Pour Linux, j’ai essayé Cantata. Il me convient, si ce n’est qu’il a l’air un peu abandonné, et il a une interface certes conviviale, mais quand même un peu brute. Il existe des widgets qui s’intègrent aux différents environnements de bureaux pour les différents systèmes d’exploitation, je n’ai pas exploré. Le site de MPD propose une liste de clients, et le wiki de Arch aussi.

 M.A.L.P, un client mobile pour MPD

Samba pour déposer les morceaux (et les playlists)

Déposer des morceaux, vous allez probablement le faire depuis un ordinateur, et à peu près n’importe quel système d’exploitation est capable d’aller chercher un dossier SMB en réseau, alors je vous propose de configurer un serveur Samba. Ça a le bon goût d’être très léger, très simple à faire et de fonctionner depuis n’importe quel OS. Allons-y, et tant qu’à faire, on va aussi installer Avahi, qui permettra aux ordinateurs sous Linux et Mac de découvrir les dossiers partagés tous seuls :

sudo apt install samba avahi-daemon

On va partager nos dossiers music et playlists au monde entier en lecture-écriture (YOLO). On édite /etc/samba/smb.conf:

[Musique]
path=/var/lib/mpd/music
read only=no
writable=yes
comment=Fichiers musique MPD
guest ok = yes
force group = audio
force user = mpd
browsable = yes
public = yes
create mask = 0644
directory mask = 0755

[Playlists]
path=/var/lib/mpd/playlists
read only=no
writable=yes
comment=Listes de lecture MPD
guest ok = yes
force group = audio
force user = mpd
browsable = yes
public = yes
create mask = 0644
directory mask = 0755

Je ne maitrise pas particulièrement Samba et il y a peut-être des options superflues, mais globalement l’esprit c’est :

  • n’importe qui doit pouvoir accéder à ces deux en lecture et en écriture depuis le réseau. En particulier, la création de dossiers doit marcher
  • MPD doit pouvoir lire ce qu’on a écrit dans ces dossiers
  • les fichiers et dossiers doivent avoir des permissions sensées

Bien sûr, on peut vouloir restreindre l’accès à certains utilisateurs et/ou avec un mot de passe. Je vous laisse creuser.

Après un redémarrage de Samba :

sudo systemctl restart samba

Avec un peu de chance, dans l’onglet « Réseau » de votre gestionnaire de fichier, dans la section « Partages SMB », votre appareil apparait. Sinon, vous devriez pouvoir y accéder avec smb://HOST/ avec Dolphin et probablement Nautilus, probablement \\HOST sous Windows.

Alternatives possibles à Samba

  • Si on a un NAS, monter un dossier sur le serveur MPD, voire installer MPD sur le serveur de stockage, ou avoir une tâche chron qui fait un rsync bien placé
  • Mettre en place une synchronisation avec Nextcloud ou Syncthing, et faire pointer MPD vers le bon dossier, ou ajouter le dossier de MPD comme dossier de stockage externe à Nextcloud par exemple
  • SFTP
  • NFS
  • FTP (mais les autres options sont probablement meilleures)

Récepteur Bluetooth

Ce n’est bien sûr pas nécessaire si vous êtes parfaitement satisfait·e avec MPD, mais si vous voulez que votre appareil soit en plus capable de se comporter comme une enceinte Bluetooth, vous êtes au bon endroit.

Les difficultés qu’on va résoudre sont les suivantes :

  • pour l’instant, MPD accède au son directement avec ALSA, et en général on ne peut pas être plusieurs sur ALSA. En tout cas, et même s’il a l’air possible de faire fonctionner Bluetooth et ALSA ensemble, ça n’a pas l’air d’être terriblement simple ou même stable. Donc on va utiliser PipeWire. On aurait pu utiliser PulseAudio, mais PipeWire le remplace, et fonctionne généralement mieux.
  • PipeWire, c’est pensé pour être lancé dans une session graphique d’un utilisateur, mais nous, on a un serveur headless. Il va falloir faire en sorte de lancer une session utilisateur au démarrage sans interaction, et que cette session ne soit pas tuée.
  • mpd tourne avec son utilisateur, PipeWire avec son utilisateur, et après s’être rendu compte qu’il faut que ça soit les mêmes, faut aussi savoir comment, et le faire.

Lors de l’installation de Debian, on a défini un utilisateur. On peut utiliser cet utilisateur. Sinon, on peut aussi en créer un pour ça, pensez bien à l’ajouter aux groupes audio et bluetooth.

Garder une session utilisateur active

On va démarrer une session utilisateur au boot :

sudo loginctl enable-linger user # remplacer user par le nom d’utilisateur

On va s’assurer que les processus de cette session ne sont pas tués au moment où on quitte une session (par exemple quand on quitte une session ssh) : dans le fichier /etc/systemd/logind.conf, décommentez la ligne KillExcludeUsers et ajouter le nom d’utilisateur après le =. Vous deviez avoir

KillExcludeUsers=user

user est le nom d’utilisateur.

On peut maintenant recharger ces paramètres :

sudo systemctl restart systemd-logind

Installer PipeWire et les choses nécessaires

À ce stade, MPD bloque probablement l’utilisation du son parce qu’il s’y connecte via ALSA. On va le stopper.

sudo systemctl stop mpd

PipeWire et WirePlumber vont dorénavant gérer le son, et libspa-0.2-bluetooth permet au démon qui gère le Bluetooth (Bluez) de s’inter-connecter à PipeWire pour le Bluetooth Audio.

sudo apt install wireplumber pipewire libspa-0.2-bluetooth

En tant que votre utilisateur (nommé user dans les commandes précédentes) (c’est important), activez PipeWire au démarrage et lancez-le :

systemctl --user enable --now pipewire wireplumber

Notez que pipewire-pulse n’est pas nécessaire, d’ailleurs vous pouvez le supprimer ou le désactiver en toute sécurité s’il a été installé.

Installer un agent Bluetooth qui accepte toutes les connexions audio sans vérifications avec code

Normalement, accepter les connexions Bluetooth se fait à l’aide d’un agent Bluetooth :

  • qui tourne dans votre session graphique : c’est géré par votre environnement de bureau, ou une application comme bluetooth-applet (est-ce que ça existe encore ?) que vous lancez. Là, évidemment, on n’a pas de session graphique, et pour l’instant on n’a pas d’agent Bluetooth qui tourne.
  • En ligne de commande, avec un outil comme bluetoothctl. Je vous invite à essayer. Vous pouvez lancer des commandes comme pairable on, discoverable on, scan on, et essayer de vous connecter avec un autre appareil. Après vos tests, vous pouvez tout recommencer en faisant oublier les appareils des deux côtés.

Évidemment, on ne va pas se connecter en ssh pour lancer bluetoothctl à chaque fois qu’on veut se connecter en Bluetooth. On va mettre en place un agent qui démarre automatiquement et qui a un comportement similaire à un casque ou des enceintes Bluetooth : qui accepte toutes les connexions Bluetooth audio. Pour ça, on va utiliser un script Python partagé par Collabora sous Licence LGPL 2.1+ qui fait ça très bien et qu’on va lancer au démarrage.

Bien sûr, ça veut dire que vos voisins peuvent s’amuser à jouer des trucs chez vous, ou même se connecter fortuitement en choisissant la mauvaise entrée.

Ce script a une dépendance, qu’on va installer :

sudo apt install python3-dbus

On va placer ce script dans speaker-agent.py:

#!/usr/bin/python3
# SPDX-License-Identifier: LGPL-2.1-or-later

import dbus
import dbus.service
import dbus.mainloop.glib
from gi.repository import GLib

BUS_NAME = 'org.bluez'
AGENT_INTERFACE = 'org.bluez.Agent1'
AGENT_PATH = "/speaker/agent"

A2DP = '0000110d-0000-1000-8000-00805f9b34fb'
AVRCP = '0000110e-0000-1000-8000-00805f9b34fb'

bus = None


class Rejected(dbus.DBusException):
    _dbus_error_name = "org.bluez.Error.Rejected"


class Agent(dbus.service.Object):
    exit_on_release = True

    def set_exit_on_release(self, exit_on_release):
        self.exit_on_release = exit_on_release

    @dbus.service.method(AGENT_INTERFACE,
                         in_signature="", out_signature="")
    def Release(self):
        print("Release")
        if self.exit_on_release:
            mainloop.quit()

    @dbus.service.method(AGENT_INTERFACE,
                         in_signature="os", out_signature="")
    def AuthorizeService(self, device, uuid):
        # Always authorize A2DP and AVRCP connection
        if uuid in [A2DP, AVRCP]:
            print("AuthorizeService (%s, %s)" % (device, uuid))
            return
        else:
            print("Service rejected (%s, %s)" % (device, uuid))
        raise Rejected("Connection rejected by user")

    @dbus.service.method(AGENT_INTERFACE,
                         in_signature="", out_signature="")
    def Cancel(self):
        print("Cancel")


if __name__ == '__main__':
    dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)

    bus = dbus.SystemBus()

    agent = Agent(bus, AGENT_PATH)

    mainloop = GLib.MainLoop()

    # By default Bluetooth adapter is not discoverable and there's
    # a 3 min timeout
    # Set it as always discoverable
    adapter = dbus.Interface(bus.get_object(BUS_NAME, "/org/bluez/hci0"),
                             "org.freedesktop.DBus.Properties")
    adapter.Set("org.bluez.Adapter1", "DiscoverableTimeout", dbus.UInt32(0))
    adapter.Set("org.bluez.Adapter1", "Discoverable", True)

    print("RPi speaker discoverable")

    # As the RPi speaker will not have any interface, create a pairing
    # agent with NoInputNoOutput capability
    obj = bus.get_object(BUS_NAME, "/org/bluez")
    manager = dbus.Interface(obj, "org.bluez.AgentManager1")
    manager.RegisterAgent(AGENT_PATH, "NoInputNoOutput")

    print("Agent registered")

    manager.RequestDefaultAgent(AGENT_PATH)

    mainloop.run()

Le script mentionne le Raspberry Pi, mais il n’y a absolument rien de spécifique au Raspberry dedans, il est suffisamment générique.

On va lancer ce script au démarrage en créant le fichier ~/.config/systemd/user/speaker-agent.service

[Unit]
Description=Bluetooth speaker agent

[Service]
ExecStart=python3 speaker-agent.py

[Install]
WantedBy=default.target

Et en l’activant (--now le lance tout de suite) :

systemctl --user enable --now speaker-agent.service

Il faudra aussi mettre JustWorksRepairing = always dans /etc/bluetooth/main.conf pour permettre le re-appairage sans interaction. Bon là j’avoue, je paraphrase largement ma source :-)

Ensuite, on va autoriser la connexion Bluetooth même sans session active (en SSH par exemple) (source). Si on ne fait pas ça, la connexion Bluetooth n’est pas possible si l’utilisateur n’a pas une session active (les symptômes : on arrive à se connecter en Bluetooth que quand on est loggué en SSH ou autre, et la connexion Bluetooth casse dès qu’on quitte la session).

mkdir -p ~/.config/wireplumber/bluetooth.lua.d
cat > ~/.config/wireplumber/bluetooth.lua.d/80-disable-logind.lua << EOF
-- Disable arbitration of user allowance of bluetooth via D-Bus user session
bluez_monitor.properties["with-logind"] = false
EOF
systemctl --user restart wireplumber

Adapter MPD (et Samba) pour utiliser PipeWire

Pour que MPD utilise PipeWire, il faut adapter :

  1. sa configuration pour qu’il tourne avec le même utilisateur
  2. sa configuration audio_output
  3. les permissions dans /var/lib/mpd

Dans /etc/mpd.conf, changer la ligne user :

user                            "mpd"

Elle doit maintenant utiliser votre utilisateur :

user                            "user"

Commentez votre bloc audio_output, on va maintenant utiliser PipeWire (je suppose qu’on pourrait garder les deux et les clients MPD peuvent probablement permettre de choisir la sortie son, mais ça me parait complexifier l’utilisation pour un intérêt pas clair, ce qui va contre nos objectifs) :

audio_output {
        type            "pipewire"
        name            "PipeWire Sound Server"
}

Maintenant, il est temps d’adapter les permissions dans /var/lib/mpd. On va stopper Samba juste avant, et adapter sa configuration.

sudo systemctl stop mpd samba # si mpd tournait encore
sudo chown -rv user /var/lib/mpd
sudo systemctl start mpd

Note : MPD peut aussi être démarré dans une session utilisateur et à ce stade, c’est ce qu’il serait probablement le plus logique de faire, en bougeant /etc/mpd.conf et le contenu de /var/lib/mpd dans le dossier de notre utilisateur. C’est d’ailleurs la manière privilégiée de démarrer MPD à partir de Debian Trixie. Par simplicité et cohérence, et parce que cette section « Récepteur Bluetooth » est optionnelle mais que les manipulations pour lancer une session utilisateur au démarrage décrites dans cette section seraient nécessaires pour lancer MPD en tant que service utilisateur au démarrage dans tous les cas et que ça apporte une réelle complexité, on fait le choix de garder MPD en tant que service système.

Modifiez /etc/samba/smb.conf. Dans les deux blocs de partages qu’on a ajouté précédemment, changez la ligne force user = mpd en:

force user = user

Puis on peut redémarrer Samba :

sudo systemctl start samba

Permettre à PipeWire de configurer sa priorité

Si vous voyez cela dans les logs de PipeWire :

user@tablette:~$ journalctl --user -fu pipewire
avril 29 13:41:01 tablette systemd[514]: Started pipewire.service - PipeWire Multimedia Service.
avril 29 13:41:01 tablette pipewire[531]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
avril 29 13:41:01 tablette pipewire[531]: mod.rt: found session bus but no portal
avril 29 13:41:02 tablette pipewire[531]: mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied
avril 29 13:41:02 tablette pipewire[531]: mod.rt: could not set nice-level to -11: Permission non accordée
avril 29 13:41:02 tablette pipewire[531]: mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied
avril 29 13:41:02 tablette pipewire[531]: mod.rt: could not make thread 547 realtime using RTKit: Permission non accordée

Ça veut grosso modo dire que PipeWire cherche à se rendre plus prioritaire via un mécanisme fourni par les environnements de bureau (xdg-desktop-portal), n’y arrive pas parce qu’évidemment, aucun environnement de bureau ne tourne, alors il essaie de demander au service système rtkit, et se fait jeter.

Ce n’est pas très grave et on pourrait vivre sans, mais ça pourrait aider à limiter les saccades sonores, donc on va réparer ça (et je pense avoir vu une bonne amélioration grâce à ça).

Le fichier /usr/share/polkit-1/actions/org.freedesktop.RealtimeKit1.policy dicte qui a le droit ou non de configurer sa priorité (découvert ici, mais le conseil de modifier ce fichier système n’est pas bon, au moins parce qu’une mise à jour future risque d’écraser les modifications) :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
        "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
        "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
        <vendor>Lennart Poettering</vendor>

        <action id="org.freedesktop.RealtimeKit1.acquire-high-priority">
                <description>Grant high priority scheduling to a user process</description>
                <description xml:lang="tr">Bir sürece yüksek öncelikli çalışabilme yetkisi ver</description>
                <message>Authentication is required to grant an application high priority scheduling</message>
                <message xml:lang="tr">Sürecin yüksek öncelikli çalıştırılabilmesi için yetki gerekiyor</message>
                <defaults>
                        <allow_any>no</allow_any>
                        <allow_inactive>yes</allow_inactive>
                        <allow_active>yes</allow_active>
                </defaults>
        </action>

        <action id="org.freedesktop.RealtimeKit1.acquire-real-time">
                <description>Grant realtime scheduling to a user process</description>
                <description xml:lang="tr">Bir sürece gerçek zamanlı çalışabilme yetkisi ver</description>
                <message>Authentication is required to grant an application realtime scheduling</message>
                <message xml:lang="tr">Sürecin gerçek zamanlı çalıştırılabilmesi için yetki gerekiyor</message>
                <defaults>
                        <allow_any>no</allow_any>
                        <allow_inactive>yes</allow_inactive>
                        <allow_active>yes</allow_active>
                </defaults>
        </action>

</policyconfig>

Dans un système Unix, les paramètres systèmes sont dans /etc. Pour Polkit, il existe un mécanisme pour écrire des règles, qu’on va utiliser. On va créer une règle qui permet à n’importe quel utilisateur du groupe audio de modifier la priorité de ses processus. C’est probablement trop large, mais je ne connais pas bien Polkit et ça fera le taf pour notre application dédiée à l’audio. Si vous avez des meilleures idées, n’hésitez pas à partager en commentaire.

sudo cat > /etc/polkit-1/rules.d/rt.rules << EOF
polkit.addRule(function(action, subject) {
        if (subject.isInGroup("audio") && (
                action.id == "org.freedesktop.RealtimeKit1.acquire-high-priority" ||
                action.id == "org.freedesktop.RealtimeKit1.acquire-real-time"
        )) {
                return polkit.Result.YES;
        }
})
EOF

sudo systemctl restart polkit.service
systemctl --user restart pipewire

On pourra constater l’absence des échecs dans les journaux de PipeWire.

Bon, on sent bien que toute cette utilisation audio sans session utilisateur standard n’est pas un cas d’utilisation hyper bien prévu et on se retrouve à toucher des coins un peu sombres du système…

Évitez les flux Wifi 2,4 GHz

Si vous avez un Wifi en 2,4 GHz, ça peut causer des soucis avec le Bluetooth, et le son peut saccader. Si vous observez cela, il faudra alors limiter au maximum les services et autres tâches de fond qui font des communications réseau. Évidemment, si vous pouvez utiliser un câble Ethernet, c’est encore mieux.

Sur ce plan, tous les codecs audio Bluetooth ne semblent pas se valoir. Pour tester ça, j’ai lancé un test iperf3 entre la tablette et mon ordinateur portable pour saturer le Wifi. Ça devenait immédiatement catastrophique avec le codec SBC-XQ, alors qu’avec le codec Opus 05, il y a initialement des saccades, puis ça s’améliore vite. J’imagine que le codec Opus dégrade très efficacement la qualité pour compenser. Bon, malheureusement, tous les systèmes ne permettent pas de choisir son codec donc ce n’est qu’une solution partielle au problème.

Note sur l’utilisation des ressources

C'est léger :

load average: 0,12, 0,10, 0,05
$ free -mh
               total       utilisé      libre     partagé tamp/cache   disponible
Mem:           986Mi       253Mi       324Mi       6,1Mi       550Mi       733Mi
Échange:       974Mi          0B       974Mi

Globalement, le CPU s’ennuie en pleine lecture, et à peine un tiers du Giga de mémoire vive est utilisé, la partition d’échange s’ennuie, donc il y a encore largement la place de faire tourner d’autres trucs sur cet appareil si jamais. On peut aussi constater qu’ajouter MPD et tout ce bazar à une installation existante ne la surchargerait pas plus que ça.

On a aussi un temps de démarrage autour des 20 secondes, ce qui est franchement pas mal.

Conclusion et améliorations possibles

On est pas mal rentrés dans les détails, c’était l’occasion d’explorer plein de choses mine de rien. J’ai à la fois appris des choses, précisé des connaissances, et mis plein de choses que je savais ensemble pour obtenir un résultat très satisfaisant. On se retrouve à manipuler de la gestion de services, des configurations systemd un peu poussées, du bluetooth, du son avec ALSA et PipeWire, de la gestion de session utilisateur sur un système headless, et plein d’autres trucs et aller dans les détails comme le boot pour avoir quelque chose de rapide, comme l’écran éteint au bon moment, ou la personnalisation du comportement du bouton power (honnêtement, je n’étais pas très sûr que c’était possible, j’avais lancé la recherche au cas où !).
J’espère que l’aventure vous a plu aussi.

Bien sûr l’ensemble est perfectible, alors je vous laisse avec des idées, n’hésitez pas à partager les vôtres en commentaires :

  • Jouer un son au démarrage / à l’appairage Bluetooth. – pour l’instant, la tablette s’allume et puis plus rien. En général, les enceintes Bluetooth jouent un petit son quand elles sont prêtes ou qu’elles viennent d’être appairées et ça peut être pratique
  • Commande vocale. Il y a clairement des manières d’utiliser le micro de la tablette pour demander le morceau suivant, précédent ou régler le volume. Ça peut être pratique quand on n’a pas le téléphone sous la main et ça peut avoir son petit effet en soirée la première fois, tant que les gens ne sont pas encore complètement blasés par le concept parce que tout le monde n’a pas un Google Nest ou un Alexa chez soi, surtout dans ma bulle sociale. Mais c’est probablement finalement très gadget et je me vois mal interrompre une conversation en criant un ordre pour gérer la musique…
  • Appairage Bluetooth plus sécurisé. En général, les enceintes Bluetooth acceptent les nouveaux appareils dans un mode spécial. En appuyant sur le bouton Bluetooth, ou quelque chose comme ça. Ça peut éviter que les voisin·e·s ne te rickrollent au moment le plus inopportun. Ça vaudrait le coup de travailler sur quelque chose comme ça. Avec l’écran tactile, il est probablement possible de dessiner une forme particulière reconnue (ça serait un peu badasse, ou plus probablement, n’accepter (une seule) nouvelle connexion que dans les X minutes après le démarrage ou le retour de veille. Comme ça, demander l’appairage consiste à appuyer deux fois sur le bouton power, ce qui est plutôt acceptable. Si vous avez des idées, n’hésitez pas à partager…
  • Réveil à distance avec du Wake-on-LAN. Ça ne s’applique probablement pas à mon matériel, mais il est possible d’utiliser astucieusement le WoL pour réveiller l'appareil à distance, avec éventuellement la complicité d’un routeur ou d’un serveur toujours allumé chez vous.
  • Désactiver le Wifi quand le Bluetooth est utilisé. Pour éviter les interférences, on pourrait imaginer que quand un appareil se connecte en Bluetooth, on éteint le Wifi (avec rfkill par exemple), on met MPD en pause (ou on le stoppe s’il est en train de jouer un flux) parce qu’on ne peut plus le contrôler, puisque le Wifi n’est plus actif, et on réactive le Wifi quand l’appareil Bluetooth est déconnecté. On pourrait même être plus fin et détecter quand du son est joué.
  • Automatiquement mettre MPD en pause lors d’une connexion Bluetooth. (un peu doublon avec le précédent point) Pour l’instant, il faut manuellement mettre en pause mpd, sinon les deux flux audios se jouent en même temps. -- Changer la classe Bluetooth de l’appareil. Ça permettrait à l’appareil de se déclarer comme appareil audio, pour que ça affiche le bon icône sur les autres appareils.
  • Mises à jour automatiques. Il ne faut pas que ça casse des choses en pleine lecture, ni que ça cause des interférences avec le Bluetooth à cause des téléchargements.
  • Ne pas persister les logs. Pour l’instant, les logs sont écrits dans /var/log sur le SSD, entrainant une usure et un ralentissement cependant probablement tous deux négligeables. On pourrait vouloir ne pas les garder, mais c’est aussi risquer de perdre des informations de débogage le jour où il y a un pépin.

Je vais probablement trouver d’autres choses à améliorer après publication de l’article. Je partagerai peut-être les choses intéressantes en commentaires ou dans des journaux, et je ferai peut-être vivre l’article sur mon site.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Reçu avant avant-hier

Nouveautés de mai 2025 de la communauté Scenari

Scenari est un ensemble de logiciels open source dédiés à la production collaborative, publication et diffusion de documents multi-support. Vous rédigez une seule fois votre contenu et vous pouvez les générer sous plusieurs formes : site web, PDF, OpenDocument, diaporama, paquet SCORM (Sharable Content Object Reference Model)… Vous ne vous concentrez que sur le contenu et l’outil se charge de créer un rendu professionnel accessible et responsive (qui s’adapte à la taille de l’écran).

À chaque métier/contexte son modèle Scenari :

  • Opale pour la formation ;
  • Dokiel pour la documentation ;
  • Optim pour les présentations génériques ;
  • Topaze pour les études de cas ;
  • et bien d’autres…

💗 Parole de Scenariste

Scenari a attiré mon attention en 2020, à l'occasion d'une formation chez un un grand compte public qui m'en parle. J'ai découvert le potentiel d'une dissociation entre contenu et forme.
Nous percevons les avantages d’une réutilisation de contenus et la déclinaison de supports avec une mise en forme différence selon le contexte d’animation de nos formations.
Chez way2Sv, nous décidons de migrer l’ensemble du corpus de nos formations dont les supports étaient initialement au format Libre Office. Cette migration s’opère en mode coopératif, grâce à l’usage de MyScenari.

Eric Fruit Eric Fruit, gérant de way2Sv, consultant et formateur sur l’usage du numérique et gestion de la connaissance métier. Modèles utilisés : Opale

Réorganisation des catégories dans le forum

📣 Réorganisation des catégories dans le forum

Nous avons réorganisé les catégories dans le forum pour qu'elles soient plus en adéquation avec le site de téléchargements.

Juste après la catégorie « Actualités », tu trouveras désormais les catégories « Modèles et applications bureau » et « Solutions serveur ».

Nous avons créé aussi la catégorie « Usages / métiers » pour discuter non pas de l'utilisation des outil Scenari, mais autour d'un métier ou d'un domaine. En effet, parfois on a besoin d'être guidé vers le ou les bons outils pour une pratique donnée.

Nouvelle page vidéos de présentation outils

📣 Nouvelle page vidéos de présentation outils

Une nouvelle page a vu le jour sur scenari.org : « Présentation d'outils Scenari ».

Tu y retrouveras une présentation de chacun des principaux modèles et outils Scenari sous forme de vidéo courte (moins de trois minutes).

On parlera de Scenari au QPES2025

📣 On parlera de Scenari au QPES2025

Sandrine et Nicole, membres du bureau de l'association Scenari, donneront, avec d'autres collègues du Cnam, une conférence intitulée « Accessibilité et pédagogie numérique au Cnam : 10 ans d'expérimentation avec Scenari Opale » le 22 mai à 14h au colloque QPES2025 : Colloque "Questions de Pédagogies dans l'Enseignement Supérieur". 👏

L'article qu'elles ont cosigné présente les vertus de Opale pour créer des contenus accessible et explore les atouts et freins à l'adoption de Scenari, en s'appuyant sur les résultats de l'enquête de notre stagiaire Eric.

✨ Le savais-tu ?

Il existe un atelier communautaire de tutoriels. L'idée est de créer et maintenir ensemble des tutoriels Scenari.

Tu peux :

📊 Le chiffre du mois

5 5, C'est le nombre de langues dans lesquelles Opale 24 est officiellement disponible. Et les traductions dans 5 autres langues sont en cours. Si tu peux donner un coup de main pour les traductions, écris à direction@scenari.org.

🦋 Scenari présent dans …

👋 Nouvelles adhésions d'organisations

Souhaitons la bienvenue à :

  • Le Pole développement de l'arbitrage de la commission sportive roller hockey / FFRS qui nous a rejoint dans le collège des Utilisateurs Personne Morale. Outils libres utilisés : Opale , Parcours, Platine-suite.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Nouvelles de Haiku - 1er trimestre 2025

18 mai 2025 à 20:59

Il est temps de s'intéresser à nouveau aux nouveautés de Haiku pour ce dernier trimestre.

Les gros changements sont:

  • Un nouvel allocateur mémoire qui permet enfin d'allouer plus de 3GiB par application (un reste de l'historique de Haiku sur les systèmes 32 bits), tout en étant plus rapide et moins gourmand en mémoire,
  • Des raccourcis claviers sans touches modificatrices,
  • De grosses mises à jour dans la bibliothèque C,
  • La poursuite du nettoyage de code et de l'optimisation du navigateur de fichiers Tracker,
  • La reprise du travail sur le pilote NFS4 pour les systèmes de fichiers en réseau,
  • Et bien sûr, de très nombreuses corrections de bugs et petites améliorations un peu partout dans le système.

Sommaire

Google Summer of Code

Le Google Summer of Code est un programme organisé par Google pour encourager de nouveaux développeurs à se lancer dans la contribution aux logiciels libres. Il prend la forme d'un stage, où un projet de logiciel libre fournit un sujet et une équipe d'encadrement, et Google se charge de financer le nouveau contributeur pour quelques semaines.

Cette année, la candidature de Haiku a été rejetée, la préférence étant donnée à des projets engagés dans l'intelligence artificielle et dans la cybersécurité (deux domaines beaucoup demandés par les personnes souhaitant participer au programme). Ce n'est finalement peut-être pas une mauvaise chose pour Haiku: les développeurs d'autres projets se sont plaints d'avoir reçu des centaines de candidatures visiblement générées par des LLM sans aucun travail de préparation, ce qui leur demande donc beaucoup de temps pour faire le tri dans les candidatures. Les développeurs de Haiku vont cette année pouvoir se consacrer à d'autres tâches.

Applications

Tracker

Le travail de refonte du Tracker se poursuit. Les changements intégrés en début d'année ont provoqué un certain nombre de régressions qui sont corrigées petit à petit:

  • Il est à nouveau possible d'ouvrir le dossier contenant un résultat de requête en double cliquant la colonne "emplacement" dans les résultats.
  • Correction d'un crash et de problèmes de gestion de la mémoire et de problèmes de synchronisation entre threads.
  • Ré-optimisation de la gestion des menus dynamiques pour éviter de les reconstruire à chaque clic de souris, mise en cache de certaines parties du menu dont la construction nécessite des accès disque (liste de patrons pour le menu "nouveau document", liste d'add-ons)

Toujours beaucoup de nettoyage de code à faire dans le Tracker:

  • correction de dimensions en dur dans les menus spéciaux du Tracker,
  • nettoyage du glisser-déposer,
  • refactorisation de la logique de dessin,
  • amélioraiton du chargement des add-ons,

Optimisation de la méthode de surveillance des dossiers, utilisation d'un "node monitor" (équivalent de inotify sous Linux) récursif pour surveiller un dossier et tous ses sous-dossiers au lieu de créer un monitor pour chaque dossier. Cela a nécessité des changements au niveau du noyau avec l'ajout du flag B_QUERY_WATCH_ALL pour couvrir ce cas d'usage.

Par jscipione, waddlesplash

MediaPlayer

L'infobulle sur le "scrubber" (barre de navigation temporelle dans le fichier) s'affiche dès que la souris est au-dessus de la barre. Elle contient le marqueur de temps correspondant à la position de la souris, permettant de naviguer avec précision dans le fichier. Ceci a nécessité des évolutions dans BToolTip, la classe responsable des infobulles, qui n'était pas prévue pour faire des infobulles persistantes poursuivant le déplacement de la souris.

Ajout d'une option pour afficher une vidéo à 25% de sa taille originale (les contenus en 4K ou plus se faisant plus courants).

Par AkashKumar7902, x512, waddlesplash

WebPositive

WebPositive ne prétend plus savoir traiter les liens utilsant le protocole gopher. Ces liens ne fonctionnaient plus depuis le retour à l'utilisation de cURL pour la couche réseau de WebKit au lieu d'essayer de réimplémenter un client HTTP maison.

Amélioration de la gestion des sessions : sauvegarde du workspace utilisé pour chaque fenêtre, restauration de la session complète lorsque le navigateur est démarré en cliquant sur un lien, avec ouverture du lien dans une fenêtre du workspace courant s'il y en a déjà une, et dans une nouvelle fenêtre sinon.

Par nephele, ilzu

HaikuDepot

Amélioration de performances, en particulier lors de l'affichage des résultats de recherche, qui étaient très très lents sur les machines un peu anciennes.

Par apl, oco, waddlesplash

ProcessController

Affichage de "system resources" avant "caches" afin de rendre les statistiques d'utilisation mémoire plus claires et plus lisibles.

Correction de problèmes dans la mesure d'utilisation de resources par le noyau.

Par OscarL, waddlesplash

Terminal

Correction d'un bug d'initialisation de la couleur du curseur, visible principalement lorsque le terminal est utilisé comme réplicant dans une autre application. Cette possibilité est utilisée dans l'IDE Genio par exemple.

Par jackburton

StyledEdit

Interdiction d'entrer des caractères de contrôle ASCII dans un fichier texte (via les raccourcis clavier control+une lettre).

Par OscarL

Screenshot

Ajout de la possibilité de sélectionner un rectangle à capturer (en plus des possibilités existantes de capturer tout l'écran ou la fenêtre active).

Préférences

Nettoyage de code inutile dans les préférences d'affichage

Amélioration de la gestion des erreurs dans les préférences de sons si le dossier où devraient se trouver les fichiers son n'existe pas.

Par captain0xff, humdinger

Outils en ligne de commande

strace: Décodage des arguments passés à rlimit ainsi que de l'argument "type" pour mmap, affichage correct des valeurs de type ssize_t ne pouvant pas être représentées sur 32 bits.

Fusion des outils query et filteredquery. Ces deux outils permettent de rechercher des fichiers à partir de leurs attributs (xattrs) qui sont indexés par le système de fichier. Cette méthode de recherche retourne tous les résultats, le filtrage pour limiter à certains dossiers doit donc être fait par l'outil après avoir récupéré les résultats de la recherche. Cette fonction étant très utile, il n'y a pas de raison de l'implémenter comme un outil séparé.

keymap: l'option -h affiche l'aide, en conformité avec les bonnes pratiques d'interface utilisateur. L'option pour afficher un header est donc réaffectée et devient -H.

leakanalyzer (outil d'analyse des fuites mémoire): ignore la mémoire allouée en interne par le "locale kit" pour le support des locales dans la librairie C, cette mémoire ne peut pas être libérée.

listusb: correction de l'alignement vertical du statut des ports qui n'était pas en face des autres informations affichées.

waitfor (petite application permettant d'attendre différents évènements, très utile dans certains scripts) peut maintenant attendre la disponibilité d'une connexion réseau.

Par humdinger, jmairboeck, korli, OscarL, waddlesplash

Kits

Interface Kit

Les raccourcis claviers pour les menus peuvent maintenant ne pas utiliser la touche "Commande" du clavier. Cela permet de définir des raccourcis sans touches modificatrices ou avec des touches non-standard. L'utilisation de ce type de raccourcis est relativement rare, mais nécessaire dans quelques cas particuliers. Par exemple, la touche "Supprimer" peut être utilisée pour supprimer un fichier ou un élément de liste de lecture, la touche "F2" pour renommer un fichier dans le Tracker, …

Correction de la gestion des raccourcis claviers dans BPopUpMenu qui pouvaient être associés à la mauvaise fenêtre.

Amélioration du mode sombre: meilleure méthode de choix de la couleur de fond dans BTextView, utilisation d'une combinaison de couleurs cohérentes pour les boutons des barres de défilement.

Ajout de définitions et de documentation pour tous les côdes de contrôle ASCII dans InterfaceDefs.h. Certains d'entre eux n'étaient pas documentés, ce qui pouvait laisser penser qu'il restait de la place libre utilisable pour coder d'autres choses.

Ajout de vérifications dans BMenuField::SetLabel pour traiter correctement les labels NULL.

Optimisations de BScrollView et BColumnListView pour limiter les rafraîchissements inutiles de l'affichage (dans le cadre des améliorations de performances pour HaikuDepot). Dans BColumnListView, ajout d'APIs pour ajouter et supprimer un ensemble d'éléments d'un seul coup, ce qui est beaucoup plus rapide que de les traiter un par un.

Meilleure gestion du sémaphore de synchronisation des menus dans BWindow. Tous les menus dans Haiku sont implémentés comme des fenêtres, ce qui signifie que chaque menu s'exécute dans un thread dédié avec sa propre boucle d'évènements. La synchronisation peut donc être particulièrement complexe.

Correction d'un use-after-free (utilisation de mémoire libérée qui ne devrait logiquement plus être accédée) dans BSlider.

BDecimalSpinner (un contrôle pour changer une valeur numérique au clavier ou avec des boutons '+' et '-') utilise BNumberFormat et affiche donc le nombre en fonction des préférences de localisation.

Par apl, bitigchi, jscipione, korli, nipos, nephele, PulkoMandy, waddlesplash, x512

Support Kit

Modification de BObjectList pour passer l'argument "owning" en paramètre de template plutôt qu'en paramètre du constructeur. Cela améliore les résultats d'analyse statique qui détectaient de nombreux faux positifs "double free" ou "use after free", et rend également plus difficile de faire des erreurs sur la gestion de la mémoire avec ces listes.

Certaines utilisations de BObjectList<BString> ont été remplacées par la classe dédiée BStringList, plus simple à utiliser pour ce cas particulier.

Amélioration de performances dans BList, BMessage et certaines parties du code les utilisant beaucoup pour réduire la quantité d'allocations mémoire dynamiques, en utilisant la pile comme stockage temporaire ou simplement en retardant au maximum les allocations. Par exemple, plutôt que de pré-allouer de la mémoire pour une liste dès la création de cette dernière, on attend l'insertion du premier élément dans la liste. On élimine ainsi des allocations dans les cas où du code crée une liste, mais n'insère finalement jamais rien dedans.

Amélioration des erreurs remontées par les classes de traitement de fichiers JSON.

Ajout de vérifications de pointeurs NULL manquantes dans BString pour corriger des crashs quand il n'y a plus de mémoire et qu'une allocation échoue.

Par ilzu, waddlesplash

Storage Kit

Amélioration de BFilePanel pour mieux réagir lorsque le dossier de destination n'existe pas.

Inhibition de BBlockCache lors de l'utilisation d'un allocateur mémoire de debug ou avec des gardes pour détecter les mauvaises utilisations mémoire. Dans ce cas, il vaut mieux se dispenser des gains de performance de la mise en cache mais détecter correctement l'utilisation de mémoire après sa remise à disposition dans le cache.

Ajout d'un type MIME pour les BMessage serialisés sur disque (souvent utilisés pour sauvegarder les préférences d'applications par exemple).

Par augiedoggie, nephele, waddlesplash

Serveurs

input server

Amélioration du clavier virtuel pour se mettre à jour automatiquement lors des changements de résolution d'écran et de disposition du clavier. Ce clavier virtuel n'est pas inclus par défaut dans l'installation de Haiku, il est réservé aux personnes aventureuses qui utilisent Haiku sur une tablette ou qui débugguent un pilote de clavier en ne disposant que d'un écran tactile comme périphérique d'entrée.

Correction du traitement des appels systèmes interrompus (SIGINT), ce qui permet à input server de s'arrêter (et de se redémarrer) lorsqu'on le lui demande. Cela est principalement utile pour tester les pilotes de périphériques d'entrée.

screen blanker

L'écran de veille utilise le mot de passe "système" (configuré dans /etc/passwd) au lieu d'implémenter son propre système de mot de passe. La commande screen_blanker permet de lancer l'écran de veille immédiatement, et peut être configurée comme un raccourci clavier pour implémenter un verrouillage simple de la session (note: ne faites pas confiance à l'écran de veille pour sécuriser votre session, actuellement il est assez facile à contourner par exemple à l'aide du debugger noyau).

launch daemon

Améliorations sur le launch_daemon: correction du traitement des conditions échouées pour lancer un service, ajout de la possibilité de définir une condition sur le contenu d'un fichier au format "driver settings" (format similaire aux fichiers ini) en plus des fichiers BMessage (format binaire), correction de l'arrêt des services.

app server

Remise en route du test_app_server (outil de test permettant de lancer un deuxième app_server dans une fenêtre, et donc de tester des changements sur le serveur graphique sans avoir besoin de redémarrer tout le système).

Correction de bugs dans app_server pour l'affichage de texte: retrait de code dupliqué, ajout de nouveaux cas de test, meilleure gestion du clipping et des "bounding boxes" des glyphes, correction de problèmes sur les lignes de "décoration" (texte souligné, barré) utilisées en combinaison avec une transformation (rotation, déformation).

Par augiedoggie, korli, nipos, madmax

Pilotes

Le pilote i2c prend en charge les plateformes AMD en plus des machines PCH Intel. Le module i2c utilisé (conçu par Designware) est le même pour les deux fabricants à quelques petits détails près.

Amélioration de la détection du pointeur racine ACPI: ce pointeur était fourni par le bootloader sur les machines EFI, mais détecté par l'OS après démarrage sur les machines BIOS. C'est désormais la seule responsabilité du bootloader dans les deux cas, ce qui simplifie le code.

Correction d'un crash sur certaines machines dans le pilote des batteries ACPI.

Ajout de vérifications supplémentaires et corrections du traitement de quelques cas particuliers dans la pile XHCI (USB3).

La gestion des "révisions" des périphériques virtio a été mise en conformité avec la spécification virtio. Pour les anciennes versions de virtio, ce champ de la configuration PCI indiquait la version du protocole virtio à utiliser. Mais cela implique qu'un seul pilote virtio (identifiant les périphériques par leur ID PCI uniquement) doit implémenter toutes les versions de virtio. Pour les nouvelles spécifications, ce sera donc le "device ID" qui va changer, et il sera beaucoup plus simple de développer des pilotes spécifiques "virtio v1", "virtio v2", etc pour chaque version majeure.

Mise à jour des pilotes wifi iaxwifi200 (nommé iwx chez BSD) et ethernet atheros813x pour supporter de nouvelles générations de matériel. Import du nouveau pilote FreeBSD pour les cartes MT7601U, mais il n'y a pas encore de confirmation de son bon fonctionnement sous Haiku.

Nettoyage de code dans les pilotes SCSI et ralinkwifi.

Dans le pilote NVMe, activation de l'option de mise en veille automatique qui permet de réduire la consommation électrique lorsque le disque n'est pas sollicité (réduction de 1W constatée sur certaines machines).

Correction de problèmes dans les pilotes d'entrée (clavier, souris) qui empêchent de redémarrer l'input_server et de retrouver l'usage de ces périphériques.

Ajout de la tablette graphique Cintiq13HD dans le pilote Wacom.

Correction du pilote framebuffer pour ne mapper en mémoire que la zone utilisée pour le framebuffer, et pas toute la mémoire de la carte graphique. Non seulement cela réduit la consommation mémoire reportée, mais surtout, le reste de la mémoire peut ainsi être configuré pour autre chose (par exemple, de l'accélération 3D).

Ajout des cartes Polaris 10 et correction de quelques erreurs de versions du chipset pour d'autres cartes dans le pilote Radeon HD. Ces cartes récentes sont toujours désactivées dans le pilote, le support reste expérimental et peut conduire à un écran noir. Il vaut mieux donc utiliser les pilotes VESA ou framebuffer pour l'instant.

Par ilzu, korli, Lt-Henry, waddlesplash

Systèmes de fichiers

Poursuite d'investigations pour améliorer le temps d'exécution de "git status" qui est anormalement lent par rapport à la même opération sous Linux. Amélioration de l'itération sur les arbres B+ dans BFS, qui faisaient plusieurs "get" et "put" du même bloc disque successif (les opérations "get" et "put" permettent d'obtenir l'accès exclusif à un bloc disque, puis de le libérer, le cache de blocs se chargeant de lire les blocs depuis le disque, puis de les réécrire lorsque c'est nécessaire).

Amélioration également des verrous de parallélisme dans BFS, ce qui devrait corriger quelques kernel panic.

Correction d'un blocage de ramfs lors de l'utilisation de "trim" pour libérer de la mémoire.

Ajout d'un contrôle du flag O_DIRECTORY dans plusieurs systèmes de fichiers lors de l'ouverture d'un fichier. En particulier cela permet d'écrire une image disque sur un disque à l'aide de la commande cp fichier.image /dev/disk/.../raw.

Plusieurs corrections sur le pilote NFS4 qui était délaissé depuis quelque temps: gestion des inodes "périmés" (fichier présent dans un cache local, mais supprimé par une autre machine sur le serveur), et correction d'autres problèmes rendant le pilote instable. Ajout également de divers outils de debug pour investiguer l'état du pilote.

Le serveur userlandfs peut être lancé plusieurs fois (B_MULTIPLE_LAUNCH), ce qui permet d'utiliser plusieurs systèmes de fichiers FUSE ou userlandfs en même temps.

Par augiedoggie, Jim906, waddlesplash, x512

libroot

Bibliothèque C standard

dlsym(RTLD_NEXT) et d'autres fonctions similaires du runtime_loader recherchent maintenant les symboles dans toutes les régions ELF chargées, et pas seulement dans la première.

Ajout de RTLD_NOLOAD dans la fonction dlopen, ce qui permet d'accéder à des symboles déjà présents dans l'exécutable sans charger un fichier de librairie à nouveau. Il ne s'agit pas d'une fonction standard C ou POSIX, mais d'une extension proposée par GNU et la glibc.

Ajout de la fonction getloadavg qui permet d'obtenir une mesure de la charge du système. Cela peut être simplement informatif (dans des outils comme htop) ou utilisé pour allouer au mieux les ressources CPU (l'outil de build ninja peut par exemple utiliser cette valeur pour décider combien de jobs lancer en parallèle)

Mise en conformité de l'ordre d'appel des destructeurs de pthread_key (il faut potentiellement appeler les destructeurs plusieurs fois, jusqu'à PTHREAD_DESTRUCTOR_ITERATIONS, pour contourner les problèmes d'interdépendances). Correction de l'ordre d'appel des destructeurs lors de l'arrêt d'une application: les destructeurs globaux C++ doivent être appelés avant les destructeurs de threads (il existe plusieurs méthodes pour enregistrer des fonctions à exécuter à l'arrêt d'un thread ou d'un programme, et c'est assez compliqué de toutes les séquencer correctement).

Une petite optimisation de pthread_cond_signal pour éviter un appel système dans certains cas.

Poursuite du remplacement de fonctions de la libroot par les versions provenant de musl: memmove, strlen, strlcat, ainsi que toutes les fonctions de conversions entre chaînes de caractères et nombres flottants.

Synchronisation de l'implémentation de glob avec FreeBSD.

Optimisation de la famille de fonctions memcmp, strcmp, strncmp: utilisation de comparaisons sur 64 bits lorsque c'est pertinent, retrait de calculs inutiles.

Réécriture et optimisation des fonctions génériques memcpy et memset (utilisées pour les machines qui n'ont pas une version optimisée manuellement en assembleur). Utilisation de la version optimisée de NetBSD pour les machines x86 32 bits. Pour la version 64 bits, le code utilisé par Haiku est meilleur que celui des autres systèmes, et reste donc en place. Le bootloader utilise uniquement la version générique pour simplifier les choses (il n'a pas besoin de fonctions de très haute performance).

Correction de la fonction write() avec une taille supèrieure à 2Gio sur les systèmes 64 bits (la taille était accidentellement tronquée à 32 bits).

Mise en conformité POSIX de la fonction dup3: retour de EINVAL si l'ancien et le nouveau descripteur de fichier sont identiques.

Déplacement de la fonction qsort_r de la libgnu vers la libroot (elle a été standardisée dans POSIX Issue 8). Il s'agit d'une version de qsort permettant de passer un paramètre supplémentaire à la fonction de comparaison contenant un contexte réservé à l'utilisateur de la fonction.

Nettoyage du code restant dans la libroot qui provient de la glibc: retrait de déclarations internes présentes dans les en-têtes publics, retrait de fonctions qui ont déjà été remplacées, suppression de fichiers non utilisés, remplacement d'un maximum de fonctions par les versions de musl ou de BSD, ajout des fonctions stdio_ext de musl en remplacement des fonctions privées supprimées, retrait d'une partie des fonctions mathématiques au profit de celles de musl, retrait d'une couche d'abstraction pour l'interfaçage entre la glibc et le support des locales dans Haiku. Certaines parties de la glibc continuent d'être utilisées pour assurer la compatibilité avec BeOS, mais l'objectif est de minimiser cette partie et d'utiliser les fonctions de BSD ou de musl, qui sont souvent beaucoup plus simples. La raison est que la glibc est conçue pour pouvoir être utilisée comme librairie C alternative sur de nombreux systèmes, et doit donc avoir un comportement très proche de la librairie C originale. Par exemple, le format des nombres "long double" peut être différent d'une architecture et d'un système à l'autre, et la glibc implémente de nombreux formats spécifiques, là où musl se contente des formats les plus classiques.

Mise à jour de getopt, printf et scanf avec la verson de la glibc 2.41. Pour l'instant ces fonctions continuent d'utiliser la version de la glibc, afin de préserver la compatibilité avec les applications existantes (notamment les applications pour BeOS). En effet, des structures internes sont exposées dans l'ABI et ne peuvent pas être facilement remplacées par une autre implémentation.

Tous ces changements sur la librairie C standard sont faits également en collaboration avec un développeur de la gnulib, dont la suite de tests permet de repérer de nombreux comportements incorrects ou non standards.

Gestion de la mémoire

Finalisation d'un gros chantier de refonte de la gestion de la mémoire, avec en particulier la possibilité de fusionner des zones de mémoire adjacentes lorsqu'elles sont redimensionnées. Suite à ces changements, l'allocateur mémoire hoard2 a pu être remplacé par une nouvelle implémentation basée sur celle de OpenBSD, avec quelques adaptations et améliorations spécifiques à Haiku, dont en particulier un cache d'allocation global pour chaque application. Le nouvel allocateur est légèrement plus rapide en général, et plusieurs ordres de grandeur plus rapide sur certains cas particuliers (par exemple: gcc avec les options de link-time-optimization, ou le compilateur SDCC, ou un test de compilation passe de plusieurs heures à une ou deux minutes). Ce nouvel allocateur est également moins consommateur de mémoire et permet aux applications d'allouer plus de mémoire (hoard2 limitait les allocations à environ 3Go y compris sur les systèms 64 bits).

Amélioration des messsages d'erreur de la "guarded heap" (allocateur mémoire de débug) pour afficher des messages d'erreurs plus spécifiques au lieu de "generic segfault".

Autres changements

Ajout de macros manquantes dans le fichier elf.h ainsi que de la constante MAP_FILE (inutile mais présente sur Linux et tous les systèmes BSD) pour faciliter le portage de WebKit.

Interdiction de l'appel de create_sem avec un compteur négatif. Cela était interdit par BeOS mais autorisé par Haiku et il n'y a pas vraiment de raison de le faire.

Modification du code assembleur d'appel des appels systèmes pour inclure des informations de debug sur la pile d'appels. D'autre part, dladdr a été modifié pour pouvoir accéder aux informations sur ces symboles, qui sont chargés dans la commpage (une zone de mémoire partagée entre le noyau et les processus utilisateurs, qui n'est pas à proprement parler une section de code classique en mémoire). Cela permet à libunwind d'analyser une stacktrace comprenant un appel système.

Par korli, PulkoMandy, trungnt2910, waddlesplash, zeldakatze

Noyau

Désactivation des états de veille C5 et C6 sur les machines Intel "Skylake", car elles empêchent ces machines de démarrer correctement pour l'instant.

Réparation du cache d'objets "guarded heap" qui permet de détecter et d'investiguer certains problèmes d'allocation mémoire dans le noyau.

Traitement d'un cas d'erreur dans le cache de fichiers, si la taille d'un fichier est devenue plus petite que son cache entre le moment ou une application demande un accès et le moment où l'accès va effectivement être réalisé.

Protection de l'accès à certains "spinlock" par des mutex. L'accès aux spinlocks doit être rapide, puisque l'attente est faite de façon active et monopolise un coeur de CPU. Il faut donc s'assurer que le spinlock pourra être rapidement disponible. En particulier, l'affichage de logs à l'écran lors du démarrage pouvait considérablement ralentir les choses (l'affichage se fait page à page et le processus de démarrage est mis en pause en attendant que l'utilisateur appuie sur une touche).

Déplacement de la calibration du timer APIc x86 dans le noyau au lieu du bootloader. Amélioration de la précision de la mesure et utilisation de la calibration fournie via les registres CPUID si elle est disponible (c'est le cas pour certains hyperviseurs par exemple, sur lesquels le système virtualisé peut difficilement faire lui-même une mesure fiable).

Correction du traitement d'un cas particulier par mprotect, qui se manifestait par un kernel panic lors de l'utilisation du navigateur Iceweasel.

Ajout d'un timeout sur l'envoi d'infos sur le port série sur les machines x86. Par exemple sur le Steam Deck, le port série n'est pas du tout présent et cela empêchait le démarrage du système.

Réécriture de la fonction x86_{read|write}_msr pour les machines 32 bit en tant que fonction inline (c'était déjà le cas pour les machines 64 bits).

Correction de problèmes trouvés en essayant de démarrer Haiku sur un laptop très récent: ajout du support de X2APIC dans le bootloader EFI, allocation de la page "PML4" avec une adresse physique < 4Go pouvant être codée sur 32 bits, et à l'inverse traitement correct de la table GDT lorsqu'elle se trouve au-delà de cette limite de 4Go.

Déplacement de code de bfs vers le VMCache générique pour traiter le cas particulier du mmap sur un fichier dont la taille n'est pas un multiple de la taille de pages du système. La dernière page doit alors être remplie avec des 0. Cela avait été corrigé pour bfs, mais le problème était également présent pour d'autres systèmes de fichiers dont en particulier ramfs.

Réécriture des FIFOs noyaux (utilisés pour implémenter pipe(2)). Le benchmark stress-ng --pipe 1 passe de 230 Mo/s à 2.5Go/s (dans une machine virtuelle).

Ajout d'une option syslog_max_history pour pouvoir conserver plus que 2 fichiers de syslog (ce qui reste l'option par défaut).

Nettoyage et optimisation de la structure Thread utilisée dans le noyau pour représenter les threads: utilisation d'une liste doublement chaînée pour accélérer les manipulations de la liste, correction du décomptage du temps CPU utilisé par les processus, correction d'une fuite mémoire, et correction d'un problème dans la fonction get_next_thread_info si les identifiants de threads bouclent (c'est-à dire que plus de 4 milliards de threads ont été créés et que des identifiants de threads ont donc dû être recyclés).

Le kernel panic se produisant si un thread tente de libérer un mutex qui ne lui appartient pas affiche automatiquement la stacktrace du thread qui est propriétaire du mutex.

Ajout d'un appel à cpu_pause dans le code des conditions variables pour réduire la consommation électrique inutile lors d'une attente active.

Correction de plusieurs problèmes de sauvegarde du contexte de la FPU pour l'architecture x86_64:

  • Remise à 0 de l'état de la FPU lors des changements de threads,
  • Stockage de l'état de la FPU dans la structure d'info sur le thread au lieu de la stocker sur la pile,
  • Envoi des bons codes d'exception FPE_* lors des exceptions SIGFPE,
  • Gestion des "control words" lors des changements de contexte.

Cela corrige des crashs d'application et même des kernel panic dans certains cas.

Les drapeaux de protection des zones de mémoire du noyau ne sont plus visibles par les utilisateurs non privilégiés. L'utilisateur "user" principal peut toujours y accéder, cela est utilisé par exemple par ProcessController. Correction d'un flag mal positionné pour les zones mémoire de l'allocateur "slab", qui n'étaient pas indiquées comme accessibles en écriture.

Renommage des fonctions concernant la gestion des interruptions pour éviter l'abbréviation "int" qui pouvait prêter à confusion avec "integer" dans certains cas. Utilisation du mot complet "interrupt" lorsque c'est possible, ou à défaut de "intr".

Correction d'une fuite de mémoire dans la gestion de la mémoire physique avec du paging à 5 niveaux (LA57).

Correction d'un interblocage dans le cache du système de fichier identifié à l'aide des tests de gVisor.

Correction d'un bug dans la fonction vsnprintf du noyau qui n'affichait pas correctement les nombres inférieurs à 0.1 (les 0 après le point étaient perdus, et donc 0.01, 0.001. 0.0001, … étaient tous affichés comme 0.1).

L'appel système create_dir retourne EEXIST si un fichier ou un dossier existe déjà à l'endroit demandé, et ce, même si le système de fichier est en lecture seule. Auparavant, l'appel système retournait EROFS, ce qui perturbe certaines applications.

Amélioration du traitement des "doubles fautes" (lorsque le traitement d'une exception matérielle déclenche une autre exception matérielle) sur x86. Le registre GS était corrompu, ce qui empêchait l'utilisation du debugger dans ce cas, et plusieurs autres problèmes conduisaient vraissemblablement à une "triple faute" (une exception dans le traitement de l'exception dans le traitement de… bon vous voyez le principe), et à un redémarrage de la machine car à ce stade il est peu probable qu'aucune autre opération ne remette le système dans un état cohérent.

Bootloader

Amélioration du bootloader PXE pour afficher clairement "Network" dans la méthode de démarrage, ainsi que l'adresse IP du serveur de disque fournissant le rootfs.

Remise en route du développement sur la console graphique utilisée pour simuler un mode texte pour le menu de démarrage, lorsque la machine ne fournit pas un mode texte matériel ou au niveau de son BIOS (c'est le cas par exemple sur certains Chromebooks avec SeaBIOS). Pour l'instant, cela nécessite une version du bootloader compilée spécifiquement pour ce cas de figure, car on ne sait pas encore détecter de façon fiable si le mode texte du BIOS est disponible.

Par Anarchos, augiedoggie, korli, phcoder, waddleslplash

Scripts de compilation

Poursuite du travail pour corriger tous les warnings détectés par le compilateur, ainsi que quelques problèmes détectés par les sanitizers de gcc (libasan et libubsan) qui sont maintenant compatibles avec Haiku.

Correction de problèmes empêchant de cross-compiler Haiku depuis FreeBSD ou un système Linux utilisant la libc musl. Correction également de problèmes pour le build depuis macOS.

Suppression de fichiers inutiles dans la version de unzip intégrée dans le build de Haiku.

Généralisation des options permettant d'activer la "stack protection" à plus de parties du système.

Remplacement de la commande which par command -v. Cette dernière est un builtin de la plupart des shells, elle est donc plus rapide à exécuter et ne nécessite pas une dépendance supplémentaire.

Migration de Python 2 à Python 3 pour le script générant les fichiers "libroot stubs" (utilisé uniquement lors du bootstrapping de Haiku pour une nouvelle architecture).

Mise à jour de la version de m4 utilisée pour le bootstrap de Haiku (compilation de tous les paquets à partir des sources, utile en particulier pour le portage sur une nouvelle architecture).

Ajout des modules PCI manquants dans l'image de bootstrap.

Par korli, PulkoMandy, waddlesplash

Documentation

Ce trimestre, il y a principalement du travail sur la documentation interne. Il s'agit d'un document destiné aux développeurs de Haiku, par opposition aux développeurs d'applications pour Haiku, qui se tourneront plutôt vers le Haiku book pour les informations sur les interfaces publiques du système.

Mise à jour de la documentation sur la procédure à suivre pour synchroniser du code avec d'autres systèmes. Haiku réutilise du code de FreeBSD, NetBSD, OpenBSD, musl et quelques autres, et maintient également deux copies de gcc et des binutils. Il est important d'avoir une procédure bien définie pour tracer ce qui a été importé, depuis quelle version, et quels changements ont été effectués. Plusieurs documentations existaient avec différentes fçons de faire, dont certaines étaient obsolètes.

Dans la documentation du device manager, ajout d'une image montrant un exemple de device tree, pour mieux visualiser ce qui est expliqué dans la page.

Déplacement d'articles sur l'implémentation des appels systèmes du site web principal vers la documentation interne (dans le cadre d'un très long projet pour réorganiser la documentation et libérer le site principal de nombreux articles techniques pour en faire une vitrine plus orientée vers les utilisateurs).

Ajout dans la documentation interne d'un article sur le profilage et l'analyse de performance des applications.

Correction de liens internes morts dans la documentation interne sur la gestion des paquets, suite à des erreurs de formatage.

Mise à jour de la documentation interne sur le processus de bootstrap.

Par kuku929, oco, PulkoMandy, waddlesplash

Commentaires : voir le flux Atom ouvrir dans le navigateur

QuickJS version 2025-04-26 et QuickJS-NG version 0.10

16 mai 2025 à 10:27

Finalement Fabrice Bellard est comme tout le monde, lui aussi numérote ses versions avec des dates, c'est plus simple. Voici donc la version annuelle de QuickJS (licence MIT), son moteur JavaScript incorporable et compact (le binaire Linux 64 bits fait 757 kiB). QuickJS est compatible avec ECMAScript 2023 — sauf pour les appels tails que les auteurs ne trouvent pas indispensables — et passe presque toute la suite de tests ECMAScript (en sélectionnant ES2023).

En 2023, pour revivifier un développement un peu dormant, la fourche QuickJS-NG a été lancée (par un des contributeurs de Jitsi). QuickJS-NG est intéressant pour ceux qui veulent utiliser cmake et compiler le projet sous Windows avec le compilateur C Microsoft. Il intègre aussi le support de quelques fonctionnalités récentes de la norme JavaScript que QuickJS ne supporte pas encore. (Je cite Fabrice Bellard). Les différences ne sont pas énormes. La version 0.10 est toute neuve.

Ci-après, Fabrice Bellard m'a très gentiment expliqué les principaux changements de QuickJS.

Changements les plus importants dans QuickJS 2025-04-26

Les explications viennent de Fabrice Bellard :

  • La suppression d'extensions non standardisées que j'avais ajoutées pour avoir des nombres flottants en précision arbitraire et la surcharge des opérateurs. Précision historique : j'ai créé QuickJS au début afin d'avoir une calculatrice avec une syntaxe compatible JavaScript. L'idée était de pouvoir manipuler des entiers ou des nombres flottants en précision arbitraire, des polynômes ou des matrices tout en utilisant une syntaxe familière. D'où des extensions au langage JavaScript présentes dans QuickJS. Mais ces extensions étaient compliquées et source de bugs, donc j'ai décidé de les supprimer. La calculatrice est maintenant un projet à part1.
  • L'implémentation des BigInt se reposait sur la librairie libbf que j'ai supprimée avec les extensions non standardisées. Il y a donc une nouvelle implémentation des BigInt, plus rapide et plus simple.
  • La réimplémentation des "weak references" avec le support de fonctions présentes dans ES2023. QuickJS-NG les supportait déjà mais avec une implémentation qui utilise plus de mémoire, est moins efficace et surtout potentiellement incorrecte en présence de cycles.
  • La concaténation de petites chaînes de caractères est plus rapide grâce à l'utilisation de "ropes". Beaucoup de programmes fabriquent de longues chaînes de caractères en concaténant des petites chaînes de caractères avec une grosse s = ""; for(i=0;i<n;i++) s += "a". C'est une méthode déconseillée car inefficace, mais les moteurs JavaScript comme V8, SpiderMonkey ou JavaScriptCore l'optimisent donc elle est très utilisée.
  • Ajout des numéros de colonne dans les erreurs. QuickJS-NG le faisait déjà mais la méthode ne me convenait pas. Celle utilisée dans QuickJS est plus simple et (normalement) plus précise.
  • Les nombres flottants sont maintenant analysés et convertis en chaînes de caractères sans utiliser la librairie C. Cela est nécessaire pour être complètement compatible avec la norme JavaScript et accroître la portabilité du code.

Principaux changements de QuickJS-NG 0.10

  • Implémentation de Array.fromAsync
  • supporte os.Worker sur Windows
  • ajout du mode de build parserless
  • ajout de os.exePath()
  • ajouts des hooks Promise
  • correction des Promise non gérés
  • nouvelle implémentation de BigInt par Fabrice Bellard (voir ci-dessus)
  • et divers…

Sous-projets

QuickJS héberge des bibliothèque C qu'on peut utiliser pour d'autres projets :

  • libregexp : une bibliothèque Regexp petite et rapide, totalement conforme aux spécifications Javascript ES2023.
  • libunicode : une petite bibliothèque Unicode supportant les conversions de casse, la normalisation unicode, les requêtes unicode scriptées, les requêtes unicode de catégorie générale et toutes les propriétés unicode binaires.
  • dtoa : une petite bibliothèque pour l'impression et l'analyse syntaxique en float64.

Téléchargements

Les binaires sont dispos avec jsvu (JavaScript Version Updater, de Google) ou esvu (ECMAScript Version Updater, projet communautaire), ainsi qu'en téléchargement depuis les sites respectifs. Fabrice Bellard a aussi préparé des binaires QuickJS construits avec la Libc Cosmopolitan pour Linux, Mac, Windows, FreeBSD, OpenBSD, NetBSD tant sur les architectures ARM64 que x86_64.


  1. NumCalc n'est pas encore indépendant de QuickJS, mais c'est le but. Pour l'instant la nouvelle calculatrice (bfcalc) n'est disponible qu'en ligne de commande. 

Commentaires : voir le flux Atom ouvrir dans le navigateur

QEMU 10.0

Comme tous les ans, Qemu sort une nouvelle version majeure. Le numéro n'implique donc pas de grands bouleversements. Il s'agit plutôt d'une base stable qui va être maintenue et améliorée pendant quelques années. Ainsi, les versions 7, 8 et 9 ont eu des mises à jour en mars 2025.

Comme d'habitude, les architectures ARM et Risc-V se taillent la part du lion et sont enrichies de nouvelles architectures. Les accès aux stockages sont partout plus rapides, et l'espace utilisateur accède toujours mieux au matériel.

Qemu est devenu une pièce importante dans le monde des serveurs et des développeurs. En tant qu'émulateur il permet de développer, compiler ou lancer un programme sur un processeur ou une machine différente. Couplé à KVM, XEN ou VMWare, il permet une virtualisation performante.

Quoi de neuf ?

L'article de Next résume bien les changements sur ARM et Risc-V. C'est technique, n'étant pas connaisseur je vous y renvoie.

x86 bénéficie de changements globaux à toutes les architectures avec quelques ajouts spécifiques pour des processeurs Intel. Mon petit doigt impatient de tester me souffle que ça sera plus rapide avec des accès "multithread1" aux périphériques de stockage (virtio-scsi et virtio-blk). L'accès direct au matériel en espace utlisateur continue de s'améliorer (VFIO, fonctions virtuelles d'entrées-sorties).

Les autres changements concernent l'émulation des architectures HPPA et S390.

Attention aux trucs enlevés

À chaque version ou presque, des morceaux sont enlevés. Si vous faites dans l'exotique, ne vous précipitez pas sur la dernière version sans consulter la liste des Removed features.

Documentation d'introduction pour QEMU et la virtualisation

En guise de conclusion, voici quelques pistes pour ceux et celles qui débutent avec la virtualisation sous Linux et/ou QEMU. Différentes distributions Linux ont de la documentation sous licence libre. Loin d'être exhaustif, voici quelques choix :


  1. Qu'on me pardonne ce mot, je simplifie pour faire court! 

Commentaires : voir le flux Atom ouvrir dans le navigateur

Kivy : un cadriciel graphique unique en Python

6 mai 2025 à 17:13

Kivy est un cadriciel (framework) graphique, permettant de développer des interfaces tactiles (ou utilisable à la souris) sur toutes les plateformes, y compris mobiles. Il s'accompagne d'une suite de logiciels très pratiques que nous allons présenter ici.

logo Kivy

Sommaire

Kivy : boîte à outils graphique multi-plateformes

Kivy permet de créer des interfaces graphiques naturellement adaptées aux écrans tactiles (mais qui restent utilisables sur un environnement de bureau traditionnel, à la souris et sans écran tactile). Il est écrit principalement en Python mais les parties critiques sont écrites en Cython, ce qui lui permet d’avoir de bonnes performances.

Une interface Kivy peut s’écrire de deux façons (ou, plus couramment, par une combinaison de ces deux façons) : en Python directement, ou via kv, une syntaxe déclarative dont nous parlons plus bas.

Pour vous donner une idée, voici un exemple de hello world repris du site officiel de Kivy :

from kivy.app import App
from kivy.uix.button import Button

class TestApp(App):
    def build(self):
        return Button(text='Hello World')

TestApp().run()

Ce qui donnera :
capture d’écran du hello world

Une interface est composée de « widgets » agencés via des « layouts ». Certains widgets permettent de facilement mettre en place des composants communs de nos jours, comme par exemple le widget Carousel :
capture d’un widget Carousel

D’autre part, Kivy fournit des outils qui simplifient la vie du développeur ou de la développeuse, en particulier un système de propriétés (à ne pas confondre avec les propriétés Python) qui permet de mettre automatiquement l’interface à jour quand elles sont modifiées, ou de facilement attacher une fonction de rappel (« callback »), voir plus bas pour un exemple simple. On peut aussi citer un mécanisme d’animations très pratique et efficace.

kv : interface graphique en déclaratif

kv est un langage permettant de décrire des interfaces, il met à profit les propriétés mentionnées plus haut et l’interface va se mettre à jour automatiquement quand des propriétés utilisées dans kv sont modifiées.

Reprenons le hello world vu plus haut, et faisons-le avec kv:

Widget:
    Button:
        text: "Hello World"

Plutôt simple non ?
Le code kv est généralement mis dans des fichiers séparés avec l’extension .kv.

Les propriétés

Kivy a donc un concept de propriété, qui permettent la liaison de données bidirectionnelles (two-way data binding), ou en d’autres termes de facilement avoir l’état mis à jour entre le code python et l’interface décrite dans le fichier kv. C’est à l’usage très pratique et facile.

Un exemple va sans doute aider à comprendre.

Commençons par faire un environnement virtuel Python avec Kivy:

$ mkdir demo

$ cd demo

$ python -m venv env

$ source env/bin/activate

$ pip install kivy

Ensuite créez le fichier demo.py suivant :

from kivy.app import App
from kivy.uix.boxlayout import BoxLayout
from kivy.properties import NumericProperty

class CompteurWidget(BoxLayout):
    compteur = NumericProperty(0)

    def increment(self):
        self.compteur += 1

class DemoApp(App):
    def build(self):
        return CompteurWidget()

DemoApp().run()

Et maintenant, dans le même répertoire, ajoutez le fichier demo.kv suivant, ce dernier sera automatiquement découvert par Kivy parce qu’il s’appelle comme notre application (DemoApp) sans le suffixe App et en minuscule :


<CompteurWidget>:
    orientation: 'vertical'
    padding: 20

    Label:
        text: str(root.compteur)
        font_size: 30

    Button:
        text: "Incrémenter"
        on_press: root.increment()

Il ne nous reste plus qu’à lancer le programme :

python demo.py

Et à admirer :

capture d’écran du programme de démo

Le label se met automatiquement à jour quand le compteur compteur est incrémenté.

La lectrice ou le lecteur assidu de DLFP pourra faire un TapTempo en exercice.

Note: Ne vous arrêtez pas au fait que l’UI est un peu "moche" par défaut, il y a des extensions beaucoup plus attractives (cf. KivyMD plus bas), et il est très facile de personnaliser l’interface et d’en faire une très belle en modifiant un peu ses fichiers .kv.

Plyer : accéder facilement aux fonctionnalités matérielles de votre appareil

Plyer est une bibliothèque permettant d’accéder à nombre de fonctions utiles de manière indépendante de la plateforme. Ainsi vous avez une API commune pour afficher une notification, demander l’état de la batterie, faire vibrer l’appareil, faire de la synthèse vocale de texte (« text-to-speech »), ouvrir un fichier avec le dialogue natif de la plateforme, etc.

Bien que développé par la même équipe que Kivy, ce paquet est utilisable indépendamment et est donc particulièrement utile pour n’importe quel projet multi-plateformes. Référez-vous à la page du projet pour avoir un tableau des fonctionnalités supportées selon les plateformes, et à la documentation pour plus de détails.

Python For Android : utiliser Python… sur Android

Si vous souhaitez distribuer votre application sur Android, vous allez devoir avoir une version de Python compilée pour cette plateforme, ainsi que de tous les paquets nécessitant une compilation.

C’est le rôle de Python pour Android, qui est une collection d’outils qui s’appuient sur l’Android SDK pour permettre d’utiliser Kivy ou d’autre paquets Python sur Android, et ainsi faire votre propre distribution Python.

Si vous utilisez un paquet qui n’est pas en pur Python (c’est-à-dire qu’il y a des parties à compiler) et qui n’est pas encore disponible ou qui l’est mais dans une version trop ancienne, vous pouvez écrire ou mettre à jour des « recettes » (recipes en anglais) qui indiquent comment compiler. Référez-vous à la documentation pour voir comment faire.

Notez toutefois qu’il y a une pénalité à utiliser du Python par rapport à une application dans un langage compilé : il faut charger l’interprète au démarrage, et au tout premier lancement de votre application (et uniquement au premier) il y a aura une phase de décompression de vos fichiers. En dehors de ces petits inconvénients, ça fonctionne très bien.

Là encore, le projet est indépendant de Kivy et peut être utilisé avec un autre cadriciel.

Kivy for iOS : déployez sur les appareils Apple

À l’instar d’Android, l’équipe de Kivy fournit les outils pour faire votre distribution Python pour iOS.

Il vous faudra posséder une machine Apple pour les utiliser, à cause des restrictions imposées par cette plateforme (ceci n’est pas spécifique à Kivy pour iOS, mais s’applique à tous les outils pour développer sur iOS).

Ainsi avec une seule base de code (et après avoir passé un peu de temps pour configurer correctement les outils de compilation), vous pouvez déployer votre application Kivy/Python sur toutes les plateformes majeures (hormis le web, pour lequel il existe d’autres options comme Brython, Pyodide ou PyScript, mais c’est un sujet pour une autre dépêche).

Pyjnius : utiliser l’API Java Android depuis Python

Parfois l’utilisation de Plyer mentionné plus haut et de la bibliothèque standard Python ne suffisent pas, et vous avez besoin d’accéder à l’API d’Android, mais cette dernière est faite pour être utilisée avec Java ou Kotlin.

Pour pouvoir utiliser l’API d’Android depuis Python, PyJNIus est disponible. Ce paquet permet d’accéder aux classes Java comme à des classes Python en utilisant JNI (« Java Native Interface » ou « Interface Native de Java »).

Ce paquet fournit une méthode autoclass qui convertit automatiquement une classe Java en Python, c’est très facile à utiliser et souvent suffisant pour les cas simples.

KivyMD, des widgets Material Design

KivyMD n’est pas un projet officiel de l’équipe Kivy, mais un projet tiers dédié à la création d’un ensemble de Widgets thémables adoptant Material Design.

Image d’exemple de KivyMD issue de la documentation

L'image ci-dessus est issue de la documentation de KivyMD, vous trouverez également des démos vidéo sur le dépôt du projet.

Quelques limitations

Une petite note sur mon expérience personnelle (Goffi). Kivy est un excellent cadriciel, et l’équipe est accueillante et réactive : c’est un projet que je recommanderais en général. Ceci dit, dans mon cas particulier (un client XMPP ayant de nombreuses fonctionnalités), j’ai quelques limitations qui me poussent actuellement à chercher des alternatives, notamment basées sur Qt (PyQt et PySide) :

  • l’accessibilité est un problème majeur. L’équipe y travaille, mais aujourd’hui les applications Kivy ne sont pas accessibles. C’est notamment dû au fait que l’interface utilisateur est entièrement gérée par Kivy, au lieu d’utiliser des composants natifs, et c’est un point complètement bloquant pour moi.
  • il n’y a pas de webview ou de rendu HTML natif, ce qui est bloquant parce que je fais du rendu de blogs.
  • le rendu de texte est incomplet, notamment sur les plateformes mobiles. C’est compliqué de faire un rendu riche avec des émojis, par exemple, un gros problème pour une application de messagerie de nos jours.
  • le support des portails Freedesktop est inexistant : il faut faire l’implémentation à la main, alors qu’il est natif sur des cadriciels majeurs comme GTK ou Qt. Je pense par exemple à l’ouverture ou l’enregistrement de fichier. Les portails sont particulièrement nécessaires si on veut voir son application sur Flatpak. Plus de détails sur ce ticket.
  • le support Wayland existe, mais lors de mes tests sur des distributions GNU/Linux sur Pinephone, il n’a pas fonctionné et je n’ai pas pu afficher l’application.
  • le chargement de l’interprète Python prend un certain temps, ce qui rend le lancement de l’application sur plateformes mobiles telle qu’Android et probablement iOS (que je n’ai pas testé) un peu lent. Sachant que sur ces plateformes l’application peut être tuée à n’importe quel moment auquel cas il faut tout relancer, cela peut mener à une mauvaise expérience utilisateur. Ceci dit, avec une distribution optimisée (en enlevant les paquets non utilisés), et sur les téléphones actuels qui sont très puissants, le problème est sans doute moindre.

Notez que je n’ai pas eu l’occasion de travailler avec Kivy récemment, peut-être que ces remarques ne sont plus à jour. Merci d’indiquer en commentaires s’il y a eu de l’évolution sur ces points.

Aussi, mon cas d’utilisation est très demandant (rendu HTML, affichage de texte performant, etc). Dans la plupart des cas, Kivy remplit sans problème toutes les cases (sauf l’accessibilité, qui reste son problème le plus important à mon sens).

Conclusion

Comme vous pouvez le voir, un travail considérable a été effectué sur Kivy et son écosystème, et il en sort un cadriciel performant, pratique, et qui peut potentiellement fonctionner sur la plupart des plateformes. Kivy est agréable à utiliser, et dispose d’une communauté très active et disponible.

Ce cadriciel mérite de s’y attarder, et est une option sérieuse si vous voulez développer un projet rapidement pour une ou plusieurs plateformes.

Une note d’histoire

Cette dépêche a été commencée le 04 octobre 2018 à 14:19 (au premier jour de la Pycon FR 2018, à Lille, où une partie de l’équipe de Kivy était présente). Je crois que c’est haut la main la dépêche qui est restée le plus longtemps dans l’espace de rédaction. Comme quoi, tout vient à point à qui sait attendre, comme dirait l’autre.

Merci à toutes les personnes qui ont participé à la correction de la dépêche.

Commentaires : voir le flux Atom ouvrir dans le navigateur

WoPiX, un serveur WOPI libre, indépendant, simple et léger

Un serveur WOPI (Web application Open Platform Interface) permet à un logiciel client de modifier un fichier stocké sur un serveur. C'est la couche indispensable pour qu'OnlyOffice, LibreOffice (Collabora Online) et d'autres suites bureautiques puissent être utilisés sur le web. Ainsi, lorsque vous réclamez l'ouverture d'un document depuis votre navigateur web, vous vous connectez à la suite bureautique en ligne avec une URL particulière, contenant, entre autres, le nom du fichier à ouvrir. La suite bureautique peut alors discuter avec le serveur WOPI pour récupérer le document. Les lectures, écritures et modifications d'un document sont gérées par le serveur WOPI, à la demande de la suite bureautique. Le protocole a été créé par Microsoft en 2012, la révision 14.5 de WOPI est sortie le 18 février 2025.

Les serveurs WOPI libres de Nextcloud, Seafile, Tracim… ne sont pas indépendants. Comme je voulais utiliser Collabora Online sans déployer un NextCloud complet, j'ai écrit un serveur WOPI très simple. Il est utilisé depuis plus d'un an sans problème et il est libre. Il est écrit en Java.

J'ai commencé ce développement car je travaille sur deux lieux privés différents avec un ordinateur à chaque endroit, un NAS dans l'un d'eux et je communique entre les deux machines à l'aide d'un dépôt git sur le NAS. Ça fonctionne relativement bien pour des fichiers qui n'ont pas vocation à rester ouverts dans des applications, mais pour des fichiers ODS ou ODT qui restent ouverts, c'est plus compliqué car je me retrouve souvent avec des versions concurrentes sur les deux machines. J'ai donc regardé du côté des suites de collaboration en ligne.

À une époque , je me servais d'Etherpad et de son équivalent tableur Ethercalc. Mais ces logiciels manquent de fonctionnalités, surtout le tableur. Problème supplémentaire : j'ai déjà beaucoup de fichiers aux formats LibreOffice.

Ça tombe bien, il y a la suite LibreOffice online, éditée par Collabora Online (CODE). Le problème — comme souligné par une dépêche — c'est qu'une fois CODE installé, tu te retrouves à poil avec rien qui marche : il faut un serveur utilisant le protocole WOPI.

Pour éviter d'installer tout un NextCloud, j'ai écrit un petit serveur WOPI. C'est du Java avec Spring Boot. Le serveur est très simple, sur le principe que plus un système est simple, moins il a de chances de tomber en panne.

Par exemple, il n'y pas de droits d'accès et on ne peut pas avoir plusieurs utilisateurs simultanés. Il faudrait mettre en œuvre le système de verrous et le système de droits d'accès (faire reposer les droits d'accès sur les droits du système de fichier, implique d'avoir un utilisateur sur la machine pour chaque utilisateur du logiciel). Cela n'a pas été implanté parce que je suis le seul utilisateur sur ma machine. Mais ce ne serait pas long à développer.

Le serveur une fois lancé expose des services REST, accessibles par la suite bureautique, mais aussi un service https qui permet d'afficher la liste des fichiers. Cette liste de fichier est cliquable et permet de se connecter à Libre Office avec la bonne URL. C'est la raison des paramètres proxyHost et code URL de l'application : être en mesure de générer la bonne URL.

Liste des fichiers

Le code est prévu pour avoir plusieurs backends à l'aide d'une interface. Le seul mis en œuvre pour l'instant c'est un stockage sur disque local (avec auto discovery : on lui donne un répertoire et il expose tout les documents du répertoire).

Il consomme peu de ressources, la charge dépendra plus de Collabora Online ou d'OnlyOffice. Le serveur WOPI se contente de lire un fichier à l'ouverture et de l'écrire de temps en temps (comme lors des enregistrements automatiques).

Il n'est pas testé avec OnlyOffice. En principe WOPI est une norme et ça devrait fonctionner.

On peut le lancer avec java -jar. C'est du Spring Boot. On pourrait utiliser systemd. De mon côté, je l'ai mis dans un container docker qui lance la commande suivante

java -Dlogging.level.root=INFO \
     -Dlogging.level.org.wopiserver=INFO \
     -Dserver.port=8880 \
     -jar /opt/app/app.jar \
     --baseDir /mnt/docs \
     --disableTLSCheck \
     --codeURL https://172.17.0.8:9980 \
     --proxyHost 192.168.124.252

Le code de WoPiX est dispo sur github et je suis ouvert à toute requête :-)

Commentaires : voir le flux Atom ouvrir dans le navigateur

La version 2.2 de LDAP Synchronization Connector est là !

25 avril 2025 à 10:18

LDAP Synchronization Connector (LSC) est un outil de synchronisation de données entre référentiels d'identités (annuaires LDAP, bases de données, API REST, …) disponible sous licence BSD.

Logo LSC

Ce logiciel a été créé il y a plus de 20 ans et est déployé dans de très nombreuses organisations qui l'utilisent le plus souvent pour alimenter les comptes et groupes dans leur annuaire d'entreprise depuis leur outil RH, ou bien pour synchroniser les données entre OpenLDAP et Active Directory.

La version 2.2, en préparation depuis plusieurs années, a enfin vu le jour en ce mois d'avril 2025, grâce au travail de la société Worteks et à l'aide du programme NGI Commons de NLnet.

Configuration par variables d'environnement

La configuration de LSC se fait dans un fichier XML. Il est désormais possible d'y mettre des variables d'environnement pour par exemple passer facilement d'un environnement à un autre ou récupérer des secrets à la volée.

Voir la documentation

Hooks

Il existait déjà un plugin LSC nommé Executable qui lançait des scripts pour les ajouts/suppressions/modifications/renommages, rendant le logiciel compatible avec tous les référentiels si tant est qu'on puisse exécuter une commande pour s'y connecter.

Mais le nouveau système de hook est différent : cette fois-ci les opérations sont bien réalisées avec le connecteur natif (mais aussi pourquoi pas avec le plugin Executable) et en cas de succès, pour chaque opération et entrée, une commande est lancée.

Un cas d'usage bien connu est l'envoi d'un mail lors de la création d'un compte.

Voir la documentation

Transformation de pivot

Le pivot est la valeur qui relie une entrée en source avec une entrée en destination. Si ces deux entrées ont la même valeur de pivot, alors LSC considère que c'est la même et applique les modifications. Sinon les entrées sont créées ou supprimées.

Cependant il arrive que la valeur soit un peu différente entre la source et la destination (majuscules, minuscules, préfixe, suffixe, …), il faut donc transformer cette valeur dans un sens, puis dans l'autre.

Voir la documentation

Version de Java

LSC 2.1 était bloqué à la version 8 de Java, ce qui devenait problématique. LSC 2.2 est désormais compatible avec Java 21.

GraalVM

Les JavaScripts utilisés pour transformer les valeurs peuvent désormais être exécuté dans GraalVM, en utilisant le préfixe "gjs:"

Voir la documentation

Commentaires : voir le flux Atom ouvrir dans le navigateur

Gestion simple de tournois sportif PyTournois

Sportifs du dimanche, on a souvent besoin de gérer des tournois très simples du type « tout le monde rencontre tout le monde » avec quelques contraintes:

  • nombre de terrains limité ;
  • temps d’attente minimal entre deux matchs ;
  • règles variées sur la gestion des scores.

Depuis une vingtaine d’années, je développe différents sites en Python/Django. Du coup j’ai fabriqué un début de site :).

Code

Libriste depuis toujours, le code du projet est sous licence GPL. Actuellement très simple, le site permet de gérer uniquement le mode « toutes les équipes se rencontrent ». Plus tard, suivant les retours, les utilisations et mon temps libre, j’ajouterai d’autres modes (par exemple pour gérer des groupes de placements).

Pour éviter les calculs inutiles, l’affectation des rencontres utilise des grilles de placement. Ces grilles sont calculées une fois pour toutes et contenues dans le projet. L’avantage est d’être efficace et rapide sur la génération de toutes les rencontres. L’inconvénient est que seules quelques combinaisons sont actuellement disponibles :)

Fonctionnement

Le fonctionnement est très simple, le principe de base est que toutes les informations sont visibles sans connexion. Il y a quatre grands rôles utilisateurs:

  • administrateur: sert surtout pour créer des comptes utilisateurs ;
  • organisateur: peut créer des équipes et réinitialiser un tournoi ;
  • arbitre: peut enregistrer/modifier les résultats des matchs ;
  • anonyme: accès à la liste des matchs et au classement.

Les règles de classement sont affichées. On peut également définir un message d’accueil. Si on veut sauvegarder les résultats d’un tournoi, il y a un export au format CSV.

Démonstration

Il y a évidemment un site de démonstration du projet. Le lien se trouve ci-dessous. Les ressources nécessaires pour faire tourner le site sont extrêmement limitées. Si les fonctionnalités du site vous conviennent et que vous voulez l’utiliser pour un club/tournois, n’hésitez pas à me contacter. Je pourrais mettre en ligne une version dédiée gratuitement.

Commentaires : voir le flux Atom ouvrir dans le navigateur

yahi un agrégateur de statistiques dans l'esprit d'awstats

24 avril 2025 à 13:44

J’ai la nostalgie d’awstats : la possibilité de faire des statistiques web sans déployer des tonnes d’infrastructure (genre Grafana).

Pour cela, j’ai codé Yahi, un module Python qui agrège dans sa forme basique les statistiques web en format usuel (nginx, apache, lighthttpd, varnish) pour les présenter dans une page web « tout en un ».

Il se décompose pour sa partie utilitaire en deux scripts:
- un d'agrégation des statistique de journaux de serveurs webs dont l'écriture d'une version personnalisée ici celle que j'utilise pour faire des démos sans IP ou URLs est relativement simple;
- un de génération d'une page de visualisation HTML avec les données.

Certes cette page requiert du JavaScript pour fonctionner, mais elle requiert zéro dépendance vers des liens externes et inclut autant toutes les visualisations que les données dans une seule page (données, CSS, visualisations). Cela permet de l’avoir en marque-page grâce à quelques ruses de javascript, et cela rend son hébergement aisé pour les sysadmins. (NdM: goaccess (MIT en C) sait faire aussi).

Son API permet en outre de faire des agrégations plus compliquées.

Et, je recherche des bétas testeurs pour en faire un produit fini.

Commentaires : voir le flux Atom ouvrir dans le navigateur

❌