This week we’ve been playing Command & Conquer. We discuss your recent feedback about snaps and Ubuntu rolling release. Then we bring you some command line love and go over the rest of your wonderful feedback.

It’s Season 13 Episode 14 of the Ubuntu Podcast! Mark Johnson, Martin Wimpress and Stuart Langridge are connected and speaking to your brain.

In this week’s show:

  • We discuss what we’ve been up to recently:
  • We discuss all your feedback about snaps and rolling releases.
  • We share a Command Line Lurve:
sudo apt install python3-proselint
proselint text.md

That’s all for this week! If there’s a topic you’d like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to [email protected] or Tweet us or Toot us or Comment on our Facebook page or comment on our sub-Reddit.


2 Comments » for S13E14 – Ace of spades
  1. James Henstridge says:

    The original name we planned for a rolling release was “Grumpy Groundhog”:

    https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/GrumpyGroundhog

    It was a big more ambitious than just packaging the latest release of each upstream: it was going to package the tip of the main development branch of each upstream, assuming it was buildable.

    The references to “hct” in the document refer to the “hypothetical changeset tool” that would help bring packaging (and patches) forward to new releases through distributed version control (probably Arch: I don’t think we’d yet migrated fully to bzr at the time).

  2. Stefan says:

    Regarding the issue of Mint ‘breaking’ Chromium in APT, I think that it is good that you have taken the time to discuss this problem (twice). However, I feel that the two issues that concern me the most, were not discussed at length. The reason is probably that they are relatively minor issues in the grand scheme of things. From my point of view, the crucial aspect is not that Chromium is now packaged as a snap rather than a deb. That makes perfect sense to me, given that it is not the primary browser and that it gets updated very frequently. Reducing the burden of creating new debs for several versions of Ubuntu seems like a very good idea indeed. Also, I have no problem trusting Canonical. As you have pointed out, if you trust the company to deliver debs and all the rest of it, why not snaps?

    So, what problems do I have with snaps?

    The first problem, as I see it, is that it is very easy to end up installing snapd without intending to, and perhaps even without understanding that it has been installed and what implications that will have. When you run ‘sudo apt-get install chromium browser’, APT does tell you that it intends to pull down a couple of dependencies. One could argue that this should be enough to alert most people who choose to use apt-get, assuming that they understand the full ramifications of satisfying those two dependencies. However, those using apt instead of apt-get, are given no warning, and I would guess that the same applies to those using a graphical installer.

    I would say that the people (person) behind Mint have (has) a point in that it seems too easy to end up installing snapd by mistake (or ignorance). I think that this could be fixed by modifying APT to raise a warning flag before installing a program that requires snapd. The default, the first time, should probably be to opt out rather than in, but it is nice that APT can do the installation for those of us who wish to use snaps. For some use cases involving users with powerful hardware and no interest in ‘technical’ matters, it might be OK to default to opt-in (e.g. in some graphical installers).

    Personally, I like the concept of snaps and I have a few installed on my Ubuntu MATE desktop, but at the same time I think that there can be valid reasons for not wanting to install snapd, for example on systems that have very little RAM or disk space available. I have avoided using snaps on my laptop because it is an old machine and I sometimes use it in places where I have very limited bandwidth, which brings me to the second issue I have with the (early) implementations of snapd. I do not want to allow my laptop to run updates when tethered to my phone (which runs Ubuntu Touch). It is easy enough to disable automatic updates of deb packages, but automatic updates of snaps adds another level of complexity. I’m sure it can be solved, but trying things like “sudo snap get system refresh.hold” does not work on my current desktop system (it returns: ‘error: snap “core” has no “refresh.hold” configuration option’). My guess is that this is because my current desktop system is too old (Ubuntu MATE 18.04 LTS), but do I want to trust that it will work if I upgrade to the next LTS? Or do I play it safe and go with Mint…?

    I might add that I’m using Mint on my laptop, primarily because it is so old that there was no Ubuntu MATE edition available when I first installed Linux on it, so Linux Mint MATE seemed like the obvious choice. Since then, I’ve upgraded it successfully a number of times and it is currently running Mint 19.3.

    I addition, I’m not completely satisfied with the way the snaps have performed on my main desktop. They take so long to start up, that I hesitate to run them on much less powerful hardware. Also, I started using GIMP as a snap because I wanted version 2.10 instead of 2.8 from the repo. However, on a few occasions, the program wouldn’t start and I reverted to the deb version after a couple of such experiences. Eventually, I found a ppa that solved the problem and I’m now using version 2.10 again (but no longer from a snap). Since then, I have tested the GIMP snap and it now works fine again, so I guess it might have been a case of an automatic update gone wrong somehow (perhaps not the update itself, but GIMP may have been updated to a version that contained a bug). Or what else might have caused a temporary problem like that? It persisted over days or weeks, but not months.

    In summary, I do like the concept of snaps and I will continue to use them, but I wish that APT would ask for permission from the user before installing and running such a game-changing program as snapd. I would also like to see a simple and unified way to prevent the machine from updating itself under some circumstances, the typical use case being when tethered to a mobile phone in the remote wilderness. This is easy for debs and I’m sure it is possible for snaps (at least in newer versions of Ubuntu), but having to remember to do this in more places than one, makes the issue more complex. Personally, I don’t mind using the command line to do this sort of thing, but I know that some of my friends are much less inclined to use a somewhat complex command and would prefer a single GUI to manage everything related to updates. Can I recommend Ubuntu to them right now? Does the Software Boutique or some other graphical utility in 20.04 make this easy? My feeling is that they should stay on Mint for now and perhaps re-evaluate when 22.04 LTS comes around or at least until I have tested 20.04 and found that it works as outlined above. I would be willing to change my recommendation to beginners, should it turn out that it is indeed easy to manage this graphically in 20.04 LTS.

    I don’t expect you to read this long and somewhat belated comment on the podcast, but I do think that my two main issues with snaps (the risk of unintentional installation of snapd and the added complexity when tweaking update policies) were more or less glossed over in previous discussions. I do appreciate that ‘hiding’ the issue of updates was a design decision, but I do not want to waste a lot of bandwidth on updates when my laptop is tethered to my phone. I don’t feel that I can recommend new users to choose Ubuntu 20.04 over Mint until these (minor) issues have been sorted out, although on the whole I do support the concept of snaps. I don’t feel that these minor issues make Ubuntu 20.04 LTS a bad release, but it seems to me that right now it might present new users with a few extra things to worry about, compared to Linux Mint 20. And I know that at least some of my friends appreciate the five year lifespan of Mint. I think that (for now) my recommendation to those seeking a green distro, will have to be to choose a minty one. I have not yet decided which one I will upgrade to, but I admit that support for five years rather than three, is tempting. If I decide to go with Mint, I’ll probably enable snapd manually.

    Finally, I do hope that these issues can be resolved and won’t lead to any prolonged animosity between Canonical and Linux Mint. Ubuntu and Mint are the distros I most frequently recommend to new users, and I don’t want to be forced to side with one of them against the other.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.