19 ms·

From the linked announcement: https://blog.linuxmint.com/?p=3906 https://blog.linuxmint.com/?p=3906 > Applications in this store cannot be patched, or pinned.

From the linked announcement: https://blog.linuxmint.com/?p=3906 https://blog.linuxmint.com/?p=3906 > 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. This is a great summary of why people rightfully feel nervous about Snap. People run linux because they want visibility and control into what is happening on their systems. Canonical seems to want to take away that visibility and control from their users.

ncr100 6y ago
Is there no way to sandbox these packages - "have you cake and eat it too?" I'm a noob to modern Linux. Edit: Are snaps images? ...like containers? Edit 2: answer: > mounted dynamically by the host operating system, together with declarative metadata that is interpreted by the snap system to set up an appropriately shaped secure sandbox or container for that application
- solarkraft 6y ago
  The main (and better supported) competitor is Flatpak, which at least doesn't have the terrible marketing.
  - ncr100 6y ago
    Thank you - :) Reading about the cons of Snap now - "auto-updates cannot be turned off" - https://en.wikipedia.org/wiki/Snap_(package_manager) https://en.wikipedia.org/wiki/Snap_(package_manager)
    - nawgszy 6y ago
      Just what we all want on our production hosts.
      - entropicdrifter 6y ago
        Especially when they're being installed covertly through APT
    - _jal 6y ago
      Yep. One of many reasons they're banned in our shop. Even for client software it is bad - an app quitting out from under me because it wants to update is functionally equivalent to a crashing bug - but they're offering daemons this way, which is just insane. Who doesn't want all their containers randomly restarting because someone up the distro chain decided when your machine needed to upgrade? https://snapcraft.io/lxd https://snapcraft.io/lxd
      - tomponline 6y ago
        The containers do not restart when the snap package is updated.
      - tssva 6y ago
        If snap decides to update lxd on the nodes of your lxd cluster at the same time that a node has failed it is a CF. The cluster will not come up because your down node is now not the same version as the other cluster nodes.
      - Lorkki 6y ago
        > an app quitting out from under me because it wants to update This doesn't happen, at least on account of Snap. It's copy-on-write when it comes to updates, and whatever version you have running at the time of update will happily keep on running. I've been mildly confused by this a couple times, when I would end up with two different versions of VS Code running side by side, but the bright side was that my work wasn't interrupted. It incidentally also sidesteps all the problems that stem from libraries or configuration being updated under a running application, which can happen with Apt.
    - xet7 6y ago
      Auto-updates of all Snap packages can be turned off at /etc/hosts by adding a line: 127.0.0.1 api.snapcraft.io
      - bscphil 6y ago
        This is sort of like saying you can turn off auto-updates by leaving your Internet connection disabled - true, but missing the point that what people are primarily complaining about is having to adopt an adversarial relationship to the software they use.
  - superkuh 6y ago
    All containerization is just the fever to the sickness that is the futureshock from extremely fast rate of development of major libs like c++$year, glibc (no matter what they say about having stable endpoints), and the like. You can't run a program written today on the system repo libraries from 5 years ago. Containers try to mitigate this problem but like a fever they often end up making things worse.
    - zentiggr 6y ago
      I don't run any APT based distribution right now but I understand the issues... I think the biggest problem I see is Canonical developing what looks like a very useful tool but holding it proprietary. If Canonical provided the snap creation and hosting tools to the community I imagine it would be judged on its technical merits. As it is, I see more and more reports that Canonical is trying to gain more and more control and that's exactly what I don't like to see. Would have tried Ubuntu but they've poisoned that well. I'll have to recalculate.
      - xav0989 6y ago
        As far as I can tell, snapcraft[0], the tool that allows the creation of snaps is open-source and on github. However the hosting server-side code is closed source. [0]: https://github.com/snapcore/snapcraft https://github.com/snapcore/snapcraft
    - drewg123 6y ago
      Wouldn't it just be simpler to statically link apps then?
      - enriquto 6y ago
        Indeed! All this "packaging abstraction" stuff is ridiculously silly when you can simply distribute a static binary.
    - solarkraft 6y ago
      Do you see the fast development itself as a problem? I tend to see as the real issue that most package managers only allow one version of a package to be installed, leading to conflicts very quickly. The best known manager that does allow this is Nix, do you know of any more, maybe ways to get this working with "traditional" package managers (completely transitioning to Nix is would be quite hard, from my limited experience)?
  - AnIdiotOnTheNet 6y ago
    Depending on the qualities your after, AppImage is also really great. Advantages over Flatpak are that they are completely portable (you can store them anywhere and run them from anywhere), and they don't require a special runtime or package management infrastructure of any kind.
    - solarkraft 6y ago
      AppImages are basically (kind of) statically linked binaries. Not my favorite to install software since they're usually huge (500mb is not far out of the norm), but great for things that are hard to install, as they're pretty much guaranteed to work. I just wish there was a command line switch to stop it from wanting to install itself on my system (move the AppImage to /opt).
      - AnIdiotOnTheNet 6y ago
        I have never seen that behavior from an AppImage. I just mark them executable and run them and they do their thing. If there is a specific AppImage behaving this way then it is probably the fault of the author, and if all of them are doing it then I wonder if it is the behavior of something like appimaged?
- entropicdrifter 6y ago
  If you need this kind of packaging but want to retain freedom, just use an alternative solution like flatpak, which sandboxes from the get-go and lets you control what parts of your system the application can access
  - ncr100 6y ago
    Neat - "permissions that are defined by the maintainer of the Flatpak and can be controlled (added or removed) by users on their system" - https://en.wikipedia.org/wiki/Flatpak https://en.wikipedia.org/wiki/Flatpak I'm wondering now if Wikipedia would be appropriate to host a linux sandboxed app packaging comparison chart in the form of https://linuxhint.com/snap_vs_flatpak_vs_appimage/ https://linuxhint.com/snap_vs_flatpak_vs_appimage/ - and it would be extensible ...since Wikipedia.
  - DoofusOfDeath 6y ago
    > just use an alternative solution like flatpak Saying "just use an alternative" seems overly dismissive of the complications that entails. IIUC, the only options for that are (a) abandon Ubuntu, or (b) actively circumvent Ubuntu's software distribution infrastructure, reminiscent of dealing with Windows 10 forced updates. IMHO this somewhat erodes Ubuntu's value proposition.
    - zentiggr 6y ago
      I have a laptop that I'm planning on rebuilding from a failed NTFS/Win10 system to Linux something. Now I know it's not going to be Ubuntu or anything else derived from Canonical.
      - Endeavourist 6y ago
        Why not EndeavourOS? It's based on Arch Linux, with minimal numbers of external packages; quite unlike Manjaro actually. You can just treat it as a standard Arch install, and even use the ISO to boot with wi-fi drivers and all and install Arch plainly, without the non-wifi and other regrets. EndeavourOS is pretty great; I personally use it as a live-ISO (XFCE environment) and just install Arch from within the live EndeavourOS booted iso. Just throwing it out there.
- michaelmrose 6y ago
  Sandboxing addresses AN issue but does not address any of the issues discussed in this article. Also sandboxing and running apps under reduced permissions makes a lot of sense but should be seen as a tool to increase security not an answer outright as poorly used any tool can be less effective or even harmful. Historically locking down increasingly effectively often leads to impeding things the user actually wants to do which leads to apps asking for and granting permissions with the net effect of training users click yes to enable whatever the app wants to do. It ends up being not just a technical challenge but a psychological one as well and its less easily resolved once you start having to deal with real users.
- blablabla123 6y ago
  It seems to incorporate some novel ideas despite its obvious shortcomings. I also think that so far Linux distributions have done very poorly when it came to cross-distribution/forward/backward compatibility of packages. This is a non-issue for popular Opensource packages since they can be easily packaged by the distributors. But not so popular packages sometimes need to be installed in a hacky way when they are not available for the target distribution. Even worse when dealing with commercial software, it can happen that it degrades with each distribution update. Also I think that probably the package format will improve over time and add additional features, that would allow auditing for instance. Also with proper de-duplication (perhaps even on filesystem level) it should be possible to also deal with waste of space.
- ex_amazon_sde 6y ago
  You can easily create very strong sandboxes for daemons using unit files and packaging them as native OS packages.
jonquark 6y ago
I can see why Snap is like it is from Canonial's perspective - but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises [1] https://flathub.org/home https://flathub.org/home (Disclaimer: I'm talking in a personal capacity but the company I work for in my day job now owns Red Hat - I don't work on Linux Operating Systems).
- lawl 6y ago
  > but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises This is interesting, because the last few days I was actually working on packaging an application of mine as a snap/flatpak. From my PoV, they both have their fair share of issues. Snaps enforce a sandbox, which I think is actually a good idea, because the desktop security model is somewhat broken. If your application cannot run as a sandboxed app, you need to be granted special permissions by canonical after manual review (my app needs this), where they also discuss if they can make a new permission in a safe way for your usecase that everyone can use afterwards. On one hand this sucks because I need to ask canonical for permission to publish something, and there's no certainty that I will get these permissions as a nobody for a new app nobody ever heard of before. On the other hand, I think I like that they're doing something about the desktop security model. The next problem is, if this is denied, how do I ship updates? Provide a self updater? Easy to write, but if everyone does that, we can just go full windows and abandon package managers. Tell people to just curl | bash? That's not more secure than a potentially shady snap. But I do have to praise canonical for being very helpful in IRC and the forums for helping me debug issues and file bugs against snap stuff. Now flatpak on the other hand, just feels kinda weird to me. It sandboxes things, but every application can pretty much grant itself access to everything. This is a completely different philosophy, but if you rely on everyone tightly sandboxing their applications without granting themselves permissions for sandbox escape, I think something like landlock[0] (when it lands) or pledge is much more suited for this, and baked into the application. Then there is this weird thing where flatpaks force a runtime on you. My application is a statically linked go binary. But flatpaks pretty much want to force me to add an entire freedesktop suite as a dependency, as you simply cannot choose no runtime. (Community-)Support for building flatpaks? Pretty much non-existant. So yeah, the entire linux upstream-packaging situation is still quite depressing honestly. And with the time and energy I have invested into this by now, I could have written a simple but sufficient self-updater about 10 times over. [0]: https://landlock.io/ https://landlock.io/
curt15 6y ago
>You can’t audit them, hold them, modify them or even point snap to a different store. In particular, it's easy to inspect the sources for apt packages using "apt-get source". Snap seems to have no equivalent command.
- IshKebab 6y ago
  Sure because Snap is designed to be able to distribute closed source applications. Part of the reason Snap and Flatpak exist is that distributing binaries on Linux is an enormous pain.
  - wtetzner 6y ago
    So allow viewing sources for the open source packages. If sources aren't available, then the user can easily opt not to install the binary.
    - blablabla123 6y ago
      Still it's an improvement over the current situation. Using snap IMHO only makes sense with closed-source or Open-source software that you don't want to self-compile but at the same time there is only a package available for a different distribution. So a typical installation procedure might be to forcibly install it with dpkg while ignoring the dependencies which cannot be resolved automatically. (Or worse, convert rpm to deb and then install it...) Of course the source is still downloadable, on the other hand, reproducible builds are anyway far from standard. I would prefer snap any time over other more crude installation methods if compiling is not viable.
  - NicolaiS 6y ago
    > distributing binaries on Linux is an enormous pain. It doesn't have to. Packaging using FPM [0] allows many targets (deb, rpm, etc) and using ELF2deb [1] (shameless plug) allows packaging any files to a .deb with no effort. [0] https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm [1] https://github.com/NicolaiSoeborg/ELF2deb https://github.com/NicolaiSoeborg/ELF2deb
craftinator 6y ago
All that, and it takes Ubuntu's default calculator program 4 full wall clock seconds to open on my laptop. Nothing grows in this desert.
simion314 6y ago
But Mint are too lazy to build their own packages so they use Ubuntu binaries that are installed as root, this is IMO a PR move and a hypocrisy, if you don't trust Canonical don't use Mint use Debian or some distribution that has the capacity to host and build their binaries.
- Daishiman 6y ago
  As long as you can audit the source and build chain what's the problem?
  - simion314 6y ago
    >As long as you can audit the source and build chain what's the problem? As long as Linux Mint developers are not doing that how it helps you? you don't trust Canonical binaries but you trust the deb binaries, you could be honest and claim that you don't like snap but you still trust the deb binaries.
    - Daishiman 6y ago
      The point isn't that the devs are the ones doing the auditing, even though pretty much everything that lives in DEB and RPM repos has maintainers which do. The point is that you can audit without having to depend on a third party. Nobody's claiming audits are free or that they're assumed. The point is that you have the option to choose to trust as much or as little of the build chain, from the compiler to the target code to the artifacts.
      - simion314 6y ago
        let me clear some things up and tell me if I am wrong, link me to the correction and I will apologize. - Mint uses Ubuntu repositories - Canonical pushes the changes they want into this repos, this changes are probably done by scripts that build source code on Canonical servers. - the Ubuntu repos also contain binary blobs - when a Mint user does an update he gets the binary directly from Canonical servers, there is no Mint dev or Mint script that does any check to see if for example the evil Canonical modified the NVIDIA driver and added even more evil in it then already is Now explain to me if all the above is true why would someone that does not trust Canonical would use Mint? There is no safety checks to prevent evil Canonical people do evil things. My conclusion is if you don't trust Canonical don't use Mint. Maybe Mint is working on addressing this and soon we will see an PR campaign that announces they are finally able to self host but until then I would stop the hypocrisy about not trusting Canonical. (Btw there are many smaller distros that can host their own repos, not sure why Mint is not doing it)
red_admiral 6y ago
I wonder how hard it would be, in theory, to write an open-source "cracked" version of snap that lets you do these things.
- commoner 6y ago
  The Snap server is closed source, so this would require building an open source Snap server as well. At this point, it would be much simpler to use Flatpak or some other solution.
  - esclerofilo 6y ago
    I hate snap as much as anyone, but it may not be as hard as you think: <https://ubuntu.com/blog/howto-host-your-own-snap-store> https://ubuntu.com/blog/howto-host-your-own-snap-store>
    - commoner 6y ago
      The difficult part is maintaining compatibility with snapd. > snapstore was a minimalist example of a "store" for snaps, but is not compatible with the current snapd implementation. As a result I have removed the contents here to avoid further confusion. https://github.com/noise/snapstore/ https://github.com/noise/snapstore/
- jhasse 6y ago
  Why not simply use Flatpak instead?
rlpb 6y ago
> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them... I think it should be noted that this generally applies to the addition of "third party apt repositories" in general, use of which is the problem that snaps fix[1] Some snaps are built from Free Software and reproducible sources, as are some third party apt repositories. In other words, if this criticism bothers you, then you should never install from any third party apt repositories ever. If some are acceptable to you, then so should some snaps. If you don't want to use third party software ever, then you can still use Ubuntu without snaps. [1] Third party apt repositories often break users' systems.
- pdonis 6y ago
  > if this criticism bothers you, then you should never install from any third party apt repositories ever. This does not follow at all. Third-party apt repositories work just like Ubuntu's apt repositories; you have just as much ability to audit, hold, pin, etc. in both cases. If there is a difference in reliability (software from third-party repos is more likely to break your system--and, btw, software from Canonical's repos has also broken systems in the past, so "avoid third party repos" is not a guaranteed way to avoid software breaking your system), using snaps to install third-party software instead of third-party repos does not fix that problem: the third-party provider is still just as unreliable as before and their software is just as likely to do something stupid.
  - giovannibajo1 6y ago
    Third-party apt repositories are a security nightmare: you are giving a third party unrestricted semi-silent root access to your computer. I can trust my distro provider with this, but it should be strongly discouraged for third-parties. Instead, installing PPAs to get updated builds of standard packages seems considered “normal”. At least, this doesn’t hold true for snaps.
    - pdonis 6y ago
      > I can trust my distro provider with this, but it should be strongly discouraged for third-parties. Again, it all depends on how much you trust the third party compared to how much you trust your distro provider. I don't have many third party PPAs installed on my computer because there aren't many third parties I trust that much. But there aren't zero either. Also, a big part of my trust of my distro provider is based on having source code forced to be open, and another big part is based on them not doing things behind my back. Snaps significantly erode both of these aspects of trust.
danudey 6y ago
From an IT perspective: I can set up an internal APT mirror for my users, servers, test systems, etc., but I can't set up an internal snap mirror as far as I can tell. This means that despite having an internal repo that I can whitelist, some package installations will now arbitrarily require internet access. I can no longer install chromium on a system without access to the internet, and package installation will fail as a result. I'd rather have an older version than a snap version, personally, but better would be two packages which Provides: the same chromium-browser, chromium and chromium-snap. The most irritating thing here is that they're using a package distribution system which handles dependencies and updates flawlessly, and has for decades, and using it to install things using a package system which does not solve those problems, and instead ships multiple copies of multiple libraries and applications, which run slower, ignoring any settings I have in APT. So far, it's a maintenance nightmare, and I loathe it.
- loopz 6y ago
  Snap can't seem to access my mounts. They're not very special mounts, but it happens in linux that you mount something, but snap just won't access. That made "no-go" a no-brainer.
  - personalcompute 6y ago
    I have the same problem. Snaps are confined to only files within $HOME. I keep almost all data under /media/ and this caused snaps to be mostly unusable for me, at least unusable for productivity apps where I need to process data. Some apps though are self contained, e.g. Spotify, for example, works fine for me as a snap. The limitation stems from a design problem, details at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706 https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706.
    - silon42 6y ago
      Yup. There needs to be considerable work to integrate snaps from completely sandboxed (no access to file system/network/hardware), to giving them controlled access to some resources, managed/monitored by root and/or user.
paulcarroty 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. 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. Short version: Canonical does classic vendor lock-in with his Snap Store. I'm pretty sure 99.9% HN users knows what it means :)
arexxbifs 6y ago
"Linux on the desktop" is apparently a lot like having sex in a greenhouse: fucking close to Windows.
heavyset_go 6y ago
My favorite anecdote about Snap is the development team's opinion when it comes to users wishing to relocate their ~/snap directory elsewhere. It's a commonly requested feature and being able to move it would follow the Freedesktop.org spec, but the developers don't care.
- etskinner 6y ago
  What's stopping someone from doing: $ ln -s /somewhere-else ~/snap
  - sascha_sl 6y ago
    bind mounts
  - jhasse 6y ago
    ~/snap would still exist then
  - hannasanarion 6y ago
    The problem isn't that the folder exists, the problem is that software is being installed in a non-hidden folder in the home directory. That's supposed to be a space for user files, not system software. If anything has to be installed in the home folder for some reason, it is supposed to go into .local, so the user doesn't see it among their documents and photos.
    - msclrhd 6y ago
      I've allocated a 5GiB partition to /home on my SSD, as it does not need to be bigger. I don't want it filling up with software or other things like ivy/maven caches.
- jrockway 6y ago
  Just hack your ls binary to not show the directory ;)
  - 6y ago
Quekid5 6y ago
You absolutely nailed it and this is why -- if I have any say in this (and I do) -- we will be moving away from Ubuntu. It's a completely insane stance for server systems. (I believe it's still possible to run server systems without snaps with various "workarounds" etc, but we can feel which way the wind is blowing...)
- jillesvangurp 6y ago
  You'd use docker instead of snaps on a server typically. Snaps are completely redundant there.
  - Quekid5 6y ago
    I personally would avoid docker, but 'containers', yes. > Snaps are completely redundant there. Yes, they certainly are but it seems to be harder and harder to get rid of snapd. It's probably not going to be an actual issue for Focal, but it's about this trend... Maybe Canonical will see sense -- who knows? Meanwhile, I do have to at least have a broad plan for the next 2-5 years, so...
- dorfsmay 6y ago
  Have you picked which distro yet?
  - Quekid5 6y ago
    Not too seriously, but it kind of depends on the project which $OTHER_DISTRO we'll go with, I think. Debian stable is an obvious choice for projects that don't rely on too much "new stuff" because we already have a lot of stuff that uses APT, deb repositories, etc. Otherwise, probably CentOS/RHEL for those situations that are just ultra-averse to incremental change and prefer a HUGE change once every 5-10 years. I think we might become a bit more adventurous and move to e.g. NixOS for "newer" projects. That's probably going to have to be trialed for a few projects before we go all in on it, but it seems really nice for servers (and dev machines for that matter), but it'll be interesting to see if you have to truly go all in to reap the benefits. (The worry here would be the amount of upstream 'support' in terms of manpower to bring in security updates, etc.). (I'm also vaguely aware of SuSE, but I only spent a very brief period of time with it about 10-15 years ago and don't really remember any distinctive features either way. Which is kinda weird, because it seems to be known as the 'popular in Europe' distro?)
Barrin92 6y ago
>People run linux because they want visibility and control into what is happening on their systems. Canonical seems to want to take away that visibility and control from their users. tbh I just run linux because I want a good dev machine and I personally don't care if canonical abstracts updating software away, as far as I'm concerned they can keep everything up to date and do their thing, for me that's a plus for snaps, I generally find them pleasant to use. In my experience people on HN in particular tend to vastly overestimate how much people value control vs features/abstracting routine tasks away.
MR4D 6y ago
Your link just convinced me to switch from Ubuntu. Thank you!
musicale 6y ago
I kind of hate snap. I thought the flatpak idea was OK but snap just feels intrusive.
MisterTea 6y ago
> Canonical seems to want to take away that visibility and control from their users. The Microsoft way: over-automated operating system DE's which attempt to make the OS appear user friendly yet create one headache after another. They suffer from massive interconnected webs of program state and logic which fails leaving you with the only sane option of rebooting. The more automation the vendor inserts the less transparency and control you have.
derefr 6y ago
> People run linux because they want visibility and control into what is happening on their systems. I mean, not really? Or rather, that's not the only reason, or the main reason for many users. Many people just want to use a FOSS OS, for the reason that any buggy component can be forked, fixed, and PRed, which—if you're an IT organization yourself—often means far less turnaround time than waiting for the appropriate vendor to fix the problem for you. Honestly, I'd be fine using Windows Server or some other "cathedral" OS, if I could fork/fix/PR its components. I want a stable operational substrate for my app that's quick to fix in an emergency; I don't care whether it's made out of tiny shell-scripts or huge C libraries, as long as it gives me that property. In that perspective, snap seems fine (you can still fork/fix/PR a snap) just like Docker images are fine, or systemd is fine. Maybe, in the end, I'm more of a BSD person than a Linux person. I mostly favor Linux installs for the hardware compatibility and performance, not because it really fits my philosophy.

ncr100 6y ago

Is there no way to sandbox these packages - "have you cake and eat it too?" I'm a noob to modern Linux. Edit: Are snaps images? ...like containers? Edit 2: answer: > mounted dynamically by the host operating system, together with declarative metadata that is interpreted by the snap system to set up an appropriately shaped secure sandbox or container for that application

solarkraft 6y ago
The main (and better supported) competitor is Flatpak, which at least doesn't have the terrible marketing.
- ncr100 6y ago
  Thank you - :) Reading about the cons of Snap now - "auto-updates cannot be turned off" - https://en.wikipedia.org/wiki/Snap_(package_manager) https://en.wikipedia.org/wiki/Snap_(package_manager)
  - nawgszy 6y ago
    Just what we all want on our production hosts.
    - entropicdrifter 6y ago
      Especially when they're being installed covertly through APT
  - _jal 6y ago
    Yep. One of many reasons they're banned in our shop. Even for client software it is bad - an app quitting out from under me because it wants to update is functionally equivalent to a crashing bug - but they're offering daemons this way, which is just insane. Who doesn't want all their containers randomly restarting because someone up the distro chain decided when your machine needed to upgrade? https://snapcraft.io/lxd https://snapcraft.io/lxd
    - tomponline 6y ago
      The containers do not restart when the snap package is updated.
    - tssva 6y ago
      If snap decides to update lxd on the nodes of your lxd cluster at the same time that a node has failed it is a CF. The cluster will not come up because your down node is now not the same version as the other cluster nodes.
    - Lorkki 6y ago
      > an app quitting out from under me because it wants to update This doesn't happen, at least on account of Snap. It's copy-on-write when it comes to updates, and whatever version you have running at the time of update will happily keep on running. I've been mildly confused by this a couple times, when I would end up with two different versions of VS Code running side by side, but the bright side was that my work wasn't interrupted. It incidentally also sidesteps all the problems that stem from libraries or configuration being updated under a running application, which can happen with Apt.
  - xet7 6y ago
    Auto-updates of all Snap packages can be turned off at /etc/hosts by adding a line: 127.0.0.1 api.snapcraft.io
    - bscphil 6y ago
      This is sort of like saying you can turn off auto-updates by leaving your Internet connection disabled - true, but missing the point that what people are primarily complaining about is having to adopt an adversarial relationship to the software they use.
- superkuh 6y ago
  All containerization is just the fever to the sickness that is the futureshock from extremely fast rate of development of major libs like c++$year, glibc (no matter what they say about having stable endpoints), and the like. You can't run a program written today on the system repo libraries from 5 years ago. Containers try to mitigate this problem but like a fever they often end up making things worse.
  - zentiggr 6y ago
    I don't run any APT based distribution right now but I understand the issues... I think the biggest problem I see is Canonical developing what looks like a very useful tool but holding it proprietary. If Canonical provided the snap creation and hosting tools to the community I imagine it would be judged on its technical merits. As it is, I see more and more reports that Canonical is trying to gain more and more control and that's exactly what I don't like to see. Would have tried Ubuntu but they've poisoned that well. I'll have to recalculate.
    - xav0989 6y ago
      As far as I can tell, snapcraft[0], the tool that allows the creation of snaps is open-source and on github. However the hosting server-side code is closed source. [0]: https://github.com/snapcore/snapcraft https://github.com/snapcore/snapcraft
  - drewg123 6y ago
    Wouldn't it just be simpler to statically link apps then?
    - enriquto 6y ago
      Indeed! All this "packaging abstraction" stuff is ridiculously silly when you can simply distribute a static binary.
  - solarkraft 6y ago
    Do you see the fast development itself as a problem? I tend to see as the real issue that most package managers only allow one version of a package to be installed, leading to conflicts very quickly. The best known manager that does allow this is Nix, do you know of any more, maybe ways to get this working with "traditional" package managers (completely transitioning to Nix is would be quite hard, from my limited experience)?
- AnIdiotOnTheNet 6y ago
  Depending on the qualities your after, AppImage is also really great. Advantages over Flatpak are that they are completely portable (you can store them anywhere and run them from anywhere), and they don't require a special runtime or package management infrastructure of any kind.
  - solarkraft 6y ago
    AppImages are basically (kind of) statically linked binaries. Not my favorite to install software since they're usually huge (500mb is not far out of the norm), but great for things that are hard to install, as they're pretty much guaranteed to work. I just wish there was a command line switch to stop it from wanting to install itself on my system (move the AppImage to /opt).
    - AnIdiotOnTheNet 6y ago
      I have never seen that behavior from an AppImage. I just mark them executable and run them and they do their thing. If there is a specific AppImage behaving this way then it is probably the fault of the author, and if all of them are doing it then I wonder if it is the behavior of something like appimaged?
entropicdrifter 6y ago
If you need this kind of packaging but want to retain freedom, just use an alternative solution like flatpak, which sandboxes from the get-go and lets you control what parts of your system the application can access
- ncr100 6y ago
  Neat - "permissions that are defined by the maintainer of the Flatpak and can be controlled (added or removed) by users on their system" - https://en.wikipedia.org/wiki/Flatpak https://en.wikipedia.org/wiki/Flatpak I'm wondering now if Wikipedia would be appropriate to host a linux sandboxed app packaging comparison chart in the form of https://linuxhint.com/snap_vs_flatpak_vs_appimage/ https://linuxhint.com/snap_vs_flatpak_vs_appimage/ - and it would be extensible ...since Wikipedia.
- DoofusOfDeath 6y ago
  > just use an alternative solution like flatpak Saying "just use an alternative" seems overly dismissive of the complications that entails. IIUC, the only options for that are (a) abandon Ubuntu, or (b) actively circumvent Ubuntu's software distribution infrastructure, reminiscent of dealing with Windows 10 forced updates. IMHO this somewhat erodes Ubuntu's value proposition.
  - zentiggr 6y ago
    I have a laptop that I'm planning on rebuilding from a failed NTFS/Win10 system to Linux something. Now I know it's not going to be Ubuntu or anything else derived from Canonical.
    - Endeavourist 6y ago
      Why not EndeavourOS? It's based on Arch Linux, with minimal numbers of external packages; quite unlike Manjaro actually. You can just treat it as a standard Arch install, and even use the ISO to boot with wi-fi drivers and all and install Arch plainly, without the non-wifi and other regrets. EndeavourOS is pretty great; I personally use it as a live-ISO (XFCE environment) and just install Arch from within the live EndeavourOS booted iso. Just throwing it out there.
michaelmrose 6y ago
Sandboxing addresses AN issue but does not address any of the issues discussed in this article. Also sandboxing and running apps under reduced permissions makes a lot of sense but should be seen as a tool to increase security not an answer outright as poorly used any tool can be less effective or even harmful. Historically locking down increasingly effectively often leads to impeding things the user actually wants to do which leads to apps asking for and granting permissions with the net effect of training users click yes to enable whatever the app wants to do. It ends up being not just a technical challenge but a psychological one as well and its less easily resolved once you start having to deal with real users.
blablabla123 6y ago
It seems to incorporate some novel ideas despite its obvious shortcomings. I also think that so far Linux distributions have done very poorly when it came to cross-distribution/forward/backward compatibility of packages. This is a non-issue for popular Opensource packages since they can be easily packaged by the distributors. But not so popular packages sometimes need to be installed in a hacky way when they are not available for the target distribution. Even worse when dealing with commercial software, it can happen that it degrades with each distribution update. Also I think that probably the package format will improve over time and add additional features, that would allow auditing for instance. Also with proper de-duplication (perhaps even on filesystem level) it should be possible to also deal with waste of space.
ex_amazon_sde 6y ago
You can easily create very strong sandboxes for daemons using unit files and packaging them as native OS packages.

jonquark 6y ago

I can see why Snap is like it is from Canonial's perspective - but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises [1] https://flathub.org/home https://flathub.org/home (Disclaimer: I'm talking in a personal capacity but the company I work for in my day job now owns Red Hat - I don't work on Linux Operating Systems).

lawl 6y ago
> but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises This is interesting, because the last few days I was actually working on packaging an application of mine as a snap/flatpak. From my PoV, they both have their fair share of issues. Snaps enforce a sandbox, which I think is actually a good idea, because the desktop security model is somewhat broken. If your application cannot run as a sandboxed app, you need to be granted special permissions by canonical after manual review (my app needs this), where they also discuss if they can make a new permission in a safe way for your usecase that everyone can use afterwards. On one hand this sucks because I need to ask canonical for permission to publish something, and there's no certainty that I will get these permissions as a nobody for a new app nobody ever heard of before. On the other hand, I think I like that they're doing something about the desktop security model. The next problem is, if this is denied, how do I ship updates? Provide a self updater? Easy to write, but if everyone does that, we can just go full windows and abandon package managers. Tell people to just curl | bash? That's not more secure than a potentially shady snap. But I do have to praise canonical for being very helpful in IRC and the forums for helping me debug issues and file bugs against snap stuff. Now flatpak on the other hand, just feels kinda weird to me. It sandboxes things, but every application can pretty much grant itself access to everything. This is a completely different philosophy, but if you rely on everyone tightly sandboxing their applications without granting themselves permissions for sandbox escape, I think something like landlock[0] (when it lands) or pledge is much more suited for this, and baked into the application. Then there is this weird thing where flatpaks force a runtime on you. My application is a statically linked go binary. But flatpaks pretty much want to force me to add an entire freedesktop suite as a dependency, as you simply cannot choose no runtime. (Community-)Support for building flatpaks? Pretty much non-existant. So yeah, the entire linux upstream-packaging situation is still quite depressing honestly. And with the time and energy I have invested into this by now, I could have written a simple but sufficient self-updater about 10 times over. [0]: https://landlock.io/ https://landlock.io/

curt15 6y ago

>You can’t audit them, hold them, modify them or even point snap to a different store. In particular, it's easy to inspect the sources for apt packages using "apt-get source". Snap seems to have no equivalent command.

IshKebab 6y ago
Sure because Snap is designed to be able to distribute closed source applications. Part of the reason Snap and Flatpak exist is that distributing binaries on Linux is an enormous pain.
- wtetzner 6y ago
  So allow viewing sources for the open source packages. If sources aren't available, then the user can easily opt not to install the binary.
  - blablabla123 6y ago
    Still it's an improvement over the current situation. Using snap IMHO only makes sense with closed-source or Open-source software that you don't want to self-compile but at the same time there is only a package available for a different distribution. So a typical installation procedure might be to forcibly install it with dpkg while ignoring the dependencies which cannot be resolved automatically. (Or worse, convert rpm to deb and then install it...) Of course the source is still downloadable, on the other hand, reproducible builds are anyway far from standard. I would prefer snap any time over other more crude installation methods if compiling is not viable.
- NicolaiS 6y ago
  > distributing binaries on Linux is an enormous pain. It doesn't have to. Packaging using FPM [0] allows many targets (deb, rpm, etc) and using ELF2deb [1] (shameless plug) allows packaging any files to a .deb with no effort. [0] https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm [1] https://github.com/NicolaiSoeborg/ELF2deb https://github.com/NicolaiSoeborg/ELF2deb

craftinator 6y ago

All that, and it takes Ubuntu's default calculator program 4 full wall clock seconds to open on my laptop. Nothing grows in this desert.

simion314 6y ago

But Mint are too lazy to build their own packages so they use Ubuntu binaries that are installed as root, this is IMO a PR move and a hypocrisy, if you don't trust Canonical don't use Mint use Debian or some distribution that has the capacity to host and build their binaries.

Daishiman 6y ago
As long as you can audit the source and build chain what's the problem?
- simion314 6y ago
  >As long as you can audit the source and build chain what's the problem? As long as Linux Mint developers are not doing that how it helps you? you don't trust Canonical binaries but you trust the deb binaries, you could be honest and claim that you don't like snap but you still trust the deb binaries.
  - Daishiman 6y ago
    The point isn't that the devs are the ones doing the auditing, even though pretty much everything that lives in DEB and RPM repos has maintainers which do. The point is that you can audit without having to depend on a third party. Nobody's claiming audits are free or that they're assumed. The point is that you have the option to choose to trust as much or as little of the build chain, from the compiler to the target code to the artifacts.
    - simion314 6y ago
      let me clear some things up and tell me if I am wrong, link me to the correction and I will apologize. - Mint uses Ubuntu repositories - Canonical pushes the changes they want into this repos, this changes are probably done by scripts that build source code on Canonical servers. - the Ubuntu repos also contain binary blobs - when a Mint user does an update he gets the binary directly from Canonical servers, there is no Mint dev or Mint script that does any check to see if for example the evil Canonical modified the NVIDIA driver and added even more evil in it then already is Now explain to me if all the above is true why would someone that does not trust Canonical would use Mint? There is no safety checks to prevent evil Canonical people do evil things. My conclusion is if you don't trust Canonical don't use Mint. Maybe Mint is working on addressing this and soon we will see an PR campaign that announces they are finally able to self host but until then I would stop the hypocrisy about not trusting Canonical. (Btw there are many smaller distros that can host their own repos, not sure why Mint is not doing it)

red_admiral 6y ago

I wonder how hard it would be, in theory, to write an open-source "cracked" version of snap that lets you do these things.

commoner 6y ago
The Snap server is closed source, so this would require building an open source Snap server as well. At this point, it would be much simpler to use Flatpak or some other solution.
- esclerofilo 6y ago
  I hate snap as much as anyone, but it may not be as hard as you think: <https://ubuntu.com/blog/howto-host-your-own-snap-store> https://ubuntu.com/blog/howto-host-your-own-snap-store>
  - commoner 6y ago
    The difficult part is maintaining compatibility with snapd. > snapstore was a minimalist example of a "store" for snaps, but is not compatible with the current snapd implementation. As a result I have removed the contents here to avoid further confusion. https://github.com/noise/snapstore/ https://github.com/noise/snapstore/
jhasse 6y ago
Why not simply use Flatpak instead?

rlpb 6y ago

> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them... I think it should be noted that this generally applies to the addition of "third party apt repositories" in general, use of which is the problem that snaps fix[1] Some snaps are built from Free Software and reproducible sources, as are some third party apt repositories. In other words, if this criticism bothers you, then you should never install from any third party apt repositories ever. If some are acceptable to you, then so should some snaps. If you don't want to use third party software ever, then you can still use Ubuntu without snaps. [1] Third party apt repositories often break users' systems.

pdonis 6y ago
> if this criticism bothers you, then you should never install from any third party apt repositories ever. This does not follow at all. Third-party apt repositories work just like Ubuntu's apt repositories; you have just as much ability to audit, hold, pin, etc. in both cases. If there is a difference in reliability (software from third-party repos is more likely to break your system--and, btw, software from Canonical's repos has also broken systems in the past, so "avoid third party repos" is not a guaranteed way to avoid software breaking your system), using snaps to install third-party software instead of third-party repos does not fix that problem: the third-party provider is still just as unreliable as before and their software is just as likely to do something stupid.
- giovannibajo1 6y ago
  Third-party apt repositories are a security nightmare: you are giving a third party unrestricted semi-silent root access to your computer. I can trust my distro provider with this, but it should be strongly discouraged for third-parties. Instead, installing PPAs to get updated builds of standard packages seems considered “normal”. At least, this doesn’t hold true for snaps.
  - pdonis 6y ago
    > I can trust my distro provider with this, but it should be strongly discouraged for third-parties. Again, it all depends on how much you trust the third party compared to how much you trust your distro provider. I don't have many third party PPAs installed on my computer because there aren't many third parties I trust that much. But there aren't zero either. Also, a big part of my trust of my distro provider is based on having source code forced to be open, and another big part is based on them not doing things behind my back. Snaps significantly erode both of these aspects of trust.

danudey 6y ago

From an IT perspective: I can set up an internal APT mirror for my users, servers, test systems, etc., but I can't set up an internal snap mirror as far as I can tell. This means that despite having an internal repo that I can whitelist, some package installations will now arbitrarily require internet access. I can no longer install chromium on a system without access to the internet, and package installation will fail as a result. I'd rather have an older version than a snap version, personally, but better would be two packages which Provides: the same chromium-browser, chromium and chromium-snap. The most irritating thing here is that they're using a package distribution system which handles dependencies and updates flawlessly, and has for decades, and using it to install things using a package system which does not solve those problems, and instead ships multiple copies of multiple libraries and applications, which run slower, ignoring any settings I have in APT. So far, it's a maintenance nightmare, and I loathe it.

loopz 6y ago
Snap can't seem to access my mounts. They're not very special mounts, but it happens in linux that you mount something, but snap just won't access. That made "no-go" a no-brainer.
- personalcompute 6y ago
  I have the same problem. Snaps are confined to only files within $HOME. I keep almost all data under /media/ and this caused snaps to be mostly unusable for me, at least unusable for productivity apps where I need to process data. Some apps though are self contained, e.g. Spotify, for example, works fine for me as a snap. The limitation stems from a design problem, details at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706 https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706.
  - silon42 6y ago
    Yup. There needs to be considerable work to integrate snaps from completely sandboxed (no access to file system/network/hardware), to giving them controlled access to some resources, managed/monitored by root and/or user.

paulcarroty 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. 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. Short version: Canonical does classic vendor lock-in with his Snap Store. I'm pretty sure 99.9% HN users knows what it means :)

arexxbifs 6y ago

"Linux on the desktop" is apparently a lot like having sex in a greenhouse: fucking close to Windows.

heavyset_go 6y ago

My favorite anecdote about Snap is the development team's opinion when it comes to users wishing to relocate their ~/snap directory elsewhere. It's a commonly requested feature and being able to move it would follow the Freedesktop.org spec, but the developers don't care.

etskinner 6y ago
What's stopping someone from doing: $ ln -s /somewhere-else ~/snap
- sascha_sl 6y ago
  bind mounts
- jhasse 6y ago
  ~/snap would still exist then
- hannasanarion 6y ago
  The problem isn't that the folder exists, the problem is that software is being installed in a non-hidden folder in the home directory. That's supposed to be a space for user files, not system software. If anything has to be installed in the home folder for some reason, it is supposed to go into .local, so the user doesn't see it among their documents and photos.
  - msclrhd 6y ago
    I've allocated a 5GiB partition to /home on my SSD, as it does not need to be bigger. I don't want it filling up with software or other things like ivy/maven caches.
jrockway 6y ago
Just hack your ls binary to not show the directory ;)
- 6y ago

Quekid5 6y ago

You absolutely nailed it and this is why -- if I have any say in this (and I do) -- we will be moving away from Ubuntu. It's a completely insane stance for server systems. (I believe it's still possible to run server systems without snaps with various "workarounds" etc, but we can feel which way the wind is blowing...)

jillesvangurp 6y ago
You'd use docker instead of snaps on a server typically. Snaps are completely redundant there.
- Quekid5 6y ago
  I personally would avoid docker, but 'containers', yes. > Snaps are completely redundant there. Yes, they certainly are but it seems to be harder and harder to get rid of snapd. It's probably not going to be an actual issue for Focal, but it's about this trend... Maybe Canonical will see sense -- who knows? Meanwhile, I do have to at least have a broad plan for the next 2-5 years, so...
dorfsmay 6y ago
Have you picked which distro yet?
- Quekid5 6y ago
  Not too seriously, but it kind of depends on the project which $OTHER_DISTRO we'll go with, I think. Debian stable is an obvious choice for projects that don't rely on too much "new stuff" because we already have a lot of stuff that uses APT, deb repositories, etc. Otherwise, probably CentOS/RHEL for those situations that are just ultra-averse to incremental change and prefer a HUGE change once every 5-10 years. I think we might become a bit more adventurous and move to e.g. NixOS for "newer" projects. That's probably going to have to be trialed for a few projects before we go all in on it, but it seems really nice for servers (and dev machines for that matter), but it'll be interesting to see if you have to truly go all in to reap the benefits. (The worry here would be the amount of upstream 'support' in terms of manpower to bring in security updates, etc.). (I'm also vaguely aware of SuSE, but I only spent a very brief period of time with it about 10-15 years ago and don't really remember any distinctive features either way. Which is kinda weird, because it seems to be known as the 'popular in Europe' distro?)

Barrin92 6y ago

>People run linux because they want visibility and control into what is happening on their systems. Canonical seems to want to take away that visibility and control from their users. tbh I just run linux because I want a good dev machine and I personally don't care if canonical abstracts updating software away, as far as I'm concerned they can keep everything up to date and do their thing, for me that's a plus for snaps, I generally find them pleasant to use. In my experience people on HN in particular tend to vastly overestimate how much people value control vs features/abstracting routine tasks away.

MR4D 6y ago

Your link just convinced me to switch from Ubuntu. Thank you!

musicale 6y ago

I kind of hate snap. I thought the flatpak idea was OK but snap just feels intrusive.

MisterTea 6y ago

> Canonical seems to want to take away that visibility and control from their users. The Microsoft way: over-automated operating system DE's which attempt to make the OS appear user friendly yet create one headache after another. They suffer from massive interconnected webs of program state and logic which fails leaving you with the only sane option of rebooting. The more automation the vendor inserts the less transparency and control you have.

derefr 6y ago

> People run linux because they want visibility and control into what is happening on their systems. I mean, not really? Or rather, that's not the only reason, or the main reason for many users. Many people just want to use a FOSS OS, for the reason that any buggy component can be forked, fixed, and PRed, which—if you're an IT organization yourself—often means far less turnaround time than waiting for the appropriate vendor to fix the problem for you. Honestly, I'd be fine using Windows Server or some other "cathedral" OS, if I could fork/fix/PR its components. I want a stable operational substrate for my app that's quick to fix in an emergency; I don't care whether it's made out of tiny shell-scripts or huge C libraries, as long as it gives me that property. In that perspective, snap seems fine (you can still fork/fix/PR a snap) just like Docker images are fine, or systemd is fine. Maybe, in the end, I'm more of a BSD person than a Linux person. I mostly favor Linux installs for the hardware compatibility and performance, not because it really fits my philosophy.