| I agree with the rationale that software should be kept up to date. However, if this was their only concern, they would make it easy for updates to be applied automatically, and then would make this the default. But the rationale for completely removing your ability to opt-out of an update is different. Snapd is not actually providing a service to users, at least not in earnest. They're providing a service to software publishers. They're making it possible for publishers to ship software that isn't stable. This is a useful service for publishers, because stabilizing, releasing, and maintaining software is hard work, and requires resources that might otherwise be used implementing new features or writing new software. The life of a software publisher would indeed be easier if everyone was on the latest version as quickly as possible, and if multiple versions with conflicting feature sets were never allowed to exist at the same time. In order to convince software publishers that snapd is capable of providing this service, snapd needs to convince users that running unstable software from these publishers is a reasonable approach. But for many server operators, it isn't reasonable. I'm not here to talk about possible workarounds, or to argue about whether a delay is an adequate workaround, or about whether the delay interval is long enough. That would miss the point. I'm here to assert that snapd's philosophy is wrong, that it's design is broken, and that this makes snapd unfit for purpose. Here are three scenarios: 1. A security vulnerability is found in some stable piece of software. A minimal fix that mitigates only this vulnerability (without changing other behavior) is written and backported to the stable release. In this case, it makes sense to apply the targeted patch as quickly as possible. It's time sensitive, and the risk of unintended fallout is minimal. You can do this automatically with debian-security and unattended-upgrades. Even in industries with complex software compliance processes, there's usually a fast-track exception for targeted fixes to critical security vulnerabilities. 2. A feature was improved, added, or removed. It might improve your server's performance. It might improve performance for a different system that needs to talk to your server. It might reduce the load on the software publisher's server. It might change or remove behavior that you rely on, causing your system to break in obvious or not-so-obvious ways. It might introduce a new feature that you've been desperately waiting for. Everybody wants these updates to happen. But it takes time and resources to figure out what's changed, to figure out whether the change breaks your system, and then to implement and deploy a fix for your system that allows you to upgrade. 3. Adobe or Autodesk want to silently "upgrade" your perpetually licensed software to their new monthly SaaS version. lol, fuck that, and fuck them. ---- The problem with this approach (for software publishers) is that writing and backporting targeted fixes is hard, boring, thankless work. Similarly, it can be difficult and expensive for a publisher to have to deal with multiple versions of their software existing at the same time. They might interact in conflicting ways, they might require lots of ugly, bug-prone version-checking in client software so that different feature sets can be handled correctly. The publisher may desperately want to turn off a legacy feature on their servers, but can't until the last stable releases that rely on it are properly deprecated. But this is how stable software works. If you don't want to deal with these things, and want to insist that everyone needs to be on the latest version as quickly as possible, then your software isn't stable, and has no business running on a server. |