l'obstination de pousser à redémarrer pour les mises à jour quand on veut éteindre
Ça, à mon avis, c'est plus général que GNOME, on se dirige de plus en plus vers ça. Je crois que c'est aussi le cas de KDE.
Permettre les mises à jour sur place pendant l'utilisation, c'est continuer à ne pas pouvoir garantir la stabilité de l'ensemble à partir du début de la mise à jour parce qu'on se retrouve avec un mix de nouvelles briques qui interagissent avec des anciennes briques, voire des briques qui ont changé de version pendant l'exécution, ça ne peut pas super bien marcher à moins que chaque logiciel soit spécifiquement conçu pour gérer cette situation et ce n'est pas le cas.
Une alternative c'est de permettre d'éteindre sans appliquer les mises à jour, et les mises à jour sont appliquées au redémarrage et on redemande un redémarrage après (donc deux redémarrage pour appliquer les mises à jours, et on fait patienter les utilisateurs au démarrage, pas à l'arrêt).
Une autre alternative c'est le système A/B, où on lance le système depuis la partition A, B est une copie de A qui sera mise à jour en background, et au redémarrage B devient A, avec une possibilité de fallback si la mise à jour a cassé quelque chose. Avec des systèmes de fichiers style Btrfs ou ZFS, on peut imaginer ça avec des sous-volumes pour que ça soit plus léger. Ce système A/B suppose un peu un système immuable.
Perso, je lance des apt full-upgrade ou des zypper dup pendant que j'utilise la machine, mais je sais pertinemment qu'il faut que je m'attende à des instabilités. J'ai de plus en plus tendance à redémarrer juste après, du coup.
[^] # Re: GNOME, le moins nul des DE
Posté par raphj (site web personnel) . En réponse au journal GNOME Stop Me Now. Évalué à 2. Dernière modification le 07 août 2025 à 10:13.
Ça, à mon avis, c'est plus général que GNOME, on se dirige de plus en plus vers ça. Je crois que c'est aussi le cas de KDE.
Permettre les mises à jour sur place pendant l'utilisation, c'est continuer à ne pas pouvoir garantir la stabilité de l'ensemble à partir du début de la mise à jour parce qu'on se retrouve avec un mix de nouvelles briques qui interagissent avec des anciennes briques, voire des briques qui ont changé de version pendant l'exécution, ça ne peut pas super bien marcher à moins que chaque logiciel soit spécifiquement conçu pour gérer cette situation et ce n'est pas le cas.
Une alternative c'est de permettre d'éteindre sans appliquer les mises à jour, et les mises à jour sont appliquées au redémarrage et on redemande un redémarrage après (donc deux redémarrage pour appliquer les mises à jours, et on fait patienter les utilisateurs au démarrage, pas à l'arrêt).
Une autre alternative c'est le système A/B, où on lance le système depuis la partition A, B est une copie de A qui sera mise à jour en background, et au redémarrage B devient A, avec une possibilité de fallback si la mise à jour a cassé quelque chose. Avec des systèmes de fichiers style Btrfs ou ZFS, on peut imaginer ça avec des sous-volumes pour que ça soit plus léger. Ce système A/B suppose un peu un système immuable.
Perso, je lance des apt full-upgrade ou des zypper dup pendant que j'utilise la machine, mais je sais pertinemment qu'il faut que je m'attende à des instabilités. J'ai de plus en plus tendance à redémarrer juste après, du coup.