Surtout qu'ici on parle d'une nouveauté qui est optionnelle. Pas tout le monde ne peut et ne doit se servir de ce truc avec systemd. Uniquement si cela répond au cas d'usage identifié.
Perso, vu comment systemd progresse, je pense que ça risque d'être obligé un jour où l'autre. Pour le coup, ça ne sera pas que la faute de Lennart, puisque c'est poussé par un paquet d'autres promoteurs dans les distros.
D'ailleurs je le rappelle que ses fondateurs ont préféré concevoir son successeur à part (Plan 9) plutôt que de faire une évolution incrémentale car le changement à opérer était trop lourd.
Et on voit le résultat. Pour moi, la faillite de Plan 9 est due certes à l'inertie des utilisateurs (migrer à une nouvelle manière de voir est toujours compliqué par tout un tas de facteurs non-techniques), mais également à l'intégration trop poussée avec par exemple l'authentification ou le stockage. Parce que les syscall réduits, ça je pense que c'est une révolution que tout le monde aimerait avoir, mais l'existant aujourd'hui est tellement plus gigantesque qu'à l'époque que ça n'arrivera probablement jamais. Mais question intégration trop poussée, c'est exactement ce qui est reproché à systemd, qui a lui pourtant du succès...
Mais pour revenir à ta critique d'Unix, perso c'est le genre d'argument que j'entends régulièrement et où se sont plantés tellement de monde...
En quoi ce cheminement pourtant commun aujourd'hui est problématique ?
(je comprends que c'est problématique, t'inquiètes pas)
Ce n'est pas normal qu'un utilisateur qui déchiffre la partition déchiffre les données de tout le monde en même temps.
C'est un choix qui est depuis longtemps assumé et n'a pas posé problème, de ce que je constate. Seulement si tu as un modèle de menace parano.
Ce n'est pas réalisable actuellement sans éteindre la machine ou sans se déconnecter totalement.
Ça n'est pas fait, mais ça le serait très bien sans systemd : comme pour le login automatique si on a déchiffré le système au boot, PAM peut avoir des modules pour faire ça. Pourquoi ça n'a pas été fait par ce biais ? Je ne sais pas, mais vu la tendance de Lennart à tout réinventer à sa sauce, ça ne m'étonne pas de lui qu'il ait dû savoir que ça aurait été possible par PAM mais a préféré l'ajouter dans systemd.
Il y a bien sûr la partie interaction avec les évènements liés à la veille, qui sont le cœur originel de systemd et la raison pour laquelle il intègre udev, mais ça aurait pu (et dû !) tellement être fait de manière non-intégrée... Pour info, je suis au courant de ces problématiques bien même avant que Lennart ne s'en soit occupé, car ces interactions étaient déjà réfléchies sur les Mac PPC sous Linux (~ 2005 ou 2006 pour mon cas) puisque la gestion correcte de la veille était l'une des killer-feature de Mac OS X (les PCs étaient à la ramasse à l'époque). C'était avec des démons spécifique (pbbuttonsd ou pommed, après recherche car ma mémoire flanche) et des kernels patchés pour avoir un suspend-to-ram fonctionnel, mais il y avait des réflexions intéressantes sur comment bien intégrer ça, mais qui n'ont pas abouti.
non réalisable sans effectuer ce genre de changements profonds.
C'est faux.
Et cela n'a rien d'obligatoire, si cela ne t'intéresse pas, tu ne l'utilises pas.
C'est l'argument massue avec tout ce qui vient de systemd : t'as qu'à utiliser un système sans systemd, et voir toutes les fonctionnalités se dégrader petit à petit. Oui, les mainteneurs ne peuvent pas doubler leur efforts pour gérer plusieurs systèmes d'init, et donc dire que « c'est pas obligatoire, tu peux faire autrement » est fallacieux ; ça ne sera pas maintenu, ça ne marchera plus. (mais je sais qu'il ne tient qu'à moi d'envoyer des patchs, mais je ne mets pas assez d'effort à cette tâche ; j'ai un exemple typique avec libvirt où les scripts sysv ont été supprimés, y'a plus que des units systemd, mais ils marchent toujours très bien avec la dernière version disponible de libvirt car ils n'ont pas été effacés depuis l'ancienne — killer-feater standard de Debian qui n'efface pas les conffiles si on le souhaite, en passant)
Et forcément pour faire ça, oui il faut du bout de code et de config dans l'initrd car le disque dur est chiffré, oui des données doivent être stockées ailleurs par rapport à nos habitudes, etc. Mais il n'y a pas d'autre choix, en fait.
Si, avec cryptfs (qui est un des choix offert par systemd-homed, en plus), tu ne chiffres que le home de l'utilisateur. Perso, chiffrer le système entier je ne comprends pas l'intérêt (encore une fois, dans des modèles de menace raisonnables). Par contre pour les méta-données utilisateur d'un volume qui bouge de machine, actuellement ça n'est effectivement pas facilement faisable.
[^] # Re: Et Poettering ?
Posté par benoar . En réponse au journal Confinement : risque de release de nombreux projets inutiles. Évalué à 9.
Perso, vu comment systemd progresse, je pense que ça risque d'être obligé un jour où l'autre. Pour le coup, ça ne sera pas que la faute de Lennart, puisque c'est poussé par un paquet d'autres promoteurs dans les distros.
Et on voit le résultat. Pour moi, la faillite de Plan 9 est due certes à l'inertie des utilisateurs (migrer à une nouvelle manière de voir est toujours compliqué par tout un tas de facteurs non-techniques), mais également à l'intégration trop poussée avec par exemple l'authentification ou le stockage. Parce que les syscall réduits, ça je pense que c'est une révolution que tout le monde aimerait avoir, mais l'existant aujourd'hui est tellement plus gigantesque qu'à l'époque que ça n'arrivera probablement jamais. Mais question intégration trop poussée, c'est exactement ce qui est reproché à systemd, qui a lui pourtant du succès...
Mais pour revenir à ta critique d'Unix, perso c'est le genre d'argument que j'entends régulièrement et où se sont plantés tellement de monde...
(je comprends que c'est problématique, t'inquiètes pas)
C'est un choix qui est depuis longtemps assumé et n'a pas posé problème, de ce que je constate. Seulement si tu as un modèle de menace parano.
Ça n'est pas fait, mais ça le serait très bien sans systemd : comme pour le login automatique si on a déchiffré le système au boot, PAM peut avoir des modules pour faire ça. Pourquoi ça n'a pas été fait par ce biais ? Je ne sais pas, mais vu la tendance de Lennart à tout réinventer à sa sauce, ça ne m'étonne pas de lui qu'il ait dû savoir que ça aurait été possible par PAM mais a préféré l'ajouter dans systemd.
Il y a bien sûr la partie interaction avec les évènements liés à la veille, qui sont le cœur originel de systemd et la raison pour laquelle il intègre udev, mais ça aurait pu (et dû !) tellement être fait de manière non-intégrée... Pour info, je suis au courant de ces problématiques bien même avant que Lennart ne s'en soit occupé, car ces interactions étaient déjà réfléchies sur les Mac PPC sous Linux (~ 2005 ou 2006 pour mon cas) puisque la gestion correcte de la veille était l'une des killer-feature de Mac OS X (les PCs étaient à la ramasse à l'époque). C'était avec des démons spécifique (pbbuttonsd ou pommed, après recherche car ma mémoire flanche) et des kernels patchés pour avoir un suspend-to-ram fonctionnel, mais il y avait des réflexions intéressantes sur comment bien intégrer ça, mais qui n'ont pas abouti.
C'est faux.
C'est l'argument massue avec tout ce qui vient de systemd : t'as qu'à utiliser un système sans systemd, et voir toutes les fonctionnalités se dégrader petit à petit. Oui, les mainteneurs ne peuvent pas doubler leur efforts pour gérer plusieurs systèmes d'init, et donc dire que « c'est pas obligatoire, tu peux faire autrement » est fallacieux ; ça ne sera pas maintenu, ça ne marchera plus. (mais je sais qu'il ne tient qu'à moi d'envoyer des patchs, mais je ne mets pas assez d'effort à cette tâche ; j'ai un exemple typique avec libvirt où les scripts sysv ont été supprimés, y'a plus que des units systemd, mais ils marchent toujours très bien avec la dernière version disponible de libvirt car ils n'ont pas été effacés depuis l'ancienne — killer-feater standard de Debian qui n'efface pas les conffiles si on le souhaite, en passant)
Si, avec cryptfs (qui est un des choix offert par systemd-homed, en plus), tu ne chiffres que le home de l'utilisateur. Perso, chiffrer le système entier je ne comprends pas l'intérêt (encore une fois, dans des modèles de menace raisonnables). Par contre pour les méta-données utilisateur d'un volume qui bouge de machine, actuellement ça n'est effectivement pas facilement faisable.