Je n'ai pas encore suivi le thread sur fedora-devel et tout ça en dans un stade "initiale".
Mais ... Red Hat a acheté sistina qui développe lvm2 et device-mapper. Or device-mapper support les "snapshots" mais Red Hat a aussi un solution cluster qui supporte ça.
Dans un premier temps, cette techno sera sûrement (avis perso) utilisée pour le serveur d'"OS" (l'image de référence du système client). Actuellement il y a un "double-buffering" bien rustique.
Couplé à rpm, ça peut permettre de mettre à jours l'"OS" de référence (sur le serveur) sans géner les clients en cours de mise à jours.
> Par ce que si jamais tu commence à taf sur une session et que tu prends pas le temps de syncroniser ton boulot avant de changer de poste ca risque d etre vite le bordel dans ce cas.
Pour la partie client, il y aura évidement un "gestionnaire de conflit" lorsque tu feras l'importation.
Il est claire que si tu ouvres deux sessions en même temps (session précedente non fermée pour x raison), le serveur va gueuler (t'avertir gentillement). Comme le client va mettre un gros warning si tu ouvres une sessions sans en informer le serveur.
Il y a toujours un moment où il faut un minimum de contrôle. Si tu veux être libre à 100 %, tu ne choisi pas ce modèle sans état (côté client).
[^] # Re: sans état
Posté par 007 . En réponse au journal stateless Linux. Évalué à 1.
Mais ... Red Hat a acheté sistina qui développe lvm2 et device-mapper. Or device-mapper support les "snapshots" mais Red Hat a aussi un solution cluster qui supporte ça.
Dans un premier temps, cette techno sera sûrement (avis perso) utilisée pour le serveur d'"OS" (l'image de référence du système client). Actuellement il y a un "double-buffering" bien rustique.
Couplé à rpm, ça peut permettre de mettre à jours l'"OS" de référence (sur le serveur) sans géner les clients en cours de mise à jours.
> Par ce que si jamais tu commence à taf sur une session et que tu prends pas le temps de syncroniser ton boulot avant de changer de poste ca risque d etre vite le bordel dans ce cas.
Pour la partie client, il y aura évidement un "gestionnaire de conflit" lorsque tu feras l'importation.
Il est claire que si tu ouvres deux sessions en même temps (session précedente non fermée pour x raison), le serveur va gueuler (t'avertir gentillement). Comme le client va mettre un gros warning si tu ouvres une sessions sans en informer le serveur.
Il y a toujours un moment où il faut un minimum de contrôle. Si tu veux être libre à 100 %, tu ne choisi pas ce modèle sans état (côté client).