De même pour Linux, il existe des tas de solutions pour changer le kernel en live sans redémarrer (typiquement ce qui est fait dans les serveurs cloud, les machines virtuelles ne sont pas interrompues lorsque le porteur redémarre son noyau). Il faut pour cela que les drivers soient capables de correctement sauvegarder leur état et/ou faire un reset propre. C'est exactement la même problématique pour la veille prolongée (hibernation), le noyau sauvegarde ses états sur disque et les recharge en redémarrant. Si tu supprimes la phase "boot" au passage (qui n'a rien à faire lors d'une mise à jour), tu as une mise à jour transparente pour l'utilisateur (au pire, un freeze de quelques secondes pour la récréation des zones mémoires).
Alors le live patching du noyau ça fonctionne mais pas pour tous les correctifs non plus et c'est loin d'être trivial à exploiter.
C'est vraiment conçu comme un moyen de corriger pour de grosses failles ou gros problèmes immédiatement avant de procéder à un redémarrage plus tard à un moment plus opportun comme le weekend ou la nuit par exemple.
De toute façon il faut redémarrer aussi pour la mise à jour de certains composants type systemd ou libc de temps à autres.
La course à l'uptime n'est clairement pas une bonne stratégie de sécurité de nos jours.
[^] # Re: Atomique ?
Posté par Renault (site web personnel) . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 5.
Alors le live patching du noyau ça fonctionne mais pas pour tous les correctifs non plus et c'est loin d'être trivial à exploiter.
C'est vraiment conçu comme un moyen de corriger pour de grosses failles ou gros problèmes immédiatement avant de procéder à un redémarrage plus tard à un moment plus opportun comme le weekend ou la nuit par exemple.
De toute façon il faut redémarrer aussi pour la mise à jour de certains composants type systemd ou libc de temps à autres.
La course à l'uptime n'est clairement pas une bonne stratégie de sécurité de nos jours.