Donc, je peux prendre un script Debian et le faire tourner sur Red Hat vu qu'il y a un standard ?
Tu peux prendre un script LSB et le faire tourner sur une distribution LSB.
Si quelque chose ne marche pas, tu peux examiner la conformité du script et de la distribution et nommer les coupables. C'est ça l'avantage des standards.
systemd n'a aucun standard. C'est dommage, parce que qui dit standard, dit au moins qu'il y a plus d'une personne qui à réfléchit au truc. Du coup si je fait une réimplémentation de l'API systemd, qu'un programmeur développe un truc qui marche avec mon implémentation mais pas avec systemd, on ne sait pas de qui c'est la faute.
Ce n'est persistent, c'est justement ce que permet l'API systemd.
Ce n'est persistent avec systemd que si tu utilise son API. Le noyau en a rien à faire de systemd, et va autoriser n'importe qui à changer le hostname à travers sethostname.
Il y a tant de chose à dire aujourd'hui sur [gs]ethostname() et des considérations modernes, comme le fait qu'en 2013 un nom d'hôte à un ou plusieurs mappings vers zéro ou plusieurs adresses IP, et qu'une machine à zéro ou plusieurs adresses IP. Qu'un programme moderne digne de ce nom devrai faire une résolution inverse sur l'IP locale effectivement utilisée pour avoir le nom d'hôte. Si on voulait tout remettre à plat pour le plaisir, on aurai pu faire ça proprement.
Mais non, c'est tellement mieux de rester dans le passé.
[^] # Re: systemd
Posté par Batchyx . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à -3.
Tu peux prendre un script LSB et le faire tourner sur une distribution LSB.
Si quelque chose ne marche pas, tu peux examiner la conformité du script et de la distribution et nommer les coupables. C'est ça l'avantage des standards.
systemd n'a aucun standard. C'est dommage, parce que qui dit standard, dit au moins qu'il y a plus d'une personne qui à réfléchit au truc. Du coup si je fait une réimplémentation de l'API systemd, qu'un programmeur développe un truc qui marche avec mon implémentation mais pas avec systemd, on ne sait pas de qui c'est la faute.
Ce n'est persistent avec systemd que si tu utilise son API. Le noyau en a rien à faire de systemd, et va autoriser n'importe qui à changer le hostname à travers
sethostname.Il y a tant de chose à dire aujourd'hui sur
[gs]ethostname()et des considérations modernes, comme le fait qu'en 2013 un nom d'hôte à un ou plusieurs mappings vers zéro ou plusieurs adresses IP, et qu'une machine à zéro ou plusieurs adresses IP. Qu'un programme moderne digne de ce nom devrai faire une résolution inverse sur l'IP locale effectivement utilisée pour avoir le nom d'hôte. Si on voulait tout remettre à plat pour le plaisir, on aurai pu faire ça proprement.Mais non, c'est tellement mieux de rester dans le passé.