<story><title>Ubuntu 20.04 LTS’ snap obsession has snapped me off of it</title><url>https://jatan.blog/2020/05/02/ubuntu-snap-obsession-has-snapped-me-off-of-it/</url></story><parent_chain><item><author>kikoreis</author><text>It&amp;#x27;s probably not a surprise to you, but this is a hotly debated topic inside Canonical. And I apologize for that thread, as it really doesn&amp;#x27;t represent our best attempt at external debate.&lt;p&gt;Changing a paradigm usually involves pushing the envelope and breaking some existing assumptions; systemd is everybody&amp;#x27;s favorite example of that in the Linux world. The root of this issue with snaps is the trade-off between built-in security and user control. Some points to consider:&lt;p&gt;1. Browsers like FF and Chromium [on Windows] simply self-update, and disabling that requires configuration. So there is at least some precedent for taking the position that user applications should just update themselves. Server apps are more complex and are a strong argument counter to the existing behavior, as is the fact that many apps cannot be refreshed without user impact.&lt;p&gt;2. Ubuntu, since 16.04 LTS, ships with unattended-upgrades enabled, which means that for debian packages the default behavior is already auto-updating (although automated reboots are not enabled by default, as that would be crazy for the general purpose case). That feels like the correct default, too, given the risk of running code exposed to exploitable, public CVEs — and how reluctant users (like my dad and my wife!) are to click on &amp;quot;Install now&amp;quot; in the update-manager dialog.&lt;p&gt;3. Debian package updates run as root. Snap updates run in userspace, and confined. So in principle the risk exposure for snap updates is much smaller. And snaps do have an auto-rollback mechanism for failed updates [a]. Counter to that argument is the fact that snaps are meant to be under third-party control, and that there is no clear mechanism to separate security patches vs updates which you get with the debian pocket mechanism (i.e. focal-security vs focal-updates).&lt;p&gt;The lack of any official [b] means of user control over the snap auto-update mechanism feels wrong to many of us, including me. And while we may seem somewhat opaque in these debates, the feedback we get in threads like this one (and the snapcraft.io one) actually feeds into our decision making. So please do keep pushing on this topic and we&amp;#x27;ll do our part internally.&lt;p&gt;[a] See &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;kyrofa.com&amp;#x2F;posts&amp;#x2F;snap-updates-automatic-rollbacks&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;kyrofa.com&amp;#x2F;posts&amp;#x2F;snap-updates-automatic-rollbacks&lt;/a&gt; for a detailed guide on this topic. Of course, if your snap refreshes and you hate the new version, downgrading isn&amp;#x27;t quite always possible.&lt;p&gt;[b] There are ways to, hmmm, control auto-updating (i.e. refresh.metered, refresh.hold) if you really want to; that thread has a few. That doesn&amp;#x27;t help the debate, but I&amp;#x27;m sharing in case someone has a technical need for it.</text></item><item><author>shock</author><text>I am very diligent about applying updates as soon as I&amp;#x27;m able and generally read the changelogs of the updates I&amp;#x27;m applying in Ubuntu&amp;#x27;s Software Updater.&lt;p&gt;One thing I will not do is willingly allow somebody else a way to deploy and execute code on my computer without my say so (which snap is).&lt;p&gt;After reading the whole thread at &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;forum.snapcraft.io&amp;#x2F;t&amp;#x2F;disabling-automatic-refresh-for-snap-from-store&amp;#x2F;707&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;forum.snapcraft.io&amp;#x2F;t&amp;#x2F;disabling-automatic-refresh-for...&lt;/a&gt; and seeing Gustavo Niemeyer&amp;#x27;s arrogance (we know better than you when you should be applying updates) I will be voting with my feet and will be installing Pop!_OS instead of Ubuntu, and if snapd is present I will remove it.&lt;p&gt;The stated goal of Niemeyer, to have users use updated software, would have been fulfilled in my case if I had a way to see what updates would be applied beforehand, instead of the updates being force-installed.&lt;p&gt;Lengthy dialog with Niemeyer in the forum thread seems to have been a waste of time for all the people who participated trying to convince him to allow disabling of force-installed updates so I suggest you do the same as me and vote with your feet!</text></item></parent_chain><comment><author>canonicalwhistl</author><text>Sorry, but as a fellow Canonical employee, speaking from a throwaway obviously, it&amp;#x27;s evident to me that you&amp;#x27;re simply not telling the truth here.&lt;p&gt;You know just as well as I do that if you criticize Snap within the company, you get fired. Especially if Mark overhears you. There is no room for criticism. You either drink the koolaid or you shutup. So, no, sorry, we&amp;#x27;re going to keep pumping out Snap and those who don&amp;#x27;t fall inline will just fall out of the company. This is how we&amp;#x27;ve always done these things, despite it failing repeatedly, and Snap is no exception. Actually, Snap is in particular no exception, given how hard it&amp;#x27;s being pushed by top level management.&lt;p&gt;[An aside from the main point of this comment: your point 3 is nonsense, and any security guy will tell you the same. For packages that the main sudo-ing user executes, sandboxed or not, there still is effectively no difference between that and root. Snap&amp;#x27;s sandbox is alpha quality at best, and major platform hurdles remain to make it capable of doing anything remotely useful. Say no to auto-updating snap backdoors. Please. There&amp;#x27;s a reason why Linux has thrived and benefited with its vetted-by-distros traditional package managers.]</text></comment>
<story><title>Ubuntu 20.04 LTS’ snap obsession has snapped me off of it</title><url>https://jatan.blog/2020/05/02/ubuntu-snap-obsession-has-snapped-me-off-of-it/</url></story><parent_chain><item><author>kikoreis</author><text>It&amp;#x27;s probably not a surprise to you, but this is a hotly debated topic inside Canonical. And I apologize for that thread, as it really doesn&amp;#x27;t represent our best attempt at external debate.&lt;p&gt;Changing a paradigm usually involves pushing the envelope and breaking some existing assumptions; systemd is everybody&amp;#x27;s favorite example of that in the Linux world. The root of this issue with snaps is the trade-off between built-in security and user control. Some points to consider:&lt;p&gt;1. Browsers like FF and Chromium [on Windows] simply self-update, and disabling that requires configuration. So there is at least some precedent for taking the position that user applications should just update themselves. Server apps are more complex and are a strong argument counter to the existing behavior, as is the fact that many apps cannot be refreshed without user impact.&lt;p&gt;2. Ubuntu, since 16.04 LTS, ships with unattended-upgrades enabled, which means that for debian packages the default behavior is already auto-updating (although automated reboots are not enabled by default, as that would be crazy for the general purpose case). That feels like the correct default, too, given the risk of running code exposed to exploitable, public CVEs — and how reluctant users (like my dad and my wife!) are to click on &amp;quot;Install now&amp;quot; in the update-manager dialog.&lt;p&gt;3. Debian package updates run as root. Snap updates run in userspace, and confined. So in principle the risk exposure for snap updates is much smaller. And snaps do have an auto-rollback mechanism for failed updates [a]. Counter to that argument is the fact that snaps are meant to be under third-party control, and that there is no clear mechanism to separate security patches vs updates which you get with the debian pocket mechanism (i.e. focal-security vs focal-updates).&lt;p&gt;The lack of any official [b] means of user control over the snap auto-update mechanism feels wrong to many of us, including me. And while we may seem somewhat opaque in these debates, the feedback we get in threads like this one (and the snapcraft.io one) actually feeds into our decision making. So please do keep pushing on this topic and we&amp;#x27;ll do our part internally.&lt;p&gt;[a] See &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;kyrofa.com&amp;#x2F;posts&amp;#x2F;snap-updates-automatic-rollbacks&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;kyrofa.com&amp;#x2F;posts&amp;#x2F;snap-updates-automatic-rollbacks&lt;/a&gt; for a detailed guide on this topic. Of course, if your snap refreshes and you hate the new version, downgrading isn&amp;#x27;t quite always possible.&lt;p&gt;[b] There are ways to, hmmm, control auto-updating (i.e. refresh.metered, refresh.hold) if you really want to; that thread has a few. That doesn&amp;#x27;t help the debate, but I&amp;#x27;m sharing in case someone has a technical need for it.</text></item><item><author>shock</author><text>I am very diligent about applying updates as soon as I&amp;#x27;m able and generally read the changelogs of the updates I&amp;#x27;m applying in Ubuntu&amp;#x27;s Software Updater.&lt;p&gt;One thing I will not do is willingly allow somebody else a way to deploy and execute code on my computer without my say so (which snap is).&lt;p&gt;After reading the whole thread at &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;forum.snapcraft.io&amp;#x2F;t&amp;#x2F;disabling-automatic-refresh-for-snap-from-store&amp;#x2F;707&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;forum.snapcraft.io&amp;#x2F;t&amp;#x2F;disabling-automatic-refresh-for...&lt;/a&gt; and seeing Gustavo Niemeyer&amp;#x27;s arrogance (we know better than you when you should be applying updates) I will be voting with my feet and will be installing Pop!_OS instead of Ubuntu, and if snapd is present I will remove it.&lt;p&gt;The stated goal of Niemeyer, to have users use updated software, would have been fulfilled in my case if I had a way to see what updates would be applied beforehand, instead of the updates being force-installed.&lt;p&gt;Lengthy dialog with Niemeyer in the forum thread seems to have been a waste of time for all the people who participated trying to convince him to allow disabling of force-installed updates so I suggest you do the same as me and vote with your feet!</text></item></parent_chain><comment><author>InternetOfStuff</author><text>Let me point out: to me, auto-updating isn&amp;#x27;t even the crucial issue (I use unattended-upgrades as well, so whatever).&lt;p&gt;Yes, functionality and workflows around installation and updates are still insufficient for many use cases, but that could have been ironed out given enough time.&lt;p&gt;But what you messed up badly, IMO, was to force-migrate packages to Snap in an LTS release before it was ready.&lt;p&gt;Had you waited until Ubuntu 20.10, I&amp;#x27;d have been more forgiving. But you (collectively) were so eager to get this in before the window closed for another two years.&lt;p&gt;If you had made Snap a compelling product, even LTS users might have voluntarily migrated to snaps once they saw how good it was. Now you&amp;#x27;ve kind of pulled off the opposite.&lt;p&gt;Sadly the ship has sailed: Both in general, since you&amp;#x27;ve pushed so heavily for Snap in a LTS release when it simply wasn&amp;#x27;t ready yet. And for me personally, where the forced installation of Snaps by some debs (notably Chromium) broke my trust significantly enough that I turned my back on Ubuntu after over a decade.&lt;p&gt;Not only is the Chromium Snap dog slow, it also can&amp;#x27;t see my NFS shares. So the snap version is objectively worse, at least for now.&lt;p&gt;But if I install a deb, I expect to get a deb. You don&amp;#x27;t want to offer it anymore, fine, take it out of the repo. But sneakily migrating me to a snap, and not even notifying me, is just trust-breaking.</text></comment>