En gros, systemd a décidé unilatéralement de rendre /var/lock uniquement autorisé en écriture pour root à l’encontre du Filesystem Hierarchy Standard dont ils se fichent, et le Comité Technique de Debian a décidé de ne pas céder au moins tant que d’autres logiciels en ont besoin.
Après le remplacement du démarrage du système et des services, le remplacement de services par d’autres qui n’ont pas tout à fait les mêmes fonctionnalités (un automount qui ne démonte pas, un système de logs qui gère lui‐même la suppression des vieux logs mais qui ne permet pas d’envoyer les logs sur un serveur centralisé, une gestion des interfaces réseaux au moins statiques mais qui est loin de fournir toutes les fonctionnalités de Network Manager pour les interfaces dynamiques…), l’étape suivante logique était qu’il considère les répertoires système comme sa propriété.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Bien que ta description ne semble pas fausse, je m’attends à ce que les fans te tombent dessus et nous expliquent que tout va bien et qu’on ne comprend pas les bienfaits du système… :)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Le débat va un peu plus loin cette fois ci. Ce qui se joue c'est un changement sur la façon dont les logiciels peuvent obtenir l'accès exclusif à un fichier ou un périphérique. Par exemple, un port série: si plusieurs applications ouvrent un tel port, elles vont recevoir chacune la moitié des données.
La méthode classique est de créer un fichier dans /var/lock avec un nom choisi à l'avance t communeavec les autres logiciels qui pourraient avoir accès à la même reesource. Bien sûr ça n'est pas du tout vérifié par le système. Si un logiciel ne suit pas ce protocole, ou bien s'il l'implémente mal, on a un conflit d'accès à la ressource.
Le nouveau système est l'utilisation d'APIs dédiées (flock() par exemple. Il a l'avantage d'être explicitement lié au fichier concerné puisque il n'y a pas besoin d'un fichier séparé dans /var/lock. Et le noyau peut vérifier la orésence d'un lock et interdire l'accès au fichier à d'autres logiciels. systemd souhaite bien sûr utiliser cette nouvelle méthode, et ils ont choisi de forcer la main aux autres logiciels pour se mettre à jour rapidement en bloquant l'ancienne, car il n'est pas souhaitable de faire fonctionner les deux en parallèle (cela obligerait chaque logiciel à implémenter les deux méthodes à la fois avec de nouvelles possipilités de bugs).
Il est probable qu'une future version de FHS changera les règles pour /var/lock (de la même façon que /usr est en train de disparaître par exemple). Systemd est juste allé un petit peu vite.
ouais. Avec flatpak/snap etc.. on devrait faire un FHS plus simple:
/linux/bin
/linux/etc
/Program Files/snap
/home
/Temp Un truc moderne, quoi. Et là, on pourrait automount /home/user depuis une clé usb par exemple. Ou déployer minimalistement une distro depuis un dockerhub, le rêve \o/
Finalement, je vais ptet me prendre un -100. Dire que j'étais un gentil linuxien avec un karma à +2 :-(
La réalité est un peut moins sensationnaliste mais cela ne va pas dans le sens des conspirationnistes.
La réalité c'est que systemd propose que /var/lock ne soit plus modifiable par tout le monde (franchement en 2025 ca me semble du bon sens mais bon). Le mainteneur Debian décide tout seul de suivre cette proposition (de bon sens).
# Borg
Posté par Arthur Accroc . Évalué à 6 (+8/-4).
En gros, systemd a décidé unilatéralement de rendre /var/lock uniquement autorisé en écriture pour root à l’encontre du Filesystem Hierarchy Standard dont ils se fichent, et le Comité Technique de Debian a décidé de ne pas céder au moins tant que d’autres logiciels en ont besoin.
C’est le côté Borg de systemd. Pas le joueur de tennis, le Collectif Borg de Star Trek : « toute résistance serait futile, vous allez être assimilés ».
Après le remplacement du démarrage du système et des services, le remplacement de services par d’autres qui n’ont pas tout à fait les mêmes fonctionnalités (un automount qui ne démonte pas, un système de logs qui gère lui‐même la suppression des vieux logs mais qui ne permet pas d’envoyer les logs sur un serveur centralisé, une gestion des interfaces réseaux au moins statiques mais qui est loin de fournir toutes les fonctionnalités de Network Manager pour les interfaces dynamiques…), l’étape suivante logique était qu’il considère les répertoires système comme sa propriété.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Borg
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 0 (+1/-3).
Bien que ta description ne semble pas fausse, je m’attends à ce que les fans te tombent dessus et nous expliquent que tout va bien et qu’on ne comprend pas les bienfaits du système… :)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Borg
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+8/-0).
Le débat va un peu plus loin cette fois ci. Ce qui se joue c'est un changement sur la façon dont les logiciels peuvent obtenir l'accès exclusif à un fichier ou un périphérique. Par exemple, un port série: si plusieurs applications ouvrent un tel port, elles vont recevoir chacune la moitié des données.
La méthode classique est de créer un fichier dans /var/lock avec un nom choisi à l'avance t communeavec les autres logiciels qui pourraient avoir accès à la même reesource. Bien sûr ça n'est pas du tout vérifié par le système. Si un logiciel ne suit pas ce protocole, ou bien s'il l'implémente mal, on a un conflit d'accès à la ressource.
Le nouveau système est l'utilisation d'APIs dédiées (flock() par exemple. Il a l'avantage d'être explicitement lié au fichier concerné puisque il n'y a pas besoin d'un fichier séparé dans /var/lock. Et le noyau peut vérifier la orésence d'un lock et interdire l'accès au fichier à d'autres logiciels. systemd souhaite bien sûr utiliser cette nouvelle méthode, et ils ont choisi de forcer la main aux autres logiciels pour se mettre à jour rapidement en bloquant l'ancienne, car il n'est pas souhaitable de faire fonctionner les deux en parallèle (cela obligerait chaque logiciel à implémenter les deux méthodes à la fois avec de nouvelles possipilités de bugs).
Il est probable qu'une future version de FHS changera les règles pour /var/lock (de la même façon que /usr est en train de disparaître par exemple). Systemd est juste allé un petit peu vite.
[^] # Re: Borg
Posté par octane . Évalué à 4 (+7/-5).
Systemd fait un truc qui casse quelquechose.
(post à -10 de karma dans 3…. 2…. 1….)
ouais. Avec flatpak/snap etc.. on devrait faire un FHS plus simple:
/linux/bin
/linux/etc
/Program Files/snap
/home
/Temp
Finalement, je vais ptet me prendre un -100. Dire que j'étais un gentil linuxien avec un karma à +2 :-(
[^] # Re: Borg
Posté par GnunuX (site web personnel) . Évalué à 3 (+1/-0).
"Systemd fait un truc qui casse quelquechose."
La réalité est un peut moins sensationnaliste mais cela ne va pas dans le sens des conspirationnistes.
La réalité c'est que systemd propose que /var/lock ne soit plus modifiable par tout le monde (franchement en 2025 ca me semble du bon sens mais bon). Le mainteneur Debian décide tout seul de suivre cette proposition (de bon sens).
Le projet Debian décide de revenir en arrière.
Rien a voir avec "fait un truc qui casse" quoi.
La preuve … la correction n'implique pas un changement quelconque dans systemd : https://salsa.debian.org/systemd-team/systemd/-/commit/9250e242b9b764b3aa54aa3af77da1753a5e67d0
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.