Le 14/12/2016 17:39, Alexis Lameire a écrit :
Bonjour, Je ne suis pas un fan boy de systemd, je reste néanmoins plutôt satisfait du projet et comme cité plus haut :
- journalctl qui est un délice à utiliser
Le 14/12/2016 15:15, Thomas Constans a écrit :
Franchement, journald et journalctl, avec la possibilité de filtrer par priorité, par service, de récupérer les événements sur une période de temps donnée, c'est plutôt pas mal.
C'est vrai, avant on avait un outil performant, robuste et léger qui s'appelait grep pour faire ça.
Ensuite, pour ce qui est du délice... On parle bien du soft qui croit bon juger d'adapter sa sortie à la taille de ton écran en découpant tes lignes façon crado au milieu du message ?
- les logs binaire et le check des logs qui permettent d'améliorer la
protection contre les tentatives d'éffacement des traces
Ils sont chiffrés tes logs ? Parce que modifier des binaires ça se fait pas trop difficilement hein.... C'est plus compliqué qu'avec un sed, certes, mais ça se fait.
- l'écriture de service facilité dans bien des cas
Ça, je suis d'accord. Le problème c'est que dès que tu n'es pas dans un cas "courant", c'est impossible et on a des setups ou ton applicatif peut marcher dans un cas et pas dans l'autre. Exemple : le fait de lancer une appli en debug avec l'option "Restart=on-failure" qui fait bander les admins trop flemmards pour installer monit et les devs trop peu compétents pour faire des softs stables en prod. J'ai un peu la flemme de rechercher le ticket, mais en gros : pour systemd, une "failure" de ton service, c'est quand il écrit sur stderr. Ce qui peut correspondre à du warning ou du debug, comme communément admit par tous les devs / sysadmins depuis des dizaines d'années. Dans mes souvenirs, le ticket a été clos en "wontfix" (et plus bas tu parles de discuter avec ces personnes...)
mais aussi :
- le fait de pouvoir écrire des services générique (genre openvpn)
et d'en lancer plusieurs instance
- une vrai gestion des dépendances entre service, ce qui n'était pas
toujours évidant.
Après, il faut reconaitre que le suivis des anomalies par le projet et la politique de tests ne sont pas bon. Mais pour ces points il y a des solutions, les mêmes qui ont toujours fait vivre les projets libre :
- faire entendre vos voix de façon constructive, en proposent des
patch
- si ca ne marche pas, forker (surtout qu'avec git c'est facile merde)
et monter sa communauté plus à l'écoute des demanes
- développer son propre système d'init
Le truc, c'est que ça existe. Depuis des années. Tiens, un peu de lecture : http://blog.darknedgy.net/technology/2015/09/05/0/
De plus, la plupart des distribution fonctionnent de manière à écouté la communauté, si vous ne souhaitez pas que systemd soit utilisé par défaut ou qu'un autre système d'init le soit à sa place, je vous enjoint donc à communiquer de façon constructive vos doléance aux représentant de votre distribution préféré
Ça a été fait côté Debian. La killer feature qui a été retenue pour systemd comparé à d'autres systèmes d'init proposant les mêmes fonctionnalités (du moins, pour la gestion du démarrage), c'est le support de Gnome. Le même Gnome dont il est discuté l'abandon (au moins en tant que desktop par défaut) à chaque nouvelle version de Debian depuis au moins Lenny. Et ça, niveau discussion avec ta communauté, c'est plutôt moche. Surtout compte tenu du fait que systemd était une "technology preview" dans Wheezy et est passé "default" juste après dans Jessie.
Et si la discussion avait été possible, on aurait pas eu un départ massif de développeurs pour forker le projet (Devuan).