Euh non. L'init a besoin que quelque chose découvre le matos avant de booter, et c'est le rôle de udev
Du tout : même si c’était déprecié, tu pouvais utiliser devfs. Voire créer les fichiers à la main (j’ai ouïe dire que ça se faisait dans certains systèmes embarqué, mais j’avoue que c’est pas mon domaine).
Et dans l’autre sens udev ne dépendait pas d’un init particulier, tu pouvais l’utiliser avec initng, sysvinit, mudur, celui de slackware...
Quant à Linux c’est pas vraiment la question, udev était lié à Linux avant, il l’est tout autant avec systemd, pas de changement, je vois même pas ce qu’il y a à discuter là dessus...
Ben bah plus que dans l'ancien modèle, si ce n'est que systemd (le projet) a besoin de linux et pas un autre kernel. Encore une fois, je doute que ça change grand chose par rapport à l'ancien modèle (udev et les scripts SysV Debian tournent-ils sous BSD ? J'ai un gros doute là !)
udev non, les scripts init oui, c’est du bête shell, mais ce n’est pas la question, je ne parle pas du couplage entre l’OS et les différents composants mais des différents composants entre eux.
udev a-t-il besoin de systemd ? Non. C'est juste systemd qui a besoin de udev.
Tu as pas suivi ? udev sans systemd n’est maintenant plus supporté, autrement dit couplage fort entre les deux.
Je peux avoir le système d’init systemd sans le système de gestion de service de systemd ? Et dans l’autre sens ? Il me semble pas.
Et tu vois les choses de manière trop binaire, il y a tout un continuum entre totalement couplé/totalement découplé, et ce que je dis c’est que systemd pousse dans la première direction, ce qu’on peut difficilement nier, puisque c’est après tout un avantage que mettent en avant les défenseurs de systemd (« l’ancien système c’est un patchwork de trucs complètement indépendants qui arrivent tant bien que mal à donner un système fonctionnel, mais fonctionnel n’est ni optimal ni intégré, ce qui ne nous permet pas de lutter face à la concurrence Windows/OSX », pour caricaturer (un peu) le discours) et un objectif affiché du projet (faire un système homogène, unifié et intégré, et ça ça passe par plus de couplage, c’est les deux faces d’une même pièce).
[^] # Re: Description de systemd ?
Posté par Moonz . En réponse à la dépêche systemd versions 212 à 215. Évalué à 6.
Du tout : même si c’était déprecié, tu pouvais utiliser devfs. Voire créer les fichiers à la main (j’ai ouïe dire que ça se faisait dans certains systèmes embarqué, mais j’avoue que c’est pas mon domaine).
Et dans l’autre sens udev ne dépendait pas d’un init particulier, tu pouvais l’utiliser avec initng, sysvinit, mudur, celui de slackware...
Quant à Linux c’est pas vraiment la question, udev était lié à Linux avant, il l’est tout autant avec systemd, pas de changement, je vois même pas ce qu’il y a à discuter là dessus...
udev non, les scripts init oui, c’est du bête shell, mais ce n’est pas la question, je ne parle pas du couplage entre l’OS et les différents composants mais des différents composants entre eux.
Tu as pas suivi ? udev sans systemd n’est maintenant plus supporté, autrement dit couplage fort entre les deux.
Je peux avoir le système d’init systemd sans le système de gestion de service de systemd ? Et dans l’autre sens ? Il me semble pas.
Et tu vois les choses de manière trop binaire, il y a tout un continuum entre totalement couplé/totalement découplé, et ce que je dis c’est que systemd pousse dans la première direction, ce qu’on peut difficilement nier, puisque c’est après tout un avantage que mettent en avant les défenseurs de systemd (« l’ancien système c’est un patchwork de trucs complètement indépendants qui arrivent tant bien que mal à donner un système fonctionnel, mais fonctionnel n’est ni optimal ni intégré, ce qui ne nous permet pas de lutter face à la concurrence Windows/OSX », pour caricaturer (un peu) le discours) et un objectif affiché du projet (faire un système homogène, unifié et intégré, et ça ça passe par plus de couplage, c’est les deux faces d’une même pièce).