Merci pour tes indications, je connaissais déjà (à part pour le coup du truc.service.d), mais j’espère que ça pourra servir à d’autres.
Bref : que ce soit pour l'automontage, la gestion de l'énergie ou le format des logs, l'utilisateur a le choix.
Je ne dis pas le contraire, mais je répondais à l’affirmation « on ne réinvente pas la roue ».
Après, si Lennart réécrit une bonne partie des services pour qu’ils s’interfacent mieux avec systemd, pourquoi pas. Pour journald, c’est assez réussi, puisqu’il fait le boulot des syslogs traditionnels, mais permet en plus d’avoir des traces du tout début du démarrage.
Le problème avec une partie des autres, c’est qu’il faudrait en finir un avant d’en ajouter d’autres. Un automount suffisant sauf si on en a vraiment besoin, une gestion de l’ACPI suffisante sauf si on en a vraiment besoin, c’est quand même dommage. Autant en faire moins, mais les faire jusqu’au bout.
On me prend pour un anti-systemd primaire parce que j’ose émettre des critiques, mais ce n’est pas le cas. Quand systemd ou ses services associés peuvent faire le boulot, je les utilise de préférence, ne serait-ce que par souci de cohérence ou pour limiter le nombre de services en jeu.
Après, quand Lennart prétend remplacer l’ACPI, sauf que pour avoir les fonctionnalités qu’on peut attendre de l’ACPI, on finit avec une double configuration, une pour désactiver l’utilisation de son service et une autre pour l’ancien, ce n’est pas une amélioration par rapport à l’ancienne situation.
D’un côté, on a systemd qui remplace le système d’init en faisant aussi le café et la vaisselle, d’un autre, on a des services associés qui ne font que la moitié de leur boulot. Il ne sont pas à la hauteur.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # Re: C’est du propre
Posté par Arthur Accroc . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 9.
Merci pour tes indications, je connaissais déjà (à part pour le coup du truc.service.d), mais j’espère que ça pourra servir à d’autres.
Je ne dis pas le contraire, mais je répondais à l’affirmation « on ne réinvente pas la roue ».
Après, si Lennart réécrit une bonne partie des services pour qu’ils s’interfacent mieux avec systemd, pourquoi pas. Pour journald, c’est assez réussi, puisqu’il fait le boulot des syslogs traditionnels, mais permet en plus d’avoir des traces du tout début du démarrage.
Le problème avec une partie des autres, c’est qu’il faudrait en finir un avant d’en ajouter d’autres. Un automount suffisant sauf si on en a vraiment besoin, une gestion de l’ACPI suffisante sauf si on en a vraiment besoin, c’est quand même dommage. Autant en faire moins, mais les faire jusqu’au bout.
On me prend pour un anti-systemd primaire parce que j’ose émettre des critiques, mais ce n’est pas le cas. Quand systemd ou ses services associés peuvent faire le boulot, je les utilise de préférence, ne serait-ce que par souci de cohérence ou pour limiter le nombre de services en jeu.
Après, quand Lennart prétend remplacer l’ACPI, sauf que pour avoir les fonctionnalités qu’on peut attendre de l’ACPI, on finit avec une double configuration, une pour désactiver l’utilisation de son service et une autre pour l’ancien, ce n’est pas une amélioration par rapport à l’ancienne situation.
D’un côté, on a systemd qui remplace le système d’init en faisant aussi le café et la vaisselle, d’un autre, on a des services associés qui ne font que la moitié de leur boulot. Il ne sont pas à la hauteur.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone