Each package that contains software that wants/needs to start a traditional service at boot MUST have a systemd unit file.
Ideally, systemd unit files are reusable across distributions and shipped with the upstream packages. Please consider working with upstream to integrate the systemd files you prepare in the upstream sources.
Et celles qui l'ont adopté ont bien vu l'intérêt de systemd, sans perdre leur identité.
Mutualiser les efforts, c'est bien aussi. Sinon, pourquoi tu ne craches pas aussi sur les standards XDG ?
Par exemple, les daemons n'ont même plus besoin de forker, c'est implémenté du côté de systemd une fois pour toutes.
Houla ca c'est moche !!!!
Factoriser, c'est moche ? Juste LOL.
Et quel est le rapport avec le système de démarrage ? C'est pas son rôle de forker ou pas, c'est le rôle de l'exécutable de faire ça. Systemd se mèle de ce qui nele regarde pas.
Je pense pas que cela soit pour autant obligatoire, mais il faudrait confirmer.
systemd est orienté évènement, un truc que SysV et consorts n'ont jamais résolu (-> standardisation).
C'est à dire ?
C'est à dire de ne pas considérer la config' matérielle comme étant immuable. De pouvoir démarrer par exemple le serveur Web uniquement lorsque la connexion réseau est présente. Ou de faire un fsck sur un disque dur externe lors de son branchement :
0) it is hotplug capable: systemd assumes that all resources may appear and dissapear at any time. If you plug in your external harddrive after systemd has booted, it will be fsck'ed and mounted correctly. This is unlike initscripts which relies on all disks being enumerated and ready when it starts fsck, and then it relies on fsck of all disks being finished before it starts mounting any of them. Hotplug is important, not only because it is convenient to be able to insert/remove hardware while the system is running, but also because that's how the linux kernel does boot: every device appears to be "hotplugged" as the kernel becomes aware of it, so with a very fast boot we can no longer assume that all devices are ready and waiting for us when we need them (even if they were plugged in when the computer started). In reality this is often not a problem, but if you ever had your rootfs on an external USB harddrive you might have experienced problems (and as things become faster and faster more problems like this will crop up).
Il est capable de redémarrer les trucs qui plantent ?
Heureusement.
C'est pas censé être le script de démarrage qui doit monitorer les process applicatifs (celà dit sur ce point je suis un peu mitigé, le respawn de l'inittab étant là pour ça).
Et quel intérêt que chaque script de chaque distrib pour le même service fasse la même chose, juste de manière un peu différente ?!
Donc oui, ça réduit énormément les différences et les répetitions d'efforts pour implémenter les mêmes choses.
6) systemd service files can (and hopefully will!) be written and distributed upstream: rather than every distro writing their own rc script (with their own set of trivial bugs and misunderstandings) the people who know the software the best (upstream) possibly with some input from the people who know the init system the best (systemd devs) can write "perfect" services that should just work everywhere. We have seen some of this already, and I think it is hugely benefitial. Even for distros who don't pick up systemd yet, this will allow them to at least have an idea oh how the software is meant to be initialized.
7) systemd is a cross-distro project: every major and many, many minor distros have had people contributing to systemd. last i heard even two debian devs have commit access to the repo, among many others. systemd upstream is very accommodating of different needs and different use-cases (as long as they are presented on technical grounds) and have been a pleasure to work with so far. We are getting the joint experience of a lot of people/projects who have worked on different init systems for a long time, I think this is one of the most important "features" one could have.
Chaque distribution aura intérêt à maintenir les différences pour pouvoir survivre. Et tant mieux d'ailleurs.
Chaque distribution arrêtera de faire de la merde dans son coin avec des scripts pourris. Et tant mieux d'ailleurs.
D'autre part, si leurs seuls différences résident dans les bogues de leurs scripts d'init, c'était bien la peine de faire des distributions...
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Nope
Posté par xcomcmdr . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 4. Dernière modification le 20 août 2013 à 19:20.
systemd y change quelque chose :
Et celles qui l'ont adopté ont bien vu l'intérêt de systemd, sans perdre leur identité.
Mutualiser les efforts, c'est bien aussi. Sinon, pourquoi tu ne craches pas aussi sur les standards XDG ?
Factoriser, c'est moche ? Juste LOL.
Je pense pas que cela soit pour autant obligatoire, mais il faudrait confirmer.
C'est à dire de ne pas considérer la config' matérielle comme étant immuable. De pouvoir démarrer par exemple le serveur Web uniquement lorsque la connexion réseau est présente. Ou de faire un fsck sur un disque dur externe lors de son branchement :
Heureusement.
Et quel intérêt que chaque script de chaque distrib pour le même service fasse la même chose, juste de manière un peu différente ?!
C'est pas une question d'y croire, c'est démontré.
Et si on regarde par exemple le paquet archlinux pour networkmanager et le paquet mageia pour ce même logiciel, les fichiers .service n'y sont pas, ils sont chez l'upstream.
Chaque distribution arrêtera de faire de la merde dans son coin avec des scripts pourris. Et tant mieux d'ailleurs.
D'autre part, si leurs seuls différences résident dans les bogues de leurs scripts d'init, c'était bien la peine de faire des distributions...
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)