Submitted by “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.”
Windows has that since Windows 2000… Windows Vista has a fully transactional system since 1 year ago Tx-NTFS…
Welcome in late linux 🙂
That’s a different thing. AFAIK NTFS does not support filesystem snapshots. If you’re referring to Windows Restore then you’re completely off-tracks here..
And the article is about Nexenta, an OpenSolaris kernel with a Debian userland, not Linux. Casuto is obviously very confused.
Edited 2008-01-18 17:03 UTC
I voted down your comment, as it is offtopic, beyond being trollish.
This article is neither about Windows NOR is it about Linux.
Also, the information you provide is wrong. Windows does NOT have something similiar to the presented ZFS+apt solution.
ZFS has no need for transactional support because of copy-on-write i.e. it support atomic transactions. Snapshots are free in ZFS while in Windows they will take disk space and you’ll wait a while depending on how much data you are ‘snapshoting’.
It seems that you havent studied what ZFS really is. You should read a bit about it? It IS truly revolutianry and the next generation file system. Why all the hype and fuzz about ZFS? There is some substance about ZFS.
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.
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 …
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