1. 49
  1.  

  2. 15

    There are ways to prevent updates. We don’t tend to shout about it, because a core tenet of snaps is that machines don’t end up with old / insecure packages.

    You could for example snap download clion and then manually install it with snap install clion* --dangerous and it would absolutely never update. Not as clean as just installing and “pinning” but it is possible, does work and can be used on your system to hold a package at a particular revision.

    1. 5

      Is there a way to get onto a “security releases only” track?

      1. 2

        Publishers are free to utilize “tracks” to publish multiple major/minor versions available for the user to select from. In this case, the OP may have been able to use one of CLion’s many channels available would most likely have give them a stable security/bug fixes only track. Here you can see JetBrain’s maintains CLion releases/tracks all the way back to their 2017.3 release:

        ~$ snap info clion
        name:      clion
        summary:   A cross-platform IDE for C and C++
        publisher: jetbrains✓
        store-url: https://snapcraft.io/clion
        contact:   https://www.jetbrains.com/clion/
        license:   Proprietary
        description: |
          CLion is a cross-platform IDE which natively supports C and C++, libc++ and Boost. It offers
          instant navigation to a symbol's declaration or usages, code generation for
          constructors/destructors, operators and more. There are dozens of refactorings, code analysis
          (including Data Flow Analysis and Clang-Tidy integration) and integration with GDB and LLDB. CLion
          uses the well-known CMake build system, supports Google test, Boost.Test, and Catch unit testing.
          There is Doxygen for documenting the code, Valgrind Memcheck for memory profiling, and support for
          all the popular Version Control Systems, it can even provide a VIM-emulation mode via a plugin.
          
          CLion is available for a free 30-day evaluation.
          Monthly and yearly subscription options are available for companies and individual users. Find out
          more on https://www.jetbrains.com/clion/buy/
        snap-id: 6JBjLwyVchga4cOSDqhWJd9NgQfrTYam
        channels:
          latest/stable:    2020.2   2020-07-29 (123) 502MB classic
          latest/candidate: 2020.2   2020-07-29 (123) 502MB classic
          latest/beta:      2020.2   2020-07-29 (123) 502MB classic
          latest/edge:      2020.2   2020-07-29 (123) 502MB classic
          2020.2/stable:    2020.2   2020-07-29 (123) 502MB classic
          2020.2/candidate: 2020.2   2020-07-29 (123) 502MB classic
          2020.2/beta:      2020.2   2020-07-29 (123) 502MB classic
          2020.2/edge:      2020.2   2020-07-29 (123) 502MB classic
          2020.1/stable:    2020.1.3 2020-07-22 (121) 463MB classic
          2020.1/candidate: 2020.1.3 2020-07-22 (121) 463MB classic
          2020.1/beta:      2020.1.3 2020-07-22 (121) 463MB classic
          2020.1/edge:      2020.1.3 2020-07-22 (121) 463MB classic
          2019.3/stable:    2019.3.6 2020-05-06 (113) 460MB classic
          2019.3/candidate: 2019.3.6 2020-05-06 (113) 460MB classic
          2019.3/beta:      2019.3.6 2020-05-06 (113) 460MB classic
          2019.3/edge:      2019.3.6 2020-05-06 (113) 460MB classic
          2019.2/stable:    2019.2.5 2019-10-30  (92) 447MB classic
          2019.2/candidate: 2019.2.5 2019-10-30  (92) 447MB classic
          2019.2/beta:      2019.2.5 2019-10-30  (92) 447MB classic
          2019.2/edge:      2019.2.5 2019-10-30  (92) 447MB classic
          2019.1/stable:    2019.1.4 2019-05-30  (73) 386MB classic
          2019.1/candidate: 2019.1.4 2019-05-30  (73) 386MB classic
          2019.1/beta:      2019.1.4 2019-05-30  (73) 386MB classic
          2019.1/edge:      2019.1.4 2019-05-30  (73) 386MB classic
          2018.3/stable:    2018.3.4 2019-02-01  (61) 409MB classic
          2018.3/candidate: ↑                               
          2018.3/beta:      ↑                               
          2018.3/edge:      ↑                               
          2018.2/stable:    2018.2.7 2018-11-29  (55) 389MB classic
          2018.2/candidate: ↑                               
          2018.2/beta:      ↑                               
          2018.2/edge:      ↑                               
          2018.1/stable:    2018.1.7 2018-11-21  (52) 319MB classic
          2018.1/candidate: ↑                               
          2018.1/beta:      ↑                               
          2018.1/edge:      ↑                               
          2017.3/stable:    2017.3.5 2018-11-21  (51) 314MB classic
          2017.3/candidate: 2017.3.5 2018-11-21  (51) 314MB classic
          2017.3/beta:      2017.3.5 2018-11-21  (51) 314MB classic
          2017.3/edge:      2017.3.5 2018-11-21  (51) 314MB classic
        

        So if OP wanted to stick with a stable 2019.1 release, they may be able to snap install clion --channel 2019.1/stable --classic, or use snap refresh.

        Not all publishers take on the burden of doing this, but many that don’t want to break their users with major interface changes do :-)

    2. 9

      As someone who receives the notifications from a host intrusion detection system that looks for changes to system directories on a fleet of Ubuntu servers, Snap pisses me off. We use a couple of packages that are now only available via Snap, so it is always updating its package index files and so forth, and every once in a while it makes some change to its filesystem layout which breaks my carefully handcrafted change detection ruleset and I get deluged with notifications about unexpected edits to system directories.

      The fact that I had to carve out a bunch of exceptions to our security scans to stop looking for changes in Snap’s usual directories because otherwise it would produce so much noise as to make the scans useless means an intruder who’s aware of the situation could put their rootkit files in one of Snap’s directories and my HIDS would just ignore them. Hooray, added security!

      Granted, we could be using a better HIDS, but good lord, is it so much to ask for a system to not magically edit system stuff with no way to turn it off?

      Apparently yes. When I saw the “three-year-old thread” link in the article, I knew exactly what thread it was talking about. Requests for an off switch are summarily brushed off each time despite a steady stream of reports from people like OP who’ve had stuff suddenly break out from under them with no warning (sometimes in production environments).

      The direction Ubuntu seems to be going with this stuff is one of the reasons we will be evaluating moving to a different distro when it’s time to move off the current Ubuntu LTS version we’re running. Ubuntu on servers was nice while it lasted.

      1. 12

        This is the moment I removed all snaps:

        1.3G /snap/slack
        1.2G /snap/spotify
        1.9G /snap/vlc
        

        It’s difficult to understand how people are OK with this.

        1. 24

          You’re not looking at the on-disk footprint of the snaps. You’re peering inside (probably more than one) compressed loopback files at their contents.

          -rw------- 1 root root 145M Jul 15 10:04 /var/lib/snapd/snaps/slack_25.snap
          -rw------- 2 root root 164M Jun 15 00:09 /var/lib/snapd/snaps/spotify_41.snap
          -rw------- 2 root root 291M Jul 31 17:23 /var/lib/snapd/snaps/vlc_1700.snap
          

          Granted the vlc one is pretty bit, but it’s not 1.9GB big on disk.

          1. 4
            $ zstdcat /var/cache/pacman/pkg/vlc-3.0.11-1-x86_64.pkg.tar.zst|wc -c
            62464000
            

            59MB. That’s 20% the size of your snap. And that’s decompressed, compared with your compressed version. A fairer comparison of the on-disc footprint would be with per-file compression. If I extract that archive onto an fs with compression (zfs+lz4), it’s 35MB—nearly 10% of the snap.

            (Slack and spotify I have no interest in installing, but I expect vlc is representative.)

            1. 1

              Yeah, the vlc snap could do with some oprimisation, for sure.

              1. 1

                The vlc snap is a similar size to the others. Is there some reason to believe that other snaps aren’t also 10x larger than they need to be?

            2. 3

              Ah interesting. Still pretty huge, but certainly not 1.9GB huge :)

              (but still have no desire to use snaps)

            3. 1

              Woah, is it normal for snap to behave like this? It looks like these directories contain all old copies of apps or something?

              1. 7

                Snapd keeps an old version of each application around so that in the event that your update goes bad, you can snap revert and immediately go back to the previous revision. I don’t know if the OP tried this, but it would have allowed them to probably keep working a lot quicker.

            4. 11

              I see a fundamental disconnect here.

              Automatic updates are baked into snap’s DNA. If you didn’t want this, simply don’t install the snap.

              Choosing this medium to install your dev environment and then getting cranky when it does precisely what it was meant to do seems a bit unintentionally disingenuous to me.

              I’m not necessary arguing for the correctness of Canonical’s choices around snaps here, because I have mixed feelings about them myself, but they make it pretty clear at every available opportunity that this is how they work.

              On a more helpful note, have you tried setting the refresh.hold system wide configurable which you could set to an arbitrary date years in the future?

              1. 24

                There’s another part to the disconnect: Ubuntu is trying to replace the deb parts of (large parts of) its ecosystem with snap equivalents. Putting these two things together makes the picture pretty interesting. How are LTS releases supposed to work with this kind of setup? I’ve had bugfix releases of software introduce bugs that blocked my work. Not often, but it does happen.

                Operationally, I wish updates were always automatically-update-on-a-schedule-I-define, a la Patch Tuesday or something similar. That seems like the only possible sane option, but it seems tragically rare.

                1. 4

                  That’s interesting I’d only heard of them doing this with Chrome. What else are you referring to if you don’t mind my asking?

                  For sure there are going to be problems as this is absolutely a radical departure from traditional UNIX vendor app update strategies.

                  Their assertion is that the auto-update feature was a key blocker to bring third party vendors who otherwise wouldn’t even consider supporting the Ubuntu platform to do so.

                  I think there’s some value in that, but as you say there are definitely kinks to be worked out here. On the up side the Ubuntu folks are pretty good about engaging with the community. I’d suggest pinging Snapcraft or Alan Pope on Twitter. It’s not his job but he’s often good about taking the time to help people past snap difficulties.

                  1. 4

                    That’s interesting I’d only heard of them doing this with Chrome. What else are you referring to if you don’t mind my asking?

                    My main source is https://lobste.rs/s/9q0kta/linux_mint_drops_ubuntu_snap_packages, which links to https://lwn.net/Articles/825005/. Chromium seems to be the main program currently, but the LWN article mentions work ongoing to apply it to other things like gnome-software. Seems safe to assume that the trend is going to continue.

                    Now that I think of it, I think part of the disconnect is that vendors think of their software as an end-product that nothing else depends on, so Slack or Spotify or whatever can update their own little worlds without affecting anything else. In the real world however, people script things to download stuff from Slack or ask Spotify to do things, and so those applications changing can break others’ functionality. Even non-techies do this, mentally; how many people have complained to tech support when a silent, undesired application update “moved that damn button” and broke their workflow?

                    1. 2

                      I would urge you to be sure to get both sides of the story on the Mint snap amputation.

                      I don’t have any issue with the decision itself per se but the way they handled it was IMO very unfortunate and unprofessional.

                      Specifically, the Ubuntu folks said they were totally willing to work with Mint to accomplish the removal in a clean way that makes sense technically, but that they were never approached.

                      IMO when you choose to base your Linux distribution on an upstream distro, you agree to abide by the technical decisions that upstreeam makes, or at least to work with them in evolving your remix/flavor in a way that makes sense. None of that happened here.

                    2. 3

                      LXD is another example

                      1. 1

                        Yes. The differences betwen Docker and LXD are interesting. Docker provides a convenient packaging format and allows for layering of components to create application stacks.

                        LXD seems to want you to start out with a single image and seems to have better / more / deeper integration with system services like networking.

                        I’d love to see someone do an in depth technical comparison of thw two technologies.

                    3. 1

                      Ubuntu is trying to replace the deb parts of (large parts of) its ecosystem with snap equivalents.

                      I’ve only seen evidence of this in the packages that are particularly challenging to maintain as debs due to the way particular upstreams operate. Browsers are an example where security backports aren’t feasible so the debs that have been shipped by most distributions have for years been “fat” anyway. Snaps are mainly solving the problems of IoT device updates, third party (both Free and proprietary) software distribution directly to users and the areas where debs are a poor fit, such as shipping wholesale featureful updates to users such as with web browsers. The traditional deb parts are not affected.

                      Operationally, I wish updates were always automatically-update-on-a-schedule-I-define, a la Patch Tuesday or something similar.

                      You can configure snaps to do that that: https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--controlling-updates

                      Disclosure: I’m a Canonical employee and Ubuntu developer (and a Debian developer, if we’re going there). I’m not involved in snap architecture at Canonical (though I do maintain some snaps as I do debs in Debian!).

                    4. 7

                      Choosing this medium to install your dev environment and then getting cranky when it does precisely what it was meant to do seems a bit unintentionally disingenuous to me.

                      Agree. So what I say below doesn’t apply to the situation in the article.

                      but they make it pretty clear at every available opportunity that this is how they work.

                      They may make it clear how they work but they don’t make pretty clear when you are installing a snap. Starting Ubuntu 20.04 they’ve started installing snaps when you install a Deb

                      https://blog.linuxmint.com/?p=3906

                      1. 7

                        The reason the snap is installed is because the chromium browser moved to a snap so we could iterate faster and consume fewer developer resources packaging a non-default web browser for multiple releases. If we didn’t have the deb to snap migration in 19.10 (and 20.04) then users upgrading from 19.04 to 19.10 or from 18.04 to 20.04 would lose their browser.

                        I wrote a blog post 6 months ago about why this was done. https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-transition

                        We decided at the time not to punch people in the face during the upgrade and make them choose “Do you want to keep your browser, by migrating to the snap?” because those kind of mid-upgrade dialogs are pretty awful for end users. Generally the vast majority of the audience don’t actually care what packaging scheme is used. They just want to click the browser icon and it open.

                        Yes, we could have communicated it better. We’re working on improving it for the 20.04.1 update which is due next week. We certainly do listen to the feedback we get.

                        1. 2

                          We decided at the time not to punch people in the face during the upgrade and make them choose “Do you want to keep your browser, by migrating to the snap?”

                          You could use the motd announcements to give people ample notice.

                          1. 3

                            Good idea, but most normals don’t ever see motd.

                            1. 1

                              normals? Normies perhaps?

                        2. 4

                          Please see my answer above to icefox’s assertion along the same lines. This is only for Chromium, and there are good reasons behind that choice (They were spending vast amounts of engineering time JUST on chromium).

                          As I said in that response, IMO Linux Mint is very much in the wrong here, and has handled the situation abysmally. They could have enacted the removal of snaps/snapd in a much cleaner way without all the drama, and they chose not to do that.

                          Unfortunate.

                          1. 5

                            Please see my answer above to icefox’s assertion along the same lines.

                            Yeah, I saw it after I had posted this comment.

                            This is only for Chromium, and there are good reasons behind that choice

                            You are conflating two separate things. There may be good reasons™ behind packing Chromium as a snap only. There is no good reason to do so behind the users back. If one uses apt to install something one most certainly doesn’t expect to be installing a snap.

                            What you chose to call ‘drama’ is a political stance. The issue was not “to accomplish the removal in a clean way”. It was “This breaks one of the major worries many people had when Snap was announced and a promise from its developers that it would never replace APT.”. You may not like or agree with that position but there is nothing wrong with that.

                            Also it is disingenuous to think this will stop at Chromium. Chromium is just for testing the waters.

                        3. 5

                          Refresh.hold is stated in the article, it does not honor dates further than 60 days in the future.

                          1. 8

                            Did you try snap revert?

                            e.g.

                            # What version do I have installed?
                            $ snap info caprine | tail -n 1
                            installed:          2.47.0            (37) 66MB -
                            # Is there a pending update? (yes)
                            $ snap refresh --list | grep caprine
                            caprine             2.48.0                     38     sindresorhus  -
                            # Refresh blocked while app is running (experimental setting, should land "soon")
                            $ snap refresh caprine
                            error: cannot refresh "caprine": snap "caprine" has running apps (caprine)
                            # Let's kill the app
                            $ sudo killall caprine
                            # Try refreshing again
                            $ snap refresh caprine
                            caprine 2.48.0 from Sindre Sorhus (sindresorhus) refreshed
                            # Let's revert it because the update was terrible
                            $ snap revert caprine
                            caprine reverted to 2.47.0
                            

                            I appreciate you’re “burned” by this and will likely switch to Mint, so this information may be academic, but for others stumbling on this thread it may be handy. Hope Linux Mint works out for you.

                            1. 3

                              I’d not expect the Allen Pope to respond, you only exist in my podcasts :). How cool!

                              Now on point, also responding to the revert comment earlier. I did find that, but my point is about not being able to disable updates, not about not being able to rollback. Rolling back would not have been necessary if I could have done the update manually in two weeks, after which the plugins of the IDE would probably have been updated as well. I do however appreciate the option to rollback.

                              You also state that there are ways to disable updates and give the example of sideloading an application, after which it never gets updated. That also is not my main gripe. I do want my cake and eat it, but not automatically. As in, I want to update when I’m ready and expect it, not changing the engine while the car is driving on the highway.

                              Is there an official way to disable automatic updates? However hard to setup, with big red flashing warnings, promising my firstborn to whatever deity? Setting a proxy or hosts file might stop working, an “official” way would still give me all the other benefits of snaps.

                              As said, I do like updates and easy of use (not manually sideloading ever snap, just apt upgrade all the things) with just a bit more control.

                              1. 6

                                Haha! I’m just some guy, you know.

                                There’s currently no way to fully disable completely all updates. I appreciate that’s hard news to take. However, I have been having many conversations at Canonical internally about the biggest pain points, and this is clearly one. Perhaps we could add a big red button marked “Give Alan all my cats, and also disable updates forever”. Perhaps we could really forcefully nag you with irritating popups once you get beyond the 60 days limit that’s currently set, I don’t know. But I agree, something needs to be done here, especially for desktop users who are super sticky on particular releases of their favorite tools.

                                It’s Friday night, and I’m enjoying family time, but rest assured I’ll bring it up again in our meetings next week.

                                Have a great weekend.

                                1. 3

                                  What about a big button to disable automatic updates, and then give initially gentle, gradually escalating nags once updates are available?

                                  Maybe in the handy “Software Manager” popup UI we’ve already got built. Checkboxes to select which ones you want to update. Make it really easy to “accept all”, after my workday is over.

                                  1. 2

                                    This sounds okay in a comment.

                                    Did you use windows 10? Did you read the comments when Microsoft did similar? They were heavily criticised there was a vocal cohort of users annoyed even by that. When I was near a deadline and my windows told me I cannot postpone updates anymore and broke my flow I happened to understand them.

                                    This is a hard UX problem, despite how simple one might initially see it.

                                    1. 1

                                      It is a problem but not that hard. A simple matter of control. Do I update or not? .hold? Then not. It’s perfectly feasible to add a ..hold.forever. Your workflow is not broken sms 99%of average Joes have the latest everything.

                                      Now, this is just my opinion as am old schooler used to absolute control of my computing. I gladly let everything be automated until i don’t.

                                      1. 1

                                        It is hard of you wish to please a wide range of users, ranging from novices to power users, and wish to provide a UI serving the different needs of these different cohorts. I mean it is hard if you want to do it well. :) Microsoft tried hard, and did not get it IMHO. Other vendors fail even more miserably.

                                  2. 3

                                    Thank you for the time you take in the replies here. Enjoy your weekend!

                              2. 1

                                You’re quite right. I apologize for having missed this in my initial read.

                              3. 4

                                Automatic updates are baked into snap’s DNA. If you didn’t want this, simply don’t install the snap.

                                Choosing this medium to install your dev environment and then getting cranky when it does precisely what it was meant to do seems a bit unintentionally disingenuous to me.

                                I’ve seen snaps come up on lobsters before but had no idea that they automatically update with no option to disable the updates. I thought they were basically like Canonical-flavored docker containers.

                                Thankfully I saw this post before I update my laptop next week. I’ll be avoiding Ubuntu and their snaps for now.

                                1. 2

                                  I’ve seen snaps come up on lobsters before but had no idea that they automatically update with no option to disable the updates. I thought they were basically like Canonical-flavored docker containers.

                                  Couple of important differences between Docker and snaps.

                                  Docker containers leverage Linux’s cgroups feature to offer each container it’s own pretty much complete Linux userland.

                                  So that means that you can, as a for instance, have 3 containers all running on a Fedora system, one Alpine Linux, another Ubuntu, and a third something else.

                                  Snaps, on the other hand, are application containers. They just bundle the application itself and any libraries that are necessary to run it.

                                  Thankfully I saw this post before I update my laptop next week. I’ll be avoiding Ubuntu and their snaps for now.

                                  And that’s the beauty of the Linux ecosystem right? :) I’d guess more people on here are Debian or maybe Arch users :)

                                2. 1

                                  If you didn’t want this, simply don’t install the snap.

                                  I think a large part of the criticism is that it gets installed automatically; and if you remove it it keeps getting reinstalled anyway.

                                  have you tried setting the refresh.hold system wide configurable which you could set to an arbitrary date years in the future

                                  Have you actually tried reading the article? It’s literally mentioned in there.

                                  1. 1

                                    I don’t see anything in the article suggesting a snap gets automatically re-installed after removal? Can you please elaborate?

                                    1. 1

                                      I did read the article but missed that detail. Thanks for pointing that out.

                                  2. 5

                                    I’m a fan of Clion. And Pycharm. And Datagrip. And Rider, when I need .Net-y things.

                                    For a while I had scripts to package those into RPMs and stuff them into /opt. About 18 months ago I gave up, and just let their toolbox manage installations in my home directory. I don’t let it autostart, but it does a good job updating my jetbrains tools when I want it to, and rolling them back when an update breaks IdeaVim or some other plugin I depend on. (But usually IdeaVim.)

                                    Snaps have been uniformly terrible the 3 or 4 times I’ve tried them on Fedora, whether it’s been bad interactions with dnf or bad interactions with startup/shutdown. So I ignored the snaps for the jetbrains stuff when I saw them. I assumed the badness was just because snap is young still, and Fedora isn’t their primary target.

                                    Maybe this is evidence that they’re not very good on Ubuntu either, and they will soon get Unity’d and replaced with Flatpak. As someone who occasionally needs to package binaries for various Linux targets, I do hope one of snap/flatpak/appimage emerges as a clear best target in the near-ish future.

                                    1. 1

                                      You used snaps on fedora. What’s wrong with flatpak? (Aside from all the things that are wrong with snap as well)

                                      1. 1

                                        The only times I’ve tried snaps on fedora, I wanted to try out a tool that was available as a snap but not as a flatpak or rpm package.

                                        I haven’t had any problems with flatpak on fedora, other than those which snap and appimage share also.

                                    2. 4

                                      Ultimately, suffering from Ubuntu’s decisions is a choice.

                                      There’s plenty of options, when it comes to Linux distributions. I find most of them are not Ubuntu, and thus do not irritate me in a regular basis.

                                      1. 2

                                        Or you could just ignore snap, Ubuntu is a fine distro.

                                        1. 7

                                          Doesn’t look like that will remain an option. It doesn’t make sense for them to maintain snap and deb of a given app indefinitely, and they definitely seem convinced that snap is the easier option, so you should be expecting debs of popular apps to disappear. Ubuntu-maintained ones, at least.

                                          1. 4

                                            I prefer the path of least resistance. For me that’s Arch. YMMV.

                                        2. 0

                                          There is only one GNU/Linux distro that was remotely comparable to the Mac OS user experience. Alas. No more.