Join Log in
Score:9
reducing activity avatar Ubuntu

Is it true that Snap has proprietary server?

cn flag
reducing activity

Are there proprietary elements of Snap server? Is it possible to run Snap-based distribution independently of Canonical?

I am quite disliking Snap for multiple reasons (one of things that I like most on Linux is that I can install/uninstall things with apt-get, snap does not have even decency to provide direct help on snap upgrade).

But the most worrying thing that I heard is that Snap has proprietary elements, making it fully Canonical-controlled.

See for example https://www.techrepublic.com/article/why-canonical-views-the-snap-ecosystem-as-a-compelling-distribution-agnostic-solution/

Martin Wimpress, engineering manager for Snapcraft at Canonical at that time:

Snap store is proprietary

https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/

the server end (the 'app store' bit of the equation) is closed source, and Canonical have been refusing to tell anyone how to run their own 'app store' (...) it is entirely controlled by Canonical

(and also describes how Canonical was lying about Snap)

But infoboxes in https://en.wikipedia.org/wiki/Snap_(package_manager) list open source licenses.

What is going on? Have they released Snap store as open source? Or is Wikipedia article incomplete/damaged by Canonical employees?

I am quite worried, especially given that Ubuntu started making basically impossible to avoid Snap on Ubuntu. On the other hand I would prefer to have good reasons to switch Linux distribution, not just based on outdated blog posts.

1681
0 + 0
guiverc avatar
cn flag
guiverc
Some of your detail is *outdated* ([Martin Wimpress left Canonical some time ago](https://www.omgubuntu.co.uk/2021/02/martin-wimpress-ubuntu-desktop-lead-leaving-canonical) & it's been blogged how you can download snaps & later install them locally (like you can `wget` a *deb* package then `dpkg -i` install it); the download & install however is not a Store.
1
Reply
in flag
matigo
Canonical employees have said many things about snaps, but I cannot think of a single lie ...
0
Reply
reducing activity avatar
cn flag
reducing activity
@guiverc As I understand, at time of that article he was representing Canonical at that time (and could be treated as expert at that time). So, at least at that time, Canonical confirmed that it is proprietary and announced that it will stay this way.
0
Reply
reducing activity avatar
cn flag
reducing activity
@matigo https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/ See "it's a pretty big mis-representation" part and "They certainly did not in any way inform Fedora that they were going to send out a press release strongly implying that Fedora, along with every other distro in the world, was now a happy traveler on the Snappy bandwagon."+"claim that Snappy enables "a single binary package to work perfectly and securely on any Linux desktop, server, cloud or device" sounds lovely, doesn't it? Let's take a look at the truth"
0
Reply
reducing activity avatar
cn flag
reducing activity
@guiverc "you can download snaps & later install them locally" That seems covered by https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/ "If you want to distribute your snaps, your choices are 1) publish it through the Canonical store, entirely under Canonical's control, 2) upload it as a file and tell people to use the CLI to install it, or 3) try to figure out how to reconfigure the snap client to use a different server by reading the source code, then write your own server end from scratch."
0
Reply
in flag
matigo
Meh. I care not one bit about the perceived politics around the thing. Drama is for high school, and I'm *far too old* to be a part of such silliness. If you do not want to use Snaps, don't. There are plenty of alternatives, including Ubuntu-based derivatives that have stripped out the Snap bits. Use what works for you.
3
Reply
guiverc avatar
cn flag
guiverc
I won't deny the Snap Store contains closed source software (ie. how Canonical run the server backend), all *snap* software that you & I run on our machines is open-source; it's the *snaps* we download ourselves that may not (but we control those) & Snap Store infrastructure (Canonical) our open-source front-ends on our machines (open source) deal with isn't. I would trust Adam Williamson understanding, though I'd personally use Alan Pope's (ie. ex-Canonical-er) blogs about the topic as a more trusted source (ie. someone that was inside to form opinions; though may be a little *tongue-tied*)
0
Reply
reducing activity avatar
cn flag
reducing activity
@matigo "If you do not want to use Snaps, don't." - well, I am trying to figure out whether I want. If it is an attempt by Canonical to migrate from open source apt to something where crucial elements are controlled by Canonical then I will need to migrate myself. "There are plenty of alternatives, including Ubuntu-based derivatives that have stripped out the Snap bits. " - which ones? Is Debian also putting crucial parts of system into snap packages?
0
Reply
B.Tanner avatar
bw flag
B.Tanner
I have asked this as a new question.
0
Reply
Score:9
muru avatar Ubuntu
us flag
muru

The actual package management tools for Snaps - snapd and family - are open source. That's what makes the Snap package management system open source and Canonical is not lying about that.

It is true that snapd is hardcoded to use Canonical's servers for obtaining snaps and the metadata associated with them. And the source for the backend servers is not available as far as I know. Various other parts (e.g., the snapcraft.io website, the Snap store app itself, etc.) are open source. I mean, you could serve deb files from an IIS server, but that wouldn't make the apt package management system closed source, would it?

Can you make snapd work with another backend? Technically, you could read the snapd source, figure out the protocol (which shouldn't be difficult - I think the code is fairly readable), implement your own backend, and build a snapd with a patch to swap the backend URLs. However, nobody seems to have done that so far, and Canonical haven't published a reference implementation.

0 + 0
reducing activity avatar
cn flag
reducing activity
`I mean, you could serve deb files from an IIS server, but that wouldn't make the apt package management system closed source, would it?` If it would be sole existing way to serve deb files - then yes, it would.
3
Reply
muru avatar
us flag
muru
@reducingactivity not as long as there are alternate ways to get and use those deb files - which is indeed the case with snaps too, as you know.
0
Reply
reducing activity avatar
cn flag
reducing activity
So "If you want to distribute your snaps, your choices are 1) publish it through the Canonical store, entirely under Canonical's control, 2) upload it as a file and tell people to use the CLI to install it, or 3) try to figure out how to reconfigure the snap client to use a different server by reading the source code, then write your own server end from scratch." from https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/ is still up to date summary?
6
Reply
reducing activity avatar
cn flag
reducing activity
Also, in addition to "snapd is hardcoded" - proposal to make it configurable was WONTFIXed https://bugs.launchpad.net/snappy/+bug/1593151
4
Reply
muru avatar
us flag
muru
Yes, as far as I can tell that's still correct.
0
Reply
muru avatar
us flag
muru
Please read the comment there - you'll see that it's using environment variables specifically that was unwelcome.
0
Reply
reducing activity avatar
cn flag
reducing activity
environment variables were rejected, config files were not even mentioned, issue was wontfixed.
1
Reply
muru avatar
us flag
muru
"The best would probably be to add support for multiple simultaneous stores in snapd itself" ... which implies conifg files as an alternative. The issue was marked wontfix **three** years after no further activity followed - so presumably people who want this couldn't be arsed to work with Canonical to make it happen.
0
Reply
muru avatar
us flag
muru
Anyway, none of this changes my point that you **could** figure out the protocol and build your backend, and patch snapd to do use it, since snapd is, despite all the FUD, open source. But it seems nobody wants do all that, but instead people are just happy to post FUD.
0
Reply
reducing activity avatar
cn flag
reducing activity
Well, I am perfectly fine with apt, I would be likely perfectly fine with flatpack. I see no good reason to spend months of my life (or years) on fixing system that I do not want, do not need and I am not forced to use. I would - at most - change operating system to one not forcing snap on me. Though proprietary Snap Store is likely enough for me to avoid it.
0
Reply
reducing activity avatar
cn flag
reducing activity
"That's what makes the Snap package management system open source" - if critical parts (server) is proprietary, than Snap as entire package management system is NOT open source.
0
Reply
muru avatar
us flag
muru
@reducingactivity the protocol is right there, nobody's stopping you from making your own server, so it's not critical.
0
Reply
reducing activity avatar
cn flag
reducing activity
Neither noone stops me from creating open-source OS that is capable of running all .exe files running on Windows 10. This does not make Windows 10 open source.
0
Reply
muru avatar
us flag
muru
@reducingactivity but neither does that make an open source software that uses Windows APIs closed source. Or are you claiming that Ubuntu itself and everything in Ubuntu is closed source, because they can run on WSL 1 which is essentially a translation layer between Linux system calls and the Windows API?
0
Reply
Score:5
traktor avatar Ubuntu
au flag
traktor

The Snap Store is run and controlled by Canonical and is not open source. The rest of Snap is open source, meaning the daemon and core software. How threatening this is depends on you POV and has been the subject of much discussion. E.G.

  • "Snap v Flatpak v AppImage - In Depth Pros & Cons of Universal Packaging" on youtube.com ,
  • Linux Mint forums, e.g. this thread
  • Noting that Linux Mint (based on Ubuntu) bans installations of snaps by default (with a hint of how to enable their installation).

As a Linux newbie myself, I've just finished researching snap issues after finding the (LM) program manager doesn't list any snap packages. What I found was that adopting a firm line approach may sever dependency on the Snap Store but replaces it with another problem - in my case missing or receiving out of date packages installed using the Linux Mint package manager:

  • The (LM) PM installed a 10.x version of node instead of the current 16.3.1 LTS version,
  • The nodepad-plus-plus working snap package for Notepad++ (natively available under Windows) was simply not listed. A linux version (notepadqq) can be installed - and I did - but is not a substitute for using the original.

This is where pragmatism and life expectancy comes into play: personally I enabled snaps to install notepad-plus-plus, with which I have decades of experience and consider a "must-have", but would search extensively before installing snaps simply because I can. FWIW I'm not sure if installing node from binaries by running the archive manager GUI as root was a good idea but it got the job done.

;TLDR

Yes the Snap store is controlled by Canonical. Whether that is sufficient reason to compel a move away from Ubuntu is a matter of personal opinion and beliefs, and heavily depends on how and why you select and use snap packages in general.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.