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).
--
Benjamin Boudoir
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
