External repositories

snapd
164

What happens when the Left is angry because there is an NRA TV snap on the Store? What does one do in that situation?

I’ll make a Contra Points youtube viewing snap. Really, I think a lot of problem content could be addressed on a case-by-case basis, whether that’s hatespeech or malware, so there isn’t really the need to get wound up about what may or may not happen. If the platform becomes so popular that there’s a firehose of awful stuff getting published, there would at least be an appropriate context to discuss further measures about how to exclude what kinds of things in a more regular and automatic way. For now, the community guidelines and common sense are enough.

165

If there were two things that I wish Snap would do, it isn’t adding new features or fixing bugs. If I was a leader (which I am not and not trying to be, just theorizing), I think these would go a very, very long way:

  1. Unlock Snap, make it easy to add external repos, open-source a Snap Store implementation.
  2. Make Snap a Foundation, like GNOME or KDE. Have a board of directors, including members from, say, Elementary, Arch, Solus, Debian, etc. Canonical would be a major sponsor, but still just be a member on the board. Eliminate every implication of favoring Ubuntu.

I know that Canonical has funded a lot into producing Snap, so maybe Canonical could just make a list of how much money they spent developing Snap, and take a cut of purchased Snaps until that sum is repaid. (Maybe?)

An excellent way of preventing cross-distribution “pollution” would be that every distribution has their own Snap Store for their specific platform utilities, so the Snap Store is just apps and games. No distro-specific utilities like Livepatch on there right now. This way, you would have Snap Store + Ubuntu Overlay, or Snap Store + Fedora Overlay. I know I’ve said it before, but I still think it would work.

Hate speech is pretty hard to define. The Left (I am not trying to draw attention to these issues, just being honest) would view anything that said LGBT is not genetic, Abortion is murder, etc. as being hateful. The Right would say the opposite / that is isn’t hateful, free speech. This is a particularly touchy subject, because if Ubuntu/Canonical chooses a political view, the people on the other side (it is about 50/50 in the US where I live) would scream Censorship.

Of course I hate politics with every cell in my body, but it is important to talk about them now while forming, instead of waiting until the day we actually have problems. See Facebook as an example. I truly believe that if Snap is to be successful, it must be as politically neutral as possible. Not middle-ground, but neutral as possible. For example, if there is a snap that helps women find abortion clinics, don’t let the Right take it down. Likewise, if there is a snap which helps women find pro-life clinics, don’t let the Left take it down. Only in the cases where, say, the vast majority of both sides of the isle say something is evil (e.g. racism), take it down.

Finally, I know the Snap team is very busy innovating with new features, bug fixes, and I applaud them for that. :slight_smile: I do believe it is worth thinking and making a definite decision on how to handle such cases before they are a problem, and trying to improve the distribution-neutral picture now to get as many people on-board with Snap instead of waiting until later when it becomes a problem.

2 Likes
166

Actually it is NOT possible to set one’s refresh schedule just fine - - - :frowning: !

Zero is a number - - but it isn’t available in a snap refresh schedule.

1 Like
167

This kind of argument is very debatable. The vision that FOSS is about “choice” is your vision, it’s not some universally held truth. The very notion of “choice” is subjective anyway. In fact I, for example, have absolutely no problem with the idea of there being One True Way of doing something, and if anything, I believe we need more of it in the FOSS world, not less. Likewise the systemd “controversy” wasn’t much of a controversy at all, just a tamper tantrum by a small but extremely vocal bunch of VUAs who never managed to advance any serious arguments for their position, just tons of FUD and the notion that it’s supposedly bad because it’s “not UNIX” (by the same token, TCP/IP must be bad too, because the UNIX “philosophy” really leads to UUCP). Once Devuan got released and the usage numbers were in, everyone could see the obvious: no-one really cares and their “init freedom” distro is statistically irrelevant.

However, I do agree with your point but for another reason: FOSS, or free software in Stallman’s sense, is ultimately defined by the absence of top-down centralised control and this, nothing else, is violated by snap’s insistence on not allowing any external repositories. Despite the many weasel worded non-explanations by Canonical, I still don’t see which problem is their approach supposed to solve. Security is all important but only if it’s in the hands of the user and only the user. Put another way, it must ultimately be able to protect you even FROM Canonical rather than BY Canonical. We have no guarantee that Canonical’s snap store is really secure. In fact by design it’s not any more secure than Android’s Play store or Apple’s App store. Third-party stores may not be secure at all (just like PPAs aren’t) but that’s not Canonical’s to judge, each user should individually decide whom he chooses to trust and reputation would do the rest.

The absence of third party repos is an inherent problem that keeps coming back and back and back and Canonical won’t get that thorn out of their foot until one of three things happens:

  1. They drop the BS and come clear about the fact that they don’t want a real FOSS ecosystem, rather they see Ubuntu as another Android. Then it’s up to the users to decide whether or not they are willing to accept that; or

  2. They eat their hat and do what everyone has been calling for for years, that is support multiple repos and provide all tools necessary to create and run an independent snap store; or

  3. Snap dies for it and people move to Flatpak instead.

2 Likes
168

Replying to you in a private message, I like this line of discussion but it’s getting off-topic. Everything is political, man is by nature a political animal, and the GPL and all of opensource and free software represent a radical, novel perspective on freedom and relations to means of (information and computational) production.

2 Likes
169

Comment: I was overly sharp with the comment below. I meant the post as more of a, well, satirical look at what Ubuntu Core comes off like to me, as the definition of “security”. It was not meant to be anything serious.

Snap developers dream (and how I generally feel about this): Proposal: Ubuntu S Mode

170

Sorry, I was a little sharp with my comment above. Of course I support the work of snap, I meant it as an illustration of how this whole conversation feels.

171

I’m closing the topic, as it’s no longer meaningful discussion.

174

re-opened. Please keep in mind this topic is controversial, so try to keep things friendly. Failing that, keep it polite.

3 Likes
175

I don’t know what is controversial about this topic. Looking at the posts, I don’t see any that argue for the current position AND are not from the Canonical team. It rather looks like there is a rare unanimity about the fact that users should have the possibility to add or set up and operate independent “stores”.

I’ve been looking at (and tempted by) the Talos II Secure Workstation. Now of course Canonical’s store doesn’t build or host POWER binaries. Fair enough, it costs resources and the demand would probably be way too small to justify that. But then what? The user obviously won’t be able to access any of the open source software available from snap (such as the latest versions of LibeOffice, for example), but he (or she) also won’t be able to build them locally automatically, since snap doesn’t offer a way to download the corresponding snapcraft.yaml. And assuming he goes the trouble to retrieve upstream source code, obtain the snapcraft.yaml from the package maintainers, then build and test it on POWER, there will be no way to let the rest of the community benefit from his effort by creating a dedicated POWER store.

This is but one example of a scenario where the current model doesn’t fit legitimate expectations of FOSS users.

2 Likes
176

It definitely does provide ppc64el … snaps of that arch are just rare i guess because you need to use launchpad to create them (vs simply having build.snapcraft.io pull from a github tree (which builds x86 and arm in 32 and 64 bit))

2 Likes
177

3 posts were split to a new topic: Flatpak on Ubuntu Core

178

Just want to leave my two cents here. I’ve read the reasoning given by @niemeyer et al regarding user experience being the central focus, as well as the Snap Store being based on internal architecture making it difficult to open source. As a software developer, I fully understand these issues and choices.

Others have already sufficiently exhausted the philosophical arguments regarding decentralization and what it means for software freedom, and I fully agree with this. The Canonical devs do not seem to concur, but I think opposing sides of this philosophy do not necessarily need to translate into mutually exclusive implementations. I think a compromise can exist, where Snapcraft can be configured by default, and most users never need to think about adding custom stores/repos. PPAs could not do this because Canonical was the sole packager for the official Ubuntu repos, but that is not the case for Snapcraft. I think in practice, even after adding the ability to have multiple simultaneous stores, the vast majority of packagers of public software will still choose the central Snap Store because that is simply the easiest thing to do, and gives the end user the best experience. But at the same time, having the ability to host one’s own store clears a big hurdle for many seeking to use snaps.

I know it was mentioned that it is possible to work with Canonical to run a “branded store”, and that may well work for many companies. But there are many where that is not a practical solution. From my own perspective, my own company would never consider such a thing. It is simply too much to manage to have to coordinate with someone at Canonical in addition to any work it takes to manage the infrastructure, especially for a small team, and especially if it comes with a significant monetary cost. For us to even consider adopting it for internal use, it must be possible to spin up and maintain a server easily using nothing but the documentation. I suspect there are many other companies that manage their own infrastructure that could not even consider using snaps internally without an option to easily run their own internal repos. And you probably won’t hear from a proportionate number of them.

Another big blocker for us is not being able to disable automatic updates, but that’s another topic.

After this discussion has been open for a couple of years, and it’s still going—not to mention countless other discussions outside of this site—I think it’s pretty clear that there is high demand for it from the community. I understand prioritizing it among the undoubtedly lots of other work around the project, but it seems like Canonical’s opposition has less to do with available resources and more to do with something else not being stated explicitly. It would help a lot if the message were “we’d love to support this, but don’t have the bandwidth right now,” but we’re not even getting that. So I can’t even keep Snaps on my radar for future use.

2 Likes
179

a brandstore is a secret (or at wish, not secret) “leaf” of the global store that functions for you as a user exactly like the global store, the only maintenance overhead is a web-form where an admin user of your company manages user accounts, permissions and a few other aspects.

there is no separate infrastructure.

infrastructure, availability, security and maintenance all come for free with a brand store at the same level as the global store (and managed by the exact same teams).

a brand store also allows you to upload kernel and gadget snaps at will and gives you access to the snapd-control interface. if wanted you can also define your own (looser or tighter) security policies for single snaps in it.

not having to do any maintenance of store infrastructure (plus extra freedom and control) is exactly what the money is for. it directly tanslates to labour, service availability, security and control.

1 Like
180

@ogra thanks for the explanation! However, I fear this would not be acceptable either, as the company would not want our internal software packages hosted by an external entity that we don’t have control over. The infra maintenance isn’t the main concern by itself—that’s unavoidable in many cases—it’s having to communicate with an external company if anything goes wrong that needs fixing. We need control over it so we can fix it fast. Not to mention company wide concerns about IP.

Also, it may very well be that these are issues Canonical handles very well. You may respond very quickly to outages, and you may have tightly controlled privacy procedures in place to ensure IP leaks don’t happen. But I would have to make a convincing case up several levels of management to hope to adopt Snappy. And honestly it’s not worth the effort when other self-hosted solutions exist that work off the shelf.

3 Likes
181

well, i didnt mean to talk you into buying a brand store, i just wanted to point out that the money people pay is actually spent for relatively solid return values (plus for keeping the global store up and running for free) and not for paying for marks garden parties. :wink:

2 Likes
182

If being charitable and taking the developers at their word - it’s due to philosophical differences over how things should be done.

If being less charitable, possibly in addition to the above, it’s quite obvious to see that Canonical may receive less revenue to develop snappy if they allow users to easily create external repositories and adjust stop automatic updates - there would be potentially less demand for the paid branded stores and snap store enterprise proxy, respectively. They may not admit it, but perhaps we need to think of credible alternative forms of revenue generation for Canonical if us users want our own way on these two issues - and/or convincingly show that demand for branded stores and the enterprise proxy would not fall if we had our way on these two issues.

2 Likes
183

I mean if anything, I would expect revenue to stay the same or maybe even increase. I am not super business savvy, so take my opinion with a grain of salt, but I see there being two different markets: those who prefer to host their own solutions and those who prefer to just pay someone to host and manage it for them. It’s a pretty common business model for open source software companies to offer their source code for free for those who want to self-host, but offer a managed solution as well for revenue. Obviously they don’t get any revenue from those in the former, but I wouldn’t expect them to anyway.

There may be some who would discontinue their subscription and move to host their own infra if the server were open sourced; but on the flip side, I think there would also be some who try out Snappy with a POC self-hosted store, decide they like it, and then make the decision to buy a hosted subscription based on their positive experience.

2 Likes