Non, sinon j'aurais dit "je trouve tel truc mieux que /etc/default".
Déjà, /etc/default est pourri car ça reste du shell. Ce qui veut dire que soit tu te limites à la syntaxe FOO="truc" et c'est plus du shell, soit tu mets du vrai shell (genre $() pour lire un truc dynamiquement) et la, ça devient difficile à parser par des outils automatisés (genre ansible/puppet, etc). Ensuite, la flexibilité d'un coté implique la lourdeur de l'autre, je peux comprendre que certains préfèrent la syntaxe de /etc/default pour divers raisons.
Ensuite, avec /etc/default, tu es quand même dépendant de ce que la personne qui a écrit le script a choisi d'utiliser. Par exemple, tu peux souvent pas surcharger proprement la ligne de commande complète du service que tu veux lancer, il te faut lire et trouver la version spécifique du paramètre que tu va utiliser. Paramètres non documentés upstream, bien sur, au contraire des options de démarrage. Parfois, c'est le contraire, tu as juste les options et tu peux faire presque ce que tu veux, sauf si ce que tu veux, c'est d'utiliser un programme avant (chroot foo, nsenter foo, runcon foo).
Donc non, je parle pas de /etc/default. C'est un mécanisme vite limité par rapport à ce que systemd propose et ce que j'utilise. Mais si tu as pas de souci avec et que tu penses que c'est suffisant, pas de souci pour moi.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 5.
Non, sinon j'aurais dit "je trouve tel truc mieux que /etc/default".
Déjà, /etc/default est pourri car ça reste du shell. Ce qui veut dire que soit tu te limites à la syntaxe FOO="truc" et c'est plus du shell, soit tu mets du vrai shell (genre $() pour lire un truc dynamiquement) et la, ça devient difficile à parser par des outils automatisés (genre ansible/puppet, etc). Ensuite, la flexibilité d'un coté implique la lourdeur de l'autre, je peux comprendre que certains préfèrent la syntaxe de /etc/default pour divers raisons.
Ensuite, avec /etc/default, tu es quand même dépendant de ce que la personne qui a écrit le script a choisi d'utiliser. Par exemple, tu peux souvent pas surcharger proprement la ligne de commande complète du service que tu veux lancer, il te faut lire et trouver la version spécifique du paramètre que tu va utiliser. Paramètres non documentés upstream, bien sur, au contraire des options de démarrage. Parfois, c'est le contraire, tu as juste les options et tu peux faire presque ce que tu veux, sauf si ce que tu veux, c'est d'utiliser un programme avant (chroot foo, nsenter foo, runcon foo).
Donc non, je parle pas de /etc/default. C'est un mécanisme vite limité par rapport à ce que systemd propose et ce que j'utilise. Mais si tu as pas de souci avec et que tu penses que c'est suffisant, pas de souci pour moi.