Linux Mint drops Ubuntu Snap packages
lwn.net
lwn.net
> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.
This is a great summary of why people rightfully feel nervous about Snap. People run linux because they want visibility and control into what is happening on their systems. Canonical seems to want to take away that visibility and control from their users.
Edit: Are snaps images? ...like containers?
Edit 2: answer:
> mounted dynamically by the host operating system, together with declarative metadata that is interpreted by the snap system to set up an appropriately shaped secure sandbox or container for that application
Reading about the cons of Snap now - "auto-updates cannot be turned off" - https://en.wikipedia.org/wiki/Snap_(package_manager)
Even for client software it is bad - an app quitting out from under me because it wants to update is functionally equivalent to a crashing bug - but they're offering daemons this way, which is just insane.
Who doesn't want all their containers randomly restarting because someone up the distro chain decided when your machine needed to upgrade?
The cluster will not come up because your down node is now not the same version as the other cluster nodes.
This doesn't happen, at least on account of Snap. It's copy-on-write when it comes to updates, and whatever version you have running at the time of update will happily keep on running. I've been mildly confused by this a couple times, when I would end up with two different versions of VS Code running side by side, but the bright side was that my work wasn't interrupted.
It incidentally also sidesteps all the problems that stem from libraries or configuration being updated under a running application, which can happen with Apt.
127.0.0.1 api.snapcraft.io
Containers try to mitigate this problem but like a fever they often end up making things worse.
If Canonical provided the snap creation and hosting tools to the community I imagine it would be judged on its technical merits.
As it is, I see more and more reports that Canonical is trying to gain more and more control and that's exactly what I don't like to see.
Would have tried Ubuntu but they've poisoned that well. I'll have to recalculate.
The best known manager that does allow this is Nix, do you know of any more, maybe ways to get this working with "traditional" package managers (completely transitioning to Nix is would be quite hard, from my limited experience)?
glibc does have a stable ABI. What they don't have is a frozen ABI so they will all new entry points. But old programs linked against glibc do and will continue to work fine.
> You can't run a program written today on the system repo libraries from 5 years ago.
You can absolutely write programs today targeting 5 year old ABIs. I agree that the FOSS toolchains could be more helpful there so you can just pass some compiler flag for the oldest glibc version you want to support but it is not impossible to achieve that on your own.
Not my favorite to install software since they're usually huge (500mb is not far out of the norm), but great for things that are hard to install, as they're pretty much guaranteed to work.
I just wish there was a command line switch to stop it from wanting to install itself on my system (move the AppImage to /opt).
I'm wondering now if Wikipedia would be appropriate to host a linux sandboxed app packaging comparison chart in the form of https://linuxhint.com/snap_vs_flatpak_vs_appimage/ - and it would be extensible ...since Wikipedia.
Saying "just use an alternative" seems overly dismissive of the complications that entails.
IIUC, the only options for that are (a) abandon Ubuntu, or (b) actively circumvent Ubuntu's software distribution infrastructure, reminiscent of dealing with Windows 10 forced updates.
IMHO this somewhat erodes Ubuntu's value proposition.
Now I know it's not going to be Ubuntu or anything else derived from Canonical.
Why avoid Ubuntu derivates like Mint or Pop!_OS, though?
They're doing the heavy lifting of fighting Canonical on this issue. Maybe using one of those distros instead of vanilla Ubuntu actually strengthens the pressure that Canonical feels on this topic.
If I know I can avoid Snap crap by changing distros for now, that's what I have a timeslice for.
Also sandboxing and running apps under reduced permissions makes a lot of sense but should be seen as a tool to increase security not an answer outright as poorly used any tool can be less effective or even harmful.
Historically locking down increasingly effectively often leads to impeding things the user actually wants to do which leads to apps asking for and granting permissions with the net effect of training users click yes to enable whatever the app wants to do.
It ends up being not just a technical challenge but a psychological one as well and its less easily resolved once you start having to deal with real users.
I also think that so far Linux distributions have done very poorly when it came to cross-distribution/forward/backward compatibility of packages. This is a non-issue for popular Opensource packages since they can be easily packaged by the distributors. But not so popular packages sometimes need to be installed in a hacky way when they are not available for the target distribution. Even worse when dealing with commercial software, it can happen that it degrades with each distribution update.
Also I think that probably the package format will improve over time and add additional features, that would allow auditing for instance. Also with proper de-duplication (perhaps even on filesystem level) it should be possible to also deal with waste of space.
(Disclaimer: I'm talking in a personal capacity but the company I work for in my day job now owns Red Hat - I don't work on Linux Operating Systems).
This is interesting, because the last few days I was actually working on packaging an application of mine as a snap/flatpak.
From my PoV, they both have their fair share of issues.
Snaps enforce a sandbox, which I think is actually a good idea, because the desktop security model is somewhat broken. If your application cannot run as a sandboxed app, you need to be granted special permissions by canonical after manual review (my app needs this), where they also discuss if they can make a new permission in a safe way for your usecase that everyone can use afterwards.
On one hand this sucks because I need to ask canonical for permission to publish something, and there's no certainty that I will get these permissions as a nobody for a new app nobody ever heard of before. On the other hand, I think I like that they're doing something about the desktop security model.
The next problem is, if this is denied, how do I ship updates? Provide a self updater? Easy to write, but if everyone does that, we can just go full windows and abandon package managers. Tell people to just curl | bash? That's not more secure than a potentially shady snap.
But I do have to praise canonical for being very helpful in IRC and the forums for helping me debug issues and file bugs against snap stuff.
Now flatpak on the other hand, just feels kinda weird to me.
It sandboxes things, but every application can pretty much grant itself access to everything. This is a completely different philosophy, but if you rely on everyone tightly sandboxing their applications without granting themselves permissions for sandbox escape, I think something like landlock[0] (when it lands) or pledge is much more suited for this, and baked into the application.
Then there is this weird thing where flatpaks force a runtime on you. My application is a statically linked go binary. But flatpaks pretty much want to force me to add an entire freedesktop suite as a dependency, as you simply cannot choose no runtime.
(Community-)Support for building flatpaks? Pretty much non-existant.
So yeah, the entire linux upstream-packaging situation is still quite depressing honestly. And with the time and energy I have invested into this by now, I could have written a simple but sufficient self-updater about 10 times over.
[0]: https://landlock.io/
Just wanted to easy one worry of you: the age, popularity and maturity of your application has no influence on whether or not these permission requests are granted. The approval process is formally defined and mostly depends on what your application does exactly.
You can find the specific processes in the docs at the bottom of this page: https://snapcraft.io/docs/permission-requests
For me the only acceptable solution besides proper .debs are AppImages. AppImage doesn't try to "replace" the package management for desktop apps like the former two candidates. It tries to complement package systems for some special cases (like for example commercial software, or for the cases where the user "just wants to try something out" without "polluting" the whole system with a lot of dependencies).
For my desktop needs AppImage is like "Docker, the good parts". A simple self contained format that runs everywhere without any further dependencies. Compared to that Snap and FlatPak are bloated annoyances.
So out of curiosity:
My application is already self contained and statically linked, so no AppImage needed, but it behaves like one, you can just run download and run it everywhere. And so what you're describing will be for sure an option for those who like it (in fact currently it's the only option in alpha).
How would you like to get updates for something like this? Visit the website yourself occasionally to check for updates? Have the application notify you a new version is available? Have an integrated updater so the binary can update itself?
Stuff like AppImage, static binaries, Docker & Co are for me at least a kind of "last resort". Even I'm using Docker a lot[1] to try things out I first look for an AppImage in those cases. But when I decide that some app should become part of my system I will look for a proper package. One source to rule them all…
[1] Docker is a big problem on it's own. But as I can't avoid to have it installed because of work I decided I could use it at least to "keep experiments under control". Before I was forced to have Docker I've used systemd-nspawn for that use-case.
Appimages are great but there's no sandboxing or updates. But hey, we used to downlad debs and install them by hand on Debian 1.3, before apt was a thing. Maybe appimages could be signed and distributed in a similar fashion.
What do you mean? There's debian go packaging team: https://go-team.pages.debian.net/ as well as go packages in stable (for example https://packages.debian.org/buster/influxdb)
Actually there is sandboxing and updates, if you want to take an extra steps.
I prefer AppImages over Flatpack and Snaps for essentially the same reasons commented above.
I typically launch them with Firejail for the sandboxing. i.e. "firejail --appimage /path/to/appimage" instead of just the appimage alone. Seems to work just fine. Firejail has additional options that can be done.
Some AppImage creators do provide an update method that can be installed using zsync2, but I've not tried it since the whole point is disposability.
In addition, Debian definitely does package Go programs -- they've packaged some of mine and they have possibly the most ambitious way of solving the great vendor/ issue (which most other distributions have ignored).
The likely issue with LXD is that they require specific versions of various system libraries that they package in their source code bundles (including a fork of sqlite3!). I packaged LXD for openSUSE[1]. It wasn't really fun, but it is fairly doable if you have a flexible enough view on "good packaging practices" (and I imagine Debian packagers didn't feel like going through all the necessary workarounds -- which includes patching the ELF binary in the openSUSE case). And note that LXD isn't even a static binary -- I tried to compile it statically to get around a whole range of issues and it was a nightmare.
[1]: https://build.opensuse.org/package/show/Virtualization:conta...
I know nothing about AppImages, but up above someone said they do have updates: https://news.ycombinator.com/item?id=23773878
* Linking with system libraries (what GP mentioned).
* Linking with Go packages (what you're talking about).
I’ve often came across orphaned packages where Debian was stuck with an old version, but didn’t know what to do about it other than installing from source. Or using a PPA if I was lucky.
0: https://www.debian.org/doc/manuals/debmake-doc/index.en.html
However, you could also include a facility to manually check for updates and either self-update or just show the changelog. Why manually? "I know you're about to do this thing real quick that needs to get done, but a new version is available! Would you like to twiddle your thumbs for 5 minutes while watching a progress bar?".
That's a very Windows-centric point of view. Programs on Linux can be updated without closing them. You get the new version when you restart them.
sudo apt update && sudo apt full-upgrade -y && sudo apt autoremove -y && echo 'All done!, rebooting' && sudo reboot now
For everything else.
Now if the process tries to access some datafiles that changed contents during the upgrade, it might just crash and burn, eventually corrupting data in the process.
I'd want it in an apt repo, really.
I've seen all three approaches with AppImage'd software.
There are also package managers specifically for AppImage'd software, though it doesn't look like any of 'em are particularly mature.
I much prefer Debian packages over RPM, and Apt over Yum/DNF, but unfortunately setting up a Debian package repository is more difficult than for RPM. The tools exist, and are more sophisticated and capable--for example, Aptly--but there's a higher learning curve. Also, good luck using them outside Linux. Years ago I published Debian package repositories from OpenBSD, but I had to manually hack the relevant tools to build and work on OpenBSD. For RPM/Yum I could have more easily written (and at a different job later did) an indexing tool from scratch.
The problem with Debian packages and Apt repositories isn't that they're not capable, it's that they have high learning curves due to the slow accretion of features that obscure their potential. A better tooling story would help, particularly for repositories. Better tools for initializing Debian package builds exist; the problem is more a surfeit of choices.
[1] It's more complicated and creates unnecessary headaches than dropping a file into trusted.gpgp.d, but the practice seems to reflect the opacity of the Debian packaging ecosystem. There's a better, simpler way to do it, but everybody cargo cults the same old solutions and then complains that it's too complex or inelegant.
https://docs.appimage.org/packaging-guide/optional/updates.h...
Mint also has Debian based distro.
1) Application won't need root privileges
2) Without compromising on the systems security
I think fixing what we have in standard kernel/userland, and leaving the containers for specialized developer/devops deployed workloads may well be where this (what will be known as the snap/flatpack saga) started from, and will end as well.
However, a quick note: As someone who unofficially maintains a linux port of my companies software, I have considered packaging it as an appimage, but there's one problem with appimages that kills the concept.
Appimages are read-only[1]. I'd love to package my companies product that way, but we already have update-delivery infrastructure that works on windows and mac (and linux), and it assumes it can write to the "install folder". Changing the entire update infrastructure specifically for an OS we don't officially support is a non-starter.
From a developer perspective, I would love the ability to update an appimage's contents in place. However, as a user I'd also like the ability to set it read-only to block updates if I desire. Flatpak's mandatory updates are one of the key reasons I dislike it. Never the less, if the goal is to smooth the path for proprietary software to support linux without making half a dozen different packaging solutions, in place updates need to be supported.
[1] edit: according to comments below, they now have an update mechanism, but it's still a totally appimage-specific process, so my problem remains :/
...why not make a new release and ship that? That's the way package managers work. Developer makes a package. User installs the package. Then when developer fixes some bug and releases a new version the user can install the new version when the user decides it's necessary.
The whole point about this is that it's user-centric. That's good.
This has burnt a few projects pretty badly (especially where distros have packaged an old version and never updated it).
As for sandboxing with Flatpal - AFAIK this is all intentional for the time being. The authors have ckearly statet their initial effort targets app dependency isolation and app portability, not security just now. That is much harder to do without severely limitting useful applications in what they can do.
I have encountered incomplete sandboxing systems that strived for security in past and it has not been a good experience.
For example I had the onr and only official Ubuntu Touch tablet, which used a predecessor of the Snap technology. One day I wanted to show my friends a couple photos from a micro SD card. I put it in to the tablet, bit no photo viewing app could show photos from the card.
Why ? Because back then you could only open files from outside of the apps sandbox one by one using a special system controlled dialog. Not really usable for hundreds of photos and forget about a text editor or an IDE.
This is where I like Flatpak - it gives you all the goodies of app separation and portability without all the hassle of a strict but unfinished secure sandbox. You only need to make sure you are getting the software from thrusted sources.
A I think that's something one should be doiny anyway, even with a strct sandbox - if it can't support basic app use cases, who knows what security holes have the authors left in it...
That's a weird criticism to have of Flatpak. The FreeDesktop dependency is the base set of libraries all flatpaks have access to. You don't have to use it. In fact Freedesktop is a great idea, to provide a base framework applications can use that goes further than just libc. If we want Linux on the desktop, we need a common desktop framework interface.
It would be like being unhappy a static go binary on Windows COULD access all of the win32 libraries.
Also, Flatpak currently is best suited to GUI apps. If your go binary is a GUI app using either GTK or KDE, these will need the freedesktop facilities (such as D-Bus) to actually run properly.
In addition: users always have the option to override permissions. The approval process is for automatic (default) permission grants. Even if these are not granted, users can grant them manually.
The specific processes for approval are listed at the bottom of this page: https://snapcraft.io/docs/permission-requests
Which is what Apt has done for 20+ years - packages are gpg-signed, developers sign with their individual keys (and have to have their identity verified by at least one other developer) and even someone who controls a root CA (which is most national governments and many large corporations, let's be fair) would have to mount a dedicated attack to subvert that process.
AFAICT,debian packages themselves are not signed, just the repository release files are gpg-signed.
It is bashed by those who value reproduction and discoverability:
* every person receives same script, confirmed by signature
* multiple mirrors, no single point of failure, no pull out by author (left-pad)
* no silent update (browser addons)
* tested to work on your system
* clean remove of installed files
* search in packages not in web (anti fishing)
* hosted in secure environment
* watched by many eyes
That's the longest spelling I've ever seen for a three-letter company.
Like, in terms of user experience it's about as close to the Windows-style "download this .exe and run it" approach as one could get, though it'd be interesting to see a macOS-style "put this .app in your ~/Applications" approach as well (which should be doable with a daemon watching such a folder and generating e.g. menu entries and such, as an optional component or perhaps a feature of the desktop environment itself).
Criticism specifically regarding Flatpak: https://flatkill.org/
However, ignoring the aspect of software distribution, wouldn't you agree that the approach taken by the Linux desktop today is deficient security-wise? For example, I would like to be able to give mbsync (or Thunderbird or whatever) my IMAP password without giving it to any other program. So I don't want to store it in mbsync's config file in plain text. Neither will I use gnome-keyring (or any other keyring) because it doesn't have any kind of "program authorisation". Any program can just spawn a new "secret-tool" process and get my credentials from gnome-keyring.
I've been thinking for a while about implementing a keyring which runs as a daemon with SUID of a dedicated user and checks which program sends requests to it, using /proc/pid/exe, but I'm not sure if it's a secure source of truth: how e.g. namespaces affect what's visible in /proc/pid/exe. I know you've been developing himitsu[1]. Have you thought about this problem in that context?
Issues mentioned on flatkill are already fixed, will be fixed or doesn't depend on flatpak itself (like the UI / icon in the software app store).
I don't like Flatpak either but I think we should elevate the debate to deeper architectural issues of flatpak that won't be fixed easily. Personally, I do not like the following in Flatpak :
- no effort on full reproducibility like Nix&Guix
- a big fat flat runtime rather than traditional fine grained dependencies (although OStree avoids duplication, but still very elegant)
- you can't install extra pkg in the sandbox. So the quite overkill solution in RedHat's vision is to separate between Toolbox/Podman for devs vs Flatpak for users, rather than trying to make a single unified sandbox for everything. Of course everything breaks down when you try to code using a Flatpaked IDE, if you follow RedHat's vision you basically need to spawn a toolbox container from an unsandboxed flatpak instance of your IDE : https://github.com/flathub/com.visualstudio.code/issues/44
So personally, I'm still waiting for a packaging system that is :
- compatible with the idea of a declarative/immutable os (like nix, guix, silverblue)
- tries to make everything reproducible (like guix)
- sandboxed with runtime permission API (like Flatpak portals, IOS, Android)
- sandbox can be augmented with packages so that you can code in your sandboxed IDE + add necessary dev packages inside a same sandbox without having to break it
In particular, it's easy to inspect the sources for apt packages using "apt-get source". Snap seems to have no equivalent command.
It doesn't have to. Packaging using FPM [0] allows many targets (deb, rpm, etc) and using ELF2deb [1] (shameless plug) allows packaging any files to a .deb with no effort.
As long as Linux Mint developers are not doing that how it helps you? you don't trust Canonical binaries but you trust the deb binaries, you could be honest and claim that you don't like snap but you still trust the deb binaries.
The point is that you can audit without having to depend on a third party. Nobody's claiming audits are free or that they're assumed. The point is that you have the option to choose to trust as much or as little of the build chain, from the compiler to the target code to the artifacts.
- Mint uses Ubuntu repositories
- Canonical pushes the changes they want into this repos, this changes are probably done by scripts that build source code on Canonical servers.
- the Ubuntu repos also contain binary blobs
- when a Mint user does an update he gets the binary directly from Canonical servers, there is no Mint dev or Mint script that does any check to see if for example the evil Canonical modified the NVIDIA driver and added even more evil in it then already is
Now explain to me if all the above is true why would someone that does not trust Canonical would use Mint? There is no safety checks to prevent evil Canonical people do evil things.
My conclusion is if you don't trust Canonical don't use Mint. Maybe Mint is working on addressing this and soon we will see an PR campaign that announces they are finally able to self host but until then I would stop the hypocrisy about not trusting Canonical. (Btw there are many smaller distros that can host their own repos, not sure why Mint is not doing it)
* Nonfree software is generally demarcated as such. There is nonfree software that has available source (in the case of some codecs), other that comes as blobs.
* The Chromium package is open source, and in most distros comes as binary built from the toolchain set up by the package maintainers. In all free software distros if you don't want to download the binary, you can download the source and build locally with the provided build scripts (in the case of most APT packages in Debian/ubuntu).
* Serving Chromium binaries with Snap removes the option of downloading, inspecting, and running the build chain locally
* Serving a different version of Chromium, or replacing the stock version with a different variety, cannot be done without creating a new Snap repository. Downstream distros like Mint need to replace some of the stock Ubuntu stuff, just like Ubuntu changes stock Debian packages
* Because there is no open source Snap repository software, Mint is unable to set up an alternative repo that could work around some of the objections they have with Ubuntu.
Again, if Canonical is evil and can't be trusted why I would run Mint? Do the developers run any scripts to alert me if Canonical slips some bad thing in a binary?
I think is fine if they remove snaps but IMO is stupid to accuse Canonical to be evil and not trustworthy while you blindly trust their repos.
Rational self-interest. I don't think the tech giants are good for society, but not working with them would mean slipping into irrelevance.
Say, I'm a game developer. Do I trust Microsoft? No. Do I sacrifice 90% of my profit to boycott Windows? No. There are different degrees of "evilness", and the scale does matter, too.
Honestly tell me if this does not sound idiotic "Microsoft is evil and we don't trust them, please run our own Windows copy that is the exact same thing but with different colors, MS can push an update and delete all your files because this is not a supported configuration and we have no scripts to check for it but we are not competent enough to setup our own repos and scripts like other distress"
I understand why Mint does what it does, the only idiotic part is complaining about trust in Canonical.
This is the same in apt as it is in the Snap Store. Compare https://snapcraft.io/chromium to https://snapcraft.io/spotify for example: the license field is clearly presented there.
> * The Chromium package is open source, and in most distros comes as binary built from the toolchain set up by the package maintainers. In all free software distros if you don't want to download the binary, you can download the source and build locally with the provided build scripts (in the case of most APT packages in Debian/ubuntu).
Also true for the Chromium snap (see next item for details).
> * Serving Chromium binaries with Snap removes the option of downloading, inspecting, and running the build chain locally
This is outright false. The Snap Store page for Chromium is available here: https://snapcraft.io/chromium. It links to the source, which is the git repository here: https://code.launchpad.net/~chromium-team/chromium-browser/+.... You can use these source together with snapcraft (which is Free Software, licensed under GPL-3.0) to download, inspect and run the build chain locally, including with any modifications that you want to make. You'll get a snap package as output, which you are free to distribute and other users can install it using the snap CLI.
> * Serving a different version of Chromium, or replacing the stock version with a different variety, cannot be done without creating a new Snap repository.
Partly false. You can ship a different version of Chromium in the Snap Store under a different name. This is an automated process, rather like creating a PPA. As long as you aren't misleading anyone and you follow the terms of the relevant licenses[1], nobody will stop you.
> * Because there is no open source Snap repository software, Mint is unable to set up an alternative repo that could work around some of the objections they have with Ubuntu.
Partly correct. One generally cited reason for this is that the same criticism was leveled at Launchpad which was opened in response - but nobody is running an alternative production of Launchpad anywhere so Canonical doesn't want to waste that sort of effort again. Another is that store fragmentation is bad. I'm just stating the other side's position here. Please don't shoot the messenger.
[1] Chromium's licenses are listed as: Apache-2.0 AND BSD-3-Clause AND LGPL-2.0 AND LGPL-2.1 AND MIT AND MS-PL AND (GPL-2.0+ OR LGPL-2.1+ OR MPL-1.1)
When I update Mint binaries, I get them from one of about 30 mirrors which Mint enables me to choose. (Or it will decide for me based on speed.) Do the mirrors at Clarkson, Harvard, Purdue, UW, etc belong to Canonical? I think not. Nor does most of the code the binaries are built from.
Canonical has made its choice, Clem's made his.
I would convert the next sentence in math logic and prove you that it makes no sense but not sure you can understand the symbols so let me try again in English.
1 Mint does not trust Canonical
2 Mint plugs their users systems directly to Canonical untrustworthy repos to run possible "evil" binaries and scripts as root.
if 1 and 2 are true then as a user you should not use Mint, as a Mint developer you should start working and finally create an independent distribution.
IMO 1 is false, probably they mentioning "trust" was a mistake.
> 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.
I think it should be noted that this generally applies to the addition of "third party apt repositories" in general, use of which is the problem that snaps fix[1]
Some snaps are built from Free Software and reproducible sources, as are some third party apt repositories.
In other words, if this criticism bothers you, then you should never install from any third party apt repositories ever. If some are acceptable to you, then so should some snaps.
If you don't want to use third party software ever, then you can still use Ubuntu without snaps.
[1] Third party apt repositories often break users' systems.
This does not follow at all. Third-party apt repositories work just like Ubuntu's apt repositories; you have just as much ability to audit, hold, pin, etc. in both cases.
If there is a difference in reliability (software from third-party repos is more likely to break your system--and, btw, software from Canonical's repos has also broken systems in the past, so "avoid third party repos" is not a guaranteed way to avoid software breaking your system), using snaps to install third-party software instead of third-party repos does not fix that problem: the third-party provider is still just as unreliable as before and their software is just as likely to do something stupid.
Again, it all depends on how much you trust the third party compared to how much you trust your distro provider. I don't have many third party PPAs installed on my computer because there aren't many third parties I trust that much. But there aren't zero either.
Also, a big part of my trust of my distro provider is based on having source code forced to be open, and another big part is based on them not doing things behind my back. Snaps significantly erode both of these aspects of trust.
Perhaps we should consider why this is: because people want up-to-date software on their computers (desktop or server), instead of being beholden to whatever version distribution maintainers have decided you can have.
I understand the _reasoning_ behind the distribution model - I just don't think it works very well, and apparently nor do all the people who use PPAs in the course of everyday use to get up-to-date software.
It's also worth noting that FreeBSD does not have this problem - ports are updated _much_ more often than most Linux distributions seem to be.
Originally you said audit, hold, modify.
You can audit snaps just as you can audit third party apt repositories. Either the publisher ships the source such that you can rebuild, or they don't.
You can hold snaps using this method: https://forum.snapcraft.io/t/disabling-automatic-refresh-for...
You can modify snaps just as you can modify what you get from a third party apt repository. Either the publisher ships the source such that you can modify and rebuild, or they don't.
I didn't; the post you were originally responding to (the GP of my original post, which is the GP of this one) did. I am not the person who made that post.
You appear to be saying that you can audit, hold, modify, pin software in third-party repositories. That means you agree with what I was saying in the GP to this post, that you have just as much ability to do all these things with third-party repo software as you do with software distributed using snaps.
I can set up an internal APT mirror for my users, servers, test systems, etc., but I can't set up an internal snap mirror as far as I can tell. This means that despite having an internal repo that I can whitelist, some package installations will now arbitrarily require internet access. I can no longer install chromium on a system without access to the internet, and package installation will fail as a result.
I'd rather have an older version than a snap version, personally, but better would be two packages which Provides: the same chromium-browser, chromium and chromium-snap.
The most irritating thing here is that they're using a package distribution system which handles dependencies and updates flawlessly, and has for decades, and using it to install things using a package system which does not solve those problems, and instead ships multiple copies of multiple libraries and applications, which run slower, ignoring any settings I have in APT.
So far, it's a maintenance nightmare, and I loathe it.
The limitation stems from a design problem, details at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706.
At this point snap sounds like a bad joke to me. Especially when Flatpak already exists.
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552
Besides, there are quality concerns with browser forks maintained by an understaffed project. The fact that ungoogled-chromium asks for internet randos to provide its own binary releases doesn't inspire confidence either. If someone desperately needs to use Ubuntu, they'd be better off using Firefox.
OK, "forever" is hyperbole - it was probably about 5 seconds. But it was enough of an annoyance for me to figure out how to install a deb packaged version. And every user having to wait an extra 5 seconds every time they open an app aggregates to a lot more time than Canonical saves maintaining packages.
That doesn't sit right with me, so my next OS upgrade will be Mint or pure Debian. I've been with Ubuntu since Dapper Drake, and I'd like to thank Canonical for making great distros all that time. But I'm not going to follow you down the snap-only path, time for me to move on.
> so my next OS upgrade will be Mint or pure Debian
I've moved one machine to debian stable and haven't looked back. There are a few teething issues like /usr/sbin not being in the default path, some sudo issues, the installer isn't as grandma friendly, but it's rock solid and doesn't nag me about updating 137 packages of things I've never heard of needing an update.
If someone is debating just setup rasp with headless ssh and have at it.
I can see that Mint could be nice though. On a desktop, running hardware a few years old.
ArchLinux NOT Manjaro
Debian NOT Ubuntu etc
And so on, the 'originals' work always better in the long run.
Except that normal people can actually install Manjaro and it doesn't make you use AUR for pretty basic things. Except that Ubuntu actually doesn't shit itself almost every time you add a 3rd party package/repo and comes with reasonable defaults. Also, have you used Pop OS?
Your statement is quite simply untrue.
And when 'normal' people try to fix a problem with a rolling distro then they have a problem.
>Except that Ubuntu actually doesn't shit itself
As if that's a problem in Debian, or are you talking about snap's?
>Also, have you used Pop OS
No thanks, using OpenSuse Tumbleweed, FreeBSD, Debian and CentOS is perfectly fine for me.
I was impressed because usually when I install Arch Linux I forget to boot the flash drive with UEFI enabled so I get stuck because I get errors during bootloader installation. I also love to do pointless things like install Arch Linux (not the iso) on a 32GB flash drive.
I'm using debian testing for more than 15 years and it never shit itself for a 3rd party repo.
Debian comes with whathever the original software developers set as the default sans the wallpaper. For sensible default you can bug the software developer in question, not debian.
To add unstable packages to a stable system with repo pinning and using apt directly is not the best practice though.
If I'm going to add stuff from unstable, I use aptitude. Its dependency resolution and solution suggestions are better and more manageable than ordinary apt. It allows you what's going to happen before actually pulling the trigger.
The only package I get from unstable is firefox. I add the repo, update the package and remove the repo afterwards because unstable and experimental are highly chaotic realms and not suitable to use continuously due to high rate of uncontrolled change. Also unstable and experimental are not guaranteed to not to break. Testing and stable are implicitly (testing) and explicitly (stable) is guaranteed to work.
With this recipe, I only had to re-install a Debian system once; to migrate it from 32 to 64 bits since a very big disk cache with very small files was triggering a bug causing disks to trash and system slow down to a crawl. There were no procedures to migrate a 32 bit system to a 64 one in a reliable manner so, I just reinstalled it.
For the longest time you couldn't dist-upgrade it, at all. The functionality wasn't there. When their web servers got hacked, they cleaned them, and got hacked again.
From a Debian user's perspective it is unclear why these small distros can't just be a Debian derivative or a Fedora spin. It's not scalable that every small distro invents their own infrastructure.
Like, I ain't crazy about what's happening with Mint and all of their hacks -- trust status: eradicated -- but I certainty get why they exist as a distro.
For me, the stability of it working (well) as it has for the last few decades is worth missing a few of the latest updates.
Short version: Canonical does classic vendor lock-in with his Snap Store. I'm pretty sure 99.9% HN users knows what it means :)
It's a commonly requested feature and being able to move it would follow the Freedesktop.org spec, but the developers don't care.
$ ln -s /somewhere-else ~/snap
If anything has to be installed in the home folder for some reason, it is supposed to go into .local, so the user doesn't see it among their documents and photos.
[1] https://en.wikipedia.org/wiki/Hidden_file_and_hidden_directo...
It's a completely insane stance for server systems. (I believe it's still possible to run server systems without snaps with various "workarounds" etc, but we can feel which way the wind is blowing...)
> Snaps are completely redundant there.
Yes, they certainly are but it seems to be harder and harder to get rid of snapd. It's probably not going to be an actual issue for Focal, but it's about this trend... Maybe Canonical will see sense -- who knows?
Meanwhile, I do have to at least have a broad plan for the next 2-5 years, so...
Debian stable is an obvious choice for projects that don't rely on too much "new stuff" because we already have a lot of stuff that uses APT, deb repositories, etc. Otherwise, probably CentOS/RHEL for those situations that are just ultra-averse to incremental change and prefer a HUGE change once every 5-10 years.
I think we might become a bit more adventurous and move to e.g. NixOS for "newer" projects. That's probably going to have to be trialed for a few projects before we go all in on it, but it seems really nice for servers (and dev machines for that matter), but it'll be interesting to see if you have to truly go all in to reap the benefits. (The worry here would be the amount of upstream 'support' in terms of manpower to bring in security updates, etc.).
(I'm also vaguely aware of SuSE, but I only spent a very brief period of time with it about 10-15 years ago and don't really remember any distinctive features either way. Which is kinda weird, because it seems to be known as the 'popular in Europe' distro?)
tbh I just run linux because I want a good dev machine and I personally don't care if canonical abstracts updating software away, as far as I'm concerned they can keep everything up to date and do their thing, for me that's a plus for snaps, I generally find them pleasant to use.
In my experience people on HN in particular tend to vastly overestimate how much people value control vs features/abstracting routine tasks away.
The Microsoft way: over-automated operating system DE's which attempt to make the OS appear user friendly yet create one headache after another. They suffer from massive interconnected webs of program state and logic which fails leaving you with the only sane option of rebooting. The more automation the vendor inserts the less transparency and control you have.
I mean, not really? Or rather, that's not the only reason, or the main reason for many users.
Many people just want to use a FOSS OS, for the reason that any buggy component can be forked, fixed, and PRed, which—if you're an IT organization yourself—often means far less turnaround time than waiting for the appropriate vendor to fix the problem for you.
Honestly, I'd be fine using Windows Server or some other "cathedral" OS, if I could fork/fix/PR its components. I want a stable operational substrate for my app that's quick to fix in an emergency; I don't care whether it's made out of tiny shell-scripts or huge C libraries, as long as it gives me that property.
In that perspective, snap seems fine (you can still fork/fix/PR a snap) just like Docker images are fine, or systemd is fine.
Maybe, in the end, I'm more of a BSD person than a Linux person. I mostly favor Linux installs for the hardware compatibility and performance, not because it really fits my philosophy.
To top it off, a couple months ago my calculator disappeared. For some reason I have been having problems with snap applications disappearing for a while now, even though I have made no configuration changes. How fun it is to discover that such a basic tool just no longer exists on your machine, way to fuck up a morning.
I get that snaps make application distribution easier, but please don't do it at the expense of the user. I've had more success with Flatpak and AppImages, but not enough experience with any of them to judge which is best.
No, just roll on with it.
There was a period of time, around 2010-2015 when I really felt that computers were fast. SSDs were getting more affordable and that was a huge improvement, every action was immediately responsive. In 2020, that has somehow been undone. It takes 5 seconds to launch a calculator. Software guys really like to undo all the advances that the hardware guys are doing.
This. snap seems to spew traces of itself all over the place on an Ubuntu install, and it's less than clear why any of them are there.
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
It is one thing when you make a controversial statement and then decide to attack downvoters, it is a different thing if you are trying to understand how and why people disagreed with you.
The calculator should -always- load in a couple ms. It's one of the simplest tools on the shelf! If a calculator snap can't load immediately then I have no interest in a single other snap app. Waiting more than a second is a nightmare, and I've definitely waited 5+ seconds at times. That's about how long it takes my system to boot. As far as I'm concerned it's a complete failure and I couldn't possibly trust it on any desktop or server that I manage.
I guess people at MS test and quality departments use I7 with an SSD driver. If so, it's bad. If not it's simply hard to understand, if we leave corporate politics aside.
To me, the calculator has always been more or less OK, but the Image Viewer is a clusterfuck.
With the old viewer, it's almost instantanious opening by clicking a file in windows explorer. The new one is slow as a crawl. The first time may take 5 or 6 seconds (in a 7 year old laptop). The next time is down to 2 or 3. Compare that to milliseconds using the native app. I've never felt the need to use an specific image viewer, but now I'm happy with Irfanview, as fast as the old app, and full of features.
How do such things pass triage stages?
The same thing with phones. Smart phones are good at a lot of things, but they are mediocre as a telephone.
I now switched to xcalc. gnome-calculator is better, honestly, but it's not worth feeling in the 90ies.
I just did it and it's quick to boot up again as it should :)
1. The micro terminal editor.
2. Chromium, because it was forced.
Well, #1 was packaged for 20.04 so I didn't need it any longer. That left Chromium. For that single package, I had to tolerate my system being spammed all over:
- Multiple irrelevant loopbacks cluttering my mounts list
- Dedicated folders in filesystem: /snap ~/snap
- Very slow startup, for chromium.
- Lots of disk space taken
- An always running daemon! (Wasn't it root too? Can't remember). apt doesn't need a daemon.
Sheesh! That's not even mentioning the store issues which others have described already.
Sorry, but a few newer packages here and there are not worth all that. I'll handle it myself, thanks. What snap does isn't actually that hard. I'd keep it around if it wasn't so obnoxious at putting itself in front and center of everything.
Oh, forgot to mention: /var/cache/snapd/
What the heck is this, windows?
With tmux it seems like this is finally possible with version 3.1 or by compiling it yourself but I remember being annoyed about this years ago.
I dislike a home directory cluttered with dotfiles just as much as that snap folder choice because when do we actually ever not list the hidden files?
Name and shame:
* docker (~/.docker)
* Arduino IDE (~/.arduino15)
* GNURadio (~/.gnuradio)
* IPython (~/.ipython)
* FreeCAD (~/.FreeCAD)
* HPlip (~/.hplip)
* IntelliJ and others (e.g. ~/RubyMine[year])
* Cargo (~/.cargo)
* Audacity (~/.audacity-data)
* PGAdmin (~/.pgadmin)
* ELinks (~/.elinks)
* NPM (~/.npm)
* sqlmap (~/.sqlmap)
* ZAP (~/.ZAP)
* GNUPG (~/.gnupg)
* crashlytics (~/.crashlytics)
* Android Studio (~/.android)
And so so so many others just crap all over home when they could just crap in .config if it's config and in .cache if it's cache. Lazy devs.
http://sergeykish.com/openssh-config-in-xdg-directory
And it is easy to make own repo. There are quite a lot of unofficial repositories https://wiki.archlinux.org/index.php/unofficial_user_reposit...
The cache is not a config, assholes. What do you think ~/.cache is for?!
export ELINKS_CONFDIR="$XDG_CONFIG_HOME"/elinks
That export list required got me weary, plus look at how many in that list are hardcoded :/, the situation is rather bad.
If world does not match your view it may be you who is outlier. I quite like current convention - hidden files in $HOME belong to applications. There is value in $XDG_CACHE_HOME - it can be safely removed (like /var/cache).
You force your view on open source community, that is rather bad.
As I said, impractical, not a solution.
> If world does not match your view it may be you who is outlier.
Looking at the amount of software that does follow the base directory specification, actually you're the outlier insisting on obsolete conventions.
You and a bunch of other developers insist on those things, in reality that is the actually harmful behaviour for open-source.
Interestingly but yet non-surprisingly, that insistence very often goes in hand with the stubborness to stay on obsolete mailing lists, ugly user interfaces, insecurity by-default, git-email, buggy issue trackers, 80-column commit messages, obsolete security standards and practices and so much more.
> I quite like current convention - hidden files in $HOME belong to applications.
The future is now, home folders aren't to be filled with trash. Move on or stay behind, seriously.
You shame software, half of it has workaround, see patching as impractical.
XDG Base Directory Specification [1] is not about your home folder. It is about default storage, separation of cache, user data and config, a way to provide another config, so one can:
* remove entire config when stuck with a problem
* remove cache, think /var/cache
* `ssh -F foo` would be `XDG_CONFIG_HOME=foo ssh`
Everyone has a pain point, everyone has a workflow, there is no One True Way. Please stop shaming authors, they quit, sometimes post it here about mob. Patching folder structure is the simplest thing. If you can't do that who is going to fix actual bugs?
[0] http://sergeykish.com/openssh-config-in-xdg-directory
[1] https://specifications.freedesktop.org/basedir-spec/basedir-...
If one feels that talking about a bug in their software is "shaming" them, then maybe they should quit or alternatively, just quit pretending they want feedback or to write FOSS. Same applies to teams writing software.
Not to mention how harmful it is to think that everyone who picks up FOSS is actually good at it. Thinking people as infallible is actively harmful for the end users.
> Patching folder structure is the simplest thing. If you can't do that who is going to fix actual bugs?
Incorrect folder structure is an actual bug. It might be simple to patch for the end user, but you're ignoring the maintenance burden, annoyance and cumbersomeness.
> Everyone has a pain point, everyone has a workflow, there is no One True Way.
There are paths more correct than others, some workflows are obsolete and stupid, and should't be catered to. It's wilful ignorance to ignore that.
> half of it has workaround
Bwahahaha, you may think that's fine, but I don't.
> Name and shame
> they should quit
That's why I've called it harmful - choice between your complains and people writing code is obvious. Fork it, patch it, there is no burden - if people care maintainers would switch, if switched enough patch would get in upstream. Or provide own repository with patches, that's FOSS way. If not by yourself than sponsor.
How much do you actually care? How much would you pay? Is it free as speech or free as beer?
Without the rest of the context and no, criticism is not harmful. If it is a "sin" like you say, should we look at things you've said about FOSS projects?
> Fork it, patch it, there is no burden
Either you're delusional or you haven't done either of the things.
> if people care maintainers would switch, if switched enough patch would get in upstream or provide own repository with patches, that's FOSS way.
Yeah, and it'll take the next decade, being optimistic. GPU acceleration in Chromium and Firefox on Linux is a perfect example how absolute shit that "way" is.
> How much do you actually care? How much would you pay? Is it free as speech or free as beer?
Feel free (as in freedom) to just type out your arguments instead of asking rhetorical questions.
Question was not rhetorical - it is realization of freedom 1. You answer implies there is a fork with GPU acceleration and no one cares (or does not answer my post). Ah, "criticism is not harmful":
Name and same:
* Avamander
No, I won't pay to devs that ignore conventions. That's like having someone take a s* on my porch and me paying them for not doing so. Plus, demanding payment is the thing not really in the spirit for FOSS.
> Ah, "criticism is not harmful":
That's just naming, without listing the reason. In addition to that, I listed projects, not people. Shows that you've totally missed the point of the original list.
Out of principle I can implement XDG Base for ssh client. Just like my work - implementing features I am not that interested in, providing support. I hardly believe any reasonable man expects complains to work in that case. So how much would you pay?
Your account may be group of people (and may be not). Project may be group of people (and may be not). Shows that you've totally missed the point.
Oh but keep in mind in some cases I'm not given a choice. If I could not use snap for example, I would not. But it was forced upon me. So I have every right to be annoyed at someone figuratively taking a shit on my porch.
Anyways this discussion has depleted itself, you have no good arguments protecting that nonstandard behaviour.
I've harbored this suspicion of GNOME developers for years. It honestly wouldn't surprise me if a lot of Canonical devs don't use Ubuntu at home.
https://bugs.launchpad.net/snappy/+bug/1620771
https://forum.snapcraft.io/t/how-can-i-use-snap-when-i-dont-...
shrug
Firefox FTW.
I rarely use it and only in incognito mode. Yes, it's a tradeoff but with numerous benefits.
I don't doubt for a moment that it makes business sense for Canonical, but I really wonder whether there's a market for this - the huge majority of people who don't care about this kind of thing are on Windows or Mac, or even just working happily away on their phones and tablets.
Linux' selling point for me was always that I was in control and could make the system work the way I wanted to; people more ideologically pure than me have slogans like "free as in freedom" or "binary blobs are bad".
I really don't see the market for "linux, but with commercial vendor practices". I switched from ubuntu to mint a while ago and I'm really happy about that right now.
[0] https://blog.system76.com/post/616861064165031936/whats-new-...
GNOME Software and KDE Discover support both Flatpak and the distribution's native package manager together. For example implementations on Ubuntu-based distributions that work out of the box, see the elementaryOS AppCenter and the Pop!_OS Pop!_Shop:
Curious... do you think that the world has moved on from the "download from website and run installer" model? Obviously that has serious drawbacks from a security perspective, but up until less than a decade ago, that was the only way to get software on Windows and macOS, and they were perfectly mainstream.
I think the majority of users out there don't understand sandboxing or permissions models or why they are useful. While I think those are the users that probably benefit from them the most, it doesn't follow that we need these things before average users will embrace a particular platform.
> A lot of people are mad at Canonical for not open sourcing the backend but no one seems to be offering to build one.
You mention Flatpak and then two sentences later claim this?
I think maybe you're just missing the point. I have been using Linux as my daily driver for a good two decades now. I don't care one bit about Linux being a mainstream desktop distro. Sure, if it was, new (and even not-so-new) hardware would get better support, and that would be a win. But getting that is not a fair trade off if what we have to accept in return is a closed-source, walled-garden software delivery model. Hard pass, no thanks.
For the most part, the only people who really care about "the year of the Linux desktop" are people trying to build a business around desktop Linux. Those aren't the sorts of people I want making decisions like this, but, unfortunately, they're often the kinds of people who have the ability to force these things on the community.
Ubuntu seems to have made clear that the snap client will not be able to connect to alternative stores. What is the point of building an alternative store.
Further snap is controlled by one company. Canonical has a history of developing groundbreaking new things for the Linux community before unceremoniously killing them off.
* Ubuntu One * Unity Desktop * Ubuntu Touch * Upstart Init system
Do you see a trend here? There is a reason the community is skeptical of something completely controlled by Canonical.
Ubuntu One file syncing, also server part, has been Open Sourced with much effort from Canonical: https://ubuntu.com/blog/ubuntu-one-file-syncing-code-open-so...
Ubuntu Touch https://ubports.com is run by community and has rapid progress, it's running on PinePhone etc.
Canonical would have liked to continue Unity: https://www.omgubuntu.co.uk/2017/10/why-did-ubuntu-drop-unit...
I would presume Upstart Init system was changed to systemd because other distros started using systemd.
I don't see a trend here.
As another long time Linux guy, I have a feeling most of those obsessed with Linux becoming a mainstream desktop platform are Mac or Windows users.
They just want to get Chrome and VSCode running without any headaches.
I used to care, nowadays I just focus on Apple, Google and Microsoft platforms instead, and leave Linux for cloud VMs.
Flatpak doesn't impose closed-source, we have distros which only use open source flatpak repos.
Models like Flatpak have the advantage of "download from website & install" i.e you get the apps directly from the producer (which is better for security) while having no walled garden app store but having the advantage of auto updates & permission systems
I do not like Flatpak for technical reasons but Flatpak itself is in no way a walled garden solution, the problem is Flathub.
> I don't care one bit about Linux being a mainstream desktop distro
If you still want to be able to run Linux at all (not even on new hardware) on a consumer hardware, then you should care.
- Linux doesn't run (decently) on Microsoft latest surfaces - Linux won't run on new Apple hardware - Linux doesn't run on Android phones (with a few exceptions) - once Google switch to Fushia no more Linux kernel on mobile hardware - on the long term Huawei will ditch Android and other OS for their own thing.
Linux will die on consumer hardware (except on servers) if it does not become more popular. According to Apple's keynote the future of Linux is in its cage, in a VM running on walled garden MacOS. According to Microsoft the future of Linux is WSL, running on top Windows.
If you do not like walled garden then you should definitively care about Linux getting more mainstream before no comsumer hardwares support it anymore
Why? Desktop computers worked just fine for 35 or so years before app stores showed up. It's completely unnecessary.
I'm not sure that "desktop computers" as we know it were around in the 60s (I certainly wasn't), but in the early 90s software tended to come from floppy disks, before that it was a C90 cassette on a spectrum.
If this is what you're looking for out of a computer, then why not just use a phone, tablet, or something like ChromeOS?
Sometimes there can be tradeoffs between convenience and security, but in the case of an app store the convenience actually enhances the security, because it diminishes the chance of people running random harmful commands from the Web.
I do not want that to be the target. Going mainstream never helped with the quality of anything. Quite the contrary: mainstream means lowest common denominator.
If you want to compromise on how much you control of your desktop os for more vendor support you already have windows and macos.
Needless to say, that was not enough for Linux to go mainstream.
The iPhone launched without the AppStore. The AppStore was not the cause of Apple's success, Usability and Power were - in the sense that it allowed users to do more things (access the web from anywhere) with less effort (no booting times or ceremony). It was the first mainstream device that made it really easy to browse the web; that is what made it successful.
The AppStore was just a play to entrench that initial success by coopting third-party developers and ensure they could only sharecrop on Apple's land: "If you do anything serious with our platform, we get 30%". That's it. Nothing to do with usability. The AppStore is actually a terrible model from a usability perspective, because it collapses discovery so much that it does not scale. "Tap and run" could have been implemented as a web protocol without a centralized UI and it would have worked just fine.
The same is true of Snap. Linux does not need a centralized store, from Canonical or anyone else; that's just a play for them to get a pound of flesh from third-party developers. It has been tried so many times before in the Linux world, and it has never succeeded. Even Nokia threw a lot of money at it, and failed.
What Linux really needs, as you say yourself, is to make it easy for developers to guarantee integrity of their solutions once they reach the user. That's why Snap is getting some traction: because it promises to move power from packagers to developers and to make it easier to guarantee that a program will Just Work, without having to deal with the packaging vagaries of this or that distribution or risking that an overzealous maintainer will "improve" your stuff with crippling patches.
If Canonical were sincere in their attempts to make Linux succeed, they would concentrate on that side of things and drop the AppStore shenanigans. But that's not what they are really after.
Also, it's not like modern developers don't sell users down the river. In fact, that's one of the very few sustainable business models that the AppStore forces you to have.
Who says it needs to be? What if what appeals to Linux desktop users is precisely what differentiates it from the mainstream?
Snap is regressive. What we have now works better, faster, lighter, and more secure. No, you can't have a convenient means of shipping your proprietary electron 10G garbage monster to end users. We don't need it to be "mainstream".
https://en.wikipedia.org/wiki/Synaptic_(software)
Sandboxing is a laudible goal but curation is more likely to result in a system that isn't pwned in the context of current sandboxing being at present being vastly insufficient to contain real threats.
I'm not sure in what fashion flatpak is behind snap given that the former supports custom software sources served over simple existing servers, local and offline installs, runtimes, fine grained permissions via portals, and turning off automatic updates.
>A lot of people are mad at Canonical for not open sourcing the backend but no one seems to be offering to build one.
This is a very strange defense to a legitimate criticism. In what universe would anyone on earth offer to spend their own time to fork snap and write their own backend instead of using flatpak, appimage, apt or 17 other choices.
Even if people do update the Snap, it's clear that it provides too many features. It has some sort of isolation model... that every Snap I've ever installed requires you to disable.
It's also surprisingly expensive to run something in a snap. For example, getting the name of my current k8s context with "kubectl config current-context":
$ sudo execsnoop.bt
Attaching 2 probes...
TIME(ms) PID ARGS
7603 29266 kubectl config current-context
7612 29272 /usr/sbin/apparmor_parser --preprocess
7614 29266 kubectl config current-context
7626 29280 /snap/core/9436/usr/lib/snapd/snap-seccomp version-info
7630 29266 /snap/core/9436/usr/lib/snapd/snap-confine --classic snap.kubectl.kubectl /snap/core/9436/usr/lib/snapd/snap-exec kubectl config current-context
7632 29266 /snap/core/9436/usr/lib/snapd/snap-exec kubectl config current-context
7634 29266 /snap/kubectl/1561/command-kubectl.wrapper config current-context
7635 29266 /snap/kubectl/1561/kubectl config current-context
Blame repo culture. In saner worlds there is no requirement for a middle man between developer and user, so users get the software when the developer releases it to them. For various reasons (only a few of which are technical), Linux has settled on this middelmen-everywhere way of doing things, and because it is FOSS all those middlemen are also volunteers, and then to top it all off there are dozens of repos and packaging formats.
AppImage (and its predecessors) have been valiantly struggling to undo this cultural brain damage.
I really don't want 187 system vulnerabilities from 12 apps which use different versions of different outdated libraries.
BSD ports had it before. And before that, Irix machines had the packages split in several CDs.
Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Mainly because the majority of the costs are for operating an instance which most other distros aren't willing to spend. Not even Mint operate run or operate their own launchpad infrastructure. They experienced large backlash back then, open sourced it and nobody contributed.
The same problem applies here. Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad. Such a cost operating would benefit nobody but Canonical because nobody else is bothering footing the bill to run an instance.
Second aspect that they wanted to avoid was the same pitfalls that they experienced previously with ppas and now being experienced with flatpak. Namely they want one location to find software, and one location to serve software. If users have to use the command line to add a external repo that has unfetted access, then that defeats any usability gains. That and the whole aspects of malware/trust goes out the window.
I will remind people that the most popular PPA to this day is a Java PPA being run by some 3rd party that doesn't offer Java. That PPA has root access to thousands of machines.
Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why?
> Namely they want one location to find software, and one location to serve software.
And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software.
> That and the whole aspects of malware/trust goes out the window.
Malware has already been successfully pushed to the Snap Store. The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code, we now trust software because it came from a store that removes well known malware.
Im not too sure as I don't work for Canonical. However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare.
Things like potentially giving some mechanism that could enable a user to sign/publish on behalf of Canonical snaps/packages for example. That kind of thing would probably need to be removed. Deep integration between CI/operational infrastructure for things like building images. I can imagine after Canonical's experience of launchpad that they probably did hardcode aspects and it isn't some modular thing you can just spin up on docker.
>And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software.
Snaps I checked aren't there to replace apt. They don't prevent the install of flatpak, appimages or any alternative. Canonical has no agreement that prevents parties like Mozilla/KDE from only publishing on the snap store.
>Malware has already been successfully pushed to the Snap Store. We now trust software because it came from a store that removes well known malware.
There was one case of a snap bundled with a cryptominer. That was settled within 3 days and addressed to the community in a blog. Since then, it has been deliberately looked for. As someone who has published on the snap store, yes there are some checks present to ensure malicious software isn't being pushed.
>The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code,
It is really easy for me to see exactly what is being run/executed on the snaps that I install. In fact I have built/used snaps successfully without even the snap store all together.
If Canonical, as a Linux company, is not willing to spend the effort to open source their software, then Snap can continue to be rejected by Linux distributions. Canonical's most obvious reason for keeping the Snap server closed source is to lock its users into a proprietary and centralized system that it has full control over. This strategy is no different from Apple disallowing installations outside of the App Store on iOS, and Google disallowing alternative app stores in Google Play.
Canonical has done this experiment precisely in the past, and we see the results of nobody operating their own launchpad instance. Nobody contributing back. That experience probably trumps all of this goodwill and opinions from the community.
Canonical is more importantly getting users, publishers and numbers behind them. A discussion I remember reading was that every snap has 10x more installs than the corresponding flatpak. That and they have 1st party support from major publishers like Google, Microsoft, Amazon, Spotify, Mozilla, Jetbrains, KDE etc....
Those aspects are more important for usability for the average user.
I've explained why it would be in the users' interest for Canonical to open source the Snap store: it reduces vendor lock-in and allows the users to enjoy the benefits of open source software (the ability to use, study, share, and improve the software with no restrictions).
Whether open sourcing the Snap server benefits Canonical is irrelevant to the users.
If Canonical goes down, a huge part of the usable linux market goes down with it. Possibly Linux Mint too, unless im mistaken.
>vendor lock-in
You are not vendor locked in. You can install flatpak, install via apt, appimages etc... Canonical doesn't ban the removal of snapd from ubuntu distros.
In fact, from a Linux dev I would argue that half the fragmentation for pointless nonsense like packaging and distributions has harmed the community far more. Namely because it's increased the cost of development for these things to a degree that companies won't even bother developing/publishing software on Linux. That has been the primary problem for Linux so far.
Canonical is actually getting first party support from major publishers and people still lampoon them. This includes publishers in the past who never would have considered publishing for Linux before.
If you don't understand the value of free and open source software, you're not obligated to use it. The maintainers of Linux Mint and other Linux distributions do understand, and that is one of the reasons they have rejected Snap.
> I'm willing to bet money you haven't looked at launchpad's source code at all. Nor have you or anyone else considered operating their own.
Your assumption is wrong and you've lost the bet. Additionally, Flatpak is available and Flatpak servers are already being hosted independently:
https://www.google.com/search?q=%22our%20flatpak%20repo%22
> You are not vendor locked in. You can install flatpak, install via apt, appimages etc... Canonical doesn't ban the removal of snapd from ubuntu distros.
Canonical has already transformed apt installs of Chromium into Snap installs, which motivated Linux Mint to reject Snap. Vendor lock-in is not black and white. For example, Android users can also install F-Droid or a variety of third-party app stores, but considering Google Play's default status on Android, most users are effectively locked in. The same applies to Canonical's handling of Chromium, and the Linux community is opposing this to discourage Canonical from continuing this dark pattern.
> half the fragmentation for pointless nonsense like packaging and distributions has harmed the community far more
Snap increases the fragmentation, and is more hostile to the FOSS community than all of the other options because its server is closed source.
Also, for what it's worth, I remain entirely unconvinced by your argument that this is fine from a users point of view. If they want to stop the push back, they need to ensure that they are not the only one with the ability to host a Snap store similar to how Flatpak does it. You can claim that this is irrelevant as it won't be used, and I suspect that you're right about that, but they will not be trusted until this happens.
If all you're doing is taking an internal repository and hosting it externally, then it takes no time. But if you make sure licenses are being used correctly throughout the code, audit to make sure no internal secrets accidentally made their way into the internal repository (this happens as much in closed source as it does in open source), and you try to remove any problematic code, commit messages or references from the code, it takes time.
We develop open source applications ourselves, and the amount of jerks who drop in from time to time and teach us how to do what (without contributing any code or donations, of course) is overwhelming. They don't care how you pay your bills and how much effort it takes to make things happen.
Not so much proprietary software (those dependencies would be owned by Canonical and therefore released in the same lot) but I understand there is considerable dependency on deployment machinery. Documentation for that machinery will need to be split out into private (contains secrets, references to customers, etc) and public (consumable by someone looking to replicate a Snap store deployment) and so on.
> Rather than trusting software because it has verifiable source code, we now trust software because it came from a store that removes well known malware.
The world has moved to that. I don't like it. I would prefer to install only distribution-curated software. However that doesn't help me get a bunch of software that isn't available that way. Where it is (and at the version I need), I use it. Note that this particular statement of yours applies equally to AppImage, Flatpak and everything else that isn't distribution-curated. It's not just an argument against Snaps.
The world has also moved to casually clicking links to "install" arbitrary apps (which in turn call stacks of arbitrary libraries and frameworks the dev probably found by casually clicking links).
You could give Debian and Ubuntu another decade to work on their packaging infrastructure and they still wouldn't reach parity with what we get through the web with the current browser security model.
I just think it's weird that a supposedly open source company like Canonical would build close source infrastructure. Like, just develop it in the open to begin with?
I understand that some complex interconnected ball-of-spaghetti of microservices makes little sense to open-source, b/c no-one can run it.
But that is essentially saying: we never wanted people to run it themselves, and now we are at a point that no-one can run it, so why bother?
They had to have actively chosen to build this closed-source software, no.
My point was only that I expect an company like Canonical to not just open source everything, but to design it in such a way that it is useful for third parties.
To make the distinction with "open source waste", where companies Open Source the software they no longer want, maintain or monetize.
> Namely that it would be expensive to open source it with little benefit in return.
I don't think that's the real reason; I think it's that Canonical wants to maintain control. Their dream of being the App Store of linux isn't working out.
> Canonical already spent a large amount of investment opensourcing launchpad
If their development practices make open-source development expensive, that's Canonical's problem, not anyone else's. Nobody else uses Launchpad because Launchpad is not a compelling platform. It's still tied to bazaar, which frankly lost the version-control wars. Treating git as a second-class citizen is not how to engender contributors.
> Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad.
Another example of having to choose: did Canonical engineer themselves into a corner, causing all of Launchpad to become technical debt from under which Snap cannot escape? Or was it a deliberate business decision to try to maintain control of the store? An affirmative conclusion in either case doesn't look good for Snap.
> Namely they want one location to find software, and one location to serve software. If users have to use the command line to add a external repo that has unfetted access, then that defeats any usability gains.
Users pretty clearly do not want this. Many people use Ubuntu expressly because of the PPA system; I'd argue that it directly caused Fedora's COPR system to exist because of the user demand. There's no mandate that PPA installation require command-line configuration; it would be trivial to create a bespoke per-PPA using e.g. Vala. Synaptic already allows configuration of PPAs via GUI. It's total non-issue.
> That and the whole aspects of malware/trust goes out the window.
They're already out the window. Snap packages are not reviewed for content and anyone can just cram software into it from random GitHub repositories. Wouldn't it be nice if it were possible to set up a 'curated' Snap store with strong promises of software quality and review? We can't, because it's apparently too hard to run. Another drag on Snap.
I'll not bother to respond to the whataboutism regarding PPAs. Literally the only difference between "a giant PPA that Canonical hosts" and the Snap store is that anyone can upload to the Snap store.
None of the problems Snap store purports to solve are compelling, so these explanations don't really further the cause.
Agreed. This is one feature of Ubuntu I miss sorely after leaving it behind for other distros.
Operationally:
- I can trivially host and control my own apt repository, either as a mirror of some upstream repository, or with bespoke packages.
- I can't do the same with snaps.
So launchpad and snap store isn't quite apples-to-apples. It would help of course if a snap store could be statically hosted or re-implemented, but the full API is quite complex.
The Snap server's closed-source nature is not a benefit to users, and there is no excuse that can justify this from the users' perspective.
There are always tradeoffs. I would argue there are advantages for having a trusted party vetting my software repos. It's why I even use Ubuntu because I trust Canonical to make some sane decisions when vetting their repositories.
You give multiple repository support and suddenly users have to one find a way to add another repo, and second there is no way of removing software from those repositories if they do end up malicious.
Which is why I brought up the webupd8 java instance having root access to thousands of machines.
>users can optionally add more repositories if they choose to do so.
Ubuntu is the version of Linux designed to be used by your grandmother. They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors.
It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains released software as a snap long before it is even possible on flatpak but nevermind that. I don't think you can even get VSCode, Spotify or Intellij on Flatpak.
> Ubuntu is the version of Linux designed to be used by your grandmother. They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors.
By default, GNOME Software and KDE Discover only use the Flathub repository. Your grandmother won't be adding other repositories to the Flatpak client. Users who don't add any extra repositories will use Flathub, which is a trusted source of software that runs on an open source server.
> It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains released software as a snap long before it is even possible on flatpak but nevermind that. I don't think you can even get VSCode, Spotify or Intellij on Flatpak.
https://www.flathub.org/apps/details/com.visualstudio.code
https://www.flathub.org/apps/details/com.spotify.Client
https://www.flathub.org/apps/details/com.jetbrains.IntelliJ-...
The microsoft, spotify and Jetbrains software comes directly from their respective publishers. Problems are supported and debugged directly. That is a major difference.
Canonical very publicly collaborated with these companies to get their software on the Snap store while Flathub has been handled in a more free-for-all manner. If you build it, they will come, and all that. Moreover, I'm not so sure Red Hat is as explicitly interested in monopolizing the Linux application ecosystem as Canonical, especially since their acquisition by IBM. Maybe IBM has other ideas, but we likely won't see similar marketing efforts on that front in the near future.
Do you really think Canonical is looking for money over here? If so do please precisely explain in the short-term how exactly you think they are gonna achieve that.
Do you think they are suddenly going to be able to dominate the entire 100% Linux desktop software market and charge 30%? Do you think a company like Microsoft/Spotify/Jetbrains would just roll over with that? I don't imagine they can do that considering Red Hat/Suse market position. Nor do I see the total Linux Desktop applications being a blip at all on their revenue streams.
Last I checked, they are still providing infrastructure to the Linux community for free. They still have more market share then the rest of the Linux distros combined. That and without them, Linux Mint wouldn't be operating as they do now.
Frankly they don't deserve the hatred the FOSS community throws at them and you are being somewhat disingenuous by presenting them as such.
It should be pretty obvious to you why they aren't exactly going to claim 30% commission on nothing from users who are as cost averse as possible. It should be plainly obvious to you also how they don't have the clout to bully software vendors to publish for them.
They have already plenty of evidence that profitability of distribution of linux software isn't exactly a lucrative market like Google or Apple. The fact that you think that is their aim or that it is feasible in the FOSS Linux community with large scale players like Google/Microsoft/IBM is ludicrous. Canonical tries to attempt to get such vendor lock-in and they would lose so much marketshare apps on their store instantaneously. They aren't even in a position like Apple/Google/Microsoft here who charge money to publish apps.
I have already explained how that argument is complete nonsense.
The backlash from Linux Mint and other distributions was partly caused by Canonical using Snap for Chromium when the user intended to install it through apt. This sleight of hand is not as extreme as a 30% commission, but it's a step in the wrong direction. The FOSS community is able to reject moves toward vendor lock-in even if the closed source Snap server does not mandate a 30% commission.
You keep repeating yourself. Having a default mechanism for installing software installed on Ubuntu distros that is using Ubuntu based infrastructure does not constitute vendor lock in. Guess what, Ubuntu uses apt rather than yum. That isn't vendor lock in either.
Having a proprietary back end does not constitute vendor lock in.
What you are saying is the equivalent of using spotify is vendor lock in. That or using Firefox. Heck Canonical's model here is practically no different from Firefox with their addon store.
A developer can choose to ignore snap all together and still distribute on Ubuntu. A user can choose to ignore snap all together and still install software on Ubuntu. They will have to face the consequence of not having to use chromium because nobody is willing to maintain it other than Canonical. What is this nonsense that you are spouting.
>The backlash from Linux Mint and other distributions was partly caused by Canonical using Snap for Chromium when the user intended to install it through apt. This sleight of hand is not as extreme as a 30% commission, but it's a step in the wrong direction. The FOSS community is able to reject moves toward vendor lock-in even if the closed source Snap server does not mandate a 30% commission.
Because any move that you or Mint disagrees with is a 'step' in the wrong direction? So be it, I and probably Canonical would rather be wrong.
Snap has 10x the install base for each snap compared to flatpak. It also has more first party software support.
Apt and yum both support configuring multiple repos, their protocols are well-documented, there are an abundance of repo implementations, etc. If apt only supported a single upstream repo and Debian kept the source proprietary, do you think Ubuntu would exist?
If this was true FOSS projects wouldn't be publishing things on the snap store (they are, and they publish on google play, winget, and other closed app stores).
No one can claim they speak for whatever you think "the FOSS community" is, let alone what it opposes or supports.
Canonical deciding that Ubuntu won't allow third-party Snap repositories is completely orthogonal to open sourcing their Snap server and/or making it easy for people to develop alternatives. They can perfectly well do both.
For years it has been recommended as the mechanism for installing Java on Ubuntu installs.
Suddenly the sysadmins in charge have forgotten they used this mechanism to install it on their ancient linux boxes.
Canonical historically provided a single "system" version of Java (meaning any system packages that depends on Java depended on this package) which meant that that was the version of Java that you got with Ubuntu XX.XX - even for LTS releases which had a 5 year lifespan.
Ubuntu 16.04 - which is still in support came with openjdk-7 and Canonical refused to provide an openjdk-8 package for it despite Java 8 being the prevalent development platform from late 2016 onwards and despite numerous requests to do so. No one was expecting Canonical to replace openjdk-7 with openjdk-8 - they only wanted to be able to install openjdk-8 along side the existing openjdk-7 system Java.
Ubuntu 18.04 - slightly different scenario but still the same problem - openjdk-8 and openjdk-11 are available but that still doesn't cover all development use cases.
Thus, people add the PPA and install the openjdk from there because someone currently is doing the work of keeping the PPA up to date.
Perhaps a business reason left unsaid is that an open source snap store would undermine Canonical's paid "enterprise edition" snap store. Why would an organization pay $30000 (https://ubuntu.com/internet-of-things) for a private app store if they could easily set up their own snap store?
I posit that this doesn't matter.
Presumably Ubuntu's infrastructure should be open source so that it can be inspected if necessary, for security reasons. It shouldn't matter if nobody else is actually hosting an alternative copy... it is still important that their copy be open source.
Second what you describe as a defect. There being multiple sources of software is a plus it means the power is in the hands of the user to decide whom to trust. What you don't want is a situation where people must configure additional sources just to have commonly needed software. The example you provide about the Java PPA is apt, pun intended, ideally commonly required software would be provided by the vendor instead of siloed in a third party source. Of course the vendor and the license must make this possible.
Launchpad has a weird user experience and was for a long time too much focussed on bazaar when git won.
At work we used bazaar and lp for a while, but still I always have to search for the right path for getting to a project's code. The bug tracker was more useful than GitHub's but that didn't help ...
Aside from that there are the legal implications of AfferoGPL which prevent many people from touching it.
But yes, doing infrastructures is hard. I however don't know how complicated hosting is and how well it's packaged. For software starting for in-house use this often is a mess ...
The problem is that the snap store is managed by Ubuntu without any community oversight.
By not releasing source code to the store, other distributions cannot create their own.
These are the reasons what is holding snap back for broader adoption.
That is already the case for most repos/launchpad on Ubuntu but people don't really have too much problems with that.
>By not releasing source code to the store, other distributions cannot create their own.
Other distributions wouldn't because the operational cost of operating it is too high.
>These are the reasons what is holding snap back for broader adoption.
Snap isn't being held back by adoption. It has more first party publisher support and more installs.
Red herring. The Linux Mint teams' main complaints have to do with issues around the way snap wrests control from the user.
>I will remind people that the most popular PPA to this day is a Java PPA being run by some 3rd party that doesn't offer Java. That PPA has root access to thousands of machines.
Imagine strawman-ing this hard.
Like Linux Mint is doing the same? There is no control being lost by using Ubuntu versus Mint. I could remove snapd there without people making that decision for me.
Worse would be Mint's decision of removing the only FOSS built version of chromium without offering an alternative in place. Canonical only installed the chromium snap because they did not have the resources to support a deb version instead.
>Imagine strawman-ing this hard.
It isn't a strawman. It is precisely what their reasoning was and it makes perfect sense. The snap store has already seen people attempt to install cryptominers. There is no way in Flatpak of banning known malicious flathub repos.
If I understood the issue correctly (and I may very well be mistaken!) the problem Mint has with Canonical is that Ubuntu has "hijacked" (for lack of a better term) some apt packages so that they now actually install snapd and the snap. So you think you're opting out of snap, but when you use apt to install Chromium you end up using snap anyway.
If I understand correctly, this is Mint's main complaint: that Ubuntu seems to be hijacking apt packages with snap.
https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-trans...
Canonical couldn't afford the maintenance costs for it. On Ubuntu distributions it's either the snap or you have to create some weird frankendeb aspect by pulling from Debian.
They explained it better than I would.
In other cases, I don't think of a case where apt installs snaps over apt. I think the only priority for the decision choice was based on most recent version. Although this aspect I am slightly unclear.
> 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.
I just use the Chrome apt repository from Google which seems simpler all around.
https://packages.ubuntu.com/focal/chromium-browser
In previous versions of ubuntu, that package would install chromium, as one would expect.
In recent versions of ubuntu, this package is a stub that installs snapd, and then snapd installs chromium.
There is a substantial difference between those two things. Users that try to install chromium through an open package management system are being pushed to Canonical's proprietary store.
So Canonical has the resources to make an entire DE, an init system, a mobile OS, a new display server (all of which were dumped on the roadside), and then going all in on a brand new sandboxing/package management system developed from scratch, but merely compiling a web browser officially supported by google and used by nearly every single one of their users is too much work?
a) One Snap package that supports all Ubuntu distros from 14.04 to newest, and also many other distros than Ubuntu
b) Compiling separate .deb package for all those Ubuntu versions from 14.04 to newest.
Chromium has huge amount of code that takes a lot of time to compile.
Ok, so the whole technology is irrelevant and should not be used then.
> Canonical already spent a large amount of investment opensourcing launchpad
Why develop it as non-open-source to begin with?
> Snap packages are effectively black-boxes; they cannot be reproduced independently as the packaging data is controlled by the package maker alone.
One of the nice properties of debian packages is the ability to `apt-get source` and build it locally. Would be a shame to lose that.
Maybe Nix and Guix can provide the best of both worlds here: self-contained software but reproducible builds too.
I think Nix/Guix is going to be the bridge to the post-POSIX world where we can move away from the trend of a globally visible filesystem and into much stronger container-based approach. But it can't be in its current form; the Nix language and Guix's Guile/Scheme are too difficult and not declarative enough.
I understand why there's consternation about usability (and a steady stream of requests focused on helping novices get it up and running), but I'm not sure the project(s)/ecosystem are ready for the stress of getting strapped to a growth rocket that brings in many new non-developer general-computing users who can't reasonably contribute back.
I don't mean this in an elitist RTFM way. More users of any stripe just inevitably exert support pressure in all sorts of directions. The community is perpetually iterating on tools/automation/process issues to try and stay on the right side of the wave. I sympathize with everyone who has a tough time finding their legs, but for the near term I think it is probably a net good if ergonomics issues filter out people for whom most distros are effectively fungible.
BTW most people don't need to write a full-fledged "script" to get their system up and running. All they need to specify are some configuration variables that specifies the sort of things you'd need to specify anyways if you're going to setup a new system, like which packages should be installed. With NixOS, you write those things on a file instead of typing it on the command line.
The capability is necessary because snaps can also ship proprietary software (eg. Spotify, Skype, etc). So one wouldn't expect this to be a property of (binary) snaps, just as it isn't for binary debs. apt/deb comes with "source package building tooling" (dpkg-source, dpkg-buildpackage, policy around debian/rules, etc) and so do snaps (snapcraft).
So don't lose that. Use Debian (or Devuan), or one of its properly-FOSS derivative distributions.
You don't get that for a lot of third party apt repos actually, no deb-src repo.
An excellent and succinct summary of the issue in the first paragraph. I have to hand it to LWN for excellent synopsis/summary paragraphs in the articles. This is a lost art in today's clickbait headline where the lede is buried in the center of the Earth.
The jetbrains stuff keeps several versions around by default, which eats disk space. I'm sure there's a way to change that, but I haven't cared enough to dig.
The other day I ran `apt install chromium-browser` on a brand new install; it chose to install via snap (grr) and then snapd promptly crashed ("Waiting for restart" -- https://forum.snapcraft.io/t/installing-the-chromium-snap-in...), but apt's wrapper wasn't notified. I ended up ctrl-Cing, which left dkpg (somehow involved) in an inconsistent state. Took several iterations of dkpg reconfigure and apt update to recover. I've been on linux for 20 years, so not a big deal for me, but my experience has been that snap is less newbie friendly than apt.
There is a negative sentiment around snap packages. Even if you are an experienced Linux user, you fall into that negative sentiment and even if an issue is small, it is a deal-breaker for you.
The "chromium" issue has been explained in 2019. Ubuntu 20.04 does not plan to package "chromium" as a deb package (too difficult to maintain properly), therefore there was a need for a backup plan if users were trying to install it.
I don't think that's fair. Apt/deb is solid, battle tested, and works. Introducing snap with this kind of instability is the source of the negativity.
> The "chromium" issue has been explained in 2019.
And the fact that it still crashes in 2020, on a flagship package on a modern laptop, is really really bad. In fact I had the same crash happen during a dist-upgrade on another laptop(!) which locked up the entire dist-upgrade.
If apt is going to call snap, it needs to be rock solid.
See "refresh.retain" from https://snapcraft.io/docs/keeping-snaps-up-to-date - the point is that you can revert an update instantly.
This is totally going to break Gnome Software's UI since it has plugins for snap, flatpack, apt, dnf, pacman, etc.. and making it so that Chromium from apt is doing a run-round with snap makes it really confusing to the user.
This is a mischaracterization. "chromium-browser" is a transitional package that installs the chromium snap for one reason: it is to provide an upgrade path for users of Chromium in previous Ubuntu releases to the latest Ubuntu release without breaking Chromium.
I use an example of where Debian does the same thing: on the latest Debian release, install "mysql-server" and you'll get MariaDB, not MySQL. Granted this doesn't bridge across from a deb to a snap, but the mechanism is the same and the technical reasoning is the same. It is to stop users from ending up with a regression in available software following an upgrade.
There is no "to make it some "universal installer"" going on here.
You may not like the decision, but please do not make it out to be for reasons that do not exist - at least without providing the facts to allow readers to decide for themselves.
(I work for Canonical but don't work in an area related to the Chromium snap, Snap Store, this decision, etc. I speak for myself, and not Canonical).
But I don't necessarily agree with the decision because "install Chromium via apt" now doesn't make any sense. It really should be something like "Ubuntu doesn't package Chromium anymore, but a Canonical supported package is available in the Snap store." Because Chromium via snap isn't a drop-in replacement: it automatically updates, it's not versioned with the distro, the usual file paths you would expect to exist aren't there anymore.
I use "universal installer" because Canonical has made apt do something really unexpected. Canonically has effectively made apt a frontend for snaps. I wouldn't expect that if I tried to install a package what wasn't in Ubuntu's repos that it would try to find some PPA that has that package, automatically enable and trust it, and install it from there.
Are you seriously, unironically claiming this?
You broke a massive amount of native plugins. The snap auto-update mechanism fucks up Chromium's data each time because Chromium gets no warning that it suddenly can't write to the disk. Its launch time is also way worse. On top of all that, Chromium just vomits all over syslog due to incomplete/bad confinement. You even made the damn switch when a massive CVE was found in Chromium, delaying a critical security update for a week due to the switch.
What a massive load of bullshit.
Yes - because when I say "without breaking Chromium", I mean that Chromium wouldn't work at all because it wouldn't be installed following an upgrade, as opposed to some things you don't like about how the Chromium snap works but don't apply to the majority of Chromium users.
Edit: you seem to be conflating your disagreement on Ubuntu's choice to move to shipping Chromium as a snap with a technical detail on how the upgrade path for users was achieved. I understand you disagree with the former. The claim that this is about "make it some "universal installer"" is entirely false, and I'm simply pointing out why. Downmodding me for disagreeing with the former is doubly inappropriate here.
Because you don't ship it as a normal package any more, which is caused by you. Calling it something you did "for the users for the sake of not breaking it" is really rather nasty.
> you seem to be conflating your disagreement on Ubuntu's choice to move to shipping Chromium as a snap with a technical detail on how the upgrade path for users was achieved.
Oh I disagree with both, there's no conflation there.
I am not an expert in apt/deb, could expand on this part?
Is this a problem due to Canonical not offering a chromium deb or is it something that was already happening before? (like chromium requires many libraries to be of specific versions and if you pin them in apt then sometimes it is impossible to install any version)
> 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.
The article takes the quote to mean that “Canonical … is using [Snap] to apply pressure where it wants to see change” and implies that Canonical is trying to pressure distros like Linux Mint to support Snap. But I think VanDine meant only that using Snap in a high-profile package puts pressure on Canonical to make Snap easier to use in Ubuntu.
That’s a less controversial goal than the one implied by the article. Of course, whether Canonical’s actions are truly motivated by that goal is a separate discussion topic.
Source code has been a dynamic thing for a while, and I think that's part of the reason the GPL (at least v2) is not very popular any more. I mean, nobody really even wants source code, it's just a maintenance headache.
Even after complexity started to take over, there was still the argument that you could audit your computer if it was doing something funny, or ask a different company to maintain it for you, instead. But that seems less and less practical as time goes on. The company that wrote the software is really the only game in town to keep it useful.
Snaps are a logical extension of this phenomenon. They cross a line in the sand, perhaps, but basically just continue a trend already going on.
Also, the unix security model seems fundamentally bad. The idea that any code you execute can delete everything in your home directory is insane. It imposes a huge burden of trust on your software distribution system for the most trivial things. That reduces the practicality of using third-party sources.
I'm not really defending snaps and I will probably avoid them as long as I can. But I sort of feel like the battle might already be lost.
- The hassle you have to do to install "non-free" software.
- It's basically RHEL unstable: plenty of opinionated, bleeding-edge software choices that are either unsupported [1] or very much undocumented, unless you can find some help on the actual RHEL guides.
- COPR (user packages) is worse than Ubuntu's PPA, both of which are much worse than Arch Linux's AUR.
1: Running Docker on Fedora 32 is non trivial because of how firewalld is configured and because Fedora decided to go all in on nftables. Sure, it's the future, but Docker hasn't got the memo yet. Nor the memo about cgroups2.
Or for that matter, regular old Debian probably has 99% of what you need.
The only thing to watch for is testing isn't covered by the Debian security team, so you need to pay attention to security advisories and make a call to keep or uninstall if a package you use has a security issue, as testing often doesn't get security fixes until a week or so after stable does.
Can't you simply opt out of using snaps and keep using .deb with Ubuntu, no matter what Canonical is pushing as their preferred distribution?
Say what you want, systemd is here to stay. Everybody's free to make a distro without it, but I wouldn't consider it for a full time workstation, at all.
There's a reason Arch is so famous and a meme: installation is a challenging weekend project if you've never done it, but it's the most stable distribution with the sanest ecosystem (AUR, sane defaults like systemd, fastest package manager, rolling releases, packages are kept as close to upstream as possible).
Once you go Arch you probably won't go back and you will just grow the meme further.
> Flutter’s native cross-platform story is growing rapidly and Canonical wanted to be at the vanguard.
> By making Linux a first class Flutter platform, Canonical is inviting application developers to publish their apps to millions of Linux users and broaden the availability of high quality applications available to them.
> Canonical will continue to collaborate with Google to further improve Linux support and maintain feature parity with the other supported platforms.
I'm curious, what "Canonical-oriented" features are you referring to? (besides snap)
After the move to Gnome, I've found Ubuntu to be less and less "Canonical-oriented"... which is good
I dislike Gnome Shell. It's clean and fast but the GUI is "locked" to the main monitor and I can't even switch windows without looking at it.
But I love how the distro is made focusing on a good user experience. To give you an example, the shop (software center) allows me to choose between deb packages and flatpak if available. Sounds like something obvious, but after having snaps shovelled down my throat when I was thinking I was installing deb packages, this means I can finally trust my distro again.
Now the only thing I need is a good DE. Maybe the next decade.
I don't use Pop!_OS, but I recommend Plasma.
In case you didn't know, check out the workspaces feature, it can make managing lots of windows much easier via the keyboard:
- Change Workspace: ctrl + alt + up/down
- Move Window to Workspace: ctrl + alt + shift + up/down
You can lock a workspace to a particular monitor too, while cycling other monitors
It just another bad move from Canonical in a long list of terrible failures, which weakend Linux fundamentally: * Upstart vs Systemd * Mir vs Wayland * Snap vs. Flatpak * Unity vs. GNOME and Gtk * Ubuntu Phone vs. you should have teamed up with Nokia and Maemo before...
Looks like they don't learn. The fork and fight against the others and always lose.
Nowadays Ubuntu is upstreaming usefull patches to GNOME, again. Thank you! But imagine what GNOME and Gtk could be look like already, when Ubuntu had "helped" them earlier. I could be already a lot of better years ago? Mutter, Gtk, Terminal and Nautilus. GNOME is healthy! But they could so much better years ago.
Forking is good thing, when it aims initially for a merge.
It says so on the description directly next to the name: "Transitional package - chromium-browser -> chromium snap"
There only for people upgrading, so they are not suddenly surprised seeing their browser gone.
Mixing your distribution systems with references to each other seems like a recipe for confusion and anger. And it looks like they got the expected outcome.
I mean: clearly some people do care, given that that this thread exists. I think you'll find that they aren't your typical Ubuntu user though.
Users who do care are quite capable of adjusting their configuration, and Ubuntu doesn't get in the way of that (configure apt not to install snapd ever, and it won't).
This is only an issue for users who want to push their political opinions on to other Ubuntu users.
People where "suddenly Chrome is gone" will be angry too.
Just imagine the outrage of a title like "The update to Catalina wiped all mac users' browsers with all their bookmarks and history. Forever".
And those are the people that cannot easily solve it. The person being able to know what a "Transitional package" or the difference between snap and apt is, is also the person who knows how (to google for) to move the old ~/.config/chrome/ directory into the snap.
This is also the person being enraged that Ubuntu offers a mechanism for all the people who cannot do that themselves. That sounds quite selfish to me.
Worse. Because when you then search the "software store", and install chromium, all your bookmarks, history, forms and other state is lost. At least the "apt package" migrates that for users.
For Ubuntu 20.04, it has been explained (in 2019!) that Chromium will be only available as a snap package. To help users transition, the command `sudo apt install chromium-browser` would install the snap package. It is better than "package not found".
It is so simple, but if you are stuck in a negative sentiment on snaps (read this thread), you get crazy.
A week or so later, I guess the snap package auto-updated itself, because my go installation broke with an error about how the go tool version no longer matches the currently running version of go.
That pretty much ruined Snap in my mind, particularly for system software.
And snap is bad not just because you can't patch, or pin, or set up a snap mirror etc. The whole concept is bad.
That
df -h | grep -v /snap
alias df='df --exclude-type=tmpfs --exclude-type=devtmpfs --exclude-type=squashfs' sudo apt autoremove --purge snapd # ;-)What is the cleanest way of ditch the snap system and its preinstalled apps? I'm assuming this won't break anything important.
PS: I'm not planning on installing 20.04 any time soon. At least not until the dust really settles. I don't see the point of running the absolutely latest version until there is a strong, evidence-backed consensus on its strong and weak points.
sudo apt autoremove --purge snapd gnome-software-plugin-snap
rm -fr ~/snap
From: https://askubuntu.com/questions/1035915/how-to-remove-snap-s...
---
..Or..
sudo apt purge snapd
rm -vrf ~/snap
# following may not be required as apt purge already removes them
sudo rm -vrf /snap /var/snap /var/lib/snapd /var/cache/snapd /usr/lib/snapd
# trying to install some package like chromium-browser will bring back snapd
# make sure snapd is not installed as a dependency anymore
# downside is that some package installation might fail because of dependecy on snapd
sudo apt-mark hold snapd
From: https://www.kevin-custer.com/blog/disabling-snaps-in-ubuntu-...
Especially if the people authoring the do-release-upgrade scripts weren't aware of this being a hot-button issue.
I personally don't see the issue with using Ubuntu as a base, _if_ you remove all of the offensive bits. iirc one of the Pop!_OS dev's was asked if they were going to rebase on Debian. The response was something akin to "We already change everything on the end user facing side, so there's not really a need."
There is also the issue of dependencies, and there is some elegance in the design philosophy of "package everything for a program and install it standalone" vs. having shared libraries.
So I see the benefit in an app-store. Someone below said "snap is horrible" because it's lock in. It isn't! Ubuntu hasn't taken away apt.
But simple, easy package distribution to nontechnical users, for the benefit of stability and ease of use, is a noble one.
Given up trying to compile VLC thanks to usual the usual python mess (ImportError: No module named 'nasm')
VLC don't bother distributing debs any more, just these shit snaps.
In years gone by distributions used to do a good job of keeping systems healthy.
They no longer seem to care about the old way of doing that though, things like debs and make just aren't cool any more. Instead you have 160 different package managers all fighting each other, which you then install to update your build environment to install another package manager to build a new build system to eventually dig down to generate some shitty python crap which runs a gcc command.
I don't have any issues with this behavior. I find it really annoying when I find a package I am looking for on apt and install it, only to realize that it's way out of date, and I'm supposed to install it via snap or some other means to get a reasonably up to date version. Pointing apt at the snap store is a nice convenience in my opinion.
I'm so sick of the app store model. The app stores usurp control of distribution from developers which adds risk which reduces willingness to invest and the result is that app stores attract low effort, low value apps unless they're coming from a huge company. Everyone loses except the app store owners, big platforms like Facebook and Spotify, and spammers / scammers.
The app store model is one of the worst things to happen to tech in my lifetime.
That is, create your snap package and publish it on the Snap Store. Do not request to pre-approve any permissions. Arrange with your users to enable those permissions on demand.
The only reason to go on that forum is to ask for automatic permissions. If you do not do that, then it's your users who have to give you that permission.
It's a snap. instead of just launching a stupid binary (it's a f-ing calculator for christ's sake) somebody decided it was better to use a snap, mount a filesystem, add a cgroup and everything.
For me that was the last straw: I eradicated all the snaps in my system, uninstalled snapd and everything gnome-related that I could. Jesus christ.
Again, it's a f-cking calculator.
I don't need a snap for that.
That's what get people hating snaps.
For the record, I'm now using xcalc. It's less pretty but it starts IMMEDIATELY.
Any suggestions on what’s a good alternative distributor go with that is widely supported and easily available on the variety of cloud platforms?
And my strong belief, is Microsoft is going to eat Linux Desktop. WSL to run your server apps and coding environment. windows for user apps. as someone who hasn't used windows in over 10 years, day by day seems windows is gonna be the future. sad to say, but true.
A common misconception about the FOSS ecosystem is that many similar projects is "wasted effort". In reality, diversity is what allows for progress and flexibility. Otherwise you end up with a single package manager which nobody can change AKA mono-culture.
> "Microsoft is going to eat Linux Desktop. WSL to run your server apps and coding environment. "
Only if Microsoft make their OS free, otherwise you're buying windows to run a translation layer of Linux (WSL) on top of it... doesn't make sense to a lot of people...
From a developers and users perspecive, it is a wasted effort. Users still keep wasting time 'choosing' a distro. There's 1 form of Windows and macOS to choose and support. For a software vendor, you need to 'define support'. I can support all Windows and macOS users, but I can only target a certain amount of Linux users on some selected distros which isn't all Linux users.
Perhaps the reason the Linux desktop has failed is because of the lack of a standard desktop or common SDKs other than the Linux kernel itself.
> In reality, diversity is what allows for progress and flexibility. Otherwise you end up with a single package manager which nobody can change AKA mono-culture.
Just look at the tons of distro configurations that a software vendor needs to test for which is why many companies place some Linux distros as under having 'unsupported' status and have to target a select few, unlike Windows and macOS.
The best "Linux Desktop" to support is WSL.
My point is that, the perceived "wasted effort" is actually learning and re-thinking the desktop. Many novel approaches to simpler OS's and package managers have risen, due to the diversity of the FOSS ecosystem.
Just like Darwinian evolution, many projects spawn into existence, only the fittest survive. The projects/distro's that don't survive were not a waste, they serve to prove which ideas work/don't work. Making all projects better off.
> "Just look at the tons of distro configurations that a software vendor needs to test for"
True there's many distros, but there's no reason to support them all, only the biggest. It's similar to translating books into other languages, you would translate a book to [1] Dumi, as it's the least used language on Earth.
Most Vendors only support the top OS's which are probably Windows, MacOS and Ubuntu.
> "Perhaps the reason the Linux desktop has failed is because of the lack of a standard desktop or common SDKs other than the Linux kernel itself."
This is a real point, and is something snap, flatpack etc. are trying to fix. Maybe one day a Linux desktop will unify on a standard...
[1] https://www.daytranslations.com/blog/rare-languages-spoken/#....
However, here on HackerNews i've seen many articles about how "flatpak is dangerous" lately. Is there any real concern? If yes, what would be another option? Appimages? I definitely don't want to rely on snaps now...
To have relatively up to date software without running unstable?
The conversation around snaps starts at 5:20.
It sounded to me that they genuinely tried to put themselves in both side's shoes.
Source: The Ubuntu podcast Telegram channel
Based on Ubuntu but with a bunch of manual patches + tweaks and driver support additions (particularly Nvidia). Really solid stock UI, and it even comes with a tiling WM built in.
I use plasma desktop on all of my other systems, but left this one with the defaults.. so far I really like it, but I have a problem with gnome-shell leaking memory over time, since I tend to not shut down or log out over long periods of time. If I don't restart / log out, /usr/bin/gnome-shell eats up more and more memory (as the gdm user). I let it get up to about 7GB before I updated some firmware and rebooted the laptop.
I mean, I put 32GB of RAM in the thing in an attempt to future-proof it, but this is kind of bonkers.
I just tried out Mint but it installs SO much rubbish. It installs mysql?!?
I don't mind it installing some useful software but Mint goes overboard.
With 20.04 I'm constantly sitting at 20-27gb of used memory when doing dev work.
> When Flatpak came out it immediately allowed anyone to create stores. The Flatpak client can talk to multiple stores. Spotify is on Flathub and they can push towards it. If tomorrow they have an argument with Flathub they can create their own store and the very same Flatpak client will still work with it. When Snap came out, it was only a client. The server was behind closed doors and the client couldn’t talk to multiple servers.
and
> Ubuntu is planning to replace the Chromium repository package with an empty package which installs the Chromium snap. In other words, as you install APT updates, Snap becomes a requirement for you to continue to use Chromium and installs itself behind your back.
Yea that seems to me to be a problem.
From the June 1st Mint blog post: https://blog.linuxmint.com/?p=3906
> ...in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.
If I'm reading this right, Snap is basically trying to fix the problem of software dependencies on older packages by bundling things together (a la flatpack)... but it ALSO replaces the various repositories in different distributions of linux with a closed-source, centralized repository that points towards cannonical, and advertises ubuntu to people using other distros and potentially gives cannonical control over the distribution of sotfware in the linux ecosystem. AND it can do this behind the scenes without the knowledge of the users, who may think they're still using their normal repo system.
The whole scheme seems completely antithetical to the principles of FOSS. You don't have to go full Stallman to see this as a bad thing IMO. From that perspective, Mint's decision to drop support for Snap makes a LOT of sense.
Also, one of the reasons I enjoy running linux (I dual-boot with windows) is that it does what I tell it to do, and ONLY what I tell it to do. There's no BS like Cortana auto-installing or onedrive automatically uploading a bunch of my pictures to the cloud (yes that actually happened). I already have a linux distro that takes that benefit away, but I accept that (for now), because it's a phone. I'm not ok with losing that on my desktop.
(Replying here because your comment I quoted above is dead! Vouching didn't help. Must have made someone mad.)
I don't believe the very few sites (mostly work related) I use chromium with have adsense, but it is possible here and there.
Also by `df` and `mount` are unusable with this stuff.
0: https://lobste.rs/s/aktv9k/problem_ubuntu_20_04_snaps_where_...
Is Ubuntu considered difficult to install? Does it not support older hardware as well as Mint? Wouldn't Ubuntu be more supported if they just ended Mint and jumped aboard?
There are people who lack so much ambition that they refer to sets of scripts and preconfigs with an OS branding.
I've used Ubuntu since 2014 and have been impressed at most of the decisions they've made, mainly:
- [1] Sticking to 6 month release cycles. Any features not ready, go into the next release. (Windows copied this, but constantly miss release dates)
- [2] Trying Unification of all applications, across desktop and mobile OS. But abandoning the project when it became clear it wasn't working.
- [3] Trying their own desktop manager Unity, then abandoning it when everyone was complaining and focusing on better Gnome integration.
I especially like how they try developing a technology and if it's not working or being adopted/liked, then it's abandoned by the core team... which is better than focusing on hated/dead technology...
[1] https://ubuntu.com/about/release-cycle
[2] https://www.bbc.com/news/technology-39490848
[3] https://arstechnica.com/information-technology/2018/05/ubunt...