On Thu, Jan 5, 2012 at 5:32 AM, Rickard Nilsson <[email protected]>wrote:
> Hi, > > On Tue, 03 Jan 2012 15:47:23 +0100, Florian Friesdorf > <[email protected]> wrote: > > Hi Rickard, > > > > On Tue, 04 Oct 2011 11:45:14 +0200, "Rickard Nilsson" > > <[email protected]> wrote: > >> > However in your case > >> > http://mawercer.de/~marc/minimal-install-archive.patch should be > >> enough > >> > if you're lucky. > >> > >> Thanks! I will start out from that and see where I end up. > > > > did you made progress with that? For a full backup there might be > > more > > files needed, e.g.: > > /etc/wpa_supplicant.conf > > /etc/passwd > > /etc/shadow > > /etc/group > > /var/lib/wicd/* > Longer term, it may be worth considering a generic approach to statefulness within nix's stateless framework. Many of the applications one would wish to deploy exist primarily to maintain stateful information. A database is a simple example. The information on disk is organized and maintained by a specific version of the database software, and hence depends on that version. There are specific procedures for upgrading the stateful information such that it can be managed by the next version of the database software. There are generally no procedures for downgrading such that the information can be managed by a previous version. The same thing applies to system configuration. Configuration file formats and contents may depend on the version of the software/service/daemon they belong to (although they're usually pretty good about being backward compatible). Desktop apps will have "user preferences" stored somewhere. Every time I upgrade Eclipse, I have a period of instability as plugins which were referenced in the workspace are replaced and individually reconfigured--and its hard to keep my "software development" version of eclipse truly separate from my Topcased (modeling) instance. In reality, very few applications are truly stateless. Web applications are even more challenging because they usually save state both in a database and on the filesystem. There is also an additional layer of "deployment information" which also needs to be saved. Deployment information should be reusable from system to system, perhaps parameterized by the base url you would like to deploy to. For Java webapps, it may include information about how to proxy the app with apache, so you don't have to suffix your hostname with :8080. The interesting question is: How would you bring the advantages of Nix+NixOS (atomic upgrades, rollbacks, etc) into the realm of applications which maintain stateful information? Could modules be used? Does some new mechanism need to be invented? Bryce
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
