This is true, but it's not a feasible approach for software like Slack, Spotify, and VSCode that gets updated /weekly/. These aren't packages like 'libgit' that you could validate once and leave the same until you ship the next OS release. Some of these apps completely stop working if you fall behind by too many versions. Having people running older versions is also a huge pain in the ass as a developer, because those users inevitably email support, complain online about how the product is bad, etc. and only after lots of emailing does it turn out they're using a year-old version. (Full disclosure: I maintain Mailspring and switched to Snapcraft /very/ enthusiastically to have an auto-update mechanism that works across linux distros!)
Package managers don't prevent this at all. If you host the repository then you can update as often as you'd like. Some whole distros (arch) do just this.
I'm all for debs and rpms, but they seem best suited to providing the base system.
[disclaimer: I'm on the Snapcraft team]
That depends entirely on your perspective. If you're happy using packages entirely from your distribution and from no other sources, then sure, carry on as you are.
Snaps (not sure about flatpaks and confinement) are far better than the "curl ...|bash", PPA and other installer type vectors, even from your perspective.
A bad thing compared to other bad things does not make the bad thing good. If you're missing a package on your distro, bug a package maintainer to build it, or step up and volunteer.
Mozilla has some interesting technical solutions to this problem: https://wiki.mozilla.org/Security/Binary_Transparency
https://blog.mozilla.org/press-uk/2017/10/06/testing-cliqz-i...
>Users who receive a version of Firefox with Cliqz will have their browsing activity sent to Cliqz servers, including the URLs of pages they visit.
I don't think it's reasonable for such a small group of people as Debian developers (or any other maintainers) to review each change looking for potentially malicious code. Especially in codebases as big as Firefox.
I disagree. Wholeheartedly.
We're clearly of very different opinions about what personal computing is all about.
[0]Ok, there are some hoops regarding unsigned drivers.
Snap and Flatpak aren't much better, though. Give me AppImage any day.
> not to mention tarballs or compiling from source code
Seriously? You may as well say iOS is open because you can root it.
This leaves the distro maintainers two choices: either recompile/restructure the whole distro to placate one upstream, or freeze said upsteam on an older version and suffer their social media wrath.
If your Snap account is unverified, there seems to be no way to know who created the snap. It looks like I can create an account with the name of any company and distribute stuff in their name, including malware.
With something like AppImage, your users know that the AppImage is actually coming from you if you host the file on your domain. Then again, AppImage has its own drawbacks. But at least, if Slack put an official AppImage on its homepage, I'd be able to download it. Installing a Slack snap from the account of "Felix Rieseberg" doesn't sound to good to me (https://snapcraft.io/slack). If you dig around, you can see that Felix Rieseberg does work at Slack, but for this big a company, that just looks fishy IMO.
Your closed source app can shove it.
I suppose I should stop using Linux then, because I occasionally play games from Steam.
edit: btw, I agree with you on the "attitude" thing. There should be more commercial options on Linux desktop.
affiliation: tech lead for the snapcraft tool and linux user since 1999.
Application Bundles (GNUStep), AppDirs (ROX), Flatpak (formerly xdg-app), and AppImage (formerly Klik).
But Canonical invented a fifth anyway. Forgive me if I'm skeptical that change will actually occur this time.
Also, in that category, you forgot Gobo.