given how many things Mint hacks up quietly i wouldnt be surprised if their /etc/profile.d handling (which sets the /snap/bin path in all .deb based distros by default (and works on all others btw)) would be broken.
Mint kind of has its own standards for system modification and secret package changes …
Rather than jump to conclusions and throw rocks at their policies…
I just booted my Mint machine and /snap/bin is indeed in the path. @G.S.1 what makes you think it isn’t?
The point to take away from the news article is that they’re going to have Flatpak’s installed and integrated (with their software center) by default and aren’t doing the same for snappy. Thus, ordinary Mint users who don’t read news articles and hear about snappy will end up using Flatpak’s and not snaps.
The reason given by Mint for Flatpak > snap is the external repositories issue. Maybe they would have more objections even if that were fixed, but that is the stated reason. Like GS I respect and see why snappy won’t add this feature but also respect and see why some FOSS distros and users thus won’t have snappy installed and integrated by default. There is a cost to snappy’s decision here. Personally I think Flatpak’s approach of central OSS(?) Flathub + optional external repos has the better tradeoff than snappy’s approach of central proprietary store + no external repos allowed - it’s a less neat but more OSS-pleasing approach that doesn’t tie OSS developers to Canonical’s policies with the snap store. We’ll have to see how many distros choose to have snappy installed and integrated by default despite snappy’s decision.
we have had PPAs for about a decade now with their advantages and disadvantages … snap’s centralized nature overcomes quite a bunch of the disadvantages (security wise… i.e. the central gatekeeping on uploads via security checks etc) while the above pretty much just duplicates the old PPA approach… sure, there is a political drawback here but it is a security and trust advantage on the other hand …
… if you would want to just allow random stores you would either take away one level of security and rely only on the local confinement … or you would have to develop something (probably at high cost) that external stores could hook into … which makes you end up again with the “someone controls it” argument …
regarding mint … they do not seem to have a problem with the “canonical controlled debian archive” that they use to build their distro…
Nice response!
For me the main problem with PPAs was the hassle (three line install for PPA’d apps, re-enable after every upgrade) and potentially conflicting dependencies etc. With the dependency problem removed, and with a one-click way to install external repositories, and with confinement for all apps, they wouldn’t be so bad. I thought snappy was all about removing the distributor middleman anyway, but I guess ideally you still want some sort of verifying middleman. Still, the choice to add an external repo would be up to the user.
Also, as Zyga has pointed out, OSS is usually happy to use the proprietary GitHub in their toolchain. And I guess a proprietary snap store is useful for paid apps.
(Added a ? to my statement that Flathub is OSS because I’m not actually sure it is, though maybe it’s pretty much just the buildbot, which is open)
I actually was just writing a long response @Ads20000 when you posted that. 
One of my points is that with Snap, there are no dependency problems. Therefore, it is not like PPA. It is like a PPA that always works.
Flathub is open source. https://github.com/flathub
This actually makes me wonder about Snap, a lot. Instead of a proprietary server implementation, why can’t we just use Buildbot like Flatpak? It is open source, works like a charm for Flatpaks… why not?
Snap is about a verifying middleman… Here is an option: What if there were levels of security, and things were layered. Let me explain. For example, you have:
Everybody includes Snap Store (by default), then you have a distro-specific store like the “Solus Store” or “Linux Mint” store that is independently operated and runs on top, and then you have user-added stores. Layer 1 and Layer 2 are automatically approved, layer 3 has more warnings.
Furthermore, these would not hook into eachother. Rather, it would be written into Snap itself to combine the results of the store, using a foreach loop. It would only take a few days to program, but it would work using a flow like this:
Seems obvious, but it is actually only a minor tweak, doesn’t break too much, and would work. So you would now have:
You get the trust, but users are still more happy. Ideally, there would be no middleman (in my view), but I think this would, at least, be compatible and keep distros happy.
Well, all these hypthetical setups, as great as they might be, will depend on code being available, which is not the case today and as has been stated above a few times will be a major piece of work. no matter what is being discussed here, a possible implementation of anything is far out in the future, how about we put this thread to sleep until there is actually something to discuss when there actually is any opensourced code
@ogra Why can’t we use Buildbot?
You could have open-source Buildbot for building things, and a fork of the open-source uAppExplorer for the frontend. We could then fork the open-source (though no longer working) Snap API implementation on GitHub, fix it up…
Most of the closed source gunk, gone.
Having Buildbot doesn’t suddenly mean that we have the layout you want, it would require more work.
That is unlikely to happen unless if the snappy developers think this is the right direction and act on it? At the moment, you don’t think it’s the right direction, so no opensourced code exists!
no idea, i’m quite happy with snapcraft, build.snapcraft.io and the store as is (as … i guess 99.9% of snap users are) … i havent felt the need to even look what buildbot is …
(and again … i dont think this thread is going anywhere until there is any opensourced snap store you could work with … )
Buildbot is what Flathub and others use for building, instead of build.snapcraft.io. The advantage is it can do (I believe) almost everything build.snapcraft.io can do, but is open source.
It may just be a vocal minority of snappy users who aren’t happy with this, but you run the risk that distributions only have Flatpak installed and integrated by default and not snappy, which will hurt wider adoption. Interestingly, Solus did this with Flatpak first, and snappy later, perhaps Mint will do the same.
@Ads20000 Snap backend isn’t open source, but there are open-source alternatives already. Buildbot, uAppExplorer, the implementation on GitHub. It would be hard… but what a project! Building a truly open-source Snap Store, with all the parts brought together.
We just lost Linux Mint over this. It is real.
Buildbot (in my opinion) is actually better for the job than current build.snapcraft.io. It has GitHub SSO already, it has seemingly far more features, etc. Seriously @ogra try Buildbot a little bit. It is really nice.
I am more saying, perhaps Ubuntu doesn’t have to work on open-sourcing the current Snap Store. Rather, why not just work on integrating the alternatives? They work, they are already open.
Snap is adopting the way, Google adopt for there Play Store, I don’t find anything wrong with this, it basically, save us from managing external links.
The thing i don’t like about flatpak is that it uses more space, cause the app isn’t in compressed form.
I am just a casual User, who is looking for theme support in snap 
I and we (if I can say that) are afraid of this though. Not only because a corporation has total control over it, but also because… what if a critical attack took place on the Snap Store? If Snap was down for a few days, every distribution would be swearing off Snap Store forever.
Just because of the hacking risk, the Snap Store centralized design will not work in the long term @Ads20000 @ogra. We will need mirrors… and there probably should be an incentive to run mirrors, don’t you think? Now what would a good incentive be…?
You know… open sourcing the Snap Store as it is now would be a ton of work according to the developers, and I will take their word for that. However, we have open-source replacements that are semi-complete for many things:
Obviously incomplete implementation, some work to be done. However…
The code for build.snapcraft.io is on github.
uAppExplorer is a 3rd party site. individual snaps have their own web frontend on snapcraft.io - for example yakyak.
While the tools developed by the flatpak developers are awesome, I’m sure, can we please focus on our projects?
Yes, we can. I am implying we can take inspiration from Flatpak on this. You already did this, taking inspiration from them for theme support.
And not to forget that also the launchpad snap build code is entirly available as open source. See https://launchpad.net/launchpad-buildd for details.
bah, now you finally made me click on in and install it via gnome software 
