The snappy approach is faster, more reliable, and lets us provide stronger security guarantees for apps and users — that’s why we call them “snappy” applications.

How does transactional update make snappy more secure, faster and more reliable? Since it sounds so good, why doesn't Ubuntu adopt the snappy approach?

  • Have a look at this to know how transactional updates differ from normal updates. As for the adoption, rumors has that 16.04 will support it. – Ron Dec 12 '15 at 13:04

Well, that was kind of an over-arching sentence, that Snappy has those advantages-- they don't all come from transactional updates. Transactional updates applies to the "faster" and "more reliable" parts.

With the normal Ubuntu (Debian) packages, you only install one version at a time. If you install version 1 of package foo, and version 2 is released into the repos, then you update to version 2, which effectively uninstalls version 1. If you don't like version 2 (or it was broken), you have to essentially uninstall it and install version 1 again.

In Snappy this changes a bit. If you install version 1 of package foo, and version 2 is released into the store, then you update to version 2. However, version 1 remains installed, it's simply deactivated. If you don't like version 2 (or it was broken) you can roll back to version 1 immediately, without downloading anything. You can see how this would be faster and makes for a more reliable system.

As for why Ubuntu doesn't adopt the Snappy approach, well, that's what Ubuntu Core is! Ubuntu Next is now also based on Snappy. It's just that Snappy is still being developed when it comes to GUI-based things (note that Ubuntu Core is CLI-only).

  • Thanks. Upvoted and chosen as answer. It sounds like it will consume lots of hard-disk space with Snappy. If I upgrade from ver1 to ver10, I will have all 10 versions of the package. This could be a problem. I am surprised Snappy is going to be on Internet of Things since things are embedded devices which may not have that much disk space. – user768421 Dec 12 '15 at 14:00
  • We will in future send only binary deltas for package updates (so the download is more efficient than re-fetching the entire thing as we do today in debs). You are correct that storing multiple copies would be inefficient, but we store them compressed (about 5x saving) so storing two or three copies isn't really a big problem. In many embedded cases compression saves you from the most critical performance problem - disk i/o. In the end, though, we are targeting environments where the cost of a few GB flash is much less than the cost of sending out a technician or a fixed product. – Mark Shuttleworth Dec 13 '15 at 13:32
  • It all sounds so wonderful, but essential reverting to an older version is still downgrading. How can snappy guarantee that things do not break, due to a user's configfiles which are not forward compatible. (thus running older code with already upgraded config and/or data files) – hbogert Apr 21 '16 at 12:48
  • @hbogert I'm not sure such a thing is possible. The snap in question comes from a developer who may have made a mistake, which Snappy can't control. Similarly, if the snap utilizes user-supplied configs and the new version of the snap breaks because of the given config, Snappy can't control that either. What Snappy CAN do is give you a way to continue working in the face of these issues (i.e. rollback to one that DID work). Of course it's a downgrade, but that's because the new version doesn't work! – Kyle Apr 21 '16 at 13:58
  • 1
    @hbogert ah-- the data (e.g. a user config) is copied as well as the new version. Rolling back both rolls back the version of the snap used, as well as the data associated with it. Say a snap had a mysql database, and a new version of the snap needed to run some migrations on the database. When upgrading the database would be copied, and the migrations run on the new copy. If the migrations fail, the rollback would rollback to using the version of the database before the copy (and migrations) occurred. – Kyle Apr 21 '16 at 19:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.