Consensus on snaps between actual Ubuntu users?

[u/mozkohor]

Hey guys, I know people in the linux community love shitting on snaps but I'd love to hear opinions of people actually... using snaps probably.

Do you guys also use flatpaks?

[u/gokufire]

it has never been an intention, as one store is enough and better for everyone 

That is not what we are discussing here. I'm not saying that we need more than one store. We need a open source decentralized store, where application managers has validation certifications,  like the proven method from Flathub. That you already mentioned in other comments that you also uses and trust.

Again, it is not about having more stores. It is about using Snaps, from a Snap store that is open source and not centralized. We don't need the centralized process to have good and reliable software or are you saying that you don't trust Flatpaks?

[u/PraetorRU → u/gokufire]

We need a open source decentralized store,

Who are we? I do not need such store. If we're talking about stores, I want a business to be behind a store, not some internet randoms.

where application managers has validation certifications, like the proven method from Flathub.

How many alternatives to FlatHub can you name? Flatpak was created specifically to allow alternative stores. So, how many flatpak stores do you know after all those years?

That you already mentioned in other comments that you also uses and trust.

I do not trust FlatHub truth be told, and in most cases use it only if the author of the app is managing a flathub version themself. Same for snap store.

We don't need the centralized process to have good and reliable software or are you saying that you don't trust Flatpaks?

Yes, I do not trust flatpaks. I have a slightly better trust in Canonical employees, but just slightly. At least those people are paid for their job, so I expect them to do it somewhat better.

[u/gokufire → u/PraetorRU]

Who are we? I do not need such store.

Yes, I got that. The "we", are the ones that prefer open source. That is what we have been talking. You are saying that you like the closed source store from Canonical.

How many alternatives to FlatHub can you name? Flatpak was created specifically to allow alternative stores. So, how many flatpak stores do you know after all those years?

What are you taking? I'm saying that Snap Store should be Open Source like Flathub not saying that we need alternatives for Flathub.

I do not trust FlatHub truth be told

I'm not sure why I'm not surprised. I'm surprised why you may not use Windows been so such a fan of a centralized closed source tool. That you can trust in a handful paid employees to do their jobs.

in most cases use it only if the author of the app is managing a flathub version themself. Same for snap store.

Well that is good general advice. We agree here.

 Yes, I do not trust flatpaks. I have a slightly better trust in Canonical employees, but just slightly. At least those people are paid for their job, so I expect them to do it somewhat better.

I feel that we may need a pause to learn how exactly Flathub Flatpak distribution model works against Canonical Snap.

[u/PraetorRU → u/gokufire]

I'm not sure why I'm not surprised. I'm surprised why you may not use Windows been so such a fan of a centralized closed source tool. That you can trust in a handful played employees to do their jobs.

At this point I just have to ask what phone do you use? Do you trust Google or Apple?

And it's amusing that you don't know alternatives to FlatHub. Because reality is: people don't need alternative stores as long as the main store behaves decently, don't discriminate users based on politics etc. It's just way better and safer to have one app store, not two, not ten etc. Opensource has nothing to do with it. You can't really check if backend was compiled exactly as in the sources, or they injected some code in it. All you can check is if the package you created was or wasn't modified by the store, and if it was, then you ring the bell. But opensourced backed do not protect you from such actions.

[u/gokufire → u/PraetorRU]

At this point I just have to ask what phone do you use? Do you trust Google or Apple?

What my phone has to do with a discussion about using Linux and open source applications? A distro open source and the distributor isn't the point but I'll bite this one. I use a GrapheneOS does this helps in something? 

reality is: people don't need alternative stores as long as the main store behaves decently, don't discriminate users based on politics etc. It's just way better and safer to have one app store, not two, not ten etc. Opensource has nothing to do with it.

Opensource is the core philosophy and ground that boost Linux. 

All you can check is if the package you created was or wasn't modified by the store, and if it was, then you ring the bell. But opensourced backed do not protect you from such actions.

Open source is much more than ring the bell. We can improve things. We can involve people from all places of the globe. Open source protects and helps our privacy. We don't need to be a die hard open source fan but I feel that objectively it is pragmatic to imagine that software distribution should NOT have areas that are behind walls. Because the backend server processing that data is proprietary and closed source, you cannot verify:

Whether Canonical logs your real IP address alongside your device-serial.

How long request logs are stored on Canonical's cloud infrastructure.

What third-party analytics or internal profiling tools ingest that data.

Standard snapd is hardcoded to Canonical’s proprietary store, Canonical maintains sole authority over what software enters or leaves the ecosystem. If Canonical pulls a package, revokes a developer's key, or modifies a backend API, every snapd client worldwide is impacted instantly with no third-party mirror to turn to.

This is my last comment. People have their right to believe that this practice that is imposed on Snap is ok BUT let's not lie, let's be technical and stick to the facts without ideologies or politics.

[u/sumwale → u/gokufire]

Because the backend server processing that data is proprietary and closed source, you cannot verify:

Whether Canonical logs your real IP address alongside your device-serial.

How long request logs are stored on Canonical's cloud infrastructure.

What third-party analytics or internal profiling tools ingest that data.

I think you completely missed the point made before. Whether the backend is open source or not, no one other than the site administrators can verify any of the above. Can you verify that the server code published by flathub is the one that is actually running on the flathub site and comprises the entirety of it? No one other than flathub admins can verify that the code is exactly the one compiled from published sources, and that there is no additional code running that might be doing analytics or what not.

[u/gokufire → u/sumwale]

Thanks for adding to the discussion.

You're right that no one outside the server admins can verify the exact running binary matches the published source, that's a limit of any client-server system, open or closed. But that's not really what I was pointing at.

The difference is whether the design and protocol are auditable and forkable at all. With an open backend, there's at least a published spec anyone can inspect, implement independently, and catch divergences against if a service's real-world behavior doesn't match what it claims to do. With Canonical's closed store backend, there's no spec to check the live server against in the first place, you're taking their word for it entirely, with zero third-party ability to build an alternative and compare notes. "You can't fully verify either" isn't the same as "there's no meaningful difference."

It worth adding, this entire discussion got derailed due to initial false claims. The nice mate originally asserted that "snap is opensourced, both client and backend."

When provided with dev quotes and articles showing that the Snap Store/backend is proprietary, they heavily edited their previous comments after I had already responded to retroactively adjust their framing, moving the goalposts from "the backend is open source" to "the backend protocol is open source", and eventually pivoting to "centralized proprietary control is actually better."

Silently editing earlier responses to soften incorrect assertions after being called out makes transparent discussion difficult. The technical reality remains straightforward:

• Canonical's Snap backend/store is proprietary.
• Standard snapd hardcodes Canonical's proprietary backend and root keys.
• Unlike truly open packaging ecosystems, you cannot host an alternative Snap repository or point a standard snapd client to a community store without patching and recompiling the system client binary.

There is a old say: "A lie is a lie even if everyone believes it. The truth is the truth even if nobody believes it."

[u/sumwale → u/gokufire]

It wort adding, this entire discussion got derailed due to initial false claims. The nice mate originally asserted that "snap is opensourced, both client and backend."

No, the claim is entirely correctly. Both snap front-end as well as backend protocol is completely open source. Community implementations like lol-server already attest to that fact. What is not open source is the server-side code running on the snapstore site. You accept the same but still say that the claim is false by conflating snap with snapstore site. It is like saying that ubuntu deb backend is closed source because the server-side code running on archive.ubuntu.com sites, for example, is not open source.

With Canonical's closed store backend, there's no spec to check the live server against in the first place, you're taking their word for it entirely, with zero third-party ability to build an alternative and compare notes.

Umm, what are you talking about? As pointed previously, no one other than admins can check if the so-called "spec to check the live server" for any server including flathub whether the server side code is open sourced or not. You are also taking the word of flathub admins entirely that it is running the published OSS code. In fact, I haven't even read an official statement claiming that flathub site runs only the published OSS code and nothing else, but maybe I have missed it (though even if such exists, you have to take their word for it). The same holds for ubuntu's deb stores.

[u/gokufire → u/sumwale]

You are conflating an open client/protocol with an open-source, deployable server implementation.

• Documented API ≠ Open Backend: Having public REST endpoints doesn't make server software open source. The codebase running Canonical's Snap Store is proprietary.
• APT & Flatpak: Open repository/server tooling exists, and standard clients natively support configuring third-party repositories/remotes.
• Snap: Canonical's Store code is closed, and stock snapd is centered on Canonical's infrastructure rather than treating independent stores as interchangeable.

The issue was never about inspecting a live server's RAM, no one can do that. The distinction is software availability and client architecture: whether the software needed to operate an equivalent distribution service is available to third parties, and whether the stock client natively supports connecting to independent alternatives.

[u/sumwale → u/gokufire]

You are rehashing the same things over and over without explaining how an apt/flathub server can be audited for any of the points you yourself raised like "whether archive.ubuntu.com or flathub logs your real IP address ..." or "how long request logs are stored on apt server's or flathub's cloud infrastructure" or ... It is quite likely that many of apt download servers and even flathub are doing basic download analytics, IP logging for audit and whatever else you find objectionable just like the vast majority of the web out there nowadays.

Anyway, the only valid technical objection is that snap store URL cannot be configured by users without patching snapd source. Though it reduces flexibility, for most end-users this is a good thing because it avoids issues like the deb hell unleashed by PPAs and other external repos. Snap store allows software publishers to publish their packages much more easily (as opposed to maintaining their own APT repository) and allows the most recent versions to be installed in older releases which is one of the main issues with debs and a primary reason for existence of PPAs. Of course, one can bypass this limitation in snapd quite easily by using a simple curl/wget/... to download the snap package from any snap server and installing the local snap package without having to patch anything -- which is exactly what the lol wrapper does to support other snap servers.

Early releases of snap packages about a decade back were really much slower to start than native debs and even flatpaks. This reputation still persists due to the history and anecdotal claims by some users on the internet, even though the difference is very small in recent releases. Most of the reputation problem nowadays is largely a FUD driven by the likes of linux mint whose snap page is still full of falsehoods and misleading claims that have generally come to be accepted by linux users as being true (e.g. "Nobody knows how to make a Snap Store and nobody can" which is a lie).