It’s not possible to freeze a working configuration with snaps as they always auto-update. This is problematic for deploying software that has known working dependency versions.
Edit: I didn’t know about the new updates to snap and pinning. Thanks for the info!
- As a user: Snaps are annoying and don't work like a native app. It creates a new folder in my home directory, has little very consistency with other apps (even other packages of the same app), and feels generally unsuited for desktop use. If I'm going to use any of these godawful statically-linked-runtime package managers, it won't be the proprietary one.
- As an admin: Snaps are alright. If you just need to insta-configure something and are extremely lazy, it's a faustian deal pre-installed on every Ubuntu machine. As loathe as I am to admit it, most snaps are a cinch to install compared to native packaging or even Flatpak.
The snap client only supports the Canonical Snap Store. There is not even an "advanced configuration" to add your own. I do not want a single point of failure in the Linux ecosystem. Canonical does.
Slow, proprietary, auto update, sandboxed (which causes integration problems with other things). Solves a problem for Canonical and makes everyone else's life harder.
Sandboxing is a necessary evil - the Linux security model for applications installed on your computer is atrocious. The two main options we have to fix it are either a fine-grained capabilities model, or a coarse-grained sandboxing model - and the latter is an order of magnitude less work to implement.
However, Snaps do an impressively poor job of implementing a sandbox.
"Necessary" because Linux's security mitigations are unacceptably insecure for the 21st century. As it stands, I have to completely trust applications before I run them, and there's literally no reason for that to be the case - sandboxing is a straightforward mechanism, not a tricky problem like Traveling Salesman.
I don't care if you work in security - the fact is that I have to completely trust every application that I want to run on Linux, which is unacceptably bad, and "Simply not necessary for normal applications running on my local desktop" is factually false (unless you're using some "gotcha" convoluted definition of "normal").
A sanely-designed OS will provide either capabilities or sandboxing - the tech has been around for decades, and they're more needed than ever in the 21st century with its abundance of malware.
Well, each to his own I guess. I don't see the need for myself. Data is backed up, critical data is encrypted and I've never had a malware infection. I'm pretty careful.
You can run something like Qubes if you want better isolation.
> Well, each to his own I guess. I don't see the need for myself.
That's not an attitude that someone working in security would have.
It doesn't matter if "critical data is encrypted" if a keylogger is present when you enter your password. It doesn't matter that you've "never had a malware infection" because millions of other people have. And it doesn't matter that you're "pretty careful" because one of the core tenets of information security is that people are imperfect and it's best to remove as much of the human element as possible.
These are relatively basic facts that someone with a few years of experience would know.
> You can run something like Qubes if you want better isolation.
Qubes is sandboxing - but the thread topic is about sandboxing on Linux, and the need for it in OSes in general. Security should come built-in, not as something you use a special OS for.
We are talking about different things. I was talking about my own reasons for not wanting snap on my desktop. You are talking about the need for better security on operating systems in general.
Security is never an absolute, it's always a trade off between many different factors, such as usability, protection, and cost. You have to take a risk based approach. People who work in security have to do this on a daily basis.
For myself, the sand-boxing trade off is not worth it on my own desktop. Everything I have tried has significantly interfered with being able to do what I need to. If we were talking about what was needed on a critical, internet-exposed system, my answer might be different.
On the subject of what a good secure OS would look like, I studied capabilities extensively when I did my MSc in Info Sec. The E language and the EROS operating system were absolutely fascinating. Getting rid of ambient authority would be awesome. I have worked with people who worked on CHERI, which is also a really promising approach to use capabilities for better memory protection - and has the advantage that it can work with code not written for it.
When something like that is available, I'll be one of the first people trying it out!
Snap has been around for 8 years and during this time it got zero traction outside of Ubuntu. Canonical is known for axing their own projects eventually when they fail to get traction, so it seems pretty safe to assume that the writing is on the wall for snap.
No. Snap started as a project and got useful before flatpak.
Wayland technically was before Mir, but existed as blueprints and ideas back then. Shuttleworth tried to influence its design for his vision of linux desktop, but got rejected, so Mir was created. Mir became useful way before first implementations of Wayland, but Shuttleworth idea to expand Mir and Ubuntu to phones resulted in feature creep, lack of funding and eventually to project failure.
Gnome shell was also released after Unity. Both were influenced by MacOS LaF. The problem with Unity was that it was based on gnome 2 and compiz, that was a good compositor back in the days, but a dead end as a technology, as compositor should’ve been implemented on a lower level and be an integral part of DE. Shuttleworth started Mir and new Unity based on that, but both sank and Ubuntu had to revert to gnome-shell that became useful and more performant than earlier versions.
The difference is that Canonical forces the contributions ownership to be handed over, while RedHat plays by accepted opensource practices.
So while Canonical might have good initial ideas, the way they manage projects really kills them, e.g. snaps properly opensources might have been successful, instead they enforces the use of their proprietary server and ignore community requests (like moving /snap to /var/snap or making it configurable or allowing different servers/sources for snaps, while you can relatively easily make your own flatpak server and have users add the repo to their systems).
I don't know how broad this is, but the container based networking doesn't work with many corporate firewalls. So it's irritating if you happen to use your Ubuntu PC to VPN into work.
They just don't offer the same user experience as deb packages did. Firefox has always been a deb and it was fine. Now, it's a snap, it has issues with external devices like smartcard readers and so, and I remember it telling you to close it before X days so it could update, but closing the browser made no difference (I eventually moved to the Firefox tarball to forget about all those issues so I'm not really sure how you were supposed to solve it). So, for me, it didn't offer any advantages over the deb package, but brought new headaches. Also, I don't really like much this new concept of packing all the application dependencies instead of working with shared libs.
And I'm not the one that criticizes Canonical just for seeking its own solutions, in fact, I liked things like Unity and Upstart. But for me, snaps came to solve a non-problem.
It's worth noting that, in addition to Snaps starting up slower (a common complaint on this thread), they actually cause the OS to boot up slower. Every Snap application adds a small amount of startup time. I think I shaved a third off my total time by removing a bunch of Snaps, which is atrocious, unacceptable, and unjustifiable.
This is a ridiculous assumption. I'll boot my PC multiple times per day because I dual-boot and I'll sometimes need to switch between OSes repeatedly.
This is also a ridiculous dismissal. Snaps don't increase your startup time because it's an intrinsic limitation of the technology (e.g. like how internet connectivity necessitates higher power draw), but because they're designed badly. There's no reason for them to act like that, and people are rightly upset at it.
According to this blogpost from 2020 [0], this AskUbuntu discussion [1], this random german blog [2] and many other search results of "canonical snap backend proprietary software", the snap backend is proprietary software. There is no official information from Canonical available (that I've managed to find), so I think we can reasonably assume all this correlating information is true.
According to this Ubuntu documentation [3], the "dedicated snap stores" are just Canonical-hosted snap stores with more granular control, which isn't equal to hosting your own snap store.
There is an open-source implementation of snap store [4] which (assuming it works and someone is using it) would fall under "reverse engineering the protocol" part of my post, because the guy who wrote it reverse engineered the protocol [5]. Assuming that it works, this is the only part of my post that is not completely accurate - it is technically possible to host your own snap server without reverse engineering the protocol yourself, but that's only because someone else already did it. But Canonical could change the protocol any time and render this implementation obsolete, as they've done in the past [6].
So Screenly needs to distribute updates as Snaps, and in his talk, Petersson talked about the issues around that in some detail, including that Screenly runs & hosts its own private Snap store for this, and that it's built 100% from components in the Ubuntu repos.
I also talked to the developer of the Snap format, and the Ubuntu desktop lead, and they told me that they keep their store closed as a security measure, but it's perfectly possible to run your own.
> "This Ubuntu milestone release demonstrates our progress in raising the bar for the enterprise developer desktops, thanks to our best-in-class Linux integration with Active Directory (AD) Domain Services and now Azure Active Directory," said Canonical CEO Mark Shuttleworth.
I specifically moved to 20.04 and 22.04 when they touted this. I don’t see anything amazing here though, even on the desktop side. Eventually I still had to manually configure smb, sssd, nss, and chrony to make AD auth work natively in both my lab and prod networks.
Am I missing something?
Note: I’m not a landscape user or whatever the new version of their management system is.
22.10 was pretty bogus on recent Intel machines, even the 12th generation Core but especially 13th. It was so bad I upgraded to development Lunar as soon as they landed a 6.x kernel. Have been very happy since then. 6.2 is a giant leap beyond 5.19.
For those seeking a recent kernel, it's not necessary to be on the latest Ubuntu - the kernel of the LTS version is synced with the latest non-LTS version, some time after the latter has been released.
I did couple of months ago clean ubuntu 22.10 install. Somehow curl was installed from snap - of course I had problem saving curled files due sandboxing. Installed mosquitto2 (MQTT server) - of course it did not read my custom confs from /etc/... anymore - due sandboxing. Installed Libreoffice from snap - it Calc (excel alternative) was exctremely slow somehow - switched to Libreoffice from APT repo - it was fast as it should be.
and to not start with the autoupdate nonesense that you can not disable.
I have been ususing Kubuntu since 2010 and thinking of switching to some other distro with KDE and all because of SNAPs
I bailed after 20.04 and have been a happy Pop_OS (Ubuntu minus all the snaps out of the box), Fedora and Arch user ever since. Definitely try Pop as it's the most direct move from Ubuntu--really the only diff you'll notice is a different default system theme and background picture.
That's true for the store (Pop Shop), but not for the CLIs (apt and flatpak).
If an app has only a .deb or flatpak version, it's not clear which will be
installed. If there are multiple versions, you get a dropdown menu to select
one. Unfortunately, some apps are listed more than once (different packagers,
I assume).
Ubuntu, on the other hand, will sneakily install snaps via apt.
Similar boat, after about a decade on Kubuntu I switched to Manjaro, and there had been very little downsides (things like Postgresql major upgrade requires manual migration for example, which I didn't notice while updating the system) and a lot of advantages (or just one really, the AUR). Moving your right dotfiles (KDE ones are painful though) you can do the switch in less than a day and the change won't really be noticeable.
I currently run a small research cluster, and snaps are great. They make spinning up for instance a new redis instance super quick and painless. I think that snaps are mostly a server use, and the desktop users don't like it because they're not server admins and have different needs.
It looks like that flatpaks have mostly won the desktop market, but on the server side docker and snaps are both really nice.
Damn, i was wondering why is everyone still talking about snap and nobody is mentioning what I clearly remember reading recently, so i went back and looked for it and lo and behold the publishing day:
https://news.itsfoss.com/ubuntu-ditch-snap/
Canonical really seem to have lost their mojo. They've had a long-running tendency to forge on ahead regardless with fingers in ears, instead of listening to their userbase about what they actually want. Forcing snaps on users being a prime example of this behaviour. As a consequence, many users are jumping ship to other distros, and who can blame them?
In fact, I'm in the same camp. I'm imminently replacing a very nearly EOL 18.04 install with Arch. I've tried a non-trivial amount of distros over the course of my Linux days (since Fedora Core 5) and Ubuntu has probably seen the most install time over that period, but my time with Ubuntu is now at an end. Snaps suck.
I agree completely with all of that. My added difficulty is that I use a lot of hosts and they are a mix of AMD64, Arm, Arm64, and RV64GC so having a single distribution on all simplifies my life. Ubuntu in my experience has the best support for that set, but I experimented with Arch, Debian, Fedora, and OpenSUSE as well. I'd welcome insights, but Fedora appears most promising for me with Debian a close 2nd. (Arch is actually awesome, but package support is very mixed).
There is nothing wrong with apt and dpkg. It’s just that Ubuntu infected apt with their poison by making ‘apt install firefox’ install a snap package and they’re poised to do it with more packages (maybe they already have).
I personally can’t think of anything software related that Ubuntu provides over Debian for normal desktop users. Only the Ubuntu 6-month release schedule can be a bit nicer.
Snaps, flatpack, whatever, comes down to the core problem with linux, little binary compatibility between distro versions. The entire OS and all apps are recompiled on latest versions of compiler and libraries. Its a bandaid fix for a fundamental problem with the entire ecosystem of linux flavors.
This was the same issue that passed onto linux based android os, requiring updated blobs for drivers, held older android devices to older versions.
Why settle for a substitute? Just use Debian. More honest, more free, no commercial shenanigans and no snaps.
I've been a Debian user on all my laptops, desktops and servers for 25 years and counting, it's the best there is, for me.
I switched to Arch as soon as ubuntu started pushing snaps and never looked back. Of all the reasons to hate snaps what did it for me was the loopback device spam when trying to list block devices. Canonical has a track record of doing things the community doesn't agree with, carefully reading all the feedback, and then doubling down on whatever terrible idea they had and continuing anyway.
I didn't mind the snaps since I always was able to disable them on every update, but somehow I started to get a lot of kernel freezes when running some IO heavy unit tests, it was getting really annoying. It may have been a btrfs bug or some other bug but I blamed ubuntu and installed archlinx instead.
Same btrfs/snapshotting configuration on arch and never had any issues so far...
61 comments
[ 4.2 ms ] story [ 131 ms ] threadEdit: I didn’t know about the new updates to snap and pinning. Thanks for the info!
- As a user: Snaps are annoying and don't work like a native app. It creates a new folder in my home directory, has little very consistency with other apps (even other packages of the same app), and feels generally unsuited for desktop use. If I'm going to use any of these godawful statically-linked-runtime package managers, it won't be the proprietary one.
- As an admin: Snaps are alright. If you just need to insta-configure something and are extremely lazy, it's a faustian deal pre-installed on every Ubuntu machine. As loathe as I am to admit it, most snaps are a cinch to install compared to native packaging or even Flatpak.
However, Snaps do an impressively poor job of implementing a sandbox.
Can you elaborate on the "necessary" part? I'm able to accomplish my computing goals without snaps.
A sanely-designed OS will provide either capabilities or sandboxing - the tech has been around for decades, and they're more needed than ever in the 21st century with its abundance of malware.
You can run something like Qubes if you want better isolation.
That's not an attitude that someone working in security would have.
It doesn't matter if "critical data is encrypted" if a keylogger is present when you enter your password. It doesn't matter that you've "never had a malware infection" because millions of other people have. And it doesn't matter that you're "pretty careful" because one of the core tenets of information security is that people are imperfect and it's best to remove as much of the human element as possible.
These are relatively basic facts that someone with a few years of experience would know.
> You can run something like Qubes if you want better isolation.
Qubes is sandboxing - but the thread topic is about sandboxing on Linux, and the need for it in OSes in general. Security should come built-in, not as something you use a special OS for.
Security is never an absolute, it's always a trade off between many different factors, such as usability, protection, and cost. You have to take a risk based approach. People who work in security have to do this on a daily basis.
For myself, the sand-boxing trade off is not worth it on my own desktop. Everything I have tried has significantly interfered with being able to do what I need to. If we were talking about what was needed on a critical, internet-exposed system, my answer might be different.
On the subject of what a good secure OS would look like, I studied capabilities extensively when I did my MSc in Info Sec. The E language and the EROS operating system were absolutely fascinating. Getting rid of ambient authority would be awesome. I have worked with people who worked on CHERI, which is also a really promising approach to use capabilities for better memory protection - and has the advantage that it can work with code not written for it.
When something like that is available, I'll be one of the first people trying it out!
Upstart -> systemd
Unity -> Gnome 3 Shell
Mir -> Wayland
Snaps -> flatpak
I’m not saying Red Hat is wrong to do this, that’s the nature of healthy competition and we all benefit from this.
And GNOME 3 as well? Unity was a reaction to GNOME 3's big changes.
Either way, I agree that competition is better.
Wayland technically was before Mir, but existed as blueprints and ideas back then. Shuttleworth tried to influence its design for his vision of linux desktop, but got rejected, so Mir was created. Mir became useful way before first implementations of Wayland, but Shuttleworth idea to expand Mir and Ubuntu to phones resulted in feature creep, lack of funding and eventually to project failure.
Gnome shell was also released after Unity. Both were influenced by MacOS LaF. The problem with Unity was that it was based on gnome 2 and compiz, that was a good compositor back in the days, but a dead end as a technology, as compositor should’ve been implemented on a lower level and be an integral part of DE. Shuttleworth started Mir and new Unity based on that, but both sank and Ubuntu had to revert to gnome-shell that became useful and more performant than earlier versions.
So while Canonical might have good initial ideas, the way they manage projects really kills them, e.g. snaps properly opensources might have been successful, instead they enforces the use of their proprietary server and ignore community requests (like moving /snap to /var/snap or making it configurable or allowing different servers/sources for snaps, while you can relatively easily make your own flatpak server and have users add the repo to their systems).
It causes problems on Windows with WSL2 as well.
And I'm not the one that criticizes Canonical just for seeking its own solutions, in fact, I liked things like Unity and Upstart. But for me, snaps came to solve a non-problem.
1. They don't scale, space-wise; libraries can take very considerable space
2. Permission issues
3. Configuration issues
4. Startup speed issues
Compared to a trusted (I stress "trusted") apt repository, for my use case, they have only downsides.
This is also a ridiculous dismissal. Snaps don't increase your startup time because it's an intrinsic limitation of the technology (e.g. like how internet connectivity necessitates higher power draw), but because they're designed badly. There's no reason for them to act like that, and people are rightly upset at it.
Without reverse engineering the protocol, it is impossible to host your own snap repository.
Other companies have and do most their own snap stores.
According to this Ubuntu documentation [3], the "dedicated snap stores" are just Canonical-hosted snap stores with more granular control, which isn't equal to hosting your own snap store.
There is an open-source implementation of snap store [4] which (assuming it works and someone is using it) would fall under "reverse engineering the protocol" part of my post, because the guy who wrote it reverse engineered the protocol [5]. Assuming that it works, this is the only part of my post that is not completely accurate - it is technically possible to host your own snap server without reverse engineering the protocol yourself, but that's only because someone else already did it. But Canonical could change the protocol any time and render this implementation obsolete, as they've done in the past [6].
[0] https://hackaday.com/2020/06/24/whats-the-deal-with-snap-pac...
[1] https://askubuntu.com/questions/1383583/is-it-true-that-snap...
[2] https://merlijn.sebrechts.be/blog/2020-08-02-why-one-snap-st...
[3] https://ubuntu.com/core/docs/dedicated-snap-stores
[4] https://github.com/freetocompute/kebe
[5] https://forum.snapcraft.io/t/announcing-project-kebe-open-so...
[6] https://github.com/noise/snapstore
So, before, you said:
> Feel free to provide information that proves otherwise.
OK, then, I will.
Here's a story I researched and wrote myself about a 3rd party store:
https://www.theregister.com/2022/02/04/rudra_sarsawat_ubuntu...
Here's his announcement:
https://forum.snapcraft.io/t/lol-an-open-source-snap-server-...
I attended last year's Ubuntu Summit. There were multiple talks on Snap. Here's my report:
https://www.theregister.com/2022/11/09/canonical_conference/
One talk was by Viktor Petersson:
https://www.screenly.io/blog/author/vpetersson/
This is his company, Screenly:
https://www.screenly.io/
Screenly does autonomous remote managed digital signes, running Ubuntu Core.
As you probably know Core has no other packaging format than Snap:
https://www.theregister.com/2022/06/17/ubuntu_core_22/
So Screenly needs to distribute updates as Snaps, and in his talk, Petersson talked about the issues around that in some detail, including that Screenly runs & hosts its own private Snap store for this, and that it's built 100% from components in the Ubuntu repos.
I also talked to the developer of the Snap format, and the Ubuntu desktop lead, and they told me that they keep their store closed as a security measure, but it's perfectly possible to run your own.
I specifically moved to 20.04 and 22.04 when they touted this. I don’t see anything amazing here though, even on the desktop side. Eventually I still had to manually configure smb, sssd, nss, and chrony to make AD auth work natively in both my lab and prod networks.
Am I missing something?
Note: I’m not a landscape user or whatever the new version of their management system is.
There's a good synopsis of what's new in this release here:
https://www.howtogeek.com/883728/whats-new-in-ubuntu-23-04-l...
I did couple of months ago clean ubuntu 22.10 install. Somehow curl was installed from snap - of course I had problem saving curled files due sandboxing. Installed mosquitto2 (MQTT server) - of course it did not read my custom confs from /etc/... anymore - due sandboxing. Installed Libreoffice from snap - it Calc (excel alternative) was exctremely slow somehow - switched to Libreoffice from APT repo - it was fast as it should be.
and to not start with the autoupdate nonesense that you can not disable.
I have been ususing Kubuntu since 2010 and thinking of switching to some other distro with KDE and all because of SNAPs
I really dislike snaps.
Ubuntu, on the other hand, will sneakily install snaps via apt.
It looks like that flatpaks have mostly won the desktop market, but on the server side docker and snaps are both really nice.
In fact, I'm in the same camp. I'm imminently replacing a very nearly EOL 18.04 install with Arch. I've tried a non-trivial amount of distros over the course of my Linux days (since Fedora Core 5) and Ubuntu has probably seen the most install time over that period, but my time with Ubuntu is now at an end. Snaps suck.
I just want that, I guess it means back to Debian?
I’m not excited or interested about spending time dealing with a package manager.
I personally can’t think of anything software related that Ubuntu provides over Debian for normal desktop users. Only the Ubuntu 6-month release schedule can be a bit nicer.
This was the same issue that passed onto linux based android os, requiring updated blobs for drivers, held older android devices to older versions.
And same issue for ARM flavors.
Same btrfs/snapshotting configuration on arch and never had any issues so far...