WARNING: This is an example of a clear violation of the Code of Conduct.
Casually assuming bad faith is disrespectful and irresponsible.
Everybody: Stay away from ALL forms of name-calling.
If you must j’accuse to make a point, then perhaps reconsider if this is the appropriate venue for your participation.
How about some of Ubuntu’s failed projects; Unity, Upstart.
In terms of a compelling argument, that’s not a really good one. We’re not talking about anything other than Snaps and Debian packages here.
And besides, so what? Everyone fails. Does that mean that everything anyone does is going to be a failure? If you fail once, you’re doomed to fail always?
Please, please, please: if you don’t have something to add to the discussion, just move on. Please. The rest of us would actually like to talk about this.
At one time I was concerned about the stock Thunderbird deb package in 22.04 and in previous versions. I was concerned about its security and whether it was version bumped often enough so that vulnerabilities were being addressed in a timely manner (appropriate to the CVE level). So I looked on Launchpad at the version bump dates and compared them to the Ubuntu CVE Reports. It turned out that when there was a CVE of level “high” that Thunderbird was version bumped within a week to ten days to receive the patch. So I felt at ease continuing to use the deb package.
When I tried to investigate the same thing with regard to the snap Thunderbird it turned out that there was no such documentation of its version bumps. I even asked on the snap forums and got no responses. Pretty sure I asked on Ubuntu Forums as well. This meant that I simply had to trust Canonical that it was version bumping often enough.
The thing is, one of the things I like about Linux is the fact that I don’t have to trust the distribution. I can look at the source code (or others can who understand it). I can look at when packages get version bumped and see if security vulnerabilities are being addressed in a timely manner. It seems that neither of these is possible with snaps. (Please correct me if I’m wrong.) I have to trust. So there seems to be less transparency with snaps than with debs.
So, the Thunderbird snap is co-maintained by Canonical and the Thunderbird foundation, even though the snap itself says it’s being maintained by Canonical.
How do I know this?
name: thunderbird
summary: Mozilla Thunderbird email application
publisher: Canonical✓
store-url: https://snapcraft.io/thunderbird
contact: https://www.thunderbird.net/contact/
license: unset
description: |
Thunderbird is a free email application that’s easy to set up and customize - and it’s loaded with
great features!
Check the contact: field. That’s not a Canonical contact, that’s a contact for Thunderbird themselves.
Furthermore, if you want to report a bug that link can be found at snapcraft.io/thunderbird:
If it was Canonical, like many snaps are, then it would have a Launchpad address, or perhaps a Github address, at which you’d report the bug. However, Thunderbird wants it at bugzilla.
Also, I personally know the maintainer of the Thunderbird snap. She’s a former Canonical employee and now she works for Thunderbird maintaining this snap. I will not single her out here, but she’s a wonderful person and works very hard.
I have been debating whether to add my thoughts here to this discussion.
I am an ordinary home desktop user, no server or corporate usage of Linux.
But, both on Ubuntu Forums and now here I am seeing, for lack of a better description now, an anti-snap attitude.
I ran an experiment on my Linux box, not nearly as scientific as the data provided by @popey but enlightening nevertheless (at least for me).
On my EndeavourOS install, no snaps, I used the time firefox command with the following results:
First run: 23s to fully load
Second run: 8s to load
Then I switched to Ubuntu 24.04, with snaps, and ran the same command:
First run: 25s
Second run: 9s
In other words, practically no difference whatsoever.
Without intending any kind of attempt to sway the argument in one direction or another, this is my personal conclusion:
The argument against snaps is more a question of perception, emotional perhaps ideological.
When I first came across Linux in 2005 after watching an interview with Klaus Knopper, creator of Knoppix, I was fascinated by the freedom and choice that Linux offers.
We do not have to use snaps or flatpack or Ubuntu or anything else. In fact, if so inclined, we can even build our own distro with our own package management.
I wish, very sincerely, that people would understand that all these arguments for or against a certain way of doing things can be constructive if used to better improve our experiences.
Sadly, that seems not to be the case in many posts I have seen over the years.
In response to another thread here on another subject, I tested Ubuntu 4.10 in a virtual machine.
What a blast from the past!
But it also helped me realize how far Ubuntu and Linux in general has come from those early days.
Change can be hard to accept sometimes but if we embrace the challenge, we will all benefit.
Well said my friend.
@wxl You ask for testing by ordinary users who probably have no inkling of how to go about doing these sorts of tests. How many ordinary Ubuntu users will have three different sets of hardware with which to test? I would respectfully point out it is more in the purview of the software proponents and developers to run these sort of tests, once they have been informed of the relevant issues.
I for one am extremely reluctant to contaminate my system with the snap ecosystem after the various issues I have experienced, just to satisfy a developer’s curiosity. In my humble opinion it is up to the new software proponents to do their best to ensure their new ecosystem is fit for purpose before advocating its universal adoption. The primary issue for me is to ensure the ecosystem is fully functional in all respects, and when a snap denies access to some directories on a users computer, it is a very long way from being a fully developed and functioning alternative to .deb packages. When that issue is finally addressed and completely mended I will be the first to adopt snaps as the way forward, irrespective of other issues such as slow performance.
No, unfortunately, it wouldn’t. That’s because snap does have a specific problem, which is to do with the inflexibility of its sandbox.
A specific case: For me, the snap version of Gedit is unusable, because it allows you to edit files only in selected directories in your home folder. For example, I can’t even edit my own scripts in ~/bin, never mind files outside my home such as /etc/fstab.
There is no way around this. I’ve asked for Gedit to be allowed to be installed in Classic Mode, but the request has been ignored.
This is the one significant area where snap has a big failing.
For “normal” users, this isn’t a problem. It doesn’t affect them. In fact, for corporate and similar organisations, which is Canonical’s target market, it’s actually an advantage. This includes immutable distributions such as Ubuntu Core.
But, for power users, it’s a significant failure. This is one area where flatpak shines, because flatpak allows you to tailor each app’s sandbox as required (something that I was pleased to be able to do with Gedit).
I don’t mind using snaps (on modern hardware, there is no discernable speed difference with debs), but only when their security settings allow me to do what I have to do.
The problem that I have with ‘snapped’ applications is that we are asked to report bugs but either the bug reports are not always updated, or the bugs remain and are never fixed.
For instance, I was asked to report:
over five and a half years ago. It is currently shown as being ‘Confirmed’ with 13 other users seeing the issue that I reported. The developer that was working on the Chromium snap has moved on and the last comment by a member of the Desktop Team was made over five years ago. I could not report the issue upstream as the Chromium project is not responsible for the Chromium snap.
Today I ask myself:
I’m going to change the status of the bug report to ‘Incomplete’ and still sees the issue in any of today’s supported releases of Ubuntu and its many flavours or was it actually fixed some time ago.
SECOND WARNING: Name-calling will not be tolerated.
Nether snaps nor apt nor flatpaks are “contaminants.”
The multiple private warnings this topic has generated have become tedious.
You are adults. Behave so.
Unfortunately, the ‘slow mode’ which is currently active (and I don’t disagree with) prevents me from editing and updating my last post.
The updated and somewhat more applicable text is as follows:
Referencing my last bullet point that is a question that could be asked of any ‘snapped’ application that the Canonical/Ubuntu developers decide to move from a Debian package to a ‘snap’ application in a default installation of Ubuntu.
And referencing my bug report I’ve changed the status of the bug report to ‘Incomplete’ and asked if anyone still sees the issue in any of today’s currently supported releases of Ubuntu and its many flavours or was the bug fixed some time ago and the bug report that I linked to needs updating.
You make some good points as to why the Thunderbird snap can be trusted in general. I would only say that there’s nothing like being able to verify it yourself. I observed that sometimes the Thunderbird snap would version bump maybe 2 or three weeks after the upstream Thunderbird update. But I couldn’t go back and check the pattern of version bumps and compare them to the corresponding CVE’s. So I was put into the position of having to “trust” as opposed to really knowing.
It’s easier than you think.
If you really want to investigate on your own machine, snap download thunderbird would do the trick.
It will download it depending on what branch you’re currently tracking. As I’m, personally, tracking the latest/beta branch, this is what my machine shows:
$ snap info thunderbird
name: thunderbird
summary: Mozilla Thunderbird email application
publisher: Canonical✓
store-url: https://snapcraft.io/thunderbird
contact: https://www.thunderbird.net/contact/
license: unset
description: |
Thunderbird is a free email application that’s easy to set up and customize - and it’s loaded with
great features!
commands:
- thunderbird
snap-id: k1Ml1O9GzSO2QftV0ZlWSbUfQ78nN460
tracking: latest/beta
refresh-date: 8 days ago, at 15:01 PST
channels:
latest/stable: 128.7.0esr-1 2025-02-12 (644) 220MB -
latest/candidate: 128.7.1esr-1 2025-02-15 (663) 220MB -
latest/beta: 136.0b2-2 2025-02-13 (656) 211MB -
latest/edge: ↑
installed: 136.0b1-1 (637) 211MB -
Once you have the .snap file downloaded, all you have to do is unsquashfs {snap file}. Granted, that will be the binary, and not the source code.
That said, you can also browse the code.
lp:~desktop-snappers/thunderbird/+git/snap : Git : Code : Mozilla Thunderbird is where the snap is built.
Using the beta branch again, we can see the snapcraft.yaml, which is the recipe for making the snap: snapcraft.yaml - ~desktop-snappers/thunderbird/+git/snap - [no description]
override-pull: tells us where it’s grabbing the source from:
override-pull: |
if [ $CRAFT_ARCH_BUILD_FOR = "amd64" ] || [ $CRAFT_ARCH_BUILD_FOR = "arm64" ]; then
VERSION=$(craftctl get version | cut -d- -f1)
BUILD=$(craftctl get version | cut -d- -f2)
TBINFO=$(curl -s https://ftp.mozilla.org/pub/thunderbird/candidates/$VERSION-candidates/build$BUILD/linux-x86_64/en-US/thunderbird-$VERSION.json)
TB_SOURCE_REPO=$(echo $TBINFO | jq -r .moz_source_repo)
TB_SOURCE_STAMP=$(echo $TBINFO | jq -r .moz_source_stamp)
GECKO_REV=$TB_SOURCE_REPO/raw-file/${TB_SOURCE_STAMP}/.gecko_rev.yml
GECKO_REVS=$(curl -sSL "${GECKO_REV}" | grep -v "#")
MOZ_SOURCE_REPO=$(echo "$GECKO_REVS" | grep GECKO_HEAD_REPOSITORY | sed -e 's/GECKO_HEAD_REPOSITORY: //g')
MOZ_SOURCE_STAMP=$(echo "$GECKO_REVS" | grep GECKO_HEAD_REV | sed -e 's/GECKO_HEAD_REV: //g')
FETCHES=$MOZ_SOURCE_REPO/raw-file/$MOZ_SOURCE_STAMP/taskcluster/kinds/fetch/toolchains.yml
TOOLCHAINS=$(curl -sSL "${FETCHES}")
unset PYTHONPATH
REPO=$(echo "${TOOLCHAINS}" | /usr/bin/python3 -c 'import yaml, sys; fetches = yaml.safe_load(sys.stdin); print("{}".format(fetches["dump-syms"]["fetch"]["repo"]))')
SHA1=$(echo "${TOOLCHAINS}" | /usr/bin/python3 -c 'import yaml, sys; fetches = yaml.safe_load(sys.stdin); print("{}".format(fetches["dump-syms"]["fetch"]["revision"]))')
git clone "${REPO}" . && git checkout "${SHA1}"
fi
You can see it gets a .json file, in this case https://ftp.mozilla.org/pub/thunderbird/candidates/134.0b4-candidates/build1/linux-x86_64/en-US/thunderbird-134.0b4.json, which has the source repo at https://hg.mozilla.org/releases/comm-beta.
The one tracking the latest/stable branch is https://hg.mozilla.org/releases/comm-esr128/, easily enough, based on what we can deduct from the above code, as Thunderbird is an ESR release.
So, as you can see, it comes directly from Thunderbird, is compiled on Launchpad, and then released on snapcraft.io.
With that, now you can know as opposed to trusting.
@eeickmeyer , thanks. I really appreciate it. It’s good to be able to see how this all works. Thanks again! One less worry about snaps!
@popey offered some suggestions as to what tests to run. @rubi1200 mentioned using time which is crude, but totally reasonable. You can simulate different systems with virtual machines, so anyone can do it. At the very least, anyone can do it on their own machine.
However, that comment was not directed at you. I understand your concern. It was directed at someone concerned about performance, where such tests are actually relevant. Assumedly such a person already knows how to measure performance because they’re complaining about seeing a difference in performance. I was merely suggesting being more scientific about it.
If all developers used this same philosophy, we’d lack a lot of software. Look at Matrix. It’s still not perfect, even after 11 years of development. But we can use the software while we wait for the changes to make it more functionally complete. Incremental improvements will ultimately lead to better software. This is very nature of open source. What you’re suggesting sounds a lot like that problem classic design/engineering problem: “the perfect gets in the way of the good.”
I have a somewhat similar concern which I’ve expressed elsewhere here:
and even on the Snapcraft Discourse:
with almost no response. The managing of reporting problems seems like a real issue. I haven’t looked at what this is like on Flatpaks but on AppImages it’s even worse since there’s no inherent app management tool and so it’s very hard to find out where to report bugs. So I guess we’re in a better state than that, but this is still a huge problem relative to Debian packages.
Didn’t see anyone bring this up, but I hope that this gets solved in Snaps. I had to switch my LibreOffice to Flatpak just because it can’t write to my SMB share.
It seems to me like accessibility to the whole filesystem is one of those double edged swords of the sandbox design: it’s more secure, but also more problematic. I think this is a general concern but one that I have hope will eventually be worked out.
@wxl Until this issue is sorted out snaps will never become the default for the ordinary user. It is just too hard for them to be able to log in as root, change the permissions on all the directories and files they need to access then re-log back in as an ordinary user and see if that worked.
This to me should be the No.1 problem for them to sort out. If they are unable to sort out the sandbox then why don’t they just remove it until they can fix it? Security issues should always come as a secondary consideration to functionality. Linux systems are inherently more secure than others so I really don’t see the problem with just ditching the sandbox until they have permission issues worked out.
Well, there are Snaps that don’t need the same file access, so there are reasons. Still, I’m not exactly sure why (or if?) the option to turn the sandbox off isn’t there. I’m no Snap expert at all but isn’t that what classic confinement is?