Flatpak va probablement devenir dépendant de systemd

• Flatpak a longtemps mis en avant comme atout le fait de permettre de « construire des applications pour toutes les distributions », mais une dépendance à systemd pourrait apparaître dans la prochaine version majeure
• Flatpak Next ou Flatpak 2.0 ressemble davantage à une réécriture destinée à dépasser les limites d’une conception vieille de plusieurs décennies de la branche 1.x, et n’en est encore qu’au stade de projet
• Le nouveau service systemd-appd aura un rôle central : stocker les identifiants et permissions des applications, permettre aux autres composants de les interroger, et rendre possible le sous-sandboxing
• Pour les distributions sans systemd, il existait une possibilité d’implémentation sous forme de démon indépendant, comme elogind, mais après l’ampleur prise par la controverse, la volonté des développeurs de faire cet effort semble avoir diminué
• Si la dépendance à systemd se durcit, l’usage de Flatpak pourrait devenir difficile sur des distributions comme Void, Guix ou Alpine, et sa neutralité vis-à-vis des distributions pourrait s’affaiblir

---

Évolution possible de la neutralité de Flatpak vis-à-vis des distributions

• Le site de Flatpak met en avant en premier avantage “Build for every distro: create one app and distribute it to the entire Linux desktop market.”, et sa liste de distributions prises en charge inclut aussi des distributions comme Void Linux, Guix et Alpine, qui utilisent un système d’init autre que systemd
• Aujourd’hui, Flatpak ne se soucie pas du système d’init utilisé par l’utilisateur, mais la prochaine version majeure pourrait introduire une dépendance à systemd
• Si ce changement est effectivement adopté, la question centrale sera de savoir si les distributions n’utilisant pas systemd pourront continuer à proposer Flatpak

Flatpak Next et l’orientation de la refonte

• Arian Vovk et Sebastian Wick ont présenté l’avenir de Flatpak lors du Linux App Summit dans cette présentation
• La version actuelle de Flatpak continuera d’être améliorée, mais il devient de plus en plus difficile de contourner les limites d’une conception vieille de plusieurs décennies
• Le travail appelé Flatpak Next ou Flatpak 2.0 s’apparente à une réécriture de fait, intégrant l’expérience accumulée depuis Flatpak 1.x
• La nouvelle architecture est pensée pour s’appuyer sur des technologies et idées modernes qui se sont imposées depuis la conception initiale de Flatpak
• Le contenu de la présentation reste encore au stade de planification, et comme pas une seule ligne de code n’a encore été écrite, le résultat final pourrait beaucoup évoluer au cours des prochaines années

systemd-appd et le déplacement de la gestion des permissions

• Le changement central dans l’orientation de Flatpak consiste à déplacer la gestion des permissions hors de Flatpak lui-même, vers une couche de services
• Le nouveau service systemd-appd attribuera des identifiants aux applications, stockera leurs permissions et permettra aux autres composants du système d’interroger ces données
• Cette structure rend possibles plusieurs fonctions, en particulier le sous-sandboxing (subsandboxing), considéré comme une capacité importante
• Le plan actuel prévoit d’introduire cette fonction dans la version actuelle de Flatpak, ce qui entraînerait une dépendance de Flatpak à systemd

Une marge de manœuvre pour les distributions sans systemd

• Selon l’explication de Vovk, il y avait l’intention de faire preuve de « beaucoup de considération » envers les distributions et utilisateurs n’employant pas systemd
• Le modèle envisagé est comparable à la manière dont systemd-logind a été séparé sous la forme du démon distinct elogind, permettant à des distributions utilisant d’autres systèmes d’init de faire tourner des environnements de bureau dépendant de systemd-logind
• Les développeurs de Flatpak semblaient eux aussi vouloir laisser autant de marge réaliste que possible pour permettre une implémentation indépendante similaire de systemd-appd
• Si cette approche avait été maintenue, Flatpak aurait pu continuer à être proposé sur des distributions sans systemd

Extension de la controverse et changement de ton chez les développeurs

• Des utilisateurs de distributions comme Void ou Alpine ont fait part de leurs inquiétudes : si Flatpak dépend fortement de systemd, il pourrait ne plus fonctionner sur leurs systèmes
• Des questions ont été adressées en masse à une personne qui n’était pas techniquement impliquée dans le développement de Flatpak, et ses réponses ont parfois été peu utiles, insultantes ou provocatrices
• Comme beaucoup ont cru à tort qu’il participait au développement de Flatpak, des questions sérieuses et bienveillantes se sont retrouvées mêlées à des réactions virulentes hostiles à systemd, aggravant la situation
• En conséquence, les développeurs de Flatpak ont fini par réagir en disant qu’ils n’avaient plus envie de consacrer du temps à prendre en compte les distributions et utilisateurs n’employant pas systemd
• Si cette dynamique se poursuit, la dépendance à systemd pourrait devenir plus stricte, et une implémentation indépendante reproduisant les fonctions de systemd-appd pourrait devenir bien plus difficile que prévu à l’origine

Conséquences attendues et portée du changement

• Dans la situation actuelle, il est probable que Flatpak acquière une dépendance à systemd dans les prochaines années
• Il est également possible que disparaisse la volonté de faciliter la création d’un démon indépendant capable de remplacer les fonctions de systemd-appd sur les distributions sans systemd
• Dans ce cas, Flatpak aurait plus de mal à continuer à revendiquer sa neutralité vis-à-vis des distributions, c’est-à-dire la possibilité de distribuer une seule application pour toutes les distributions
• Comme Flatpak est un outil réellement utilisé quel que soit le système d’init, cette évolution aurait un impact direct sur l’étendue de la distribution des applications de bureau Linux

[GN⁺]

Avis sur Lobste.rs

• Je ne comprends pas pourquoi tant de gens détestent systemd. Personnellement, je trouve qu’il fournit des fonctionnalités utiles grâce à une API facile à utiliser et à une gestion raisonnable des dépendances et des conflits
  Ceux qui n’aiment pas systemd avancent souvent seulement des raisons vagues comme « ce n’est pas dans l’esprit Unix », « c’est centralisé » ou « le format de fichier de systemd-journald n’est pas du texte brut »
  Si vous y êtes opposé, j’aimerais entendre des raisons concrètes, des solutions, et pourquoi d’autres systèmes d’init sont meilleurs. Je pourrai alors expliquer pourquoi les scripts rc sont des bricolages affreusement sales

  • Une grande partie de la polémique Mastodon liée relève en réalité moins d’une opposition à systemd que d’une opposition à la centralisation. Si Flatpak devient dépendant de systemd, les systèmes Linux utilisant d’autres systèmes d’init perdront l’accès à flatpak
    La philosophie de Linux, du moins pour moi, a toujours fondamentalement été une question de choix, et si Flatpak exige un système d’init précis, cela réduit les options dont disposent les utilisateurs pour configurer leur système afin d’obtenir le résultat souhaité
  • J’utilise volontiers systemd, mais dans le cas de Flatpak, je comprends la réaction. Flatpak, en substance, sert à « faire en sorte que ça marche sur n’importe quelle distribution Linux », et une dépendance à systemd en réduit donc une partie de l’utilité
  • Mon mécontentement non atténué envers systemd tient à peu près à ceci : l’implémentation de journald n’est pas terrible, mais l’idée elle-même est bonne, et l’file de travaux qui constitue la véritable abstraction par laquelle systemd gère les unités comporte des cas limites étranges, non documentés ou difficiles à trouver
    Il devrait être plus facile à embarquer dans une image de conteneur, et le systemd utilisateur devrait avoir un accès API en lecture à l’instance système afin de pouvoir au moins planifier des unités avec des choses comme After et Requires
    Malgré cela, je pense que c’est la meilleure chose qui soit arrivée à Linux depuis la suppression de HAL, et j’ai même déjà serré la main de Lennart pour le remercier de ce projet
  • Les gens qui implémentent réellement une pile alternative crédible, comme Chimera, ne répandent pas de FUD et se montrent aimables et modestes. En revanche, la foule en colère en ligne n’a explicitement pas de solution, et n’en aura probablement jamais
    Ce que ces « opposants » défendent en pratique se rapproche davantage de l’idée que la solution elle-même ne devrait pas exister. Ils se comportent comme une HOA de Linux ; à mes yeux, c’est une politique réactionnaire qui freine les progrès permettant à des systèmes réellement solides, utilisables et compétitifs de déloger les systèmes d’exploitation monopolistiques
  • Je n’ai rien contre systemd s’il n’est utilisé que sur des systèmes servant des pages web ou affichant des pages web dans un navigateur GUI. Pour les déploiements sur VPS, écrire directement des unités systemd me va très bien, et je n’aurais pas eu d’objection majeure si c’était SysV init ou upstart
    Mais sur un ordinateur portable, je veux autre chose. J’ai une idée de la façon dont je veux que mon environnement personnel fonctionne, je veux aussi des fonctions de confort que l’utilisateur Linux moyen ne souhaite pas forcément, et je ne veux pas que des choses se produisent sans demande explicite. Je déteste bien plus le travail nécessaire pour « empêcher que ça marche » que celui pour « faire en sorte que ça marche »
    La raison essentielle pour laquelle j’ai quitté NixOS à cause de systemd, c’était son périmètre en expansion continue et ses valeurs par défaut très prescriptives. Avec l’intégration de la gestion de l’alimentation et des connexions, il fallait sans cesse corriger le fait que fermer le capot mettait systématiquement la machine en veille ; l’évolution de la portée de linger a cassé nohup et screen pourtant exigés par POSIX ; et une gestion plus stricte des VT a obligé à repenser à la manière systemd des usages comme « se connecter une fois puis lancer plusieurs instances Xorg » ou « capturer un VT »
    J’ai fini par juger qu’un init minimal comme sinit, sans supervision de services, me convenait mieux, et j’ai écrit moi-même des scripts de démarrage shell, avec certaines fonctions système en shell et d’autres en Common Lisp. Sur mon portable, des choses comme PostgreSQL démarrent une fois puis tournent en continu ; si ça s’arrête, je peux le remarquer, et si un redémarrage suffit, c’est simple ; si ce n’est pas suffisant, alors un superviseur de services ne m’aidera pas non plus
    Parmi les cas qui ont rompu la confiance, il y a le moment où, sur HDD, journald n’affichait toujours rien après plusieurs minutes d’attente pour montrer les logs avec un cache froid, le fait d’avoir personnellement rencontré https://github.com/systemd/systemd/issues/2913, et l’absence totale d’hésitation à casser nohup
    Pendant le développement aussi, des attitudes comme dans https://github.com/systemd/systemd/issues/437 — une impression du type « nous fournissons de bonnes valeurs par défaut, mais si elles sont mauvaises, les distributions n’ont qu’à corriger » — ainsi que la réticence à promettre une API stable, visible dans http://lists.freedesktop.org/archives/systemd-devel/…, ont entamé ma confiance
    Cela dit, ces griefs sont anciens. Après avoir vu systemd résoudre certains problèmes tout en en créant d’autres, sans que ni les uns ni les autres soient ceux que j’avais au départ, je suis passé sur mon portable à des scripts shell de démarrage, et aujourd’hui le coût de maintenance est si faible que je n’ai aucune raison de réessayer systemd. Sur VPS, en revanche, j’utilise systemd dans le cadre familier de Debian

• Ce qui me frustre, c’est que cette affaire a commencé par de la désinformation venant de quelqu’un qui n’est pas développeur Flatpak, a suscité des réactions émotionnelles, puis, au fil du thread initial, des formulations toujours plus fortes se sont ajoutées, attirant les gens contre le projet Flatpak et la réputation de ses développeurs
  Il n’est donc pas étonnant que les véritables développeurs Flatpak aient été affectés émotionnellement et aient voulu prendre leurs distances avec cette foule en colère
  J’aimerais que tout le monde se calme et n’en fasse pas davantage. S’il y a des doutes ou des inquiétudes, il faut parler aux véritables mainteneurs, montrer qu’on soutient la recherche d’un terrain d’entente, et faire comprendre qu’il s’agit d’incidents isolés impliquant certaines personnes, pas quelque chose qui représente l’ensemble de la communauté
  De même que l’idée d’une dépendance à systemd n’était pas arrêtée mais seulement une idée, je pense qu’il n’est pas non plus trop tard pour que les mainteneurs reconsidèrent le support de projets plus variés

• J’aimerais qu’il y ait assez de bonne volonté pour continuer à prendre en charge les systèmes qui ne tournent pas sous systemd. Flatpak et d’autres approches par conteneurs aident les utilisateurs à exécuter des paquets qui ne se compilent pas facilement sur leur plateforme cible, et ce serait bien de pouvoir faire tourner Flatpak sur ce type de systèmes lorsqu’on a besoin d’un logiciel particulier
  Les conteneurs jouent un rôle similaire, mais faire fonctionner correctement quelque chose comme x11docker dans une configuration suffisamment atypique peut être péniblement compliqué

  • J’utilise Void avec satisfaction depuis plus de 10 ans. Je ne me souviens même plus de la dernière fois où je me suis préoccupé du système d’init ou de l’intégration à systemd. Merci pour tout le travail accompli sur Void

• J’utilise Void sur un portable, c’est efficace pour travailler et la documentation est plutôt bonne. Merci pour tout le travail accompli par les développeurs, et j’espère que l’évolution de Flatpak ne deviendra pas une charge trop lourde

• « Voilà le Linux moderne, et il n’y a que systemd. »
  Cela rappelle clairement que la communauté Linux ressemble moins à une communauté qu’à un WeWork. Pendant que tout le monde autour touche un salaire dépendant de l’existence de Red Hat, quelqu’un bricole GNU readline gratuitement

  • Il n’est pas vraiment difficile de dire que le texte a raison sur ce point : le passage parlant d’« attirer les anti-systemd fanatiques et conspirationnistes anti-Red Hat (et pire encore) »

• À ce stade, il est trop tôt pour affirmer de manière catégorique qu’il « deviendra une dépendance », cela semble très spéculatif

• Il est intéressant de voir à quel point le titre est bien plus catégorique que le corps du texte. Beaucoup de commentaires réagissent manifestement uniquement au titre, et heureusement pas tous, mais ce phénomène n’a rien de nouveau sur Internet
  Ces temps-ci, même sur lobste.rs, je vois souvent des gens réagir uniquement à un titre ou à une phrase isolée dans un long commentaire, et cela m’inquiète. En général, ils laissent très peu de place à d’autres possibilités que leur première interprétation, souvent agressive
  En lisant le texte, on dirait que quelque chose de similaire s’est produit avec les discussions autour de Flatpak 2.0. Ils semblaient vouloir laisser une ouverture pour d’autres systèmes init, mais le discours autour du sujet est vite devenu hostile, au point qu’ils ont apparemment fini par abandonner

• En tant qu’utilisateur de systèmes init alternatifs, c’est vraiment frustrant. Je fais tourner un portable sous Alpine Linux et j’utilisais Flatpak pour exécuter des logiciels qui ne fonctionnent qu’avec glibc. Ce changement va me pousser à quitter cet environnement
  Je ne déteste pas systemd. Tous mes systèmes Gentoo sont basés sur systemd. En revanche, je n’aime pas la manière dont systemd rend les logiciels libres et open source de plus en plus dépendants de GNU/Linux

• C’est clairement une bonne chose
  systemd est composé de démons stables avec des API bien définies, donc quelle que soit la partie de systemd dont Flatpak viendra à dépendre, quelqu’un pourra, avec suffisamment d’efforts, la réimplémenter proprement depuis zéro
  C’est le meilleur résultat possible. Cela réduit la fragmentation, et cela donne aux personnes ayant des besoins particuliers une cible stable à réimplémenter

  • J’ai commencé à lire en pensant que c’était satirique, mais non
    Les API de systemd sont souvent définies de manière ambiguë dans les pages de manuel, et comme le projet systemd n’anticipe pas réellement d’autres implémentations, elles ne sont ni stables ni versionnées de façon bilatérale
    Dans le cas de l’API de socket notify, c’est même stable uniquement dans l’autre sens. L’ajout du support de vsock a en pratique cassé les démons qui l’implémentaient sans dépendre de libsystemd. Si cette casse est peu connue, c’est parce que vsock servait surtout aux communications systemd-à-systemd à travers des frontières de virtualisation. Si cela avait été bien conçu, cela aurait été une extension limitée à cette frontière
    On parle de « démons », mais en pratique il s’agit surtout de logind et systemd, et comme ces deux-là exposent l’ensemble de la surface d’API, les possibilités de composition sont limitées. Cela passe par quelques interfaces DBus, désormais aussi par varlink, et via une bibliothèque unique
    Pour remplacer systemd, il faut soit le remplacer entièrement tout en s’alignant difficilement sur son modèle interne afin d’exposer des API façon systemd, soit commencer par démêler les choix de conception des API de systemd et créer une couche intermédiaire offrant des backends enfichables
    Je travaille sur ce problème depuis des années. Je pense que beaucoup de principes de conception de systemd sont valables, mais dans sa forme actuelle, la conception concentre en amont une complexité dont la plupart des gens n’ont pas besoin. Une architecture plus modulaire et interchangeable est possible, et il est relativement facile d’imaginer ou de réutiliser des conceptions d’interfaces simples et séparables
    Mais le problème vient des logiciels qui choisissent de dépendre des API de systemd. Pour les faire fonctionner avec autre chose, il faut soit faire accepter en upstream des correctifs qui séparent le support de fonctions actuellement liées à l’ensemble de libsystemd, soit ajouter la prise en charge de nouvelles API distinctes ; la première approche n’a jamais réussi, et la seconde a peu de chances d’être acceptée à cause de la charge de maintenance d’API rares ou préliminaires
    On peut aussi n’implémenter que les API utilisées par le logiciel, par exemple avec un service DBus login1 qui n’implémente pas la majorité des API. Mais cela entre alors en conflit avec d’autres implémentations qui tentent de remplacer d’autres parties de l’API, et il faut implémenter trois variantes : l’API propre d’origine, l’API DBus de logind/systemd et l’API pour varlink
    À long terme, la solution pourrait être un routeur qui implémente toute l’API systemd ou logind et la relie en arrière-plan à des API séparées. Mais la conception actuelle est traversée par d’énormes redondances et des spécificités systemd, ce qui rend une implémentation correcte extrêmement complexe
    Je ne sais pas si c’était intentionnel, mais d’après les propos des développeurs de systemd, c’est au minimum un problème qu’ils ont choisi de ne pas traiter. Créer une couche intermédiaire complexe ou fabriquer un remplaçant de systemd sans réécrire systemd est très difficile, et même si une application ne dépend que d’une partie des API pouvant être fournies sous forme de composants isolés, il est en pratique très difficile de remplacer proprement une seule partie de systemd
  • Est-ce vraiment encore vrai aujourd’hui qu’on puisse réimplémenter proprement depuis zéro certaines parties de systemd ? Le texte cite elogind comme exemple

• Je n’aime pas la façon dont Red Hat détient trop de contrôle sur l’écosystème Linux

  • Moi non plus, mais je ne sais pas très bien à quel point Red Hat exerce encore aujourd’hui un contrôle sur systemd
  • C’est très ambigu. Centraliser le contrôle est une mauvaise chose, mais payer des gens pour qu’ils développent des logiciels libres et open source en est une bonne. Et une grande partie du contrôle qu’ils acquièrent vient précisément du fait qu’ils paient des gens pour développer des logiciels libres et open source
    Malgré tout, le fait que Red Hat ait adopté le logiciel libre atténue dans une certaine mesure les inquiétudes liées à son influence. Quand on regarde les technologies qu’ils ont acquises au fil des années, même pour celles qui n’avaient pas d’upstream auparavant, ils ont parfois créé eux-mêmes un upstream libre et open source. Dogtag PKI et 389 Directory Server me viennent particulièrement à l’esprit
    Globalement, je pense que cela n’a pas été trop mauvais pour l’écosystème, et qu’ils ont plus souvent fait progresser les choses qu’ils ne les ont abîmées

• Je ne suis pas directement concerné par cette controverse, mais il n’y a rien ici qui apaise les inquiétudes face à la complexité et l’abstraction inutiles qui ne cessent d’augmenter sur les systèmes Linux
  Linux est en train de devenir rapidement le Java des systèmes d’exploitation. C’est vraiment triste