Snap Updates Happen Without User Consent
Aside from this notification apparently not being tied properly into the KDE notification system (it doesn’t show in the list of recent notifications that’s available from the system tray notifications widget, and so therefore seems to be using a different notification system), this highlights a particularly annoying (and anti-user) line of thinking by the Snap development team.
A little background, before going into detail on the issue here (skip down to the next image if you’re up to speed on Linux packaging). As is standard operating procedure in the Linux ecosystem, competing systems are vying to become a standard to solve a particular problem, and as usual we’ll end up with segmented user bases, inefficient use of sparse developer resources, and multiple ways to achieve the same thing. Human nature, ftw. The problem that’s being addressed in this case is that of software distribution.
The status quo for obtaining software for Linux distributions until fairly recently was the idea of repositories, i.e. managed collections of software, and tooling baked into the distributions to allow installing and updating software from these repositories. (Linux repositories preceded the popularity of “app stores”, but it’s basically the same idea.) Part of the differentiation between competing Linux distributions is how (and how often) they curate their repositories. While some distributions opt to be “bleeding edge”, and allow highly streamlined updates from developers to make it through to end users with a minimal amount of testing, many other (and most mainstream) distributions opt for periodical release cycles, whereby critical security updates (and some important bugfixes) can be made and pushed out quickly, but generally most other significant updates will be held until the next big release of the distribution.
This was both good and bad for users. If your system was in a fairly stable state, you could expect that applying updates when prompted to do so would leave your system in at least as stable a state as it was prior to the update, at least until the next distribution wide release (and then, your mileage might vary depending on hardware, drivers, amount of upstream testing, your own customizations, etc). “Long term support” releases were introduced, and if you opted into these, you’d be protected from distribution releases for years at a time, giving you stability at the expense of recency. Unfortunately, this meant if that if you needed an important feature update from an application, you’d either have to “sideload” it, or you’d need to wait for the distribution to include that update in the next release.