En théorie la méthode traditionnelle sous Linux est belle mais en pratique il y a des soucis.
Déjà, pour que la mise à jour se fasse, il faut au minimum arrêter le logiciel concerné pour le relancer. En cas de mise à jour de MS Office dans Windows (qui passe par Windows Update), il faut relancer MS Office. Est-ce que l'utilisateur y pense ? Pas vraiment. Et tu ne peux pas le forcer à le faire.
Les mises à jour de Windows Update sont en général : Office, le cœur de Windows, Explorer / Edge, la BDD antivirus et des pilotes. Je crois que la BDD antivirus est le seul cas où un redémarrage n'est pas nécessaire et d'ailleurs, c'est la politique de MS sur le sujet.
Ensuite, une mise à jour à chaud cela pose des problèmes de cohérence entre les binaires des applications et des bibliothèques. Cela peut conduire à des bogues difficiles à identifier, prévoir ou éviter. Quand cela ne conduit pas à un crash de la machine.
Dans le cas des applis les bibliothèques sont chargées au démarrage de l'appli et donc ne changent en mémoire que si l'appli est redémarrée. Et pour la gestion du redémarrage tous les OS modernes fournissent des mécanismes de notifications. C'est donc faisable.
Sous debian on a l'outil checkrestart qui permet de lister les process qui nécessitent un redémarrage suite à une upgrade. Un utilisateur chevronné sait relativement facilement quelles applis doivent être redémarrées, parfois c'est tout le bureau, pour d'autre autant redémarrer la machine. Mais la décision pourrait être facilitées en jouant sur une catégorisation des composants (paquets dont dépendent des composants systèmes, un bureau dans son ensemble (exemple tout ce qui touche à des composants gnome/kde), ou seulement des applis isolées.
Crash de la machine ? Cas hyper extrême et que je n'ai pas souvenir d'avoir vu, en tout cas dans le monde debian/BSD. Il n'y a que les composants très bas niveau qui peuvent avoir une influence importante.
Par exemple, il y a pas si longtemps, chez Fedora (https://forums.fedora-fr.org/viewtopic.php?id=65807), un crash du serveur X survenait lors d'une maj de systemd (et non, systemd n'est pas le seul coupable, X11 l'était aussi). Résultat, si tu faisais ta mise à jour via un émulateur de terminal graphique, ta session plantait, ta maj avec et tu avais un système dans un état bien pénible à récupérer.
Je ne crois pas que Fedora, une distribution qui a pour vocation d'implémenter les technos les plus récentes, soit un cas d'école. C'est plus un prototype qu'un OS.
[^] # Re: Compléments
Posté par Psychofox (Mastodon) . En réponse au journal Après WannaCry, un 2e ransomware utilisant une cyberarme volée à la NSA ?. Évalué à 2.
Dans le cas des applis les bibliothèques sont chargées au démarrage de l'appli et donc ne changent en mémoire que si l'appli est redémarrée. Et pour la gestion du redémarrage tous les OS modernes fournissent des mécanismes de notifications. C'est donc faisable.
Sous debian on a l'outil checkrestart qui permet de lister les process qui nécessitent un redémarrage suite à une upgrade. Un utilisateur chevronné sait relativement facilement quelles applis doivent être redémarrées, parfois c'est tout le bureau, pour d'autre autant redémarrer la machine. Mais la décision pourrait être facilitées en jouant sur une catégorisation des composants (paquets dont dépendent des composants systèmes, un bureau dans son ensemble (exemple tout ce qui touche à des composants gnome/kde), ou seulement des applis isolées.
Crash de la machine ? Cas hyper extrême et que je n'ai pas souvenir d'avoir vu, en tout cas dans le monde debian/BSD. Il n'y a que les composants très bas niveau qui peuvent avoir une influence importante.
Je ne crois pas que Fedora, une distribution qui a pour vocation d'implémenter les technos les plus récentes, soit un cas d'école. C'est plus un prototype qu'un OS.