27 ms·

Why is there only one Snap Store?

175 points by reddotX 6y ago

ISL 6y ago
Debian user here, who has apparently missed the memo: What do snaps do that apt doesn't?
- entropicdrifter 6y ago
  they bundle all of their dependencies inside the snap, so even if the projects the snap depends on makes breaking changes and you update your system with those changes, the snap will still work. Snaps also update on the fly without user interaction, which some people like and other people hate. Personally, I think Flatpak makes more sense than Snap. Snap's all tied up with Canonical
  - jdbernard 6y ago
    I don't think anyone is upset about the ability of a snap app to update without user intervention. It's the lack of choice. You're forced to take updates.
    - entropicdrifter 6y ago
      Agreed. I wasn't saying the 'ability' to update without interaction was something some people like and some people hate. I said they 'do' update without user interaction, etc etc. I think we're on the same page. Thanks for articulating that bit of nuance.
- barrkel 6y ago
  A mounted FS per installed application so you can run different versions side by side. I like it for large standalone apps, less so for command-line utilities. It easily beats untarring some third-party thing to /opt.
  - AnIdiotOnTheNet 6y ago
    > A mounted FS per installed application so you can run different versions side by side. Does it strike anyone else as very telling that people looked at the problem of "we can't install more than one version of an application at a time because of how we structure our filesystem and hardcode paths" and decided that the solution was "let's give each application its own filesystem!"?
    - sebastos 6y ago
      I know, what's up with this? I always feel like the systems guys must know something I don't, and that it would be way harder than I'm imagining. But like.. haven't we learned enough in the last 30 years to know that we need something smarter for mutually dependent pieces of software? Why is nobody trying to do this? I get that Docker, Snap, Flatpak, etc. are expedient in the here and now. But shouldn't we be trying to rebuild everything on top of nix, and then make nix completely transparent to most users?
    - barrkel 6y ago
      ISTM that anything which lets you install multiple versions side by side will require each version to have pinned versions of dependencies, transitively, until it's very close to the dominant node, which ultimately is the OS API, which in turn, done right, is backward compatible. You can implement that versioned dependency DAG as a database of versioned libraries etc. combined with a version pinning database; or you can simply use disk space, and keep a copy of every dependency and put each in its own subtree, making the version pinning database implicit in the tree construction. I don't see the latter solution as being intrinsically worse than the former. I don't think there's a real alternative either; the most reliable set of dependencies is the same set as the original binary was built and tested with. (And of course it's not just libraries, but also configs of various flavours, assets, etc. If you didn't use the subtree approach, you'd need to reimplement it in a shim layer to simulate it, in order to package yesterday's applications today.)
      - m4rtink 6y ago
        For the record Flatpak solves the same issue without mountpoint spam by using OSTree zo store flatpaks and their shared runtimes. Not only that, it gets full deduplication of everything and diff downloads just by using OSTree. AFAIK Snap has no deduplication of installed stuff & not even any dhared runtimes. Not sure if it has diff downloads.
- programmarchy 6y ago
  Main benefit is the sandboxed app environment. Snaps are also bundled with their dependencies, so you don't need globally installed dependencies to run the app like you do with apt.
- simion314 6y ago
  From my understanding the new packaging is designed to move the control from the distribution maintainer to the developer. So depending on software and distribution you get a range of advantages and disadvantages. You can continue using apt, snap, flatpack,Stram and binaries from tar.gz so we only gained in choices.
  - MereInterest 6y ago
    Also, moving control from the user to the developer. Snaps automatically update, and until recently had no way to disable this behavior. This is a poor security choice, and means that a stable system cannot be made. While apt can still be used, many packages were replaced by snaps, completely defeating the purpose.
    - aiphieng 6y ago
      "many packages" as in "less than 10 out of 10s of thousands".
      - EE84M3i 6y ago
        notably, I thought ripgrep became a snap?
        boogies 6y ago
        doesn't look like it: https://github.com/BurntSushi/ripgrep#installation https://github.com/BurntSushi/ripgrep#installation
        EE84M3i 6y ago
        > (N.B. Various snaps for ripgrep on Ubuntu are also available, but none of them seem to work right and generate a number of very strange bug reports that I don't know how to fix and don't have the time to fix. Therefore, it is no longer a recommended installation option.) I distinctly recall getting suggested by 'command-not-found' to install rg from a snap in some version of ubuntu, but I don't remember what version it was.
- rolph 6y ago
  for one thing snaps use a closed source back end
- spanhandler 6y ago
  Pollute your mount list and make your software start way slower and take up more space. Also sometimes break or require intervention for basic operation due to security restrictions on it. The benefits are supposed to be that they're more secure, more portable, and don't junk up your system with files strewn everywhere. Personally I'm waiting for a better solution than anything we've seen so far for the first of those benefits, and would prefer a cross-platform user-oriented package manager like Homebrew or Nix (but better-supported-on-Linux in the former case and with a UX less like studying for a math exam in the latter) for the other two. IMO every solution to these problems on Linux desktop currently sucks to one degree or another.
  - boogies 6y ago
    I'm curious to try GNU Guix, does it sufffer from the same problems as Nix? (Edit: looking at https://guix.gnu.org/en/videos/everyday-use-of-gnu-guix,-part-one/index.html https://guix.gnu.org/en/videos/everyday-use-of-gnu-guix,-par... from the top of https://guix.gnu.org/ https://guix.gnu.org/, basic installation and removal of packages looks exactly like apt, literally the same command line with 'apt' replaced with 'guix' and 'sudo' unnecessary because you can install packages per user.)
    - spanhandler 6y ago
      I admit I've not checked and have just assumed the package list is both ideologically- and mindshare-crippled, due to the GNU on the name and the seemingly low rate of use, respectively. Nb I think free software goals are great and all but if I need Slack for work or need my proprietary wifi card to work using a binary blob then I f#cking need those things, and it's nice if my package manager can install them for me. It's also nice if it's got enough eyes on it that I essentially never run into a broken package, even when installing kinda-obscure things.
      - boogies 6y ago
        You can use Guix on distros with impure repos, not just the GNU Guix system, and use the host distro's packages for proprietary software (if you can't just use Slack's web client, or use a laptop with a freedom-respecting wifi card / a little dongle / ethernet).
- Barrin92 6y ago
  snaps are self-contained apps that ship with their own dependencies, so you get software directly from the developer and you'll be on whatever version they ship. software installed with apt on Debian is fixed until the next release (unless you're on testing/unstable), so that would be the biggest difference.
  - inetknght 6y ago
    So a snap is a more complicated version of a statically-built binary?
    - Barrin92 6y ago
      yeah basically, although 'more complicated' depends on what you consider to be complicated, because another benefit is that you can be sure they run cross platform across any distro that runs snapd, and you don't actually end up replicating all dependencies in every binary, because snapd doesn't duplicate the ones already installed.
- galgalesh 6y ago
  Provide a recent version of Arduino on debian-based systems ;) They're mainly useful for applications which either release too fast or too slow compared to regular distributions. The apps contain their own dependencies. Another advantage is for messy applications. I'd much rather run Wine applications inside of a sandboxed snap than pollute my base system with all the multilib stuff that's required for wine. For more information; I also wrote a blogpost about why things like Snaps and Flatpaks are useful for Open Source apps: https://merlijn.sebrechts.be/blog/2020-07-06-why-snap-flatpak/ https://merlijn.sebrechts.be/blog/2020-07-06-why-snap-flatpa...
justaguy88 6y ago
What does snap do that flatpak doesn't?
- gjsman-1000 6y ago
  Well, if you are building an IoT Device, lots of stuff for reliability. Automatic rollbacks, self-repairing, immutable FS... For a desktop user, honestly, very little.
  - curt15 6y ago
    >Well, if you are building an IoT Device, lots of stuff for reliability. Automatic rollbacks, self-repairing, immutable FS... For that there is ostree, which is already supported by at least one major embedded systems vendor (https://docs.windriver.com/bundle/Wind_River_Linux_Tutorial_Using_OSTree_for_Updates_at_Run_Time_LTS_19/page/ont1573078060508.html https://docs.windriver.com/bundle/Wind_River_Linux_Tutorial_...).
    - m4rtink 6y ago
      BTW, OSTree is also the technplogy behind Fedora Silverblue, Fedora IoT and modern versions of Coee OS. Also flatpaks use OSTree internally for deduplication of all runtimes and flatpaks & for diff only downloads.
  - AgentME 6y ago
    That reliability stuff sounds good on desktop too. I don't exactly enjoy re-running apt after it has mysterious failures halfway through installs.
    - gjsman-1000 6y ago
      You might find Fedora Silverblue fascinating. It's an OS that uses Flatpak for Desktop Apps exclusively, which disposable "toolboxes" for non-Flatpak apps.
      - 6y ago
war1025 6y ago
Semi-related: Does anyone else feel like Ubuntu has lost a lot of its momentum over the past few years? I don't hear about things they're doing nearly as often anymore.
- gjsman-1000 6y ago
  Well, they spent several years on Unity8+Mir, and then abandoned it went that went nowhere. They then pivoted to Snaps, where they are so proud of themselves on their echo chamber of a forum that they can't see that the end users are less than impressed. Honestly, I've stopped paying attention because Ubuntu is great at building technology with critical, mind-bogglingly obvious flaws that sink the project every time.
  - hannasanarion 6y ago
    Don't forget Upstart, Juju, and Ubuntu Phone
    - unixhero 6y ago
      Wait JuJu is dead?
      - deleted 6y ago
        [deleted]
      - padraic7a 6y ago
        No juju seems to still be going strong. Mír is still going strong - though it is a Wayland client now, even Ubuntu Touch is still going, though as a community project rather than a Canonical one.
    - xet7 6y ago
      That OS of Ubuntu Phone, Ubuntu Touch https://ubports.com https://ubports.com has rapid progress as a community project, it works very well on PinePhone, and there are also other Open Source OSes for PinePhone.
clvx 6y ago
I do like the snap concept, but some implementations are just not that great. For instance, kustomize as snap doesn't let you read anything outside that is not in the snap fs. Not even in --classic mode. A similar issue happens with nextcloud which is good on paper, but if you tweak something inside the snap fs it will be overridden in the next update(expected behavior); however, for services that require mutable configuration there needs to be a way to preserve that data (I tested that nextcloud behavior more than half a year ago).
- galgalesh 6y ago
  > For instance, kustomize as snap doesn't let you read anything outside that is not in the snap fs. Not even in --classic mode. Classic snaps have complete access to the host filesystem. It is up to the publisher, however, to request classic confinement. If the publisher creates a `strict` snap, users cannot override this (because strict snaps would break when their container and dependencies suddenly disappear) > for services that require mutable configuration there needs to be a way to preserve that data (I tested that nextcloud behavior more than half a year ago). Snaps have access to multiple locations to store mutable data like `SNAP_COMMON`, `SNAP_USER_COMMON`, `SNAP_DATA` etc. Snaps can optionally also access regular directories. Afaik, Nextcloud stores its configuration in one of those directories. I think what you experienced might be an issue with the NextCloud snap because snapd itself already supports this.
gjsman-1000 6y ago
"Interestingly, Canonical actually released an open-source prototype Snap store backend a few years ago, but there was very little interest from the community in in actually maintaining and running a second Snap store, so the project bit-rotted and became incompatible with the current Snap protocol." That open-source server was a single-python-file hacky prototype written in an employee's spare time. It's not surprising it got little interest. Not only that, but this is the biggest omission of the truth: Making your own server is no longer possible because of assertions. All Snaps are now digitally signed by Canonical, so you actually need to have the end-user install a forked snap tool on their system to access the custom repository. You cannot disable this signing - your only way around it is to manually download the snap and install it with `--dangerous` through the CLI. And you won't get auto updates that way.
- simion314 6y ago
  > All Snaps are now digitally signed by Canonical, so you actually need to have the end-user install a forked snap tool Isn't the client side open source so you can put your own signature? Digital signing things seems a good idea for security.
  - gjsman-1000 6y ago
    I wish, but the signature is actually compiled into the snapd (the software on your system)'s binary. Deliberately impossible to reconfigure. Like I said, you can change the signature... by distributing a forked binary to users that would be incompatible with the main store.
    - lfmunoz4 6y ago
      You can always modify the Linux Kernel system call "open" to detect when an attempt to open the certificate is being attempted and then read out your own certificate.
    - simion314 6y ago
      Isn't this good? I mean if you are a distribution you compile the software yourself so you can add the distribution keys (there are some that don't compile stuff ). Probably you are thinking there should be atext file in your home where you could add new signature to be sued, but that could be a security issue so probably needs to be something more safe,did any serious patch was sent to improve this and was it rejected or why we expect Canonical to prioritize this over other issues?
snicker7 6y ago
It does not seem that the author is affiliated with Canonical. Ideally, Canonical should be the ones defending their product. IMO, it is okay for the backend to be propriety as long there is a published, easy to implement protocol for talking to snapd (along with an accessible way for clients to configure snapd). Otherwise, there is lock-in to the service. It's not just the FOSS community that should be concerned, but business users as well. Do you want to internally distribute in-house snaps via Canonical's servers? > DockerHub and GitHub are insanely popular and they are completely proprietary. These are arguments against, not for, using these services. And many proprietary SaaS companies sell installations on on-prem air gapped servers.
- galgalesh 6y ago
  Canonical has defended their product in many places. This article contains a lot of the same info, for example: https://www.techrepublic.com/article/why-canonical-views-the-snap-ecosystem-as-a-compelling-distribution-agnostic-solution/ https://www.techrepublic.com/article/why-canonical-views-the...
Animats 6y ago
Control. 1. Get market share with free product. 2. Start charging once monopoly is achieved. 3. Profit!
- kd913 6y ago
  Lol as if there is oodles of money to be gained from hosting a store like that on Linux. We can see all these steam game publishers desperate to release games to a community that is rather famous fo being cheapskates. Also, snap existing doesn't hinder flatpak or appimage or debs or rpms.
  - teraflop 6y ago
    They aren't going for a model like Steam where they sell software to end-users. The idea is to get enterprises hooked on using snaps to distribute their software internally, and then charge them for private repository hosting.
    - kd913 6y ago
      Then fair play for Canonical to get revenue streams from enterprise? From my perspective the primary motivation seems rather simple in minimizing the maintenance costs/testing of having to publish software for 5-6 distributions. That to me seems more plausible than evil mustache twisting capitalist reasons.
  - stonogo 6y ago
    Does the Google Play Store not make moeny?
  - setzer22 6y ago
    Since when are linux users "famously considered cheapstakes"? I was under the impression it's quite the opposite! Of course, all generalizations are just that. But if anything, the linux gaming community has many passionate people more than willing to pay for games on their platform. Most game developers don't port/build for linux due to the lower market share. A way simpler explanation that obeys basic market rules. OTOH I know more than a fair share of people who exclusive pirate all the games they play on Windows. I also don't know many people who bought a license to windows itsellf.
hajile 6y ago
Have they fixed the unearthly slowness of SquashFS? Is there a filesystem out there that is slower?
- galgalesh 6y ago
  The fault isn't SquashFS itself but the compression they use. They use an old compression algorithm by default to support older kernels. They are working on optionally enabling quicker compression on distros that support it though. See this for more info: https://forum.snapcraft.io/t/squashfs-performance-effect-on-snap-startup-time/13920 https://forum.snapcraft.io/t/squashfs-performance-effect-on-...
zaro 6y ago
This article is disingenuous at best!
- galgalesh 6y ago
  Author here. I'm happy to address any issues in the article. Let me know if there are any issues.
Conan_Kudo 6y ago
"Although they invested significant resources in open sourcing Launchpad, there is still only one instance of Launchpad running and they have not received any significant contributions from non-Canonical employees." For what it's worth, there is another Launchpad instance in existence: https://quickbuild.io/ https://quickbuild.io/ From personal experience, I found it functionally impossible to get a local instance working when I tried a few years ago. I applaud someone else managing to pull it off.
- rosywoozlechan 6y ago
  Launchpad is also objectively more complex and hard to use than alternatives, and subjectively I'd say it's ugly and looks dated. Launchpad isn't probably something people want to use because of product design, and thus there's not much activity around it outside of Canonical. I think it would be silly to assume that a separate project that is liked wouldn't get traction outside of Canonical because of their experience with Launchpad.
  - galgalesh 6y ago
    > Launchpad is also objectively more complex and hard to use than alternatives, and subjectively I'd say it's ugly and looks dated Launchpad is _really_ old though. When it was open sourced, there were very few alternatives and those were often even more complex and harder to use. I think part of the reason why it was almost never used was because it does so much: project management, bug trackers, build service, package hosting, ISO and distro building, .. If you only need a few of these features, you are much better of using alternatives with a smaller scope.
    - stubish 6y ago
      Launchpad actually predates Ubuntu :) A lot of the methodologies and practices used to develop it (both good and bad) didn't even get names until years later. I even hear monoliths are becoming fashionable again.
    - pseudalopex 6y ago
1_person 6y ago
That reminds me of the stake Ubuntu Core was born with in its heart: > An Ubuntu SSO account is required to create the first user on an Ubuntu Core installation. They just keep flinging shit at nothing and hoping to hit a wall they can build a gate in. They're trying to boil the frog slowly with Snap on the Server/Desktop branches. There is no possible genuine motive for these maneuverings to be in the position of gatekeeper. If anyone at Canonical is listening, you should be aware it doesn't matter how slowly and carefully you approach this, or how you justify it, the first time I'm forced to kiss the ring to get my software to work, your software is gone from any system I own or manage, immediately and forever. You're not going to get within a thousand miles of monetizing the ecosystem by gatekeeping it -- the moment you even so much as assert the position of gatekeeper you're trying to create for yourselves you're dead to me.
- psanford 6y ago
  I was excited for Ubuntu Core and then "noped" out as soon as I saw the Ubuntu SSO account requirement. I'm not going to use an OS that you can't login to without it phoning home to a third party.
  - kyrofa 6y ago
    You realize that's literally just to fetch SSH keys, right? It's the authentication method so they don't have to provide a default password. It's not some sort of phone-home method.
    - ifmpx 6y ago
      I, like GP, noped out as soon as I saw the SSO requirement. I also noped out of Microsoft's /free/ embedded offing for the same reason. I don't care why it's needed. I'm not interested in voluntarily tying my business to your product if you're going to restrict access to it this early on.
    - psanford 6y ago
      Yeah giving a third party the ability to control what ssh keys get provisioned on a machine isn't a big deal.</sarcasm>
seaghost 6y ago
I highly recommend switching to Pop!_OS.
vffhfhf 6y ago
Is this another whining post? Here is what I think. Ubuntu actually works. Wont crap out every other month. Most stable OS for linux are all ubuntu based. Even Snap works. So why is there only one snap store? Coz if there were more, they would be crap/dogshit like 99% of linux OS are. Go back to what ever OS you like. You are not needed. Useless free loaders.
- kilo_bravo_3 6y ago
  People will be angry with your bluntness, but you are absolutely, irrefutably, correct. Ubuntu is so much more stable and capable than any other distro that is ridiculous. If Micro$oft or "Crapple" gave users similar levels of reliability that other distros did, every single user on HN (EVERY SINGLE ONE) would be frothing at the mouth criticizing them. Hell, until F32, Fedora would not boot to a usable system after installation without GRUB and config file tweaks on my workstation (TR1950X+GTX1080+dual 4k monitors). Ubuntu? "No problem man I can do it."
  - zelly 6y ago
    This is also a reason more companies don't go into open source or target the GNU/Linux desktop. Whenever you do something that slightly disagrees with the Richard Stallman philosophy, or god forbid charge for software, they will froth at the mouth, attack you, and say stuff like "I will fork you and make your company obsolete". Nobody who sells software on the Mac App Store for example ever has to hear stuff like this.
- galgalesh 6y ago
  Author here. Read the post.
curt15 6y ago
This is easy to explain if you think of it as a business decision. Why would anyone pay $30000 for a custom "enterprise edition" snap store[1] -- which among other features restores full control of updates -- if anyone could easily set up their own snap stores? [1]https://ubuntu.com/pricing/devices https://ubuntu.com/pricing/devices
- galgalesh 6y ago
  I don't think open sourcing the store would significantly cut their sales. Running a world-wide package distribution network in itself is an incredible cost which many companies are willing to pay for. CentOS did not cut into the sales of RHEL either, for example. It's useful to have someone to yell at when things break. Also note that there are already alternatives. I personally know a few companies who built their own stores internally and it's actually very easy to do so if you install the apps using side-loading.
jamieweb 6y ago
My main reason for disliking Snap is the fact that it allows anybody in the world to publish a package with minimal moderation. This completely undermines the inherent trust that system package managers should have. When installing critical system packages, I want to be absolutely certain that these are legitimate/official, and that even if I make a minor error in typing a command, I won't inadvertently install some sort of typosquatted fake version of the package. When using Apt with the default repositories, this isn't a problem at all, as only known, trusted packages are available. In other words, there's no chance of someone publishing a fierfox or apahce2 package to try to typosquat someone. I don't even want to talk about the forced automatic updates either... these make it essentially impossible to have a stable/reliable system for specialist use cases, e.g. browser testing, bastion host, build environment, where control over updates is very important. On the sandboxing - it's good in principle, but rarely seems to be implemented in a truly meaningful way, as ultimately once you have home drive access, you don't even need to worry about escalating privileges as everything valuable is probably in your home area! There's an xkcd about this somewhere...
- xet7 6y ago
  > My main reason for disliking Snap is the fact that it allows anybody in the world to publish a package with minimal moderation. This completely undermines the inherent trust that system package managers should have. Where do we get more maintainers? Sometimes in my development I release one new Wekan version per day. Canonical's Snap build servers download Wekan source code directly from GitHub, it is very transparent. > On the sandboxing - it's good in principle, but rarely seems to be implemented in a truly meaningful way Wekan Snap has strict sandbox, so code can not access any other directory that /var/snap/wekan/common. So in case someone would find exploit for web service, it can not escape sandbox. It is very important.
acgkmopvvgvmgv 6y ago
It's not for nothing that Snap is considered dangerous by SUSE and is not officially supported. They even fail basic upstream responsibilities. https://blog.linuxmint.com/?p=3906 https://blog.linuxmint.com/?p=3906 > A year later, in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you. > First, I’m happy to confirm that Linux Mint 20, like previous Mint releases will not ship with any snaps or snapd installed.
- galgalesh 6y ago
  > Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. This is not entirely correct. Distributions can use a "brand store" to have complete control over which packages their users get. > You can’t audit them Many Snaps contain a build manifest in `/snap/snap-name/current/snap/manifest.yaml`. This manifest contains a log of everything that is used to build the package. For snaps built on Launchpad, this is automatically enabled and includes a link to the Launchpad build log for that snap. This is one of the build logs for the Chromium package, for example: https://launchpad.net/~osomon/+snap/chromium-snap-firstrun-notice/+build/1071421 https://launchpad.net/~osomon/+snap/chromium-snap-firstrun-n... Using Launchpad as the source of truth, you can be 100% certain that the snap you're running is built from the source it presents. This is the same infrastructure that builds and provides trust for Ubuntu itself. The snapcraft build service uses Launchpad in the background, so any snap built using that can be audited just like regular Ubuntu packages. Snaps built on third-party infrastructure can enable this manifest using an environment variable. I don't know why Linux Mint is spreading such misinformation, but this is harmful.
  - comex 6y ago
    > This is not entirely correct. Distributions can use a "brand store" to have complete control over which packages their users get. By “you” I assume they are referring to users, not distributions.
Ericson2314 6y ago
Ahaha crap on all sides. Please come to Nix (or, hell, GUIX) and side-step all these issues.
- galgalesh 6y ago
  Nix is really cool! You can actually use Nix to build Snap packages! Not sure if that's actually used a lot though. One of the advantages of Snap over Nix is that snap has security builtin. Snap is built to support a store where anyone can publish any application without curation. Nix Flakes look really cool for third-parties to "publish" applications for Nix, but I wonder how they will do security.. In Snap, the default permissions of an app are stored and distributed out-of-band with the package itself. The package defines what permissions it _can_ use and the declaration defines what permissions it is _allowed_ to use by default. Users can then override the default permissions. You could get the same level of confinement in a Nix package, but then the package contains both the app and the confinement, so the packager or software provider gets to decide what permissions a package has on your system. Any idea how Nix could address this?
  - Ericson2314 6y ago
    The building of nix packages is completely sandboxed and secure. The running of them is currently an after-thought. - https://spectrum-os.org/ https://spectrum-os.org/ is a big idea for secure running of applications, which leverages Nix for some things. - I would like to see some CloudABI/Capsicum experiments, as anything that is not capability based seems baroque, difficult to, ill-fitting the problem at hand, and generally going to end in tears. - There is currently some wrapping around systemd-nspawn which could be improved. BTW when I say "The running of them is currently an after-thought" this isn't as bad as it sounds. I would say all the good solutions are not the scope of Nix, but instead the scope of NixOS, Nix home-manager, nix-darwin, etc. Still, a real problem that deserves a solution. Thanks for bringing it up.
richardfey 6y ago
The author mentions popularity as a justification and good reason to go with a central snap store. I am baffled.
- galgalesh 6y ago
  (author here) I'm not sure what you are referring to exactly, where do you think I say that? These are the reasons I talk about in the blog: * users can easily discover new applications, * developers can easily publish their apps, * and developing Snap itself is easier.
  - richardfey 6y ago
    > That said, I’m pragmatic about the proprietary back-end. DockerHub and GitHub are insanely popular and they are completely proprietary.
liability 6y ago
Because Shuttleworth has notorious Apple-envy.
crashbunny 6y ago
I tried not to interpret the article in the worst possible way, but I failed, it feels disingenuous to me. I don't think comparing ppa's to snaps is a good comparison. ppa's have the disadvantage of potential dependency problems which might break things like upgrades, and that has nothing to do with having a distributed store. snaps solve this and that has nothing to do with a proprietary single company controlled store.
- galgalesh 6y ago
  I'm sorry you feel this is disingenuous. I really tried to explain why there is only one Snap Store from a neutral point of view. Let me know if you have any tips to make it more genuine. You are right that this has nothing to do with the dependency problems Snap solves. Snap does many things differently but this article only focusses on one to keep it relatively short. This article doesn't try to present a comprehensive comparison and definitely not between Snap and PPA. The article only focuses on the question why there is only one Snap store. The answer to this question has nothing to do with Snap bundling dependencies. I also wrote a separate blog post about bundling dependencies here: https://merlijn.sebrechts.be/blog/2020-07-06-why-snap-flatpak/ https://merlijn.sebrechts.be/blog/2020-07-06-why-snap-flatpa... That blogpost lumps Snap and Flatpak together since, for the sake of bundling dependencies, the two technologies are pretty similar.
Awelton 6y ago
The better question is why is there a snap store? With flatpack and appimage already working well, why muddy the waters with another offering, much less one that it awful.
zubairq 6y ago
There is only one Snap store as this is what Microsoft is actually buying if it buys Canonical and turns the Snap store into the Microsoft store.
inshadows 6y ago
> Snap is designed so each device only connects to a single store for three reasons: > users can easily discover new applications, > developers can easily publish their apps, > and developing Snap itself is easier. Just a PR bullshit to cover for lack of freedom and need for control. Disregard.
johnisgood 6y ago
God, I could not hate Snap more. At least a .snap file can be mounted as a SquashFS and salvage what you can to run the program without snapd. Unrelated, but it is curious that some applications I have encountered depended on some proprietary library. To the bin it went. :D
johnisgood 6y ago
If I wanted spyware, I would just install Windows 10, really. Screw Canonical.

175 points by reddotX 6y ago

ISL 6y ago

Debian user here, who has apparently missed the memo: What do snaps do that apt doesn't?

entropicdrifter 6y ago
they bundle all of their dependencies inside the snap, so even if the projects the snap depends on makes breaking changes and you update your system with those changes, the snap will still work. Snaps also update on the fly without user interaction, which some people like and other people hate. Personally, I think Flatpak makes more sense than Snap. Snap's all tied up with Canonical
- jdbernard 6y ago
  I don't think anyone is upset about the ability of a snap app to update without user intervention. It's the lack of choice. You're forced to take updates.
  - entropicdrifter 6y ago
    Agreed. I wasn't saying the 'ability' to update without interaction was something some people like and some people hate. I said they 'do' update without user interaction, etc etc. I think we're on the same page. Thanks for articulating that bit of nuance.
barrkel 6y ago
A mounted FS per installed application so you can run different versions side by side. I like it for large standalone apps, less so for command-line utilities. It easily beats untarring some third-party thing to /opt.
- AnIdiotOnTheNet 6y ago
  > A mounted FS per installed application so you can run different versions side by side. Does it strike anyone else as very telling that people looked at the problem of "we can't install more than one version of an application at a time because of how we structure our filesystem and hardcode paths" and decided that the solution was "let's give each application its own filesystem!"?
  - sebastos 6y ago
    I know, what's up with this? I always feel like the systems guys must know something I don't, and that it would be way harder than I'm imagining. But like.. haven't we learned enough in the last 30 years to know that we need something smarter for mutually dependent pieces of software? Why is nobody trying to do this? I get that Docker, Snap, Flatpak, etc. are expedient in the here and now. But shouldn't we be trying to rebuild everything on top of nix, and then make nix completely transparent to most users?
  - barrkel 6y ago
    ISTM that anything which lets you install multiple versions side by side will require each version to have pinned versions of dependencies, transitively, until it's very close to the dominant node, which ultimately is the OS API, which in turn, done right, is backward compatible. You can implement that versioned dependency DAG as a database of versioned libraries etc. combined with a version pinning database; or you can simply use disk space, and keep a copy of every dependency and put each in its own subtree, making the version pinning database implicit in the tree construction. I don't see the latter solution as being intrinsically worse than the former. I don't think there's a real alternative either; the most reliable set of dependencies is the same set as the original binary was built and tested with. (And of course it's not just libraries, but also configs of various flavours, assets, etc. If you didn't use the subtree approach, you'd need to reimplement it in a shim layer to simulate it, in order to package yesterday's applications today.)
    - m4rtink 6y ago
      For the record Flatpak solves the same issue without mountpoint spam by using OSTree zo store flatpaks and their shared runtimes. Not only that, it gets full deduplication of everything and diff downloads just by using OSTree. AFAIK Snap has no deduplication of installed stuff & not even any dhared runtimes. Not sure if it has diff downloads.
programmarchy 6y ago
Main benefit is the sandboxed app environment. Snaps are also bundled with their dependencies, so you don't need globally installed dependencies to run the app like you do with apt.
simion314 6y ago
From my understanding the new packaging is designed to move the control from the distribution maintainer to the developer. So depending on software and distribution you get a range of advantages and disadvantages. You can continue using apt, snap, flatpack,Stram and binaries from tar.gz so we only gained in choices.
- MereInterest 6y ago
  Also, moving control from the user to the developer. Snaps automatically update, and until recently had no way to disable this behavior. This is a poor security choice, and means that a stable system cannot be made. While apt can still be used, many packages were replaced by snaps, completely defeating the purpose.
  - aiphieng 6y ago
    "many packages" as in "less than 10 out of 10s of thousands".
    - EE84M3i 6y ago
      notably, I thought ripgrep became a snap?
      - boogies 6y ago
        doesn't look like it: https://github.com/BurntSushi/ripgrep#installation https://github.com/BurntSushi/ripgrep#installation
        EE84M3i 6y ago
        > (N.B. Various snaps for ripgrep on Ubuntu are also available, but none of them seem to work right and generate a number of very strange bug reports that I don't know how to fix and don't have the time to fix. Therefore, it is no longer a recommended installation option.) I distinctly recall getting suggested by 'command-not-found' to install rg from a snap in some version of ubuntu, but I don't remember what version it was.
rolph 6y ago
for one thing snaps use a closed source back end
spanhandler 6y ago
Pollute your mount list and make your software start way slower and take up more space. Also sometimes break or require intervention for basic operation due to security restrictions on it. The benefits are supposed to be that they're more secure, more portable, and don't junk up your system with files strewn everywhere. Personally I'm waiting for a better solution than anything we've seen so far for the first of those benefits, and would prefer a cross-platform user-oriented package manager like Homebrew or Nix (but better-supported-on-Linux in the former case and with a UX less like studying for a math exam in the latter) for the other two. IMO every solution to these problems on Linux desktop currently sucks to one degree or another.
- boogies 6y ago
  I'm curious to try GNU Guix, does it sufffer from the same problems as Nix? (Edit: looking at https://guix.gnu.org/en/videos/everyday-use-of-gnu-guix,-part-one/index.html https://guix.gnu.org/en/videos/everyday-use-of-gnu-guix,-par... from the top of https://guix.gnu.org/ https://guix.gnu.org/, basic installation and removal of packages looks exactly like apt, literally the same command line with 'apt' replaced with 'guix' and 'sudo' unnecessary because you can install packages per user.)
  - spanhandler 6y ago
    I admit I've not checked and have just assumed the package list is both ideologically- and mindshare-crippled, due to the GNU on the name and the seemingly low rate of use, respectively. Nb I think free software goals are great and all but if I need Slack for work or need my proprietary wifi card to work using a binary blob then I f#cking need those things, and it's nice if my package manager can install them for me. It's also nice if it's got enough eyes on it that I essentially never run into a broken package, even when installing kinda-obscure things.
    - boogies 6y ago
      You can use Guix on distros with impure repos, not just the GNU Guix system, and use the host distro's packages for proprietary software (if you can't just use Slack's web client, or use a laptop with a freedom-respecting wifi card / a little dongle / ethernet).
Barrin92 6y ago
snaps are self-contained apps that ship with their own dependencies, so you get software directly from the developer and you'll be on whatever version they ship. software installed with apt on Debian is fixed until the next release (unless you're on testing/unstable), so that would be the biggest difference.
- inetknght 6y ago
  So a snap is a more complicated version of a statically-built binary?
  - Barrin92 6y ago
    yeah basically, although 'more complicated' depends on what you consider to be complicated, because another benefit is that you can be sure they run cross platform across any distro that runs snapd, and you don't actually end up replicating all dependencies in every binary, because snapd doesn't duplicate the ones already installed.
galgalesh 6y ago
Provide a recent version of Arduino on debian-based systems ;) They're mainly useful for applications which either release too fast or too slow compared to regular distributions. The apps contain their own dependencies. Another advantage is for messy applications. I'd much rather run Wine applications inside of a sandboxed snap than pollute my base system with all the multilib stuff that's required for wine. For more information; I also wrote a blogpost about why things like Snaps and Flatpaks are useful for Open Source apps: https://merlijn.sebrechts.be/blog/2020-07-06-why-snap-flatpak/ https://merlijn.sebrechts.be/blog/2020-07-06-why-snap-flatpa...

justaguy88 6y ago

What does snap do that flatpak doesn't?

gjsman-1000 6y ago
Well, if you are building an IoT Device, lots of stuff for reliability. Automatic rollbacks, self-repairing, immutable FS... For a desktop user, honestly, very little.
- curt15 6y ago
  >Well, if you are building an IoT Device, lots of stuff for reliability. Automatic rollbacks, self-repairing, immutable FS... For that there is ostree, which is already supported by at least one major embedded systems vendor (https://docs.windriver.com/bundle/Wind_River_Linux_Tutorial_Using_OSTree_for_Updates_at_Run_Time_LTS_19/page/ont1573078060508.html https://docs.windriver.com/bundle/Wind_River_Linux_Tutorial_...).
  - m4rtink 6y ago
    BTW, OSTree is also the technplogy behind Fedora Silverblue, Fedora IoT and modern versions of Coee OS. Also flatpaks use OSTree internally for deduplication of all runtimes and flatpaks & for diff only downloads.
- AgentME 6y ago
  That reliability stuff sounds good on desktop too. I don't exactly enjoy re-running apt after it has mysterious failures halfway through installs.
  - gjsman-1000 6y ago
    You might find Fedora Silverblue fascinating. It's an OS that uses Flatpak for Desktop Apps exclusively, which disposable "toolboxes" for non-Flatpak apps.
    - 6y ago

war1025 6y ago

Semi-related: Does anyone else feel like Ubuntu has lost a lot of its momentum over the past few years? I don't hear about things they're doing nearly as often anymore.

gjsman-1000 6y ago
Well, they spent several years on Unity8+Mir, and then abandoned it went that went nowhere. They then pivoted to Snaps, where they are so proud of themselves on their echo chamber of a forum that they can't see that the end users are less than impressed. Honestly, I've stopped paying attention because Ubuntu is great at building technology with critical, mind-bogglingly obvious flaws that sink the project every time.
- hannasanarion 6y ago
  Don't forget Upstart, Juju, and Ubuntu Phone
  - unixhero 6y ago
    Wait JuJu is dead?
    - deleted 6y ago
      [deleted]
    - padraic7a 6y ago
      No juju seems to still be going strong. Mír is still going strong - though it is a Wayland client now, even Ubuntu Touch is still going, though as a community project rather than a Canonical one.
  - xet7 6y ago
    That OS of Ubuntu Phone, Ubuntu Touch https://ubports.com https://ubports.com has rapid progress as a community project, it works very well on PinePhone, and there are also other Open Source OSes for PinePhone.

clvx 6y ago

I do like the snap concept, but some implementations are just not that great. For instance, kustomize as snap doesn't let you read anything outside that is not in the snap fs. Not even in --classic mode. A similar issue happens with nextcloud which is good on paper, but if you tweak something inside the snap fs it will be overridden in the next update(expected behavior); however, for services that require mutable configuration there needs to be a way to preserve that data (I tested that nextcloud behavior more than half a year ago).

galgalesh 6y ago
> For instance, kustomize as snap doesn't let you read anything outside that is not in the snap fs. Not even in --classic mode. Classic snaps have complete access to the host filesystem. It is up to the publisher, however, to request classic confinement. If the publisher creates a `strict` snap, users cannot override this (because strict snaps would break when their container and dependencies suddenly disappear) > for services that require mutable configuration there needs to be a way to preserve that data (I tested that nextcloud behavior more than half a year ago). Snaps have access to multiple locations to store mutable data like `SNAP_COMMON`, `SNAP_USER_COMMON`, `SNAP_DATA` etc. Snaps can optionally also access regular directories. Afaik, Nextcloud stores its configuration in one of those directories. I think what you experienced might be an issue with the NextCloud snap because snapd itself already supports this.

gjsman-1000 6y ago

"Interestingly, Canonical actually released an open-source prototype Snap store backend a few years ago, but there was very little interest from the community in in actually maintaining and running a second Snap store, so the project bit-rotted and became incompatible with the current Snap protocol." That open-source server was a single-python-file hacky prototype written in an employee's spare time. It's not surprising it got little interest. Not only that, but this is the biggest omission of the truth: Making your own server is no longer possible because of assertions. All Snaps are now digitally signed by Canonical, so you actually need to have the end-user install a forked snap tool on their system to access the custom repository. You cannot disable this signing - your only way around it is to manually download the snap and install it with `--dangerous` through the CLI. And you won't get auto updates that way.

simion314 6y ago
> All Snaps are now digitally signed by Canonical, so you actually need to have the end-user install a forked snap tool Isn't the client side open source so you can put your own signature? Digital signing things seems a good idea for security.
- gjsman-1000 6y ago
  I wish, but the signature is actually compiled into the snapd (the software on your system)'s binary. Deliberately impossible to reconfigure. Like I said, you can change the signature... by distributing a forked binary to users that would be incompatible with the main store.
  - lfmunoz4 6y ago
    You can always modify the Linux Kernel system call "open" to detect when an attempt to open the certificate is being attempted and then read out your own certificate.
  - simion314 6y ago
    Isn't this good? I mean if you are a distribution you compile the software yourself so you can add the distribution keys (there are some that don't compile stuff ). Probably you are thinking there should be atext file in your home where you could add new signature to be sued, but that could be a security issue so probably needs to be something more safe,did any serious patch was sent to improve this and was it rejected or why we expect Canonical to prioritize this over other issues?

snicker7 6y ago

It does not seem that the author is affiliated with Canonical. Ideally, Canonical should be the ones defending their product. IMO, it is okay for the backend to be propriety as long there is a published, easy to implement protocol for talking to snapd (along with an accessible way for clients to configure snapd). Otherwise, there is lock-in to the service. It's not just the FOSS community that should be concerned, but business users as well. Do you want to internally distribute in-house snaps via Canonical's servers? > DockerHub and GitHub are insanely popular and they are completely proprietary. These are arguments against, not for, using these services. And many proprietary SaaS companies sell installations on on-prem air gapped servers.

galgalesh 6y ago
Canonical has defended their product in many places. This article contains a lot of the same info, for example: https://www.techrepublic.com/article/why-canonical-views-the-snap-ecosystem-as-a-compelling-distribution-agnostic-solution/ https://www.techrepublic.com/article/why-canonical-views-the...

Animats 6y ago

Control. 1. Get market share with free product. 2. Start charging once monopoly is achieved. 3. Profit!

kd913 6y ago
Lol as if there is oodles of money to be gained from hosting a store like that on Linux. We can see all these steam game publishers desperate to release games to a community that is rather famous fo being cheapskates. Also, snap existing doesn't hinder flatpak or appimage or debs or rpms.
- teraflop 6y ago
  They aren't going for a model like Steam where they sell software to end-users. The idea is to get enterprises hooked on using snaps to distribute their software internally, and then charge them for private repository hosting.
  - kd913 6y ago
    Then fair play for Canonical to get revenue streams from enterprise? From my perspective the primary motivation seems rather simple in minimizing the maintenance costs/testing of having to publish software for 5-6 distributions. That to me seems more plausible than evil mustache twisting capitalist reasons.
- stonogo 6y ago
  Does the Google Play Store not make moeny?
- setzer22 6y ago
  Since when are linux users "famously considered cheapstakes"? I was under the impression it's quite the opposite! Of course, all generalizations are just that. But if anything, the linux gaming community has many passionate people more than willing to pay for games on their platform. Most game developers don't port/build for linux due to the lower market share. A way simpler explanation that obeys basic market rules. OTOH I know more than a fair share of people who exclusive pirate all the games they play on Windows. I also don't know many people who bought a license to windows itsellf.

hajile 6y ago

Have they fixed the unearthly slowness of SquashFS? Is there a filesystem out there that is slower?

galgalesh 6y ago
The fault isn't SquashFS itself but the compression they use. They use an old compression algorithm by default to support older kernels. They are working on optionally enabling quicker compression on distros that support it though. See this for more info: https://forum.snapcraft.io/t/squashfs-performance-effect-on-snap-startup-time/13920 https://forum.snapcraft.io/t/squashfs-performance-effect-on-...

zaro 6y ago

This article is disingenuous at best!

galgalesh 6y ago
Author here. I'm happy to address any issues in the article. Let me know if there are any issues.

Conan_Kudo 6y ago

"Although they invested significant resources in open sourcing Launchpad, there is still only one instance of Launchpad running and they have not received any significant contributions from non-Canonical employees." For what it's worth, there is another Launchpad instance in existence: https://quickbuild.io/ https://quickbuild.io/ From personal experience, I found it functionally impossible to get a local instance working when I tried a few years ago. I applaud someone else managing to pull it off.

rosywoozlechan 6y ago
Launchpad is also objectively more complex and hard to use than alternatives, and subjectively I'd say it's ugly and looks dated. Launchpad isn't probably something people want to use because of product design, and thus there's not much activity around it outside of Canonical. I think it would be silly to assume that a separate project that is liked wouldn't get traction outside of Canonical because of their experience with Launchpad.
- galgalesh 6y ago
  > Launchpad is also objectively more complex and hard to use than alternatives, and subjectively I'd say it's ugly and looks dated Launchpad is _really_ old though. When it was open sourced, there were very few alternatives and those were often even more complex and harder to use. I think part of the reason why it was almost never used was because it does so much: project management, bug trackers, build service, package hosting, ISO and distro building, .. If you only need a few of these features, you are much better of using alternatives with a smaller scope.
  - stubish 6y ago
    Launchpad actually predates Ubuntu :) A lot of the methodologies and practices used to develop it (both good and bad) didn't even get names until years later. I even hear monoliths are becoming fashionable again.
  - pseudalopex 6y ago

1_person 6y ago

That reminds me of the stake Ubuntu Core was born with in its heart: > An Ubuntu SSO account is required to create the first user on an Ubuntu Core installation. They just keep flinging shit at nothing and hoping to hit a wall they can build a gate in. They're trying to boil the frog slowly with Snap on the Server/Desktop branches. There is no possible genuine motive for these maneuverings to be in the position of gatekeeper. If anyone at Canonical is listening, you should be aware it doesn't matter how slowly and carefully you approach this, or how you justify it, the first time I'm forced to kiss the ring to get my software to work, your software is gone from any system I own or manage, immediately and forever. You're not going to get within a thousand miles of monetizing the ecosystem by gatekeeping it -- the moment you even so much as assert the position of gatekeeper you're trying to create for yourselves you're dead to me.

psanford 6y ago
I was excited for Ubuntu Core and then "noped" out as soon as I saw the Ubuntu SSO account requirement. I'm not going to use an OS that you can't login to without it phoning home to a third party.
- kyrofa 6y ago
  You realize that's literally just to fetch SSH keys, right? It's the authentication method so they don't have to provide a default password. It's not some sort of phone-home method.
  - ifmpx 6y ago
    I, like GP, noped out as soon as I saw the SSO requirement. I also noped out of Microsoft's /free/ embedded offing for the same reason. I don't care why it's needed. I'm not interested in voluntarily tying my business to your product if you're going to restrict access to it this early on.
  - psanford 6y ago
    Yeah giving a third party the ability to control what ssh keys get provisioned on a machine isn't a big deal.</sarcasm>

seaghost 6y ago

I highly recommend switching to Pop!_OS.

vffhfhf 6y ago

Is this another whining post? Here is what I think. Ubuntu actually works. Wont crap out every other month. Most stable OS for linux are all ubuntu based. Even Snap works. So why is there only one snap store? Coz if there were more, they would be crap/dogshit like 99% of linux OS are. Go back to what ever OS you like. You are not needed. Useless free loaders.

kilo_bravo_3 6y ago
People will be angry with your bluntness, but you are absolutely, irrefutably, correct. Ubuntu is so much more stable and capable than any other distro that is ridiculous. If Micro$oft or "Crapple" gave users similar levels of reliability that other distros did, every single user on HN (EVERY SINGLE ONE) would be frothing at the mouth criticizing them. Hell, until F32, Fedora would not boot to a usable system after installation without GRUB and config file tweaks on my workstation (TR1950X+GTX1080+dual 4k monitors). Ubuntu? "No problem man I can do it."
- zelly 6y ago
  This is also a reason more companies don't go into open source or target the GNU/Linux desktop. Whenever you do something that slightly disagrees with the Richard Stallman philosophy, or god forbid charge for software, they will froth at the mouth, attack you, and say stuff like "I will fork you and make your company obsolete". Nobody who sells software on the Mac App Store for example ever has to hear stuff like this.
galgalesh 6y ago
Author here. Read the post.

curt15 6y ago

This is easy to explain if you think of it as a business decision. Why would anyone pay $30000 for a custom "enterprise edition" snap store[1] -- which among other features restores full control of updates -- if anyone could easily set up their own snap stores? [1]https://ubuntu.com/pricing/devices https://ubuntu.com/pricing/devices

galgalesh 6y ago
I don't think open sourcing the store would significantly cut their sales. Running a world-wide package distribution network in itself is an incredible cost which many companies are willing to pay for. CentOS did not cut into the sales of RHEL either, for example. It's useful to have someone to yell at when things break. Also note that there are already alternatives. I personally know a few companies who built their own stores internally and it's actually very easy to do so if you install the apps using side-loading.

jamieweb 6y ago

My main reason for disliking Snap is the fact that it allows anybody in the world to publish a package with minimal moderation. This completely undermines the inherent trust that system package managers should have. When installing critical system packages, I want to be absolutely certain that these are legitimate/official, and that even if I make a minor error in typing a command, I won't inadvertently install some sort of typosquatted fake version of the package. When using Apt with the default repositories, this isn't a problem at all, as only known, trusted packages are available. In other words, there's no chance of someone publishing a fierfox or apahce2 package to try to typosquat someone. I don't even want to talk about the forced automatic updates either... these make it essentially impossible to have a stable/reliable system for specialist use cases, e.g. browser testing, bastion host, build environment, where control over updates is very important. On the sandboxing - it's good in principle, but rarely seems to be implemented in a truly meaningful way, as ultimately once you have home drive access, you don't even need to worry about escalating privileges as everything valuable is probably in your home area! There's an xkcd about this somewhere...

xet7 6y ago
> My main reason for disliking Snap is the fact that it allows anybody in the world to publish a package with minimal moderation. This completely undermines the inherent trust that system package managers should have. Where do we get more maintainers? Sometimes in my development I release one new Wekan version per day. Canonical's Snap build servers download Wekan source code directly from GitHub, it is very transparent. > On the sandboxing - it's good in principle, but rarely seems to be implemented in a truly meaningful way Wekan Snap has strict sandbox, so code can not access any other directory that /var/snap/wekan/common. So in case someone would find exploit for web service, it can not escape sandbox. It is very important.

acgkmopvvgvmgv 6y ago

It's not for nothing that Snap is considered dangerous by SUSE and is not officially supported. They even fail basic upstream responsibilities. https://blog.linuxmint.com/?p=3906 https://blog.linuxmint.com/?p=3906 > A year later, in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you. > First, I’m happy to confirm that Linux Mint 20, like previous Mint releases will not ship with any snaps or snapd installed.

galgalesh 6y ago
> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. This is not entirely correct. Distributions can use a "brand store" to have complete control over which packages their users get. > You can’t audit them Many Snaps contain a build manifest in `/snap/snap-name/current/snap/manifest.yaml`. This manifest contains a log of everything that is used to build the package. For snaps built on Launchpad, this is automatically enabled and includes a link to the Launchpad build log for that snap. This is one of the build logs for the Chromium package, for example: https://launchpad.net/~osomon/+snap/chromium-snap-firstrun-notice/+build/1071421 https://launchpad.net/~osomon/+snap/chromium-snap-firstrun-n... Using Launchpad as the source of truth, you can be 100% certain that the snap you're running is built from the source it presents. This is the same infrastructure that builds and provides trust for Ubuntu itself. The snapcraft build service uses Launchpad in the background, so any snap built using that can be audited just like regular Ubuntu packages. Snaps built on third-party infrastructure can enable this manifest using an environment variable. I don't know why Linux Mint is spreading such misinformation, but this is harmful.
- comex 6y ago
  > This is not entirely correct. Distributions can use a "brand store" to have complete control over which packages their users get. By “you” I assume they are referring to users, not distributions.

Ericson2314 6y ago

Ahaha crap on all sides. Please come to Nix (or, hell, GUIX) and side-step all these issues.

galgalesh 6y ago
Nix is really cool! You can actually use Nix to build Snap packages! Not sure if that's actually used a lot though. One of the advantages of Snap over Nix is that snap has security builtin. Snap is built to support a store where anyone can publish any application without curation. Nix Flakes look really cool for third-parties to "publish" applications for Nix, but I wonder how they will do security.. In Snap, the default permissions of an app are stored and distributed out-of-band with the package itself. The package defines what permissions it _can_ use and the declaration defines what permissions it is _allowed_ to use by default. Users can then override the default permissions. You could get the same level of confinement in a Nix package, but then the package contains both the app and the confinement, so the packager or software provider gets to decide what permissions a package has on your system. Any idea how Nix could address this?
- Ericson2314 6y ago
  The building of nix packages is completely sandboxed and secure. The running of them is currently an after-thought. - https://spectrum-os.org/ https://spectrum-os.org/ is a big idea for secure running of applications, which leverages Nix for some things. - I would like to see some CloudABI/Capsicum experiments, as anything that is not capability based seems baroque, difficult to, ill-fitting the problem at hand, and generally going to end in tears. - There is currently some wrapping around systemd-nspawn which could be improved. BTW when I say "The running of them is currently an after-thought" this isn't as bad as it sounds. I would say all the good solutions are not the scope of Nix, but instead the scope of NixOS, Nix home-manager, nix-darwin, etc. Still, a real problem that deserves a solution. Thanks for bringing it up.

richardfey 6y ago

The author mentions popularity as a justification and good reason to go with a central snap store. I am baffled.

galgalesh 6y ago
(author here) I'm not sure what you are referring to exactly, where do you think I say that? These are the reasons I talk about in the blog: * users can easily discover new applications, * developers can easily publish their apps, * and developing Snap itself is easier.
- richardfey 6y ago
  > That said, I’m pragmatic about the proprietary back-end. DockerHub and GitHub are insanely popular and they are completely proprietary.

liability 6y ago

Because Shuttleworth has notorious Apple-envy.

crashbunny 6y ago

I tried not to interpret the article in the worst possible way, but I failed, it feels disingenuous to me. I don't think comparing ppa's to snaps is a good comparison. ppa's have the disadvantage of potential dependency problems which might break things like upgrades, and that has nothing to do with having a distributed store. snaps solve this and that has nothing to do with a proprietary single company controlled store.

galgalesh 6y ago
I'm sorry you feel this is disingenuous. I really tried to explain why there is only one Snap Store from a neutral point of view. Let me know if you have any tips to make it more genuine. You are right that this has nothing to do with the dependency problems Snap solves. Snap does many things differently but this article only focusses on one to keep it relatively short. This article doesn't try to present a comprehensive comparison and definitely not between Snap and PPA. The article only focuses on the question why there is only one Snap store. The answer to this question has nothing to do with Snap bundling dependencies. I also wrote a separate blog post about bundling dependencies here: https://merlijn.sebrechts.be/blog/2020-07-06-why-snap-flatpak/ https://merlijn.sebrechts.be/blog/2020-07-06-why-snap-flatpa... That blogpost lumps Snap and Flatpak together since, for the sake of bundling dependencies, the two technologies are pretty similar.

Awelton 6y ago

The better question is why is there a snap store? With flatpack and appimage already working well, why muddy the waters with another offering, much less one that it awful.

zubairq 6y ago

There is only one Snap store as this is what Microsoft is actually buying if it buys Canonical and turns the Snap store into the Microsoft store.

inshadows 6y ago

> Snap is designed so each device only connects to a single store for three reasons: > users can easily discover new applications, > developers can easily publish their apps, > and developing Snap itself is easier. Just a PR bullshit to cover for lack of freedom and need for control. Disregard.

johnisgood 6y ago

God, I could not hate Snap more. At least a .snap file can be mounted as a SquashFS and salvage what you can to run the program without snapd. Unrelated, but it is curious that some applications I have encountered depended on some proprietary library. To the bin it went. :D

johnisgood 6y ago

If I wanted spyware, I would just install Windows 10, really. Screw Canonical.