LWN: Comments on "Linux Mint drops Ubuntu Snap packages"

Linux Mint drops Ubuntu Snap packages

mcortese — Wed, 12 Aug 2020 14:15:09 +0000

Block-level deduplication is only applicable to same-version libraries. It doesn't help when a snap package includes v1.0 and another v1.0.0.1

Linux Mint drops Ubuntu Snap packages

qzPhUZ7af5M6kjJi3tDgMaVq — Mon, 20 Jul 2020 13:36:47 +0000

What about the NIX package manager approach?

Solution to the wrong problem

mathstuf — Mon, 20 Jul 2020 13:05:15 +0000

If your application supports plugins (as in `dlopen` which includes Python or Ruby), it allows them to pick up those libraries as well. No idea if your app doesn't support such things.

Solution to the wrong problem

XTF — Mon, 20 Jul 2020 12:45:10 +0000

What's the advantage of using dynamic libraries over static linking them into one big executable, assuming they're only used by that one executable in the snap?

Linux Mint drops Ubuntu Snap packages

branden — Mon, 20 Jul 2020 02:29:50 +0000

Fortunately the state of the art has advanced since Thompson coded his Trojan. Here's a paper from 2013:

"We extend the existing formal verification of the seL4 operating system microkernel from 9 500 lines of C source code to the binary level [11,736 instructions]. We handle all functions that were part of the previous verification. Like the original verification, we currently omit the assembly routines and volatile accesses used to control system hardware.More generally, we present an approach for proving refinement between the formal semantics of a program on the C source level and its formal semantics on the binary level, thus checking the validity of compilation, including some optimisations, and linking, and extending static properties proved of the source code to the executable. We make use of recent improvements in SMT solvers to almost fully automate this process.We handle binaries generated by unmodified gcc 4.5.1 at optimisation level 1, and can handle most of seL4 even at optimisation level 2."

https://ts.data61.csiro.au/publications/nicta_full_text/6...

Snap-Chromium cannot be run by a daemon

evgeny — Thu, 16 Jul 2020 07:55:27 +0000

> usually the fix is to stop using NFS :(

Well, for me the fix was to stop using snap :)

Linux Mint drops Ubuntu Snap packages

callegar — Thu, 16 Jul 2020 07:44:56 +0000

Seems a little ironic here that the new "universal" containerized package formats that got initially promoted as a way to end the linux package format fragmentation and the associated baggage of strong views about them are ending up with just another type of package fragmentation and an even stronger stance for the one or the other.

There are already two heavyweight contenders (snap and flatpack — interestingly two just like deb and rpm) and some assortment of outsiders (appimage, zero-install, docker containers as a way to distribute applications, etc.) and there might be more if snap gets forked so that every distro can have its own version of it pointing at its own software store and requiring some "--dangerous" "--I-am-really-sure" "--just-for-once-I-will-not-betray-my-favorite-distro-anymore" switches to install packages from elsewhere as it may easily end.

Seems a little sad that what was once a split at least partially owing to legacy or different views on the technical merits of the formats (thus having at least the potential advantage of a competition in features) is now becoming a split mostly based on a who-can-centralize-the-distribution-of-what view.

Also a little ironic that these wars and control issues seems to keep at the window those distributors of commercial software that would likely benefit more from the new package formats. For instance, I really wished that Matlab or Mathematica or some CADs were distributed in snaps rather than a zip or shell archive with a custom (and often buggy) install code to be run as root on X.

Snap-Chromium cannot be run by a daemon

Wol — Wed, 15 Jul 2020 23:35:22 +0000

Very ick when you've got a small disk in your workstation, and a network home that's larger than your local hard disk ...

Cheers,
Wol

Snap-Chromium cannot be run by a daemon

zlynx — Wed, 15 Jul 2020 22:22:59 +0000

I've seen some dire replacements for the lack of NFS.

How does a Windows style roaming profile sound? Rsync on login and rsync back on logout. Kind of ick, but not super bad on gigabit Ethernet.

Snap-Chromium cannot be run by a daemon

smoogen — Wed, 15 Jul 2020 17:29:46 +0000

I was looking at this and realized this is a 20/80-80/20 problem.

20 years ago 80% of the user population were on NFS home directories and these problems would get fixed. Now much less than 20% of the user population are using NFS home directories and so it not going to get fixed unless the people running into it do the fix themselves... usually the fix is to stop using NFS :(.

Linux Mint drops Ubuntu Snap packages

feb — Tue, 14 Jul 2020 16:36:22 +0000

That's actually a very good point. It was even reported on LWN: https://lwn.net/Articles/471484/

Linux Mint drops Ubuntu Snap packages

ceplm — Tue, 14 Jul 2020 11:05:24 +0000

It is not fair to put Firefox and Chromium in the same bag. I was working around the Firefox support and yes, building Firefox is complicated, but it is because it is a complex program, not because some large advertising company just throws randomly code over the fence. Mozilla people were always technical, and we were and are able to provide competent builds of the browser.

OK, I don’t know enough about Chromium, but I can see that my colleague who works on packaging it in SUSE, is getting a bit green around the time of release, and I have never had the courage to ask about his alcohol consumption in that time.

Linux Mint drops Ubuntu Snap packages

mathstuf — Mon, 13 Jul 2020 17:37:57 +0000

It'd be great if dummy backends could be used. This makes the apps not have to deal with missing permission checks (and potentially refusing to work if not provided them) and keeps your data safer.

Linux Mint drops Ubuntu Snap packages

n8willis — Mon, 13 Jul 2020 08:40:40 +0000

I recall from c.2011 that Linux Mint was altering the Banshee package to change the built-in AmazonMP3 affiliate code to its own and take 100% of the revenue from all purchases, and that there was a controversy somewhat later wherein Linux Mint was replacing the default search engine in Firefox packages with a custom Mint-branded search. And I can see on the partners page that they are currently listing "sponsored link" arrangements with Yahoo and Duck Duck Go as in-browser revenue sources.

You can certainly feel any way you want about that revenue structure itself, but it does make me wonder whether any of Linux Mint's current objection to the Snap packages of Chromium have less to do with the pure technical merits of .snap versus .deb themselves (or how Apt works), but are influenced by the mundane, practical issues of modifying different browser packages to switch on those sorts of sponsored-link arrangements in the binaries.

Linux Mint drops Ubuntu Snap packages

atnot — Sun, 12 Jul 2020 18:31:41 +0000

This is no different from the sandboxes on any other platform. The app declares the permissions it needs and users can modify them as needed. The only way in which I see your argument is that the flatpak cli does not ask you to confirm the permissions before installing. Which it definitely should, but has little to do with flatpak as a technology.

Linux Mint drops Ubuntu Snap packages

ibukanov — Sun, 12 Jul 2020 06:24:16 +0000

Mozilla supports ESR for one year, after that one has to update it by a never version. Which still implies that Debian stable has to update it several times during their support cycle.

Linux Mint drops Ubuntu Snap packages

riteshsarraf — Sat, 11 Jul 2020 09:57:12 +0000

Similar was the case of (Oracle) VirtualBox in Debian. Post the take over of the company, the release process changed and left not much choice for its maintenance in a Debian Stable release, for example.

In my observation, there's been multiple reasons for such act.

* Competition: OEL vs RHEL. Similar situation occurred when one took over work from other, such that broken down changes were stopped being released.

* Maintenance: Maybe maintaining stable branches is too much of a hassle. And perhaps Linux LTS is just an exception to it.

* USP: Everyone wants something.

Linux Mint drops Ubuntu Snap packages

pabs — Sat, 11 Jul 2020 02:18:28 +0000

I didn't say anything about consensus, just that some Debian contributors seem to think it is a good idea.

PS: I'm one of the people in the bug complaining about it.

Linux Mint drops Ubuntu Snap packages

ras — Fri, 10 Jul 2020 23:17:38 +0000

David Wheeler's paper is one solution, but I've never heard of an instance of the technique he describes catching anything.

On the other hand, the techniques Open Source has developed over the years has caught a few attempts to slip nefarious code in. Those techniques are:

1. A cryptographically sealed audit trail of every change (eg, git's sha1 sums).

2. Digitally signed commits, so if someone does slip something in you know who was responsible. (This is something Wheeler's technique doesn't give you).

3. Open Source, as in everyone can see and verify the previous two points for themselves.

But the sound of it Snap throws all of this away. In this era repeated of nation state attacks on infrastructure, to me that creates an unacceptable risk. Currently that seems to be a lonely position to take, but I'm betting as we get more Huawei style conflicts arise we see gradual realisation Open Source is the one of the few things that naturally gives rise to trust between otherwise antagonistic parties.

Linux Mint drops Ubuntu Snap packages

iteratedlateralus — Fri, 10 Jul 2020 23:02:25 +0000

Are they planning on monetizing the Snap store?

Linux Mint drops Ubuntu Snap packages

simosx — Fri, 10 Jul 2020 21:54:41 +0000

> At this point, why not just use Flatpak which is both not hostile to users of the technology and technically superior in several aspects.

There is too much such evangelism. The reality is that there are all sort of issues. The sandbox permissions are set by those that package the application. Kinda defeats the purpose of a sandbox.

Linux Mint drops Ubuntu Snap packages

simosx — Fri, 10 Jul 2020 21:47:34 +0000

Ubuntu is moving to using ZFS as the system filesystem.
At the moment you can install Ubuntu on ZFS as an experimental option, on Ubuntu 20.04 LTS.
The immediate benefit is the ability to add restore points.
In LXD, you can run containers and VMs from within the ZFS dataset, without the need to manage partitions.
There is a list of blog posts that explain how ZFS will be used in Ubuntu at https://discourse.ubuntu.com/t/zfs-focus-on-ubuntu-20-04-...
I suppose that there will be some benefits in how snaps are being used.

Linux Mint drops Ubuntu Snap packages

atnot — Fri, 10 Jul 2020 17:37:05 +0000

As the article mentions, there is little objection to the technologies used. The objection is to Canonical's business plans and decisions.

Linux Mint drops Ubuntu Snap packages

atnot — Fri, 10 Jul 2020 17:30:30 +0000

At this point, why not just use Flatpak which is both not hostile to users of the technology and technically superior in several aspects.

Linux Mint drops Ubuntu Snap packages

NYKevin — Fri, 10 Jul 2020 17:13:59 +0000

That depends on how the compression works (and whether the Snap people want it to be compatible with block deduplication).

- If you compress each library (or other major component) separately, and then concatenate them, the overall size is (probably) larger, but you can deduplicate effectively.
- If you compress the whole combination, then the overall size is smaller, but block deduplication is probably *less* effective. However, since most compression works by identifying repeated patterns of bytes, it is at least somewhat plausible that you can still do some deduplication anyway.
- If you compress at the block level, after deduplication, then you can have your cake and eat it too. But Snap (probably) doesn't do that.

Again: Theoretically solved doesn't mean practically solved.

Linux Mint drops Ubuntu Snap packages

stephen.pollei — Fri, 10 Jul 2020 15:37:39 +0000

Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers

Linux Mint drops Ubuntu Snap packages

LtWorf — Fri, 10 Jul 2020 08:58:18 +0000

Where did you gather from that link that the consensus is that it is a good idea?

Linux Mint drops Ubuntu Snap packages

alex — Fri, 10 Jul 2020 07:37:11 +0000

It is. In fact I run Debian Buster but install my Firefox via Snap because I prefer to have a more up to date Firefox rather than sticking to the ESR build. It may well come via Canonical's snap store but the package itself is built by Mozilla.

Linux Mint drops Ubuntu Snap packages

ccchips — Fri, 10 Jul 2020 04:15:08 +0000

Snap packages are compressed, so I'm confused about how deduplication will help.

Linux Mint drops Ubuntu Snap packages

NYKevin — Thu, 09 Jul 2020 23:42:04 +0000

> Using snap (or similar technologies, like Flatpak) eats a lot of disk space for no good reason (from the user's perspective).

Block-level deduplication is not a new technology, and (mostly) solves this problem automatically. Unfortunately, so far as I can tell, ext4 does not support it, and btrfs only does it if userspace manually identifies the affected files and ranges with ioctl_fideduperange(2). Of course, ZFS has proper, automatic support (as far as I've been able to determine from Google), but then you get to tangle with all the fun licensing issues.

The point: This is a (theoretically) solved problem, and the fact that it is apparently so difficult to (practically) solve is actually rather depressing.

Linux Mint drops Ubuntu Snap packages

sheepgoesbaaa — Thu, 09 Jul 2020 23:01:32 +0000

I had never heard of "Reflections on Trusting Trust", and I just read it, really interesting.

PDF link: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_...

Linux Mint drops Ubuntu Snap packages

NGRhodes — Thu, 09 Jul 2020 21:51:55 +0000

Don't forget Debian packages Firefox ESR in its stable release.

Linux Mint drops Ubuntu Snap packages

simosx — Thu, 09 Jul 2020 21:28:37 +0000

Snap packages share a "core" image. You can see it when you run "snap list". "core" is the Ubuntu 16.04 runtime, "core18" is the Ubuntu 18.04 runtime. As long as the library is found in the core image, it is shared among all snap packages.

If the snap package is a GUI application that is based on GNOME, then it will be using one of the GNOME images, such as "gnome-3-28-1804". Again, anything in this common image is shared among any snap package that is based on this image.

Finally, any other library has to be "staged" into the snap package in order to be included. Here, you may have repetition.
However, in most cases, the important libraries will be found in the "core" image, or the "gnome" image.

Linux Mint drops Ubuntu Snap packages

ccchips — Thu, 09 Jul 2020 20:38:38 +0000

If I have two snap packages installed on my computer, and they use the same libraries, don't I wind up with duplicate libraries (and hence wasted space?)

This starts to get troublesome, especially with this SMR crap that's starting to take hold....after installing a "snap-ful" operating system, I guess the data is going to end up near the end of the SMR disk, which is exactly where it shouldn't be....

Maybe a bit far-fetched, but I get troubled when environments start getting bloated.

Linux Mint drops Ubuntu Snap packages

simosx — Thu, 09 Jul 2020 19:35:35 +0000

I am using LXD as the backend, instead of multipass. And it worked for me, the snap package was created.

$ snapcraft --debug --use-lxd

I do not know why you are getting those messages.
I suggest to have a look at the page at
https://forum.snapcraft.io/t/snaps-officially-supported-b...
which lists the officially supported snap packages by Canonical.
You can file a bug report if a snap package does not build for you.

Linux Mint drops Ubuntu Snap packages

mockturtl — Thu, 09 Jul 2020 18:28:37 +0000

> rolling release

Not for a few years. It's based on debian stable (plus backports), with rolling updates for their own packages (mostly desktop-related).

Linux Mint drops Ubuntu Snap packages

IanKelling — Thu, 09 Jul 2020 16:55:02 +0000

Same error as before. Here's the last lines, some obvious ones replaced with ...

Cloning into '/root/parts/gnome-sudoku/src'...
...
Note: checking out '2ecbfa7bc71a5c79716517634858eaa16b4f9957'.
...
Collecting meson
Downloading https://files.pythonhosted.org/packages/04/db/53fe14aa9a4... (1.7MB)
100% |████████████████████████████████| 1.7MB 569kB/s
Building wheels for collected packages: meson
Running setup.py bdist_wheel for meson ... done
Stored in directory: /root/.cache/pip/wheels/66/09/2d/4fcfb30d06d18fd9bdc67a724b8a56844e94cc194a45ea41f7
Successfully built meson
Installing collected packages: meson
Successfully installed meson-0.54.3
Get:1 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
...
Get:39 http://archive.ubuntu.com/ubuntu bionic-updates/universe Translation-en [340 kB]
Fetched 31.7 MB in 6s (5240 kB/s)
Get:1 libqqwing2v5_1.3.4-1.1_amd64.deb [16.5 kB]
Fetched 16.5 kB in 0s (0 B/s)
Get:1 libgee-0.8-2_0.20.1-1_amd64.deb [210 kB]
Fetched 210 kB in 0s (0 B/s)
Get:1 libffi6_3.2.1-8_amd64.deb [17.9 kB]
Fetched 17.9 kB in 0s (0 B/s)
Get:1 libglib2.0-0_2.56.4-0ubuntu0.18.04.6_amd64.deb [1171 kB]
Fetched 1171 kB in 0s (0 B/s)
Pulling libraries
Skipping build desktop-gnome-platform (already ran)
Building gnome-sudoku
meson --prefix=/usr snapbuild
The Meson build system
Version: 0.54.3
Source dir: /root/parts/gnome-sudoku/build
Build dir: /root/parts/gnome-sudoku/build/snapbuild
Build type: native build
Project name: gnome-sudoku
Project version: 3.32.0
Using 'LDFLAGS' from environment with value: ' -L/root/stage/lib'

meson.build:1:0: ERROR: Unknown compiler(s): ['c++', 'g++', 'clang++', 'pgc++', 'icpc']
The follow exceptions were encountered:
Running "c++ --version" gave "[Errno 2] No such file or directory: 'c++': 'c++'"
Running "g++ --version" gave "[Errno 2] No such file or directory: 'g++': 'g++'"
Running "clang++ --version" gave "[Errno 2] No such file or directory: 'clang++': 'clang++'"
Running "pgc++ --version" gave "[Errno 2] No such file or directory: 'pgc++': 'pgc++'"
Running "icpc --version" gave "[Errno 2] No such file or directory: 'icpc': 'icpc'"

A full log can be found at /root/parts/gnome-sudoku/build/snapbuild/meson-logs/meson-log.txt
Failed to run 'meson --prefix=/usr snapbuild' for 'gnome-sudoku': Exited with code 1.
Verify that the part is using the correct parameters and try again.
Run the same command again with --debug to shell into the environment if you wish to introspect this failure.

Linux Mint drops Ubuntu Snap packages

simosx — Thu, 09 Jul 2020 16:02:39 +0000

> Where did I go wrong?

You used this process as a way to get access to the "snapcraft.yaml" recipe file.
And you tried to build it inside a read-only location. Snapcraft should install all the requirements

Here is what you should add.

mkdir -p ~/MYSNAPDEVELOPMENT/gnome-sudoku
cp /mnt/4/snap/snapcraft.yaml ~/MYSNAPDEVELOPMENT/gnome-sudoku/
cd ~/MYSNAPDEVELOPMENT/gnome-sudoku/
snapcraft

Snapcraft will use "multipass" to setup a VM, enter the VM, and build "gnome-sudoku". Finally, it will take the built gnome-sudoku snap package and copy it back to your host.

Linux Mint drops Ubuntu Snap packages

Comet — Thu, 09 Jul 2020 15:55:46 +0000

The portrayal of the use-cases for Snap completely misses why an informed end-user might choose to prefer Snaps as being in their best interest.

As a user of Ubuntu, I'm switching to preferring Snaps for various pieces of (free or otherwise) software, simply because they're well-sandboxed by default.

With the history of security holes in chat clients, running them unconstrained with full FS access is, to me, undesirable.

The usual immediate retort from some folks is "X is not a security mechanism". Well, I'll take the containerization and limited FS access anyway, if it means that my chat client suddenly doesn't have immediate access to my SSH agent socket or DBus or financial documents. Compromise requiring an exploit chain is better protection than compromise requiring that one author of any piece of C software I run have used less than superhuman perfection in their coding. I'll take the incremental improvements as we slowly edge towards safer computing.

Chromium is unusual in being a sufficiently staffed product to have its own sandboxing setups. Most open source simply doesn't. Most closed source, I suspect, simply doesn't bother.

Chat clients, cloud management tools, sync'd notes tools, password manager tools, I have all of these in Snaps and am happier for it.

Linux Mint drops Ubuntu Snap packages

simosx — Thu, 09 Jul 2020 15:48:29 +0000

> Your notion of reproducability seems merely to say everybody can setup a build environment.

You do not "setup a build environment" yourself. The software (snapcraft and the Build service) launch the same build environment in a brand new VM of a generic Ubuntu image. The pieces are there so that two different users may well end up with the same binaries.
Whether this is offered as a future service, it looks to be easy to implement.