5 ms·

A very important aspect of snap that should have been noted in the article is the lack of user control over the a snap's updating process; Users are not allowed

A very important aspect of snap that should have been noted in the article is the lack of user control over the a snap's updating process; Users are not allowed to control when updates are applied, leading to a windows 10-like user experience: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707 https://forum.snapcraft.io/t/disabling-automatic-refresh-for... From what I could understand, placing the update process under the control of snap app developers - rather that device owners - is deliberate design decision.

techntoke 8y ago
A poor one at that. I don't understand why they couldn't make the Deb packages portable to a containerized format, where all the work has already been done. They'd be much better off automating the package build process instead of creating a new format for package maintainers that doesn't align with Debian. At least Arch and Alpine has a simple and human readable PKGBUILD format that only takes 15 minutes to understand and update your own packages. They have up-to-date packages for pretty much everything, even though Debian and Ubuntu have been around longer. I'm all for containerizing a Linux distro, and think it is a great idea, but Canonical hasn't exactly proven to be the best at this. Right before Ian Murdock passed while working at Docker, he didn't have many positive things to say about Canonical and their leadership. Most reviews on Glassdoor also talk about the poor leadership there. Therefore I see no reason to use Snap at this time.
SmellyGeekBoy 8y ago
Indeed, Spotify (distributed via Snap on Ubuntu at least) doesn't scale properly on HiDPI screens for example, requiring a small tweak to the shortcut[1]. I know when Spotify has updated because I'll launch it and everything will be tiny again! [1]https://community.spotify.com/t5/Desktop-Linux/Linux-client-barely-usable-on-HiDPI-displays/td-p/1067272 https://community.spotify.com/t5/Desktop-Linux/Linux-client-...
niemeyer 8y ago
There's a long thread with in depth discussion about this: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/201 https://forum.snapcraft.io/t/disabling-automatic-refresh-for... For those that understandably won't want to go through it all, the short version is that by design snaps will force the update eventually, so that a system isn't simply left behind, but since snapd came out a few years ago we've been constantly working on multiple methods to offer control over when exactly the update takes place. These are features such as: - Fine scheduling of updates (https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239/10 https://forum.snapcraft.io/t/refresh-scheduling-on-specific-...) - Disabling over metered connections (https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/8 https://forum.snapcraft.io/t/snap-refresh-over-metered-conne...) - Holding of refreshes after boot (https://forum.snapcraft.io/t/delaying-refreshes-and-registration-in-particular-for-pre-seeded-classic-images/4106/3 https://forum.snapcraft.io/t/delaying-refreshes-and-registra...) - Manual delaying of updates (can't find topic) So, the goal is actually to offer control, but we are indeed trying to prevent systems from getting out of date for good. Maybe that's a bad idea, and if it turns out to be we can change that in the future, but we've been making an honest effort to try to fix the problems of automatic updates instead of simply giving up. Once we give up, there's no going back since the dynamics around package updates will change. We have plenty of experience around these aspects with the traditional systems.
- Longhanks 8y ago
  Sorry, but unless there's an option to hold back the update until I explicitly allow it, that's not being in control. This is still my computer and I decide when to update software.
  - vetinari 8y ago
    This is this being downvoted? He is exactly right. The ability to pin at specific version is needed not just because, but for multitude of reason: the newer version breaks something, or you have only license for up to certain version (think non-subscription Jetbrains products), etc. The inability to disable updates removes that packaging system from further consideration. It is a showstopper.
    - seenitall 8y ago
      The comment is mistaken. I suspect it’s being downvoted not because update control isn’t appreciated, but because it’s very much there with snaps. There are several ways to disable snap updates, and they are really quite nicely balanced for modern operations. For example, if you publish a snap that depends on another snap, say an app which uses a database, you can set things up so the database won’t update until you publish a validation certificate that your app snap version X has been validated with database snap version Y. Updates can be deferred by anybody, and I think there is a plan for snaps themselves to be able to defer their own updates (for example, a movie payer that is playing a movie at the scheduled update time). Enterprise management systems can also control the flow of updates very nicely. For example, they can have a different snap revision as ‘stable’ or ‘beta’, which means they decide when a new revision of a snap will be considered for update by all the machines tracking those channels. They can also prevent any updates from happening on specific machines. Device manufacturers also get a layer of control, similar to snap publishers with their dependencies. So an appliance that uses snaps might see specific revisions of snaps only once those have been certified on that device. Considering how rich the actual reality of ‘software update distribution and managment’ is in practice, it’s nice to see that level of thinking built in to the system. We’ve had simplistic approaches around for decades and the results in practice are too or, there are millions of vulnerable machines out there because of neglect. I’m interested to see if these mechanisms achieve a better result all round, and the simple thing you are focused on is certainly already there.

techntoke 8y ago

A poor one at that. I don't understand why they couldn't make the Deb packages portable to a containerized format, where all the work has already been done. They'd be much better off automating the package build process instead of creating a new format for package maintainers that doesn't align with Debian. At least Arch and Alpine has a simple and human readable PKGBUILD format that only takes 15 minutes to understand and update your own packages. They have up-to-date packages for pretty much everything, even though Debian and Ubuntu have been around longer. I'm all for containerizing a Linux distro, and think it is a great idea, but Canonical hasn't exactly proven to be the best at this. Right before Ian Murdock passed while working at Docker, he didn't have many positive things to say about Canonical and their leadership. Most reviews on Glassdoor also talk about the poor leadership there. Therefore I see no reason to use Snap at this time.

SmellyGeekBoy 8y ago

Indeed, Spotify (distributed via Snap on Ubuntu at least) doesn't scale properly on HiDPI screens for example, requiring a small tweak to the shortcut[1]. I know when Spotify has updated because I'll launch it and everything will be tiny again! [1]https://community.spotify.com/t5/Desktop-Linux/Linux-client-barely-usable-on-HiDPI-displays/td-p/1067272 https://community.spotify.com/t5/Desktop-Linux/Linux-client-...

niemeyer 8y ago

There's a long thread with in depth discussion about this: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/201 https://forum.snapcraft.io/t/disabling-automatic-refresh-for... For those that understandably won't want to go through it all, the short version is that by design snaps will force the update eventually, so that a system isn't simply left behind, but since snapd came out a few years ago we've been constantly working on multiple methods to offer control over when exactly the update takes place. These are features such as: - Fine scheduling of updates (https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239/10 https://forum.snapcraft.io/t/refresh-scheduling-on-specific-...) - Disabling over metered connections (https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/8 https://forum.snapcraft.io/t/snap-refresh-over-metered-conne...) - Holding of refreshes after boot (https://forum.snapcraft.io/t/delaying-refreshes-and-registration-in-particular-for-pre-seeded-classic-images/4106/3 https://forum.snapcraft.io/t/delaying-refreshes-and-registra...) - Manual delaying of updates (can't find topic) So, the goal is actually to offer control, but we are indeed trying to prevent systems from getting out of date for good. Maybe that's a bad idea, and if it turns out to be we can change that in the future, but we've been making an honest effort to try to fix the problems of automatic updates instead of simply giving up. Once we give up, there's no going back since the dynamics around package updates will change. We have plenty of experience around these aspects with the traditional systems.

Longhanks 8y ago
Sorry, but unless there's an option to hold back the update until I explicitly allow it, that's not being in control. This is still my computer and I decide when to update software.
- vetinari 8y ago
  This is this being downvoted? He is exactly right. The ability to pin at specific version is needed not just because, but for multitude of reason: the newer version breaks something, or you have only license for up to certain version (think non-subscription Jetbrains products), etc. The inability to disable updates removes that packaging system from further consideration. It is a showstopper.
  - seenitall 8y ago
    The comment is mistaken. I suspect it’s being downvoted not because update control isn’t appreciated, but because it’s very much there with snaps. There are several ways to disable snap updates, and they are really quite nicely balanced for modern operations. For example, if you publish a snap that depends on another snap, say an app which uses a database, you can set things up so the database won’t update until you publish a validation certificate that your app snap version X has been validated with database snap version Y. Updates can be deferred by anybody, and I think there is a plan for snaps themselves to be able to defer their own updates (for example, a movie payer that is playing a movie at the scheduled update time). Enterprise management systems can also control the flow of updates very nicely. For example, they can have a different snap revision as ‘stable’ or ‘beta’, which means they decide when a new revision of a snap will be considered for update by all the machines tracking those channels. They can also prevent any updates from happening on specific machines. Device manufacturers also get a layer of control, similar to snap publishers with their dependencies. So an appliance that uses snaps might see specific revisions of snaps only once those have been certified on that device. Considering how rich the actual reality of ‘software update distribution and managment’ is in practice, it’s nice to see that level of thinking built in to the system. We’ve had simplistic approaches around for decades and the results in practice are too or, there are millions of vulnerable machines out there because of neglect. I’m interested to see if these mechanisms achieve a better result all round, and the simple thing you are focused on is certainly already there.