
Snaps are an anti-pattern on Ubuntu - TheLastSamurai
https://techtudor.blogspot.com/2020/06/four-reasons-why-snaps-are-anti-pattern.html
======
SweetestRug
I had been an Ubuntu user for almost 16 years, on servers, laptops, and
recently containers. The snap situation with Ubuntu is just plain unpalatable,
both in principal and in practice. I became so disappointed in the move by
Canonical that I finally left Ubuntu altogether and no longer recommend it to
friends and colleagues.

It takes years to cultivate a garden, but only minutes to destroy it.

~~~
dheera
There are also these "AppImage" files. They launch, but there is no guidance
on how to install them to the system.

Launching Chrome: I click the Chrome icon.

Launching PrusaSlicer: Start a terminal and type

    
    
        chmod 755 ~/Downloads/PrusaSlicer-2.2.0+linux-x64-202003211856.AppImage
        ~/Downloads/PrusaSlicer-2.2.0+linux-x64-202003211856.AppImage
    

That doesn't seem like progress to me from a UX perspective.

~~~
mnm1
And flatpack. So now there's apt, snap, appimage, and flatpack. 4 fucking
systems that need to be maintained just to update apps on an OS. Frankly, it's
ridiculous and the apps from all those alternate systems all have some issues
too. None work as well as apt. I don't understand what is wrong with apt. If
they want newer packages provide a repo for newer shit. Problem solved.

~~~
ppseafield
Apt is great as long as what you want is available in the repo. Over the years
I have had a few issues though.

Often apt's versions trail behind the newest versions. There are some good
reasons for this, but it can get in the way sometimes.

I have had to ad a lot of PPAs to get some of the software I wanted. The
Aurora channel PPA for Firefox stopped getting updates at one point (they
discontinued it), and I didn't realize until a few versions later. I don't
think any of these package managers have that problem figured out, but PPAs
are commonly maintained by third party community/unofficial folks. I had the
same problems with Arch's AUR.

I believe it's fixed now, but for a long time Steam required a lot of 32 bit
libraries, which meant two versions of several dependencies were installed on
my machine.

Additionally we were using an older version of Ruby at work which required
OpenSSL1.0 for certain libraries, and a Ruby upgrade (from an old version to a
less old version) broke my development environment.

Not that the others are perfect. Just for example the Spotify snap package
from the software center doesn't even work. The Deb had problems on my machine
which I couldn't resolve. I finally installed Flatpak to get a working
version.

~~~
uhnllon
I think this thing about apps not available for apt is in the past. I
specifically use Ubuntu because there are .debs for everything. Most of the
new apps for linux published on Internet "need" to have a .dev available, if
they want to became popular.

Well, I have found some strange, out of common, software - mostly comercial
stuff - which doesn't have any .deb available nor ppas, nor nothing.

It is clearly a decision from somebody who said "no, we are not spending hours
packaging our app, if they want it, they will try to install it with the
methods we will provide"

Kind of nonsense, except that if you're in Linux looking to install a
comercial app, special snowflake, is probably because you have zero chances to
do otherwise, then you bit the bullet and try whatever crazy method to deploy
their app they have put in place.

Most common stuff I found: \- Just download my zipped binary, you know how to
deploy it \- Just run this command line, "sh something" giving it root
credentials to run code from the Internet (YEAH I KNOW TOO, as much insecure
as it gets)

Having said that, many comercial apps are there for to be easyly downloaded as
.debs (they should just install with a GUI right out from the link, in old-
Ubuntu behavior). Or they even offer you detailed instructions to configure a
ppa (to manually install with apt).

Heck, nowadays it is common sense and good netiquette to make your
installation scripts in the downloaded .deb to just deploy the ppa for apt, so
next upgrade happens automatically.

If you ask me and I wouldn't dreaming to control the app-deployment
infrastructure in Linux, I would say "yeah, you need to contact EVERY software
not providing the .deb format and start working with them, providing them free
support, even free scripts to handle the packaging"

I remember in the 90s, there was LOTs of shareware because Microsoft knew this
stuff from the 70s and 80s: if you want you're software in use, you need to
talk directly with those who could probably use it.

No, links hanging in some flashy website won't cut it, nor repos in github
half sharing some code.

------
schmichael
I think there are some very good critiques of snap (performance, provenance,
reproducibility, namespacing, etc), and the first couple points in this
article seem reasonable.

However I can't agree with this:

> apt/deb is a wonderful package management system and everyone is happy with
> it, at least the majority of Ubuntu/Debian users. Besides, dnf/rpm is also a
> similar packaging system for Fedora/RH systems and everyone is happy with
> that too.

Debs and rpms are great at assembling tightly coupled monolithic systems.
Great! Let's keep using them for the base system. However when I want to
install a QT app on a Gnome system or _gasp_ a proprietary app, Debs are
insufficient. I want all of the QT libs embedded in the package. I want the
proprietary app in a container. I want MAC with a polished UX. I don't want
debs to worry about those features. I want an "app store" done right: open yet
verifiable. Protection in depth.

~~~
zrm
> I want all of the QT libs embedded in the package.

I don't understand why anybody wants this.

Libraries should have major versions and the latest of each major version
should be compatible with anything using that major version, because that's
what major version means for a library. You might then need to have more than
one major version of the library installed, but any two applications using the
same one should be able to use the same copy, and then have it maintained by
one person in one place.

If every package has a separate copy of every library, people have to maintain
them all separately. When that library has a security update, you now have to
update five dozen packages instead of one or two, and have a security
vulnerability if _any_ of the maintainers don't keep up in a timely fashion.
Which not all of them will.

> I want the proprietary app in a container.

People want containers to be magic but they're actually a hard problem. You
want the app not to be able to do anything you don't want it to but still be
able to do everything you do want it to.

A backup app that can't read my files is useless; it can't back them up. But
it shouldn't be able to modify or delete them. But it should be able to modify
its own state. It shouldn't have general network access but should be able to
communicate with the backup server, which might have to be specified by the
user and not the package maintainer. It doesn't need access to the GPU or the
ability to use gigabytes of memory, but it does need to be able to transfer a
lot of data over the network, but the data it transfers is lower priority than
other network packets.

That requires the person configuring the app's container to have both detailed
knowledge of the app and detailed knowledge of the container system. It's
common for this not to be the case.

And that's why containers are a mess, not anything to do with the package
manager, which should have little to do with the container system outside of
packaging the app's default container configuration with the app.

~~~
schmichael
> I don't understand why anybody wants this.

Because creating debs is largely a completely distinct undertaking from the
dependency and build management the developer of an app does.

Bundles, whether via images or static binaries, allow app developers to
distribute their app against the exact dependencies it was developed against
-- potentially using the same build system.

There's obviously tradeoffs to each approach, which is why I don't think
there's one right way to distribute every bit of executable code on a system.

> People want containers to be magic but they're actually a hard problem.

I work on a container orchestrator, so I understand some of the difficulty. :)
Mobile apps are years ahead of desktop apps when it comes to containerizing in
a user friendly way. Obviously there's plenty of work still to be done, but
the problem is far from intractable and the benefits are enormous.

~~~
im3w1l
Mobile apps are a hellscape. It's an example of how wrong things can go. Apps
treat their privilege model as a license to abuse all their privileges as much
as possible.

Ability to read Contact list? Location access? Great let's upload it all to
the Googbook analytics for data mining our customers.

~~~
schmichael
But what's the alternative? No MAC and every app has all user privileges by
default like most Linux distros?

I would argue the concept has not failed, just the implementations have fallen
short. And for good reason! It's an extremely complex confluence of cutting
edge technology, UX, security, privacy, etc. It's been improving, and surely
the open source community can do it even better (or at least with a greater
focus on privacy).

~~~
nikau
It would be nice to have a prompt when the phone asks for phone book access:

Allow Deny Fake

The Fake would just have generated names and numbers to pollute their data
mining.

------
billme
Largest issue I have with Snap is that it appears to assume the owner of a
system is not in best position to make choices for their own systems.

Sure, this might be true for the average user, but it is toxic to the “super
user” community that’s in the best position to help support the larger
community and may end up pushing them away.

Snap at the very least should have an opt-out feature, if not be opt-in during
an install.

More criticisms maybe found here:

[https://en.wikipedia.org/wiki/Snap_(package_manager)#Critici...](https://en.wikipedia.org/wiki/Snap_\(package_manager\)#Criticism)

~~~
bzb4
Super users should be using Debian. Not being snarky.

~~~
Wowfunhappy
I'd expect users who go into Debian expecting some power-user version of
Ubuntu to be disappointed. To be happy on Debian, you need to adopt their
philosophy that stability is better than having the latest-and-greatest.

For those unfamiliar, Debian releases come out about once every two years, at
which point all software in Debian's repositories is frozen at its current
version. Software receives security updates between releases, but nothing
else.

I personally think this is _wonderful_ , and I would absolutely use Debian if
I was interested in switching to Linux (which I'm not, at the moment).
Constant change is inherently frustrating, even when the changes themselves
are a net positive (they often aren't). Debian's approach provides a level of
reliability and consistency that is sorely lacking in most modern software.

So, while I also recommend Debian, I do so only if you too agree with the
above paragraph.

~~~
war1025
Debian has stable, testing, unstable, and experimental repositories.

If you only enable stable, then you are signing up for very outdated software.

If you add `testing`, you get quite a ways towards having an up to date
system, while still not having to worry too much about odd bugs.

Adding in `unstable` gets you about as close to up to date as you can get
without compiling the source yourself.

Experimental is good to keep around, but in my experience most things skip it
and just hop straight to unstable.

The beautiful thing about Debian compared to Ubuntu is that it actually _is_ a
rolling release system. Ubuntu users have to worry about what version they are
on. With Debian, you set what track you want to follow and just remember to
install updates as they become available.

Because it's a rolling release, you're much more likely to catch small issues
and be able to isolate what package is causing the problem, as opposed to
doing a thousand package upgrades at once and then being snagged because one
of them had an install issue.

~~~
Wowfunhappy
Debian strongly advises against mixing repositories:
[https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Frank...](https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian)

Debian Testing is an option, but would you recommend that over a distribution
focused on rolling releases, like Arch? From my vantage point (which isn't
particularly good, as a non-Linux user myself), most of the Debian project's
effort is concentrated on producing Debian Stable. Case in point, security
updates for Debian Testing are sometimes significantly delayed.

~~~
war1025
> would you recommend that over a distribution focused on rolling releases,
> like Arch?

Everything about Debian except the `stable` repository is explicitly a rolling
release.

> Debian strongly advises against mixing repositories

Certainly you wouldn't want to add in the other repositories if you're aiming
for Debian Stable type guarantees.

This is the `sources.list` file that I've been using for nearly a decade:

    
    
       deb http://deb.debian.org/debian/ testing main non-free contrib
       deb http://deb.debian.org/debian/ unstable main non-free contrib
       deb http://deb.debian.org/debian/ experimental main non-free contrib
    

And then I have a preferences file that prefers testing to unstable to
experimental (actually three separate files in the preferences.d directory,
but I'd think you could combine them.

    
    
       Package: *
       Pin: release a=testing
       Pin-Priority: 700
       
       Package: *
       Pin: release a=unstable
       Pin-Priority: 650
    
       Package: *
       Pin: release a=experimental
       Pin-Priority: 600
    

It may not be advised, but it works pretty well. Sometimes you have to get a
bit creative when you go to run `apt-get dist-upgrade` and it wants to delete
half your system, but usually you can just manually install individual
upgrades (`apt-get install <x>`) until it unwedges itself.

------
nerdbaggy
One of my big things with snap is how it locks the snap into the home
directory. I get why they do that but it would be nice to override[1]. In my
case I want to play audio files outside of my home directory but VLC doesn’t
have access. And VLC now only updates the snaps and not it’s repos so you have
to use the snaps.[2]

[1][https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706](https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706)

[2][https://www.videolan.org/vlc/download-
ubuntu.html](https://www.videolan.org/vlc/download-ubuntu.html)

~~~
oarsinsync
The website you linked ([https://www.videolan.org/vlc/download-
ubuntu.html](https://www.videolan.org/vlc/download-ubuntu.html)) says:

> If you wish to install the traditional deb package, it is available as usual
> via APT, with all security and critical bug fixes. However, there will be no
> major VLC version updates until the next Ubuntu release.

This is in line with Ubuntu (and Debian) repo policies. You do not get major
software updates in between distribution updates unless you use a third party
repository. You do get bug fixes and security fixes, and/or can track unstable
if you need the bleeding edge.

~~~
nerdbaggy
Ohh yeah I misread that

------
uhnllon
This is a rant against snaps. Well, lets get to it.

Sorry, snaps are a LOT slower than just running a binary. Did I said they're
slow, well they're slow.

I have an SSD and it feels like it's 1992 and I'm trying to run some snap from
a Cyrix without cache and 16MB of RAM. I switch to binary version (oh my
chromium), and it freaking flash, 0.x sec. and you're there, the full app is
available.

Snaps are a NO GO my friends.

Besides having LOTS of problems running out of the standard GUI (Gnome3), or
even in the standard (supposedly heavy-tested) GUI, they are slow.

Sorry, I've already said that uh? SLOW, that's snaps.

If there is somebody from Ubuntu here, please take a serious look about how
snapped apps (pun intended), read/write $HOME defaults.

I mean we have to have defaults somewhere. So thingies like the colour theme,
the theme engine, default download path, etc. are fully followed just as the
user has configured them.

I use Ubuntu, but I certainly would not be using in the future if my
applications which now take merely 0.x seconds to open start to take, 3-4-15!
seconds to open. I fact I started to look to Debian and Fedora, they currently
appear to have saner defaults than Ubuntu.

No, the second time I open an app in a session doesn't count AT ALL for the
speed.

------
burtonator
As a package manager for my app snaps have really been an anti-pattern and
we're considering removing support for them.

Here are some problems I've had:

\- snaps use a different directory than our main app. So if you install our
debian package, then go to a snap package, all your data seems to vanish. It's
just in another hidden directory. I tried to figure out how to get the
directories to sync up but couldn't get it to work as it's yet 'another thing
to support'. I only have so much time.

\- snaps have various bugs that you encounter after you've shipped the app
that aren't present at build time. Mostly due to being in a container and
'reasonable' things not being accessible and needing to be granted access to
via a configuration file.

The strategy I'm thinking of migrating to is to just distribute as a .deb and
have our own apt line that is installed during the .deb installation. I think
this is what Slack and other Electron packages have migrated to which is
easier for them to support.

I mean conceptually it sounds great. Put your apps in a container. They will
be isolated. Great. But in practice it's a nightmare.

To be fair though. MacOS has similar issues when they started going with
isolation and privileges.

I think the main issue is that none of the OS maintainers spend a day in the
shoes of a package maintainer. And if they did they don't care because they
own the OS and many of these apps compete with your core product.

At least you have plausible deniability that your behavior isn't anti-
competitive - you're just trying to improve the security for the user!

For example, Zoom got a ton of crap about their installer but they compete
with Facetime which DOES NOT have to constantly ask the user for privileges.
Apple granted Facetime these privileges via the OS.

From the perspective of a user, it's horrible.

"Can this app access your Downloads folder?"

"Can this app access your Webcam?"

"Can this app access your Microphone?"

"Can this app access your Documents folder?"

... and on and on ad nausea.

------
gentleman11
Devils advocate: it is plain weird for every app I install to have so much
file system and system access. It’s nice to have a sandboxed solution built
in. It would be nice if it was a solution that didn’t have the problems that
this article listed, but snaps could be adapted to be good with a few changes.

Why a proprietary backend though? I suppose cannonical views packaged apps as
a platform opportunity and wants to be the first to “capture” the users
without somebody bigger coming and taking over?

~~~
2ion
> Devils advocate: it is plain weird for every app I install to have so much
> file system and system access. It’s nice to have a sandboxed solution built
> in. It would be nice if it was a solution that didn’t have the problems that
> this article listed, but snaps could be adapted to be good with a few
> changes.

Exactly. Personally I have been sticking my desktop programs into
"firejail"-managed "containers" for a long time. It's a good thing that a
similar solution has been implemented that is suitable to bring this too the
masses.

~~~
yjftsjthsd-h
> It's a good thing that a similar solution has been implemented that is
> suitable to bring this too the masses.

Couldn't you just make a "default-firejail" package that installs the symlinks
to firejail somewhere that's before the default install install location in
your path? And maybe consider installing that in the base install, but that
potentially risks breaking things unexpectedly for users.

------
kstenerud
I wanted to love snaps. I really did. I like the idea of a self-contained
program that doesn't get into DLL hell, and can't stomp all over my system if
it misbehaves, and can be cleanly uninstalled.

Unfortunately, snap comes with all of these extra issues that happen when the
developer isn't empathizing with the user. Also, much to my chagrin, snaps
don't actually uninstall cleanly, and can really hoop your system. I now
install snaps INSIDE of an LXC container so that snap can't misbehave and
break my system, or else if I can I just use apt with a custom repo (for
docker because the snap is awful). Ubuntu 20.04 will probably be my last
Ubuntu system, and that's a shame... I really liked it.

------
cocoa19
The point of snap is you have one single package for all releases instead of
one package for each release.

This reduces the maintenance burden, while also allowing you to have up to
date packages.

The way this is done is by bundling all dependencies in your snap package
rather than using the system ones.

I think it's a great idea for applications you want to be updated frequently,
like VS Code, Chrome, etc.

It's not perfect, e.g. back end is closed source, but I'm glad Ubuntu is
giving us options and being at the forefront of package management.

------
rayiner
I like Snaps. After the debacle that is Catalina, I built my first Linux
desktop in 15 years. Ubuntu 20.4 worked perfectly out of the box, with Wayland
and everything. Snaps and the Snap store are a huge improvement over the
previous GUI interface to Apt.

I ended up settling on Silverblue, a Fedora derivative that uses an immutable
base system along with Flatpak for applications, and it’s been great. Equally
trouble free, and Flatpak has many of the benefits of Snaps without some of
the downsides (fully open source).

------
BiteCode_dev
I've been using Linux for 15 years as my daily OS, I love the package system,
but this point of view is missing the point.

Those arguments are always from very tech saavy people.

They are a good exemple of purity over practicality, completly ignoring all
the problems apt/yum have for the average user or dev publishing software.

If you are looking for reasons as why Linux on the destkop never happen, well,
this is one of them.

------
noisy_boy
The whole snaps business was already annoying. Then my external monitor
stopped being detected due to some issue with Nvidia graphics on (which
probably is more Nvidia's fault then Ubuntu's). I'm using Thinkpad X1 Extreme
Gen 2. Tried Fedora 32's live usb and basically everything worked but the
installer didn't detect all partitions and didn't give a choice of choosing
exactly what goes into which partition without offering to wipe-out stuff
(they need to take a cue from the flexibility of Ubuntu's installer). Finally
tried Pop!_os's live usb and everything basically worked + had no issues with
the installer either.

I wasn't keen on using a derivative distro of a derivative distro; thought of
using Debian but wasn't very confident if the issues won't persist on it.
Considering everything just works perfectly with Pop!_os, I might just stick
with it.

Ubuntu was such a breath of fresh air at the beginning (I still remember
Dapper Drake). It is sad to see it going this way.

~~~
zdragnar
Say what you will of their hardware, but the system76 team really nailed
pop_os. So many little things I was used to suffering through manually
configuring on a fresh install were just "right" straight out of the box.

Supposedly they're working on tabbed and stacking layouts for tiled windows-
if that is the case I don't know if I'll go back to i3 or sway again!

~~~
noisy_boy
I don't have any experience with their hardware but I'll have to agree on the
software front. I have a multi-port hub that I also connect the HDMI cable for
monitor to; I connect the hub to the laptop its actually plug-n-play. I
haven't had to run one command to hack/override configs etc.

I tried their tiling option but didn't stick to it because when I maximized a
window and toggled to another, the original window went back to being tiled.
Too lazy to remember shortcuts for tiling WMs (probably to my own detriment)

------
csdreamer7
Honestly this article had some poor arguments. Like Apt being fantastic-it
isn't-see below. I do not see what the hate around snaps are for.

Yes, some snaps are not updated, and VLC only working in the home directory as
another HN commenter said is a pain.

Snaps still solve a lot of issues on Linux that Windows does not have.

What happens if the new version of your editor breaks some well known plugins?

On Windows you just install the older version from the archives. On Linux you
risk dependency issues. Snaps are a single command to switch to an older
version. Very important in both the software and media space.

One option is to stay on the LTS version of Blender.

Another is back when I used Atom, one upgrade completely broke a popular
plugin for me because of a change in Chrome. I thought it would be fixed
quickly so didn't revert the package and I lost the older version in the
cache. Took the Atom devs 2 weeks to handle the change to Google Chrome-then
Arch maintainer of the Atom package didn't get around to upgrading it for a
week or two after that.

Things like apt pinning really don't help you when you discover the issue on
your main workstation. Also, doesn't change the fact that it is so much easier
to revert on Windows. Snaps make version control even easier to do on Linux
then Windows.

The back-end being proprietary is a good argument. but for a company that has
worked so long with Linux and Free Software; give Canonical a little trust to
release it.

------
WesternStar
I honestly like snaps. I like having spotify and discord working as to his
other concerns I just don't care.

~~~
zepto
Why not just get a Mac?

~~~
contravariant
Not saying you're wrong, but if the response to people wanting to use linux is
"Get a Mac" then that's problematic.

~~~
zepto
It isn’t. I personally use both a Mac, and Linux. Openness is what makes Linux
valuable. I have no desire for Linux to become like the Mac with proprietary
parts of the system.

------
compsciphd
I'll take a contrarian/devil's advocate stance. for some applications and some
usage scenarios, snaps makes a lot of sense.

Take a multi user system and users who run applications like chromium or
firefox.

It's dangerous to upgrade the application while users are running them as the
files the running applications depend on can change thereby making them either
break in weird ways or force the end users to restart them.

if these apps were just distributed as snaps, it wouldn't matter. they would
keep on using the old image without any problem, while new executions would
get the new image. If one really wanted to encourage them to exit and restart
(i.e. some security hole), the same mechanisms that exist today to get people
to restart could be used.

with that said, I think it should be a choice, not something force down our
throat. if I install something with apt/dpkg , I expect it to be an apt/dpkg
package, not a snap. if I want to use snap, I'll install it with snap.

------
kd913
You people do realize that snaps have been around for 4 years right? It has
widespread first party support from various companies including Microsoft,
Amazon, Mozilla, Google, Spotify, JetBrains etc...

They have wide spread adoption with almost 10x the install base of Flatpaks.

Do you guys really need to keep throwing blogs at something which isn't going
away and is useful to users? How is this useful in anyway? Canonical isn't
suddenly going to give up on this, and I don't even want them to.

~~~
quantummkv
The main point here is that Snaps take away control from the user. The user
has no control over how and when apps update. The backend for snaps is
proprietary and completely in control of Canonical. If they decide to shove
ads down through Snaps, they can at any time. And the whole hijacking of the
chromium apt package to backdoor in snaps without user consent is a move
straight out of the Microsoft playbook

This feels very natural to what Apple, Google and Microsoft do on their OS.
But Canonical seems to have forgotten that such behavior is what drove a lot
of people to Linux. It is never going to be accepted. Nor it should be.

~~~
securityfreak
Very well said! I am afraid there is a prophecy in your description. I have
started moving all of our infrastructure away from Ubuntu at work. This sounds
horrible. 2020 has been bad enough for one year.

------
kemonocode
In my opinion, AppImage solved the problem Snap tried to solve, yet without
being horribly intrusive.

Kudos to Linux Mint for taking a stand in regards to it, and hopefully more
Ubuntu-based distros do the same until Canonical gets the idea.

I don't think they're out there trying to be malicious, but they need to be
set back to the correct path as it has been the case with odd monetization
choices for Ubuntu before that didn't really benefit anyone.

------
curt15
The anti-features of snap seem like business decisions. Making it easy for
users to use alternative stores would kneecap Canonical's paid IoT offerings
[https://ubuntu.com/internet-of-things](https://ubuntu.com/internet-of-
things). Also, I wonder if the ability for developers to force software
updates could be marketed as a kill switch for proprietary software vendors.

------
zubairq
My prediction (95% confidence): Snaps will become installable from Windows
(via WSL) and Microsoft will buy Ubuntu and try to take over the installers
for other Linux distros by having them use Snap as the main repo. This will be
Microsoft´s long term app installer strategy

------
olafura
Am I missing something isn't
[https://github.com/snapcore/snapcraft](https://github.com/snapcore/snapcraft)
and [https://github.com/snapcore/snapd](https://github.com/snapcore/snapd)
Free Software under the GPL3.

I had seen some discussion before about the server not being open source but I
can clearly see the store api there. I'm just looking at the code now and
haven't taken any time in testing it out for myself yet.

Regarding debian packages and apt as we have seen with the amount of PPAs,
there really has to be some solution for that. I like the snap format I
believe it's heading in the right direction. It still has some problems with
desktop software but that seems to be addressed as it has progressed.

There is this strange cold war between Red Hat and Canonical and Red Had seem
to have most of the NIH problems if you look at the history. I really don't
think Red Hat or some of it's developers possible like relying on code from
Canonical.

------
clircle
Snaps and flatpak help Linux work for me. My ideal desktop is a stable core
with a few select user applications that I can keep current. Thanks to
snaps/flatpak I can run Debian stable on my personal desktop, but keep emacs,
firefox, and a few more apps at their most recent versions.

~~~
RealStickman_
I'd like to point out that, as far as I know nobody or very few people have
problems with flatpak.

~~~
Shared404
There is flatkill.org, but that kind of comes across as FUD.

The privilege escalation attack looks a bit worrying, but aside from that it
looks either the same/better as/then native packaging (Sandbox for some apps),
or something that is on the developer (Out of date packages).

It's possible I'm misunderstanding something, if so please feel free to tell
me so.

------
panpanna
I'm _fine_ with snaps.

As long as they are limited to applications (i.e. not OS components) and look
reasonably like normal applications.

Why? Because you can't ask developers to package their apps for 100+ distros.
And they let us run latest versions of apps on an otherwise stable/old OS.

~~~
Shared404
Flatpak and AppImage would like a word.

------
superkuh
Snaps, flatpacks, and other containerization solutions only work on systems
with OSes set up in the last 5 years. Most of the containerization is justa
symptom of the real problem: future shock re: underlying libraries
(c++whatever,glibc, etc) and new features being used.

------
djohnston
i recently upgraded ubuntu and had to start dealing with snaps.. of the two i
tried to install they were both out of date and i ended up using apt to great
success. what was the point of this thing?

~~~
newacct583
> of the two i tried to install

Which two? I mean, a package is only as good as its curator. That sounds more
like a complaint about Ubuntu's Snap update policy or the community support
for whatever you were trying to install than anything about Snap.

I don't understand the fuss here. People who want control over the open source
software they install still have it, it still works like it always has. People
who don't care can't even tell the difference.

And in a handful of situations, like large apps with extensive dependencies,
or externally managed builds, or needs for cross-distro binary compatibility,
Snap has real and tangible advantages.

~~~
safetyfirstb
I think the issue here is that the apt versions are not always maintained
after an app moves to snap releases.

> And in a handful of situations, like large apps with extensive dependencies,
> or externally managed builds, or needs for cross-distro binary
> compatibility, Snap has real and tangible advantages.

I see that snaps can offer these advantages, but so can AppImage and FlatPak,
and these are even more cross-platform and don't come with the same limited
ecosystem.

------
julienfr112
I think snap versus apt is a question of taste, in the spectrum black box just
works vs hard to use but fully at the hand of the user. I'm currently having
the same choice with python between pip and conda. At the end, Ubuntu was a
very nice bridge between a use system that's just work, and server os for
production (db, backend..). I hope snap won't make that old.

------
dicroce
snaps and flatpaks are something I've wanted on Linux forever: self contained
apps. supporting umpteen million Linux distros is a non starter for small
isv's (or even large ones). if they aren't perfect, fix them... but don't
throw out the best thing thats happened to software deployment on linux in
forever.

------
cuspycode
I am currently using lxd to manage containers on a headless server. I just
found out that lxd on Ubuntu 20.04 has snapd as a dependency, which seems a
bit odd. Does anyone know if there is an easy way to install lxd without snap,
or should I just ditch it and try some other lxc-container manager?

------
darren0
I've been unhappy with the direction of Ubuntu for awhile, but having said
that it's still the best collection of packages that install with fairly sane
defaults for desktop/laptop. I've adopted a model of starting with ubuntu-
minimal installation and just installing the debs I want (disable recommended
packages by default). This gives me a fairly reliable base from Ubuntu but a
system assembled how I want (except systemd, can't avoid systemd).

~~~
afiori
Honest question: why not fedora?

------
sunstone
I've removed snaps on my new Ubuntu installs. Not sure how well this is going
to work out in the long run but if things start to mess up I'll move back to
LinuxMint.

------
mxc4
Are the arguments presented legitimate? Doesn't apt put the power in the hands
of the distro developers and not the end users? After all they get to decide
what is packaged and what is not.

Its all open source code so you can download and install yourself so I don't
buy the argument about it being against the GNU philosophy.

Apt and snaps solve different problems. The only argument I can see here is
the one about the back-end which is old and tired.

------
Ericson2314
....6 years of NixOS, and I kinda forgot remember that elsewhere unprivilaged
users and admins can't manage packages the same way.

~~~
ahnick
How is the package situation on NixOS nowadays? Do you find you have to custom
install a lot of software or are there native Nix packages for most everything
you need?

What kind of learning curve should one expect if migrating from debian/ubuntu
based distributions?

~~~
Ericson2314
There are existing packages in Nixpkgs for almost everything. Home-manager has
firmly emerged as the "configuration per user" tool. I might say, in fact, get
comfortable with home-manager and then switch to NixOS, if cold turkey sounds
like a lot.

Its a very, very different sort of distro, but if you know basic function
programming and are willing to do some "unlearning", you should be fine.

------
rafaelturk
I'm still haven't had a chance to learn more about this. Can pls someone put
in plain english what snap is?

------
justapassenger
There are real issues with snaps but “apt/deb is a wonderful package
management system and everyone is happy with it, at least the majority of
Ubuntu/Debian users” is such an immature argument.

------
pjfin123
If Linux is going to have any chance of replacing OSX or Windows for the vast
majority of users it needs to have a uniform executable which Snapcraft seems
like the best candidate for. Without a uniform executable a lot of developers
won't target Linux which is a deal-breaker for a lot of people. Clearly its
preferable to install common packages from a standard package manager, and
there should be better controls of how snaps get updated for power users, but
most potential Linux users want apps that work like apps on their phones. This
means you install it from a GUI app store, have access to proprietary apps,
and then the apps keep themselves up to date.

~~~
war1025
Desktop Linux doesn't really have the goal of replacing Windows or OSX. It's a
hobbyist thing, target more or less at software developers, and I think that's
perfectly fine.

Plus, the desktop is becoming less and less relevant every year.

I spend easily 10 hours a day probably at a traditional computer. My wife
spends an equivalent amount of time I'd guess in front of a screen, but it's
her phone.

------
securityfreak
The first I heard of snaps was while I was upgrading from 18.04 to 20.04 (I
only do LTS for work servers). What drove _me_ away personally, was I had no
idea what snap is and it was all over the place all of a sudden. After
studying up I was like “no I don’t want that, I want to have full control over
my system”.

I switched to Fedora Server. The packages are much fresher, the kernel is
fresher. It is a “staging” area for Red Hat, which for me is a plus.

Goodbye Ubuntu. I’ve been using you as my primary Linux distro since version
6.06!

------
fredsanford
Please, Canonical! unsnap snaps.

Bye bye Ubuntu if not.

------
rlpb
> The backend is proprietary.

GitHub is proprietary. I understand that some people don't accept that either.
But if you accept and use GitHub, then you should have no problem with snaps
on this basis.

Also, on this topic, consider this quote[1]:

"We did that experiment with Launchpad; the people who said they wouldn’t use
it because it wasn’t open source were the same people promoting a closed
source alternative. When we open sourced Launchpad, they said that they
wouldn’t use it anyway because Canonical was the primary contributor."

I am not saying that Flatpak is proprietary. I am saying that the focus on the
backend not having source available is specious.

> Developer controls the updates.

Users CAN defer updates (eg. because they're on a metered connection, or they
only want to update on Patch Tuesdays, or whatever). However, in the default
arrangement they cannot defer them indefinitely. But in today's Internet-
connected world, refusing updates forever is also anti-social and
unacceptable, so I don't see a great loss there. However you can manually
install a snap such that it never updates[2].

> APT does a fantastic job as it is.

No, it doesn't. It _is_ fantastic for distribution releases that don't change
their dependency structure after release. It's _terrible_ for shipping new
software to an existing distribution release. This is seen both in packages
that must have major updates frequently (eg. Firefox, which added _a whole new
Rust toolchain_ dependency that had to be backported into existing stable
distribution releases). It's also seen in various third party apt repositories
that ship software to users that break their systems by causing future upgrade
issues because they mess with distribution-provided dependencies in a way that
future distribution package updates do not know about. apt/deb also provides
no application sandboxing for third party software that you might trust less
than your distribution. If as a developer you've ever tried to ship software
to users as deb/apt, you would know this. Complaints about it are all over the
Internet and this has been the consensus for many years.

> Don't shove it down our throats, make it optional at least.

It already is optional. You can remove snapd and pin snapd in apt to a
negative score to never have it installed again[3]. Chromium won't be
available to you as a distribution-provided deb in Ubuntu 20.04 then, but nor
is it in Mint.

[1] [https://forum.snapcraft.io/t/linux-mint-20-disables-
deb2snap...](https://forum.snapcraft.io/t/linux-mint-20-disables-deb2snap-
packages-and-snaps-growing-external-adoption-problem/17913/19)

[2] [https://forum.snapcraft.io/t/disabling-automatic-refresh-
for...](https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-
from-store/707/269)

[3]
[http://manpages.ubuntu.com/manpages/focal/en/man5/apt_prefer...](http://manpages.ubuntu.com/manpages/focal/en/man5/apt_preferences.5.html)

~~~
Macha
If you don't like Github (or if they make a change in the future that makes
you dislike Github), you can use Gitlab CE, Gitea, Gitorius, git over ssh,
etc. all open source options while still using the upstream git client.

If you don't like the Snap Store, well, get coding and be prepared to fork the
client also.

~~~
m4rtink
And for the record Flatpak does not have any such limitation - while many
people use Flathub to host flatpal repos, there are many more Flatpak repos
available, including Distro hosted ones (Fedora has a system for building
Flatpaks from Fedora RPMs and hosting the resulting Flatpak repos).

------
whatsmyusername
I've never felt a desire or need to use snap at any point. Since we've been
implementing CIS standards I've started nuking snapd on host bake.

Maybe it's a thing for linux on the desktop, but my time isn't worthless so I
don't do linux on the desktop.

