Systemd a plein de switch pour son script configure. Et d’après les archives, le projet accepte assez facilement ce qui permet de désactiver certains requirements comme par exemple, selinux, pam, gcrypt, etc.
Ceci dit, de ce que je lit du code, c'est systemd qui va demander à monter de force 4/5 fs ( cf ./src/core/mount-setup.c tableau mount_table ), et qu'en effet, le logiciel requiert d'avoir /dev/ en devtmpfs. Je suis pas assez expert pour savoir si ça fait plus qu'un simple tmpfs, mais c'est vrai que c'est discutable, même si je peux comprendre l'envie de pas avoir des milliers de cas au vue de tout ce que le noyau supporte ou pas.
Ensuite, oui, le fait de dépendre d'un certain nombre d'option noyau est gênante. Par exemple, feu mes 2 RPS n'avaient pas de support de cgroups, j'ai jamais pu mettre à jour la mageia dessus. Et c'est le même souci que j'ai avec divers appareils embarqués ( téléphone, routeur ) avec des pilotes proprios ou des patchs qui sont pas upstreams dans le kernel, je peux pas mettre à jour, ou mettre à jour, c'est chiant.
Systemd, de part sa place centrale, requiert quand même un minimum d'intégration et de travail, et du coup, tu peux pas juste "je boote avec n'importe ou et ça passe" :/
[^] # Re: C'est plus facile de travailler salement...
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 3.
Systemd a plein de switch pour son script configure. Et d’après les archives, le projet accepte assez facilement ce qui permet de désactiver certains requirements comme par exemple, selinux, pam, gcrypt, etc.
Ceci dit, de ce que je lit du code, c'est systemd qui va demander à monter de force 4/5 fs ( cf ./src/core/mount-setup.c tableau mount_table ), et qu'en effet, le logiciel requiert d'avoir /dev/ en devtmpfs. Je suis pas assez expert pour savoir si ça fait plus qu'un simple tmpfs, mais c'est vrai que c'est discutable, même si je peux comprendre l'envie de pas avoir des milliers de cas au vue de tout ce que le noyau supporte ou pas.
Ensuite, oui, le fait de dépendre d'un certain nombre d'option noyau est gênante. Par exemple, feu mes 2 RPS n'avaient pas de support de cgroups, j'ai jamais pu mettre à jour la mageia dessus. Et c'est le même souci que j'ai avec divers appareils embarqués ( téléphone, routeur ) avec des pilotes proprios ou des patchs qui sont pas upstreams dans le kernel, je peux pas mettre à jour, ou mettre à jour, c'est chiant.
Systemd, de part sa place centrale, requiert quand même un minimum d'intégration et de travail, et du coup, tu peux pas juste "je boote avec n'importe ou et ça passe" :/