Et en quoi systemd est suprieur aux autres pour une utilisation desktop?
Je n'ai pas dit qu'il était forcément mieux, mais qu'il était pas moins indiqué pour une utilisation "desktop" que les autres. Nuance.
Surtout quand on sait qu'il est hotplug-capable (merci udev et hotplug) - ce qui lui permet notamment de donner des noms prévisibles aux interfaces réseaux, d'où qu'elles viennent -, qu'il permet (allié à d'autres briques bas-niveau, telles que udev) enfin un multiseat plus que correcte, et qu'il permet de lancer des units en tant qu'utilisateur.
Car j'ai beau l'utiliser, je ne vois guère de grands avantages...
Si tu ne vois pas la différence à l'utilisation, c'est que la transition s'est bien passée. ;-)
mais quand je vois upstart, je me dis que systemd fait a peine mieux.
Euh, c'est justement à cause des multiples problèmes d'Upstart que systemd est né. Rien que pour surveiller proprement les processus, Upstart était un cauchemard.
Et pour l'auteur d'un service, il est bien plus facile de décrire uniquement ce dont il a besoin dans une unit systemd, que de décrire sous quelles conditions son service peut démarrer dans un "Job" Upstart (sans compter qu'il faut s'occuper du démarrage/redémarrage/arrêt et suivi du service dans le "job"... Bref, tout un programme !)
C'est loin d'être le seul avantage. Il y a des dizaines de références là dessus (exemple). M'enfin, il suffit de reprendre ce tableau "General Features" de ce lien : http://0pointer.de/blog/projects/why.html (à part ReadAhead, qui n'a plus d'intérêt à l'ère des SSD et qui a été supprimé de systemd).
Ça te suffit ? :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Autre linux
Posté par xcomcmdr . En réponse au sondage Quelle est votre distribution préférée ?. Évalué à 2. Dernière modification le 20 janvier 2016 à 20:07.
Je n'ai pas dit qu'il était forcément mieux, mais qu'il était pas moins indiqué pour une utilisation "desktop" que les autres. Nuance.
Surtout quand on sait qu'il est hotplug-capable (merci udev et hotplug) - ce qui lui permet notamment de donner des noms prévisibles aux interfaces réseaux, d'où qu'elles viennent -, qu'il permet (allié à d'autres briques bas-niveau, telles que udev) enfin un multiseat plus que correcte, et qu'il permet de lancer des units en tant qu'utilisateur.
Si tu ne vois pas la différence à l'utilisation, c'est que la transition s'est bien passée. ;-)
Euh, c'est justement à cause des multiples problèmes d'Upstart que systemd est né. Rien que pour surveiller proprement les processus, Upstart était un cauchemard.
Et pour l'auteur d'un service, il est bien plus facile de décrire uniquement ce dont il a besoin dans une unit systemd, que de décrire sous quelles conditions son service peut démarrer dans un "Job" Upstart (sans compter qu'il faut s'occuper du démarrage/redémarrage/arrêt et suivi du service dans le "job"... Bref, tout un programme !)
C'est loin d'être le seul avantage. Il y a des dizaines de références là dessus (exemple). M'enfin, il suffit de reprendre ce tableau "General Features" de ce lien : http://0pointer.de/blog/projects/why.html (à part ReadAhead, qui n'a plus d'intérêt à l'ère des SSD et qui a été supprimé de systemd).
Ça te suffit ? :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)