Ne serait-ce donc pas cette démarche qu'il faudrait privilégier du côté de Linux plutôt que l'apparition d'un /run ?
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 /).
Tout cela ne me parait pas franchement fiable/logique, genre pansement sur une jambe de bois, et tout cela pour quoi ? gagner quelques millièmes de secondes au boot ? Rester permissif dans la gestion des dépendances des rc.d ?
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.
Mais quand on voit que certains que certains écrivent déjà dans /etc ou /lib/rw (données volatiles dans la configuration statique ou sous la racine), un /run en plus ne doit pas faire peur... :/
[^] # Re: Et les autres?
Posté par Quzqo . En réponse à la dépêche /run or not /run. Évalué à 5.
Ne serait-ce donc pas cette démarche qu'il faudrait privilégier du côté de Linux plutôt que l'apparition d'un /run ?
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 /).
Tout cela ne me parait pas franchement fiable/logique, genre pansement sur une jambe de bois, et tout cela pour quoi ? gagner quelques millièmes de secondes au boot ? Rester permissif dans la gestion des dépendances des rc.d ?
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.
Mais quand on voit que certains que certains écrivent déjà dans /etc ou /lib/rw (données volatiles dans la configuration statique ou sous la racine), un /run en plus ne doit pas faire peur... :/