D'autant que ce qui était dans /dev/.<xxx>, soit sur un montage tmpfs, donc en mémoire, va se retrouver désormais écrit dans le système de fichiers racine avec tous les risques inhérents à ce genre de pratique (des données volatiles dans /).
C'est pour ça que dans son mail, Poettering explique que /run est un tmpfs.
gagner quelques millièmes de secondes au boot ? Rester permissif dans la gestion des dépendances des rc.d ?
Ni l'un ni l'autre, mais se débarrasser de dossiers /cachés/ dans /dev.
Histoire de fusionner trois FS (/dev/.<xxx>, /etc, /lib/rw) en un, on rend plus vulnérable /. Je ne vois pas où est l'intérêt.
Je ne vois de /lib/rw ni sous Arch, ni sous Debian que j'ai sous la main, ni dans le mail de Poettering. Je ne sais donc pas exactement à quoi tu fais référence. /run a effectivement pour but de remplacer tous les /dev/.xxx, le /lib/init/rw qui est une Debiannerie qui a le même but que le /run proposé, et les choses crades qui écrivent dans /etc (d'ailleurs, je n'ai pas d'exemple en tête de scripts au démarrage qui font ceci... tu as un coupable en tête ?).
[^] # Re: Et les autres?
Posté par Frédéric Perrin (site web personnel) . En réponse à la dépêche /run or not /run. Évalué à 8.
C'est pour ça que dans son mail, Poettering explique que /run est un tmpfs.
Ni l'un ni l'autre, mais se débarrasser de dossiers /cachés/ dans /dev.
Je ne vois de /lib/rw ni sous Arch, ni sous Debian que j'ai sous la main, ni dans le mail de Poettering. Je ne sais donc pas exactement à quoi tu fais référence. /run a effectivement pour but de remplacer tous les /dev/.xxx, le /lib/init/rw qui est une Debiannerie qui a le même but que le /run proposé, et les choses crades qui écrivent dans /etc (d'ailleurs, je n'ai pas d'exemple en tête de scripts au démarrage qui font ceci... tu as un coupable en tête ?).
En quoi /run rend / vulnérable ?