Disabling automatic refresh for snap from store

[Ads20000]

@jzimm

I thought however that Epochs were already implemented in snap (even if nobody is using them)?

According to both the topic and the roadmap it’s still ‘upcoming’.

Yes, the snappy devs seem to accept that there is a small probability that potential breakage occurs, they seem to be holding back implementing an off switch to provide motivation for developers to implement proper testing procedures so that there is as little breakage as possible and so that no-one ever needs to use the off switch (if/when it eventually is implemented).

@niemeyer

For more than a decade we’ve been responsible for a system that depends on people updating their software manually. We have a reasonable understanding of many of the involved issues, including the fact that once such a switch exists, the dynamic of the whole ecosystem changes, and it’s hard or impossible to go back to automated updates.

So, they want to solve the problem where users don’t upgrade their software because it’s hassle and they end up getting hit by security vulnerabilities. I suppose the snappy developers are betting that users are going to underestimate the risk of security vulnerabilities damaging them and underestimate the benefits of updates and so they override the users’ desires on this.

@jzimm

The user should be able to make sure that the software won’t change unpredictably under his/her feet and there should be an option to install updates at the user’s discretion only.

You need more, preferably actual, use cases to prove to the snappy developers that this is necessary. At the moment they think that their mitigations cover most use cases and that they can grow features to accomodate others and that users should switch to alternative solutions (presumably Flatpak, AppImage, or traditional packaging) if snappy can’t grow the features to satisfy their use-case.

@jzimm

After all being able to implicitly trust that your computer obeys you and only you is a huge part of what FOSS is about, or is it not?

‘a huge part of what FOSS is about’ kind of, but for software to be free it merely needs to satisfy the four freedoms:

The freedom to run the program as you wish, for any purpose (freedom 0).
The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help others (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

You could argue that not having an off switch for updates violates freedom 0, to run the program as you wish, for any purpose, but one can’t say that software not having all the options that you could possible wish for means that it violates freedom 0, so it’s a bit of a tenuous argument. Since the code is open, in any case, in principle you can go into the code and create the feature you want, which is not always possible with closed-source software.

I suspect snappy devs are more interested in the definition of open-source software than free software, however. The OSS definition does not include freedom 0, it seems.

Also, obviously, the store code is closed, which Niemeyer has addressed here.