Il faut voir les objectifs du projet. systemd a ouvertement choisi de privilégier l’unification/uniformisation (/run obligatoire n’en est qu’un des aspects), une intégration forte avec le reste de l’écosystème et la maintenabilité (supporte uniquement toolchain, libs et kernel « standards » et récents) au prix de la portabilité et de la souplesse. On peut ne pas être d’accord avec la pertinence à long terme de ces choix, mais il est clair que hardcoder des chemins est totalement cohérent avec ces choix.
Ils n’ont pas fait l’économie d’une tonne de #ifdef dans le code pour le plaisir de réintroduire leurs propres constantes derrière...
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Moonz . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 5.
Il faut voir les objectifs du projet. systemd a ouvertement choisi de privilégier l’unification/uniformisation (/run obligatoire n’en est qu’un des aspects), une intégration forte avec le reste de l’écosystème et la maintenabilité (supporte uniquement toolchain, libs et kernel « standards » et récents) au prix de la portabilité et de la souplesse. On peut ne pas être d’accord avec la pertinence à long terme de ces choix, mais il est clair que hardcoder des chemins est totalement cohérent avec ces choix.
Ils n’ont pas fait l’économie d’une tonne de #ifdef dans le code pour le plaisir de réintroduire leurs propres constantes derrière...