> There's no substitute for your package maintainer personally auditing and preparing the package for you.

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!)

> 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

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.

You can update as often as you like, but that does not ensure users will get that update, nor does traditional packaging make it safe to install the update (no rollbacks, maintainer scripts run as root and have full access to the filesystem, library mismatches, etc).

I'm all for debs and rpms, but they seem best suited to providing the base system.

[disclaimer: I'm on the Snapcraft team]

> Snaps and flatpaks are just a vector for malware.

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.

>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.

Yeah, because that's totally how software distribution should work. What's so wrong with the vendor just compiling and distributing an application? Why must this be needlessly complicated?

Yes, that is totally how software distribution should work. Vendors cannot be trusted, this has been proven over and over and over again. Having a dispassionate third party do the packaging keeps malware out of your computer. This is why we have browser extensions and android apps that spy on you. This is why we have a snap which was mining cryptocurrency on your computer a few weeks ago. This is why Mozilla can add spyware to Firefox. Vendor publishing is fundamentally broken.

> This is why Mozilla can add spyware to Firefox.

Mozilla has some interesting technical solutions to this problem: https://wiki.mozilla.org/Security/Binary_Transparency

Mozilla is the one adding the spyware, though.

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.

And upstream issues such as this one should be fixed in upstream not patched endlessly with every other distro. That's the approach promoted by Arch Linux.

My point is that upstream can't always be trusted. With snaps there's no one between you and a potentially bad actor.

If you don't trust upstream why are you running their code?

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.

Well, you're free to believe that a platform that places you at the mercy of third party comrades who dictate what you can and cannot install or distribute "for your own good" is a good idea.

I disagree. Wholeheartedly.

We're not talking about some shady organization in some ivory tower. Package maintainers are people whose names and email addresses are available to you. Distros are also always looking for volunteers, you can volunteer and steer things the way you want. And if not, then there are dozens of other distros to choose from whose maintainers may agree with you more.

Yes, and look at how well all that fragmentation works.

We're clearly of very different opinions about what personal computing is all about.

Without the "fragmentation" the problem of third parties censoring applications would be even worse and it still wouldn't be any easier to deploy anything. If you want a proprietary centralized service loaded with malware, there are already plenty of those to choose from on other systems, complete with their own gatekeepers.

Neither MacOS nor Windows prevent you from installing any application you desire[0], direct from the vendor. That has only recently begun to change thanks to app stores, which bear a remarkable similarity to package repos.

[0]Ok, there are some hoops regarding unsigned drivers.

I passionately disagree. Package managers are inflexible conflict causing garbage and repos are appstore-like walled gardens which often contain out of date software, when they have what you're looking for at all.

Snap and Flatpak aren't much better, though. Give me AppImage any day.

The repository system on Debian, Arch, Fedora is clearly not a walled garden like Apple or Microsoft's app stores. Any site can host a repository that you can add to your package manager's sources, and you're free to install .deb/.rpm packages from any source you want, not to mention tarballs or compiling from source code. Also, there's no motive for lock-in like mainstream app stores have.

Only if those sources keep things up to date with the changes in the main repository, and every other repository the user uses, so as to avoid conflicts.

> not to mention tarballs or compiling from source code

Seriously? You may as well say iOS is open because you can root it.

The reason for the conflicts are rarely if ever at the package layer, and more often than not with upstream changing dependencies on a .x update.

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.

Or because it's a new feature release instead of just bugfixes. At least in e.g. Ubuntu, SRUs aren't accepted unless they're security or bug fixes, which makes it impossible to get newer features back to stable releases. Snaps provide a way out of this by removing the ability to break other applications with an update (since there are no dependencies).

noone is going to prep packages for dozens distros with different distribution mechanism. too complicated|time consuming - why Linux doesn't have first world apps.

No one is expecting you to, nor do I trust you to. Distro maintainers do this, not software developers.

How do I get my favorite app included as a user? As a publisher? The maintainer has his own schedule. What if I have a closed-source app? I presume it's just better than PPA and *.deb-s (which would be acceptable if all desktop Linux was based on Ubuntu).

There is AppImage (https://appimage.org/). I have no affiliation with it whatsoever, but if you're not going to have a verified Snap account, I think you're better off offering an AppImage from your website. And it seems like some companies are thinking about something like this (https://github.com/itchio/itch/issues/683).

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.

Verified accounts are pretty new, I suspect we'll see Slack verified soon.

You ask. Find a maintainer who works on similar or related software and send them an email. Send them a patch.

Your closed source app can shove it.

… and then wait 13 years with no response. (-:

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334120

* https://unix.stackexchange.com/a/459566/5132

You have to be proactive. Contact the maintainers directly, reach out to other maintainers, etc.

Debian Developer Stephen Kitt said the opposite, as you can see.

yeah. that's wishy-washy dreamworld. For 20 years Ive been using Linux - noone bothered packaging A-level apps for Linux, definitely not closed source ones. That's been enough of a trial run I would say.

So your argument is that anyone who wants to use any proprietary software should just switch to Windows?

I suppose I should stop using Linux then, because I occasionally play games from Steam.

And your games are spying on you. Many of these games employ invasive anti-cheat systems which shake down your computer and send a bunch of data to their servers. This shit doesn't fly with distro packages.

Yeah, they definitely wouldn't be in distro packages, but I want to play them nonetheless. That means I either have to run software which isn't in my distro repo, or switch to Windows.

Just don't ask about using WINE. (-:

* https://unix.stackexchange.com/questions/460036/

You wish! Which distro are you talking about? Can't be Ubuntu for sure...

Ubuntu is an outlier, not a representative of all of Linux. Linux is open source, you can make a distro that does anything you want, including spying on others. This doesn't make the distros that don't any worse.

This attitude is the reason Linux Desktops suck and will continue to suck.

Actually they don't. I use Linux Mint Cinnamon for 5 years and find it a very convenient operating system, better than Windows (at least 7 — I hear nothing good about Win7 except its Linux support) and OSX (at least Snow Leopard) in almost every respect, except commercial app support. I very reluctantly reboot into Windows for things like Office, Lightroom and CorelDraw. Maybe Visual Studio.

edit: btw, I agree with you on the "attitude" thing. There should be more commercial options on Linux desktop.

It was a subjective assessment to be sure, but one shared by many. You can tell because of how few users it has, though I'm sure someone will pop up and blame the fact that it doesn't come pre-installed on PCs as the reason, without consideration for the concept that if people actually wanted to use it, it might.

eh, i disagree. even if linux distros were objectively better than windows in every possible way (not speaking to the truth of that claim) if computers shipped with windows the vast majority of people would use windows.

The vast majority of Windows PCs do not ship with Chrome.

But the vast majority of internet users do use Google search and other Google products like Gmail. That's how Chrome became popular — because Google will spam you with ads for Chrome at every available opportunity.

And how did Google get popular despite Microsoft owning the OS? And for that matter, IE? My point is, people tend to use software they like. The reason Linux Desktop, despite decades of evangelism, hasn't taken off is that people don't like it. It's that simple, but the evangelists keep deluding themselves because making it better will require them to do hard things, like work together.

Wait, some of us are trying to change that.

affiliation: tech lead for the snapcraft tool and linux user since 1999.

To my knowledge, there have been at least 4 other attempts to have sane application distribution on Linux over the years:

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 Nix and Guix.

Those are just package managers trying to be less crap than currently existing package managers. Vendors still aren't expected to create and deploy the application directly to the user.

Also, in that category, you forgot Gobo.

You‘re really complaining about how the Snap Store works. Simple fix: Only maintainers can promote snaps to 'stable'.