les mises à jour qui foirent. Tu as la chance de ne pas avoir eu ce genre de problème, mais je peux t'assurer qu'ils sont encore très courants dans le monde Linux.
ça ne résout pas tous les problèmes. On avait depuis longtemps la garantie d'une mise à jour d'un fichier de façon atomique. Et le fait que le descripteur de fichier est valide tant qu'il reste au moins une utilisation. Du coup on pouvait remplacer libtruc.so.2.0 par libtruc.so.2.1, et même pour les processus utilisant l'ancienne version au même moment, ça allait (par contre le changement effectif nécessitait un redémarrage du processus).
Avec du btrfs ou avec une installation séparée dans une autre arborescence (ce que fait Nix), on a une bascule atomique d'un ensemble de fichiers vers un autre (et le retour arrière possible). Donc on élimine les cas où on a mis à jour la moitié des fichiers seulement avant d'être interrompu par une erreur du script, une saturation du disque ou une coupure électrique par exemple. Mais il faut toujours gérer les redémarrages.
Et ça ne traite pas forcément le cas des données (si tu migres de TrucSQL v2 à TrucSQL v3, les binaires sont mis à jour, les données sont éventuellement converties avec "pertes", et peut-être que le retour arrière n'est pas prévu...).
Et ça ne traite pas forcément le cas des fichiers utilisateurs (configuration, fichiers temporaires, cache, etc.) : si la v3 ajoute un fichier truc et que la v2 ne peut pas fonctionner avec ce fichier truc présent, et que personne ne personne à l'enlever/mettre de côté pendant le retour arrière, alors ça casse encore. trucpourrait aussi être un core dump imprévu par exemple.
Et ça ne traite pas le cas des fins de vie : tu mets à jour ton appli parce qu'elle contient/utilise une ressource qui expire (genre un certificat ou une clé GPG), alors le retour arrière ne fera pas de miracle non plus.
Et probablement d'autres cas...
Et comme on ne peut pas avoir toutes les propriétés que l'on veut en simultané, si chaque logiciel vient avec ses propres dépendances "privées" à lui, alors gérer la sécurité globale de tout cela est plus compliqué par exemple.
[^] # Re: Bref c'est une idée pourrie
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 7.
ça ne résout pas tous les problèmes. On avait depuis longtemps la garantie d'une mise à jour d'un fichier de façon atomique. Et le fait que le descripteur de fichier est valide tant qu'il reste au moins une utilisation. Du coup on pouvait remplacer
libtruc.so.2.0parlibtruc.so.2.1, et même pour les processus utilisant l'ancienne version au même moment, ça allait (par contre le changement effectif nécessitait un redémarrage du processus).Avec du
btrfsou avec une installation séparée dans une autre arborescence (ce que fait Nix), on a une bascule atomique d'un ensemble de fichiers vers un autre (et le retour arrière possible). Donc on élimine les cas où on a mis à jour la moitié des fichiers seulement avant d'être interrompu par une erreur du script, une saturation du disque ou une coupure électrique par exemple. Mais il faut toujours gérer les redémarrages.Et ça ne traite pas forcément le cas des données (si tu migres de TrucSQL v2 à TrucSQL v3, les binaires sont mis à jour, les données sont éventuellement converties avec "pertes", et peut-être que le retour arrière n'est pas prévu...).
Et ça ne traite pas forcément le cas des fichiers utilisateurs (configuration, fichiers temporaires, cache, etc.) : si la v3 ajoute un fichier
trucet que la v2 ne peut pas fonctionner avec ce fichiertrucprésent, et que personne ne personne à l'enlever/mettre de côté pendant le retour arrière, alors ça casse encore.trucpourrait aussi être uncore dumpimprévu par exemple.Et ça ne traite pas le cas des fins de vie : tu mets à jour ton appli parce qu'elle contient/utilise une ressource qui expire (genre un certificat ou une clé GPG), alors le retour arrière ne fera pas de miracle non plus.
Et probablement d'autres cas...
Et comme on ne peut pas avoir toutes les propriétés que l'on veut en simultané, si chaque logiciel vient avec ses propres dépendances "privées" à lui, alors gérer la sécurité globale de tout cela est plus compliqué par exemple.