"There is no ideal software, it always has bugs. Minor, major or security issues will always exist and modern operating systems need to deal with this fact. What if any software which user installs had a capability to rollback to previously known successful point and operation itself would take no time? What if developer or user has a tool which could checkpoint operating system and capability to revert changes in no time? This is possible if we will marry two great technologies: ZFS and Debian APT. Both technologies now part of Nexenta Operating System which is core foundation for its derivative distributions. Meet apt-clone. The tool which integrates with the NexentaCP system, keeps track of upgrade checkpoints and allows to create/destroy/edit checkpoints by request."
To read all comments associated with this story, please click here.
Member since:2005-12-13
I do believe this is meant to do with more than just installing / uninstalling your average Photoshop-esque application ...
This has more to do with complete installations of more complex nature, which might actually suffer from changes in applications.
I'd like to have had this kind of functionality when I once upgraded my OpenLDAP from the 2.2-branch to the 2.3-branch and suddenly nothing worked due to some changes in the database format, causing OpenLDAP to assume the database was empty ...
This happened with Debian and although not a general issue, I'm sure, a rollback of the working version of the application *and* the data associated would have been sweet ...
Member since:2005-07-24
In case anyone is interested, yum/up2date/rpm have supported "rollbacks" for a long time. Before it upgrades a package, it repackages the old one into a custom rpm along with the actual config files, which one may have made changes to, and archives it for later use, should you decide to revert. The overhead is fairly high because building the rpm can be reasonably time consuming. But it does work. For yum, automatic rollback generation for all updates can be turned on in yum.conf.
Using ZFS transactions does, however, look like an interesting approach.
Edited 2008-01-18 18:56 UTC
Member since:
2005-11-06
I'm sure it can be useful, in the same sense that restore points on a virtualized environment are, for instance but...
If I install App A and, as it later turns out, it broke things but in the mean time I installed Apps B, C & D, I can "restore" quickly to the state before I installed A. The problem is, now I have to install B, C, D...
As I said, this is very useful, but when it comes to "apps" (as opposed to system-wide changes) I rather have them be as self-contained as possible, something like (most) Mac OS X apps which are simply a folder with all components inside. To uninstall, just delete that folder.
BTW, I mention this because the summary talks about "installing software" and I consider that whenever possible, not needing to "install" by making apps self contained and therefore not needing an "uninstall" process later, is a better solution than tracking every file system change involved and rolling back later, even if ZFS makes this painless.