systemd dans postmarketOS
Récemment le les développeurs du projet postmarketOS, ont annoncé à travers un article de blog l'actualité de l'introduction de systemd aux builds du système. La raison principale pour implémenter le support systemd est la difficulté de maintenir une pile d'initialisation basée sur OpenRC face à la dépendance croissante à l'égard de GNOME et KDE des composants systemd.
La possibilité d'utiliser systemd en tant qu'administrateur système intervient après un an de travail et un prototype de configuration utilisant systemd au lieu du système d'initialisation OpenRC a été préparé et mis à disposition pour les tests.
Il est mentionné que Malgré l'ajout de systemd, le support continuera à être fourni pour créer des builds basés sur OuvertRC dans postmarketOS, au moins tant que ce système continue à être utilisé dans Alpine Linux. L'option permettant de sélectionner OpenRC sera disponible lors de la création d'images postmarketOS à l'aide de pmbootstrap. De plus, OpenRC continuera à être utilisé par les développeurs d'assemblys travaillant avec le shell graphique Sxmo (Simple X Mobile), basé sur le gestionnaire composite Sway.
En outre, le les versions avec systemd seront toujours basées sur le package de base Alpine Linux, malgré le fait que cette distribution n'a pas de support officiel pour systemd et utilise la bibliothèque Musl C au lieu de Glibc C, qui est compatible avec systemd. Les développeurs postmarketOS implémentent des correctifs supplémentaires pour intégrer systemd à Musl C et prévoient de collaborer avec les développeurs systemd pour simplifier cette intégration à l'avenir.
Bien sûr, ce n'est pas une tâche facile, l'un des principaux obstacles que nous rencontrons lorsque nous collaborons plus étroitement avec les développeurs KDE et GNOME est qu'ils ont des difficultés avec notre pile basée sur OpenRC. Pour faire fonctionner KDE et GNOME, nous utilisons de nombreux polyfills systemd en plus d'OpenRC. Ainsi, bien que techniquement "nous n'utilisons pas systemd", en pratique nous utilisons déjà une grande partie de ses composants pour exécuter KDE et GNOME, juste des versions différentes de ces composants
Pour assurer la fonctionnalité de GNOME et KDE basé sur systemd, plusieurs couches supplémentaires devaient être maintenues, et travailler sans systemd signifiait maintenir correctement ces couches et les synchroniser avec le développement de GNOME et KDE, ce qui posait des défis importants et une certaine incertitude dans la maintenance continue par les développeurs.
En plus de cela, les développeurs mentionnent que Diverses couches et packages ont été implémentés pour garantir la prise en charge des services de nom d'hôte, de localisation et d'horodatage dans postmarketOS. C'est tou inclus l'utilisation d'openrc-settingsd pour la prise en charge des services de nom d'hôte, eudev au lieu de udev pour la gestion des périphériques, elogind au lieu de logind pour la gestion des sessions utilisateur, et journal de bord au lieu de journal pour la gestion des journaux et le package superd a été utilisé pour fournir des fonctionnalités similaires à «systemd –utilisateur» et remplacer systemd.timer avec réveillé.
Cependant, une maintenance et un support appropriés ne sont garantis que pour openrc-settingsd et eudev. Des projets comme elogind, journal de bord et superd nécessitent encore des améliorations, car il leur manque certaines fonctionnalités nécessaires, et éveillé Il n'a pas été entretenu depuis environ un an. De plus, les développeurs de KDE Plasma Mobile ont exprimé leur intérêt pour l'utilisation systemd-coredumpd pour simplifier le débogage, mais en le remplaçant, collecteur de noyaux, Il n’a pas bénéficié d’entretien depuis 2020.
Ces services sont requis pour diverses fonctions de GNOME et d'autres applications. Par exemple, l'API D-Bus fournie par nom d'hôte, localisé et daté Il est utilisé dans GNOME pour modifier les paramètres régionaux et de fuseau horaire. Udev est requis pour gérer les appareils connectés, tandis que logind, "systemd –utilisateur» et journald sont utilisés pour gérer les sessions utilisateur dans gnome-session. L'horloge GNOME utilise systemd.timer pour ses fonctionnalités.
En en termes de nouvelles fonctionnalités qui peut être implémenté avec des builds basés sur systemd, y compris la gestion granulaire des privilèges, l'utilisation de fonctionnalités avancées pour garantir la sécurité et gérer les dépendances entre les services, l'intégration complète avec les groupes de contrôle, l'activation de socket pour démarrer les services selon les besoins (par exemple, CUPS ne peut être démarré que par accès au port réseau) et la disponibilité d'outils intégrés pour analyser le processus de démarrage.
enfin si tu es intéressé à en savoir plus, vous pouvez vérifier les détails dans le lien suivant.