Y'a un tor.service et un tor@default.service. Encore une syntaxe à apprendre (mais pourquoi le arobase?? quel est le sens de tout ceci?), il y a surement une bonne explication à ce truc qui me paraît initialement incompréhensible.
Merci pour l'exemple concret :-)
Okay, j'ai été voir par curiosité. Je n'ai jamais mis tor en place. Ça a l'air d'être un choix de conception de Tor expliqué ici : Tor a décidé que ça devait être un système multi-instance, dont une par défaut (le default), et que lancer Tor sans préciser d'instance n'a pas de sens.
Ils auraient pu décider de ne pas fournir de tor.service, ou de le faire échouer avec un message d'erreur spécifique, en tout cas systemd ne les empêchaient pas de le faire. Pourquoi ils ne l'ont pas fait, je ne sais pas, en tout cas ça n'a pas l'air d'être la faute de systemd.
Quant au @, c'est une convention que d'autres services utilisent. Par exemple systemd-nspawn. Si tu veux gérer un conteneur tartampion avec un service, tu vas avoir un service nommé systemd-nspawn@tartampion.service. Tor a réutilisé cette convention pour son système multi-instance. Je note qu'il n'y a d'ailleurs pas de systemd-nspawn.service, Tor pourrait certainement calquer ça pour éviter les surprises. Moi, je trouve ce @ élégant, mais question de goût. Ça aurait pu être un autre caractère. C'est bien que ça ne soit pas alphanumérique, ni un tiret, ni un point, bref, pas un caractère que tu peux utiliser dans une le nom d'une variable C. Ça aurait pu être dans un sous-dossier mais je suppose que ne pas gérer une arborescence simplifie les choses.
Donc quand tu utilises tor@default.service, tu gères l'instance default de tor. Il semble important de comprendre cet élément central de l'architecture de tor.
Pour moi on est effectivement dans une situation où il y a une bonne explication à un truc initialement incompréhensible, et ça montre aussi que c'est facile de rejeter la faute sur le mauvais acteur si on ne s'est pas assez renseigné, entrainant potentiellement des échanges un peu stériles parce que les critiques sont incompréhensibles ou tombent à côté de la réalité, et du coup c'est impossible d'échanger sur une base commune compréhensible.
Oui, mais on est pas forcément d'accord avec ces justifications.
Oui, évidemment, mais du coup ce n'est plus juste "fuck you" :-)
quel génie Lennart est
il ne s'agit pas de ça, et par ailleurs, j'aimerais aussi avoir des trains à l'heure avec une tarification qui a du sens, le train étant un de mes modes de transports principaux.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj (site web personnel) . En réponse au lien 14 ans de systemd. Évalué à 4. Dernière modification le 19 février 2025 à 12:39.
Merci pour l'exemple concret :-)
Okay, j'ai été voir par curiosité. Je n'ai jamais mis tor en place. Ça a l'air d'être un choix de conception de Tor expliqué ici : Tor a décidé que ça devait être un système multi-instance, dont une par défaut (le
default), et que lancer Tor sans préciser d'instance n'a pas de sens.Ils auraient pu décider de ne pas fournir de
tor.service, ou de le faire échouer avec un message d'erreur spécifique, en tout cas systemd ne les empêchaient pas de le faire. Pourquoi ils ne l'ont pas fait, je ne sais pas, en tout cas ça n'a pas l'air d'être la faute de systemd.Quant au
@, c'est une convention que d'autres services utilisent. Par exemple systemd-nspawn. Si tu veux gérer un conteneurtartampionavec un service, tu vas avoir un service nommésystemd-nspawn@tartampion.service. Tor a réutilisé cette convention pour son système multi-instance. Je note qu'il n'y a d'ailleurs pas desystemd-nspawn.service, Tor pourrait certainement calquer ça pour éviter les surprises. Moi, je trouve ce@élégant, mais question de goût. Ça aurait pu être un autre caractère. C'est bien que ça ne soit pas alphanumérique, ni un tiret, ni un point, bref, pas un caractère que tu peux utiliser dans une le nom d'une variable C. Ça aurait pu être dans un sous-dossier mais je suppose que ne pas gérer une arborescence simplifie les choses.Donc quand tu utilises
tor@default.service, tu gères l'instancedefaultde tor. Il semble important de comprendre cet élément central de l'architecture de tor.Pour moi on est effectivement dans une situation où il y a une bonne explication à un truc initialement incompréhensible, et ça montre aussi que c'est facile de rejeter la faute sur le mauvais acteur si on ne s'est pas assez renseigné, entrainant potentiellement des échanges un peu stériles parce que les critiques sont incompréhensibles ou tombent à côté de la réalité, et du coup c'est impossible d'échanger sur une base commune compréhensible.
Oui, évidemment, mais du coup ce n'est plus juste "fuck you" :-)
il ne s'agit pas de ça, et par ailleurs, j'aimerais aussi avoir des trains à l'heure avec une tarification qui a du sens, le train étant un de mes modes de transports principaux.
bon app'