Linux Mint drops Ubuntu Snap packages
The Linux Mint project has made good on previous threats to actively prevent
Ubuntu Snap packages from being installed through the APT package-management
system without the user's consent. This move is the result of "major
worries
" from Linux Mint on Snap's impact with regard to user choice
and software freedom. Ubuntu's parent company, Canonical, seems open to
finding a solution to satisfy the popular distribution's concerns — but it
too has interests to consider.
Backstory
The Linux Mint distribution is based on Debian and Ubuntu, providing over 30,000 packages from these projects. These packages are provided using the well-known APT packaging system used by both upstream distributions. Ubuntu, however, in 2014 started distributing software in parallel to APT using a technology called Snap.
Snap is a self-contained package-deployment system designed to make it easier to manage dependencies of an application in a Linux environment. Developed by Canonical, Snap is designed so that its packages contain all of the specific dependencies a software package needs to run, bundled into a single filesystem image. This allows a software package to run on a system that has otherwise incompatible versions of needed libraries, or even to have two different versions of a single software package with different dependencies easily coexist on a single machine. Essentially, it allows one package to be created per architecture that can run on any common Linux distribution.
The technology solves important package-management problems for Canonical and Ubuntu. It also has a strategic business value, as it allows Canonical-managed software to be installed on a competing distribution. The technology problem Canonical wants to solve is to simplify support for software packages, such as Chromium, across the multiple versions of Ubuntu. Relying strictly on APT requires independent packages to be maintained for each Ubuntu version, since various Ubuntu releases ship with different and potentially incompatible libraries. This represents a large workload that Canonical would rather not deal with, and to which Snap provides an elegant technical solution.
From a business perspective, widespread adoption of Snap as a universal
package-distribution technology would put Canonical in a strong position to
control Linux software distribution. This fact is not lost by Canonical's
competition — Red Hat supports a similar Flatpak technology. Unlike Snap, however, the
Flatpak project aims to be an
independent community and a "true upstream open source project,
dedicated to providing technology and services that can be used by all, with
no vendor lock-in.
"
The problems with Linux Mint came to a head when Ubuntu moved Chromium to Snap distribution in Ubuntu 19.10. On the surface, that isn't a problem in and of itself — the Linux Mint project can always start providing its own Chromium APT packages. The problem was the decision to change the Ubuntu chromium-browser APT package itself upstream in Ubuntu. Previously, that package would simply install Chromium directly. With the change, it would instead install the Snap package-management tools first and then install the Snap equivalent of the Chromium package — without making it clear to the user what was happening.
This behavior isn't limited to Chromium either, Canonical is using this approach on other packages as well, such as gnome-software. This decision to use APT to install a secondary, commercially-controlled package-management system, which then installs the software the user wanted, is the center of the controversy with Linux Mint. As was reported on the Linux Mint blog when the Chromium change was made:
A self-installing Snap Store which overwrites part of our APT package base is a complete NO NO. It's something we have to stop and it could mean the end of Chromium updates and access to the snap store in Linux Mint.
What's at stake and recent events
The recent decision by the Linux Mint project isn't about Chromium or any single package, but rather about the entire approach Canonical is taking to Snap and APT. Snap packages are effectively black-boxes; they cannot be reproduced independently as the packaging data is controlled by the package maker alone. Further, the Snap package manager is locked into Canonical's library (called the Snap Store) so independent third-party Snap repositories aren't currently an option, either. While Snap packages can be downloaded and installed from other sources manually, doing so requires passing along a rather ominous --dangerous flag.
According to Canonical Engineering Manager Ken VanDine, the decision to replace APT packages with Snap is driven by efficiency, and to apply pressure in ways beneficial to Canonical. Regarding moving the gnome-software APT package to Snap, VanDine said:
By shipping such a key application as a snap it will continue to keep pressure on to ensure we keep improving the experience while also reducing our maintenance burden for the LTS and future releases of Ubuntu.
So while the Linux Mint project took action specifically when Ubuntu's
decision impacted the popular chromium-browser package, it seems
this was more of the tipping point for the project than an isolated concern.
According to the project, these moves from Canonical "could reduce
access to free (as in beer) software and free (as in freedom)
software.
" It wasn't a sudden decision either — a year ago the Linux
Mint project wanted to find a reasonable solution to the problem by working
with Canonical, however nothing seems to have come of those conversations. In
fact, it is unclear if any conversations happened at all.
What is known is that, when Ubuntu 20.04 was released a year later, the APT
package that installed Chromium still installed the Snap version without the
consent (or necessarily even knowledge) of the user. In response, the Linux
Mint project made good on its previous threat; starting with Linux Mint 20
"Chromium won't be an empty package which installs snapd behind your
back. It will be an empty package which tells you why it's empty and tells
you where to look to get Chromium yourself.
" In addition, Linux Mint
20's APT package manager "will forbid snapd from getting
installed.
" The project doesn't appear to be outright forbidding users
from using Snap if they want to, but doing so would require explicit
action from the user as "by default APT won't allow repository
packages [to install Snap] on your behalf.
" Presumably this applies to
any package that Ubuntu has migrated to Snap upstream — including both
chromium-browser and gnome-software.
It appears the decision had an effect, and prompted Canonical to at least discuss a change in course according to recent reporting by ZDNet. A representative from Canonical, quoted by ZDNet, said:
We would welcome Linux Mint to engage with us and our community to discuss such topics, as we do with other distributions, and work together going forward.
Canonical's community manager for Ubuntu engineering services, Alan Pope,
provided a justification specifically for the migration of Chromium to Snap.
The justification, however, didn't cite the idea of keeping
"pressure
" expressed by VanDine regarding other packages like
gnome-software:
Maintaining a single release of Chromium is a significant time investment for the Ubuntu Desktop Team working with the Ubuntu Security team to deliver updates to each stable release. As the teams support numerous stable releases of Ubuntu, the amount of work is compounded. Comparing this workload to other Linux distributions which have a single supported rolling release misses the nuance of supporting multiple Long Term Support (LTS) and non-LTS releases. [...]
A Snap needs to be built only once per architecture, and will run on all systems that support Snapd. This covers all supported Ubuntu releases including 14.04 with Extended Security Maintenance (ESM), as well as other distributions like Debian, Fedora, Mint, and Manjaro.
It will be interesting to see what if anything comes out of this to
facilitate a resolution between the parties. In its blog posts, Linux Mint has
mentioned various changes to Snap, such as allowing third-parties to run
independent Snap package servers, that might help get to a solution. As the
project wrote, "snap could work both as a client and a file format, if
it didn't lock us into a single store.
" Doing so, however, would
likely run contrary to Canonical's strategic goals.
What's next
It's important to realize that, fundamentally, a technology like Snap would be useful for those who create packages, including proprietary software vendors. The problem in this case doesn't seem to be the technology, but Canonical's sole control over it — and the way it's being introduced through APT. As the Linux Mint project stated in its 2019 post:
[Snap] was supposed to make it possible to run newer apps on top of older libraries and to let 3rd party editors publish their software easily toward multiple distributions [...] What we didn't want it to be was for Canonical to control the distribution of software between distributions and 3rd party editors, to prevent direct distribution from editors, to make it so software worked better in Ubuntu than anywhere else and to make its store a requirement.
Ultimately there are multiple interests at play here leading to uncertainty on how things will work out. On one hand, you have companies like Canonical that see the strategic value of controlling the technology behind application distribution, and is using it to apply pressure where it wants to see change. On the other hand, you have distributions like Linux Mint that are prepared to actively block the technology while it is controlled by a single commercial interest. Hopefully this latest move by Linux Mint will prompt a change toward more openness, as a packaging system like Snap implemented in an open way would be a win for the entire Linux community.
Posted Jul 8, 2020 17:42 UTC (Wed)
by mcon147 (subscriber, #56569)
[Link] (11 responses)
Posted Jul 8, 2020 18:15 UTC (Wed)
by revmischa (guest, #74786)
[Link] (10 responses)
Posted Jul 8, 2020 21:06 UTC (Wed)
by wazoox (subscriber, #69624)
[Link] (9 responses)
Posted Jul 9, 2020 7:23 UTC (Thu)
by Nemo_bis (guest, #88187)
[Link] (8 responses)
Posted Jul 9, 2020 9:39 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (5 responses)
Posted Jul 9, 2020 11:25 UTC (Thu)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Jul 10, 2020 7:37 UTC (Fri)
by alex (subscriber, #1355)
[Link]
Posted Jul 9, 2020 21:51 UTC (Thu)
by NGRhodes (guest, #132735)
[Link] (1 responses)
Posted Jul 12, 2020 6:24 UTC (Sun)
by ibukanov (subscriber, #3942)
[Link]
Posted Jul 14, 2020 11:05 UTC (Tue)
by ceplm (subscriber, #41334)
[Link]
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.
Posted Jul 9, 2020 10:29 UTC (Thu)
by timrichardson (subscriber, #72836)
[Link]
Posted Jul 9, 2020 12:51 UTC (Thu)
by simyannis (guest, #139986)
[Link]
Posted Jul 8, 2020 20:37 UTC (Wed)
by simosx (guest, #24338)
[Link] (9 responses)
However, `snapd` progressed and switched to protocol version 2.
You can either build your own snap package yourself, and then upload to the Snap Store.
There are 30000 packages in the APT package-management system. There are hand-crafted, and the packaging adheres to the Debian rules of splitting the dependencies in separate packages. If there is a new version of the source code of a package, it needs the packaging maintainer to perform the update. There is much more effort in doing all these, and there are always too few people to help.
Posted Jul 8, 2020 20:58 UTC (Wed)
by dowdle (subscriber, #659)
[Link] (5 responses)
'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.'
Posted Jul 9, 2020 5:39 UTC (Thu)
by simosx (guest, #24338)
[Link] (4 responses)
If you are not using command-line tools, you can look at the top-right corner at https://github.com/noise/snapstore
Posted Jul 10, 2020 17:30 UTC (Fri)
by atnot (subscriber, #124910)
[Link] (3 responses)
Posted Jul 10, 2020 21:54 UTC (Fri)
by simosx (guest, #24338)
[Link] (2 responses)
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.
Posted Jul 12, 2020 18:31 UTC (Sun)
by atnot (subscriber, #124910)
[Link] (1 responses)
Posted Jul 13, 2020 17:37 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 9, 2020 9:15 UTC (Thu)
by guus (subscriber, #41608)
[Link] (2 responses)
The snap packages are a way to circumvent the principles of a stable distro release. I personally think it's a bad idea, because now you will never get a stable version of Chrome, you will just get the latest version that fixed the old bugs but comes with a whole bunch of new bugs. It would be much better if Chrome would have LTS releases every two years or so that the Linux distributions can sync with.
Apart from all that though, I don't see a technical reason why they couldn't make a proper deb package of the latest version of Chrome + a copy of the libraries they need, with a source version, so you can reproducibly build it, and without needing yet another package management system.
Posted Jul 9, 2020 11:39 UTC (Thu)
by simosx (guest, #24338)
[Link]
In a typical snap package, you specify the APT package of a dependency. Does not deviate much from the process in creating a deb package.
In the very special case of Chromium, a specific new version is just a branch of the upstream source code with several of the dependencies added in there.
I do not know if you are packaging software in Debian or another Linux distribution. If a software is actually being developed, things change, and when you try to package a new version and you get issues, then it opens up a big fat can of worms. You may create a patch to make it work. You may communicate this patch with upstream, and then figure out whether it has been applied, fully or partially. How do you test whether the software actually works? Do you test it? Actually, it would make better sense if the developer had an installation package and have them test it themselves. Because they are more suitable to figure out if something does not work. In fact, with snap packages, a developer can use the automated Build server to create snap packages, test them, and then flip a switch to push to the Snap Store.
Posted Jul 11, 2020 9:57 UTC (Sat)
by riteshsarraf (subscriber, #11138)
[Link]
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.
Posted Jul 8, 2020 21:33 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link] (21 responses)
Licensing within snaps seems intentionally poor, I just downloaded the
So, random binaries that you can't reproduce, bad licensing, no
Posted Jul 9, 2020 4:12 UTC (Thu)
by ras (subscriber, #33059)
[Link] (10 responses)
Ye gods. Thanks for summarising it so well.
Is Flatpack any better?
Posted Jul 9, 2020 7:24 UTC (Thu)
by abo (subscriber, #77288)
[Link] (9 responses)
Posted Jul 9, 2020 7:49 UTC (Thu)
by tsdgeos (guest, #69685)
[Link] (8 responses)
https://flathub.org/apps/details/us.zoom.Zoom
Posted Jul 9, 2020 8:07 UTC (Thu)
by abo (subscriber, #77288)
[Link] (1 responses)
They could of course split the repo into free and nonfree, like many other distros and third party repos of various kinds do. But that's a choice made by the Flathub maintainers, either way would be possible with Flatpak.
Posted Jul 9, 2020 14:58 UTC (Thu)
by IanKelling (subscriber, #89418)
[Link]
Posted Jul 9, 2020 8:19 UTC (Thu)
by ras (subscriber, #33059)
[Link] (5 responses)
So does Debian. In Debian non-free there are binary blobs without source that run under Debian (as opposed to being firmware that runs on a different CPU). But that it's clearly marked - in fact not even available unless you manually add it.
Just as importantly the rest (which is the vast bulk of it) is truly open source - meaning it can be built from the source files available from Debian using a one line command, perhaps even reproducibly built.
The difference is not just just philosophical. The availability of source means Debian stable can be truly stable - security flaws have just the change needed to fix the flaw applied, as opposed to an entirely new version. And the open source programs have an audit trail from the binary to the upstream source, usually going back many versions. It's one of the few antidotes we have to Ken Thompson's "reflections on trust".
So the differentiator isn't whether they include proprietary binary blobs. It's whether the flatpacks that are open source preserve all the advantages of open source.
Posted Jul 9, 2020 9:37 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
That isn't always the case, especially for packages that are their own mini-distribution, like modern web browsers such as Chromium or Firefox.
Posted Jul 9, 2020 23:01 UTC (Thu)
by sheepgoesbaaa (guest, #98005)
[Link] (3 responses)
PDF link: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_...
Posted Jul 10, 2020 15:37 UTC (Fri)
by stephen.pollei (subscriber, #125364)
[Link] (2 responses)
Posted Jul 10, 2020 23:17 UTC (Fri)
by ras (subscriber, #33059)
[Link] (1 responses)
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.
Posted Jul 20, 2020 2:29 UTC (Mon)
by branden (guest, #7029)
[Link]
"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...
Posted Jul 9, 2020 5:49 UTC (Thu)
by simosx (guest, #24338)
[Link] (9 responses)
You claim an issue with packaging gnome-sudoku. As these are packaged inside VMs, it does not make sense why it would not be reproducible.
In addition, if you are not using the Ubuntu VM to build the snap package (invoked by snapcraft for you), then you are expected to find some issues here and there. Snap packages aim to run anywhere, and the snapcraft.yaml is not tested to build anywhere.
Posted Jul 9, 2020 13:45 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link]
Posted Jul 9, 2020 15:04 UTC (Thu)
by IanKelling (subscriber, #89418)
[Link] (3 responses)
snap download gnome-sudoku
It failed on meson trying to run something and finding no c++ compiler.
Where did I go wrong?
Posted Jul 9, 2020 16:02 UTC (Thu)
by simosx (guest, #24338)
[Link] (2 responses)
You used this process as a way to get access to the "snapcraft.yaml" recipe file.
Here is what you should add.
mkdir -p ~/MYSNAPDEVELOPMENT/gnome-sudoku
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.
Posted Jul 9, 2020 16:55 UTC (Thu)
by IanKelling (subscriber, #89418)
[Link] (1 responses)
Cloning into '/root/parts/gnome-sudoku/src'...
meson.build:1:0: ERROR: Unknown compiler(s): ['c++', 'g++', 'clang++', 'pgc++', 'icpc']
A full log can be found at /root/parts/gnome-sudoku/build/snapbuild/meson-logs/meson-log.txt
Posted Jul 9, 2020 19:35 UTC (Thu)
by simosx (guest, #24338)
[Link]
$ snapcraft --debug --use-lxd
I do not know why you are getting those messages.
Posted Jul 9, 2020 15:13 UTC (Thu)
by IanKelling (subscriber, #89418)
[Link]
It's the biggest problem I have with snaps. I hope it gets done!
Posted Jul 9, 2020 15:26 UTC (Thu)
by DigitalBrains (subscriber, #60188)
[Link] (2 responses)
I think you're using a different notion of reproducibility here than is common. Reproducability means I can download a binary compiled by someone else, and using the source code, verify that it was indeed built from *that* source. In essence, I will compile a binary myself and be able to prove the binary I downloaded is the same as my binary. This requires specific things in the compilation process, for instance, there can't be any timestamps of the build or non-deterministic behaviour in compilation.
Your notion of reproducability seems merely to say everybody can setup a build environment.
Posted Jul 9, 2020 15:43 UTC (Thu)
by IanKelling (subscriber, #89418)
[Link]
You're right. I shouldn't have said reproducible. I should have said someting like buildable, or rebuildable.
Posted Jul 9, 2020 15:48 UTC (Thu)
by simosx (guest, #24338)
[Link]
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.
Posted Jul 9, 2020 0:15 UTC (Thu)
by gouldtj (guest, #48027)
[Link] (4 responses)
Posted Jul 9, 2020 0:45 UTC (Thu)
by adam820 (subscriber, #101353)
[Link]
Posted Jul 9, 2020 1:02 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
If it was all done from scratch, yes but is there a reason they can't simply build off work that has been done in Debian and use Flatpak for the rest?
Posted Jul 9, 2020 1:12 UTC (Thu)
by kokada (guest, #92849)
[Link] (1 responses)
Posted Jul 9, 2020 18:28 UTC (Thu)
by mockturtl (guest, #140072)
[Link]
Not for a few years. It's based on debian stable (plus backports), with rolling updates for their own packages (mostly desktop-related).
Posted Jul 9, 2020 0:45 UTC (Thu)
by davecb (subscriber, #1574)
[Link] (4 responses)
Having two or more of them via flatpacks/snap/whatever is easier, IFF you can get valid ones in the first place. That's the hard part.
Posted Jul 9, 2020 2:00 UTC (Thu)
by gdt (subscriber, #6284)
[Link] (3 responses)
Furthermore, that a problem is NP-complete does not preclude cheaply-found solutions for most instances of the problem-set. The ongoing operations of Fedora and Debian suggest that there are cheaply-found solutions to the problem, and the occasional difficult problem is abandoned and the dependencies altered to make a simpler problem.
Posted Jul 9, 2020 11:43 UTC (Thu)
by davecb (subscriber, #1574)
[Link] (2 responses)
Regrettably, one doesn't always succeed. The "DLL Hell" Windows developers suffer trying to find a combination of libraries to build a single application is more due to the depth of the dependency tree than the size of the set of possible libraries. In their case, having lot of libraries and versions helps make a solution possible.
I first encountered it in Solaris, where my team, part of of linkers and libraries, ran a sat-solver over everything we built(!) At the same time we re-invented an older mechanism to strength-reduce the problem. A TL;DR description of that is at https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-...
Snaps and flatpacks mitigate the problem by reproducing the old Windows trick of shipping an app and all the libraries it uses, with the right versions. At the same time they avoid breaking other applications by dumping a "wrong" set of DLLs into the system, something that used to happen to Windows victims^h^h^h^h^h^h^h users all the time
Posted Jul 20, 2020 12:45 UTC (Mon)
by XTF (guest, #83255)
[Link] (1 responses)
Posted Jul 20, 2020 13:05 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 9, 2020 1:05 UTC (Thu)
by Richard_J_Neill (subscriber, #23093)
[Link] (5 responses)
The snapd and systemd designs conflict.
It's also not the most efficient thing either - the "pressure" would be better applied to keep the library versions in sync.
Posted Jul 9, 2020 13:46 UTC (Thu)
by evgeny (subscriber, #774)
[Link] (4 responses)
Posted Jul 15, 2020 17:29 UTC (Wed)
by smoogen (subscriber, #97)
[Link] (3 responses)
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 :(.
Posted Jul 15, 2020 22:22 UTC (Wed)
by zlynx (guest, #2285)
[Link] (1 responses)
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.
Posted Jul 15, 2020 23:35 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Jul 16, 2020 7:55 UTC (Thu)
by evgeny (subscriber, #774)
[Link]
Well, for me the fix was to stop using snap :)
Posted Jul 9, 2020 7:27 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (2 responses)
Posted Jul 10, 2020 8:58 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
Posted Jul 11, 2020 2:18 UTC (Sat)
by pabs (subscriber, #43278)
[Link]
PS: I'm one of the people in the bug complaining about it.
Posted Jul 9, 2020 9:08 UTC (Thu)
by Karellen (subscriber, #67644)
[Link] (8 responses)
I use Debian, rather than Ubuntu or Mint, so this doesn't affect me directly right now, and also I love that apt Just Works™. That said, I find the following language: overly inflammatory. Distribution packaging policy guidelines are detailed and nuanced, and often have many "should" and "should not" recommendations along with the "must" and "must not" requirements. Even then, the meaning of some hard requirements can be fuzzy and open to multiple interpretations by people all acting in good faith, which Debian sometimes requires the input of ftp-masters, the TC, or a GR to resolve. As a user of any distribution (other than maybe LFS) you implicitly grant distro maintainers the authority to manage the distribution as they see fit, according to the guidelines they lay down. At what point do the actions of a distro constitute acting "without consent (or even necessarily knowledge) of the user"? How complex is a post-install script allowed to be? If a package conforms to the distros own policy guidelines, or even if it bends some of those guidelines to some degree or other in ways that are accepted by the other distro maintainers, is that really "wrong"? It may not be what you want, or what you like, but if you want something different there are other places you can go. No-one is coercing you install Chromium under threats of violence.
Posted Jul 9, 2020 11:49 UTC (Thu)
by simosx (guest, #24338)
[Link] (7 responses)
It is weird and unfortunate that the Mint maintainer went into a full diatribe-mode to claim the "without your consent". As if he did not do his job properly and now wants to shift the blame of his failings elsewhere.
I will go further and say that there is this negative sentiment by some around snap packages, that they tend to blame snap packages for all sort of things that they do not deserve.
Posted Jul 9, 2020 13:11 UTC (Thu)
by mchehab (subscriber, #41156)
[Link] (6 responses)
Using snap (or similar technologies, like Flatpak) eats a lot of disk space for no good reason (from the user's perspective).
Snap is actually worse than apt (or dnf), as it keeps multiple copies of packages, as they get updated, wasting disk space. In order to avoid that, manual cleanup procedures are required to reclaim disk space:
https://superuser.com/questions/1310825/how-to-remove-old...
Doing that for things that are big, like gnome and texlive actually means a lot of wasted diskspace. This is particularly awful on VM images, where the amount of diskspace is usually very limited.
Posted Jul 9, 2020 14:23 UTC (Thu)
by simosx (guest, #24338)
[Link]
You can use the "refresh.retain" key to limit the number of older versions of the snap package.
Posted Jul 9, 2020 23:42 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (4 responses)
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.
Posted Jul 10, 2020 4:15 UTC (Fri)
by ccchips (subscriber, #3222)
[Link] (2 responses)
Posted Jul 10, 2020 17:13 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
- 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.
Again: Theoretically solved doesn't mean practically solved.
Posted Jul 10, 2020 21:47 UTC (Fri)
by simosx (guest, #24338)
[Link]
Posted Aug 12, 2020 14:15 UTC (Wed)
by mcortese (guest, #52099)
[Link]
Posted Jul 9, 2020 10:07 UTC (Thu)
by mvdwege (guest, #113583)
[Link] (1 responses)
I find this a bit of a useful heuristic: anytime an organisation tells you a controversial change is 'improving the experience', head for the exits, because they are no longer interesting in selling you something useful, but just the mere perception of such. I am not saying Ubuntu is doing that, but use of that vacuous marketing phrase is a red flag.
Posted Jul 9, 2020 11:56 UTC (Thu)
by simosx (guest, #24338)
[Link]
A browser is an important piece of software (this statement may also sound vacuous). And you need to get it updated ASAP once yet another vulnerability has been found and the fix has been released.
What you may be asking, is to see some extra paragraph in announcements that caters for power users.
Posted Jul 9, 2020 15:55 UTC (Thu)
by Comet (subscriber, #11646)
[Link] (1 responses)
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.
Posted Jul 10, 2020 17:37 UTC (Fri)
by atnot (subscriber, #124910)
[Link]
Posted Jul 9, 2020 20:38 UTC (Thu)
by ccchips (subscriber, #3222)
[Link] (1 responses)
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.
Posted Jul 9, 2020 21:28 UTC (Thu)
by simosx (guest, #24338)
[Link]
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.
Posted Jul 10, 2020 23:02 UTC (Fri)
by iteratedlateralus (guest, #102183)
[Link]
Posted Jul 13, 2020 8:40 UTC (Mon)
by n8willis (subscriber, #43041)
[Link] (1 responses)
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.
Posted Jul 14, 2020 16:36 UTC (Tue)
by feb (guest, #60129)
[Link]
Posted Jul 16, 2020 7:44 UTC (Thu)
by callegar (guest, #16148)
[Link]
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.
Posted Jul 20, 2020 13:36 UTC (Mon)
by qzPhUZ7af5M6kjJi3tDgMaVq (guest, #140267)
[Link]
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
LMDE was their backup project, if Canonical messed Ubuntu so much they could switch to that and dump Ubuntu.
Linux Mint drops Ubuntu Snap packages
The API is documented, https://github.com/snapcore/snapd/wiki/REST-API
Both the service (snapd) and the client (snap) are available, https://github.com/snapcore/snapd
If someone is really interested in creating a third-party Snap Store, they can figure it out rather easily.
Or you can use the Build service, and it builds snap packages for you, for six architectures (amd64, i386, armhf, arm64, ppc64el, s390x).
It should be possible to create reproducible snap packages because these are built in VMs.
If anyone wants to check, they can parse these packages and report back when they were last updated. I would be interested to see the results.
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Note that this is a starting point for someone that would like to start implementing a third-party Ubuntu Store.
where it says that there are 22 forks. Click on the **22**, and it will take you directly to repository forks that show the source code.
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Here is the cloned repository of Chromium that is used to create the snap package, https://code.launchpad.net/~chromium-team/chromium-browse...
The snapcraft.yaml file that creates the snap package is https://git.launchpad.net/~chromium-team/chromium-browser...
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
nonfree and free software without giving the user any way avoid nonfree
software without manually reviewing the license of each snap.
gnome-sudoku snap, and it has insufficient license information for
GPLv3+ which it is under. Building it failed after getting fairly far
within the VM the build downloaded.
differentiation between free and nonfree, and secret repo software
clearly designed for vendor lock-in. Reminds me of docker and nodejs. I
hope people demand better in all cases. It's clear that they were are
all designed from beginning to cater to nonfree software in many ways.
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
https://flathub.org/apps/details/com.spotify.Client
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
It is a low-hanging fruit and makes sense to those that really need it.
If you look into the snapcraft.yaml, you can easily check whether it locks into a git branch or whether it tries to build from /master/.
In the latter case, you obviously expect issues. You need to see the git commit hash in the snap package information, and switch to using the exact snapshot of the source code.
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
sudo mount -t squashfs gnome-sudoku_59.snap /mnt/4
cd /mnt/4
snapcraft --debug
Linux Mint drops Ubuntu Snap packages
And you tried to build it inside a read-only location. Snapcraft should install all the requirements
cp /mnt/4/snap/snapcraft.yaml ~/MYSNAPDEVELOPMENT/gnome-sudoku/
cd ~/MYSNAPDEVELOPMENT/gnome-sudoku/
snapcraft
Linux Mint drops Ubuntu Snap packages
...
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'
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'"
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
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
> It is a low-hanging fruit and makes sense to those that really need it.
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Whether this is offered as a future service, it looks to be easy to implement.
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Solution to the wrong problem
Solution to the wrong problem
Solution to the wrong problem
and I agree that making the problem space smaller is a possible way to mitigate it.
Solution to the wrong problem
Solution to the wrong problem
Snap-Chromium cannot be run by a daemon
(e.g. a PHP page invokes either "chromium --screenshot" or "chromium --print-to-pdf" as the Apache user)
then this is impossible.
https://bugs.launchpad.net/ubuntu/+source/chromium-browse...
Snap-Chromium cannot be run by a daemon
Snap-Chromium cannot be run by a daemon
Snap-Chromium cannot be run by a daemon
Snap-Chromium cannot be run by a daemon
Wol
Snap-Chromium cannot be run by a daemon
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
What is known is that, when Ubuntu 20.04 was released a year later, the APT package that installed Chromium still installed the Snap version without the consent (or necessarily even knowledge) of the user.
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
You can say the same when you use virtualization, or containers.
With snap packages, the snap itself stays compressed.
The default is 3, which means that it keeps the last three versions of a snap package. So that you can revert to a previous version without the need to redownload, as long as the older versions are in the same epoch (there are no changes that make a downgrade incompatible).
See more at https://ubuntu.com/blog/how-to-manage-snap-updates
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
- 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.
Linux Mint drops Ubuntu Snap packages
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.
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
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Still, a power user can deduce what's being said.
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
However, in most cases, the important libraries will be found in the "core" image, or the "gnome" image.
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages
Linux Mint drops Ubuntu Snap packages