Canonical shows how to use Snaps without the Snap Store

One of the most common bits of FUD about Ubuntu's Snap packaging format is that it's proprietary – but exploring the documentation shows that is wrong. At last weekend's Ubuntu Summit in Rīga, Latvia, the Reg FOSS desk talked with Ubuntu developer advocate Igor Ljubuncic about Snap, and especially some of the myths about it: …

[Bebu]

All pretty horrid...

Quite a calm write up even if Canonical paid the airfare to Latvia - I imagine a really nice place especially at this time of year.

All been down hill from Autotools' configure, make, make install :)

One tip if you really really must extract executables and libraries from snaps, flatpaks etc and have to put them under /opt or /usr/local or whatever your peculiar poison -- patchelf can really be your friend - LD_LIBRARY_PATH and LD_PRELOAD will always eventually disappoint :)

With this nifty utility you can modify the interpreter (run time loader ld.so), the search path rpath/runpath, needed libraries and more besides in elf executables and shared libraries. ($ORIGIN is a godsend.) Always script the modifications so updates or repackaging can be automated.

If the application uses the dlopen() with absolute paths that might scuttle your efforts unless you descend into even more skulduggery. :)

I once had to do this with a binary only flatpak(?) app and repackage it as an rpm. :(

Feels a bit like Thomas de Qincey "Confessions of..."

[saif]

Trollers must be haters...

I am anticipating the usual triggered anti-canonical posters. But while security and robustness is essential for industrial environments, for the ordinary desktop linux user this is probably excessive. Like cheapskate, old fogey, junk PC recyclers, I like to get software that did the basics with best performance and reduced space requirements on any PC. Not expecting my browser software to need to be isolated from CAD software or have to worry about negotiating layers of interfaces so that my non snapped photoeditor can interact with my snapped word processor. If there was a mechanism to "unsquash" the snap (ok, gonna be complicated) would be great.

[Allonymous Coward]

Re: Trollers must be haters...

Agree it may be excessive security-wise for quite a few users.

One user problem tools like snap (& flatpak, and PPAs, and…) *do* solve, though, is “why can’t I get version N+1 of app XYZ on my desktop?”

My desktop runs Debian stable so I’m very familiar with the I’m-running-a-3yr-old-version problem :)

I tend to solve it with flatpak rather than snap mostly because I don’t like all the extra fs mounts snap creates. If flatpak didn’t exist though, I’d probably hold my nose and use snap.

[Peter Gathercole]

Re: Trollers must be haters...

I don't mind one or two mounts from snaps. but way back when snaps first made their way into Ubuntu, I typed "mount" on my laptop, and got more than one screen full of snap mounts on top of all of the OS and fuse mounts.

So, package paid for application software as snaps for portability to make it more likely that people will actually produce and/or port commercial software for Linux, but leave the OS and OS related applications as Apt or some other package management files. The core GUI code should definitely not be a snap.

[Liam Proven]

Re: Trollers must be haters...

I agree, the mounts are a pain.

I wonder if it would be possible to add a "mount only on first run" flag to a snap...?

[Anonymous Coward]

Re: I agree, the mounts are a pain

Spot on.

Then there is the fact that you have to run the snapd daemon. WTF!!!!!!!!!!

Why do you need a frigging daemon consuming resources when SNAP is a package manager or something like that.

Poettering???? Are you respinsible for this monstrous PIECE OF BOVINE EXCREMENT?

I made a choice NOT to use Ubuntu or any of the distros based on it or anything from Canonical. Then I find that I have to use SNAP because the devs of a key component of my system decided to ONLY support a SNAP image. Fsck them!

Yes, I hate SNAP.

[Steve Graham]

All these packaging products exist because it's "too hard" to maintain dependencies these days. Or is it just that the developers aren't smart enough to come up with a better solution?

[Liam Proven]

[Author here]

They exist, like AWS, like cloud computing, like Kubernetes, to save work for somebody somewhere.

Canonical typically has 5 "current" releases of Ubuntu in support. Like Debian, most of the packages in the distro stay at the same version for the lifetime of the distro.

But Firefox can't. Browsers need to be more current. They are _the_ core tool now and security problems and so on are eternally recurrent. So, Canonical has to maintain Firefox $CURRENT for 5 or 6 distros going back 5-6 years, constantly.

One package that can run on all of them saves the company a lot of work.

Much flows from that. Same goes for RHEL/Fedora with LibreOffice etc.

It's about making stuff easier, for maintainers and for users, at the cost of some disk space.

That, on the face of it, is not a bad thing.

[David 132]

Liam: It's about making stuff easier, for maintainers and for users, at the cost of some disk space.

That, on the face of it, is not a bad thing.

In a world where storage space is way cheaper per byte, and more capacious - and security is far more of a headache - than in *nix's formative decades, this does seem to be a reasonable trade-off, I'll semi-grudgingly agree.

[Grogan]

I very much disagree. My computing resources are not theirs to waste.

That's fucking bollocks, what a kludge. So now you're running suboptimal builds, linked against a bunch of suboptimal libraries, duplicating those on the system all because these commercial distros (the ones with the most money!) are too lazy to provide the environment you need.

Meanwhile you don't hear community distros complaining about supplying everything (+lib32) that people need.

[doublelayer]

"My computing resources are not theirs to waste."

Your computing resources are used for whatever you tell them to. By writing my software less efficiently than could theoretically happen, I'm not wasting your resources; you're making the choice to run it and are free to choose otherwise. For example, you never have to use Snap and can build everything that would have used it from source if you want. Thus, having the Snap option is not putting any requirements on you. Don't play the victim because you have software someone else wrote and are running it.

Every decision involves tradeoffs between the resources it will use. Packaging systems that bring along dependencies makes the decision that users may be willing to use more disk space in order to have faster access to updates without spending as much of a distro maintainer's time. The alternatives can make more efficient use of disk space at a cost of more maintainer effort required. If you don't like the decision made by your local maintainer, you can find another, and if you don't like the decisions being made in general by all maintainers, you can be your own. Either way, the tradeoffs will always be there and your preferences aren't necessarily the same as everyone else's.

[kalibey]

A software dev with no concern for the end user it seems. Possibly the end users don't see the advantage that snap brings to the software maintainers because they experience things like excess mount points, slow app launches, and the silly snap daemon. Everywhere the user looks snap is causing nuisances for them while (it seems from your post) that snap makes the maintainers life tons easier? Maybe we should move every app into Docker containers or virtual machines so they can carry their own OS as well?

[Updraft102]

"So, Canonical has to maintain Firefox $CURRENT for 5 or 6 distros going back 5-6 years, constantly."

Yes, and they still do that, even after switching to Snap Firefox (adding yet another version to the total). It's in the form of a PPA now, the Ubuntu Mozilla Team PPA, but Ubuntu people still do the work. They haven't saved any labor at all.

Even it that was not the case, Firefox is one package out of tens of thousands that Canonical maintains for each Ubuntu version, and it's released more or less "ready to go" by Mozilla as far as the source code is concerned.

You mention that a given Ubuntu typically sticks with a given version of many packages, but that doesn't imply less work. It's more work to take a given older version of a package and backport the security and stability patches, then getting it to actually compile and work as intended, before you even get to the point of packaging the thing. The newest release of a given package from its upstream provider is already tested and subjected to some level of QA, but with backports, it's the distro's job now.

Clearly, Canonical is not doing the "Snap" thing to reduce the labor when all they have really done is added the Snap on top of all of the versions they were already maintaining, and are still maintaining. It looks much more like they're using it to try to make "Snap" happen, using maintenance as an excuse, and alienating a lot of Linux users in the process.

[doublelayer]

I wouldn't pretend that this is the best solution to the problem, but if anyone has a better one, people are here to listen. Most better options are better for some use case and either painful or completely broken for others. The benefit of Snap or things like it is that they can work for a number of generic situations, rather than just one.

[Pete Sdev]

Arguably one solution is static compiling, which has existed since forever. Means the end binary is larger but that's not usually a problem these days.

Dynamically linking to libraries came from an age when disk space was limited and expensive. Unless you're developing on embedded systems or similar, that's no longer the case.

[FIA]

There's a lot to be said for fat binaries, especially in the Linux world.

A few years ago I had a (Windows) Qt app I wanted to distribute cross platform. This was in the days before Snap et. al.

Windows and Mac were fine, NSIS and macdeployqt respectively. However, for Linux (which I didn't really use) I concluded that a 'fat' binary was the way to go.

I didn't wish to spend time learning the various package managers for OSs I didn't actually use, so just ended up statically compiling the binary and shipping that, along with the object files and instructions needed to re-compile against a modified Qt for LGPL compliance.

(This was a hobby freeware app just to be clear, not a commercial or work thing).

[probgoblin]

> All these packaging products exist because it's "too hard" to maintain dependencies these days.

Yes? If I'm running an app that needs a specific flavor of Node say... 1.3, and another that requires a different specific flavor of Node (1.8) I have three options:

1. Deal with the headache of having multiple concurrent versions running on my system at the same time and making sure that whenever anything updates I go back and verify that each application is still pointed at its required version of the dependency. This may not sound too bad, until you wind up with multiple dependencies requiring multiple versions (Python, Node, and Elixir have taught me new ways to hate computer).

2. Isolate each application to its own container/Snap/Flatpack/Appimage/other Sr. Goblin's School for Wayward Binaries that keeps its needed dependencies handy but in a place where they can no longer hurt society at large.

3. Not run that app.

> Or is it just that the developers aren't smart enough to come up with a better solution?

This is the developer's solution. The only other one I can think of would be getting every developer to agree to use the latest version of whatever underlying library/language/cursed rune that their software uses and update it every time a new one drops and, while we're on Santa's lap, maybe get rid of a lot of them (who needs Crystal, really?) so there are fewer dependencies to depend on. If you look at the state of Linux (absolute) and see that there are only a few less distros than total worldwide users, many of whom are still arguing about which terminal is the best way to interact with all of this, you'll see that the likelihood of that happening is actually negative.

[Tom 38]

Apologies, can't seem to find the "Corrections" link

and I know you're proactive in the comments Liam...

Snaps are delivered as two files: the software itself, inside a file called <name>_<revision>.snap</revision></name>

Think something automated has gone "HTML?! I must close these tags!"

[Liam Proven]

Re: Apologies, can't seem to find the "Corrections" link

[Author here]

*Much laughter*

I think you are right. I will ping the editors.

[gssdu]

Re: Apologies, can't seem to find the "Corrections" link

Yellow card for attempted use of angle brackets in an illegal context. :-p)

[Anonymous Coward]

OK...So package managers suck....but.....

Fedora User Here! The Fedora package arrangements (dnf, rpm) are always compiled for the current release, right now F39.

To get to the point, it's not clear in this article whether Snap packages are similarly tied to a specific Debian/Ubuntu release.

Yes...I did read this quote ("...Firefox will try to access the root libraries, and this can lead to inconsistency in execution...")

So....RedHat/Fedora try quite hard to keep releases and their packages syncronised.....what's the position with Snap?

[Liam Proven]

Re: OK...So package managers suck....but.....

[Author here]

> Snap packages are similarly tied to a specific Debian/Ubuntu release.

No.

Snap is not the native Ubuntu packaging format. Snap is not included in Debian.

.DEB is the native format for Debian and Ubuntu just as .RPM is the native format for Fedora, CentOS, RHEL, openSUSE, Mandriva, Mageia, etc.

Snap is a cross-distro format. Its main rivals are Flatpak and AppImage.

The whole point of Snaps is that they run on any distro, just like RH's Flatpak format.

[Anonymous Coward]

Re: OK...So package managers suck....but.....

They run on any distro that has systemd.

[David 132]

Re: OK...So package managers suck....but.....

They run on any distro that has is built into systemd.

Fixed that for you. I might be a year or two premature, but not excessively so...

[Liam Proven]

Re: OK...So package managers suck....but.....

> They run on any distro that has systemd.

OK, give you that one. :-)

Although the calls are simple enough, and Oliver Grawert told me that there's no specific dependence on systemd itself, just on some of the functionality, so if another init chose to implement that, it's theoretically but perfectly possible.

I suspect that Chimera Linux might be the first to be able to do that.

[nhaines]

Re: OK...So package managers suck....but.....

Snap packages are tied to a specific core snap. This lets software designed and compiled for a different Ubuntu LTS to run on any distro that supports snaps. You could (but shouldn't) run the latest Firefox snap, based on core20, on Ubuntu 14.04 LTS (with esm support enabled so you have a recent snapd) with no issues.

[chris street]

When Snap gives me something useful over apt - I might use it. But I dont want updates outside my control, I like a lightweight environment, and I dont like the bloat and increased startup time. I dont need cross distro working.

Now if it was an alternative that would be fine. But Ubuntu stuffs it down my throat and makes me use it - yes there are workarounds but if wanted to do that I'd be faffing about with Windows.

So I use Mint.

This is not an anti Ubuntu postion. It's just the consequences of their choices.

[getHandle]

Nailed it

Plus snaps don't seem to update automatically for me. Every time I start some of my lesser-used boxes I get two package managers pop up - one for all the system stuff and one for Firefox. Yes, two package managers are worse than one!

[David 132]

Re: Nailed it

Running Firefox here on Mint. Does anyone else get irrationally annoyed when FF has been updated via Update Manager, and then refuses to open new tabs until it's been closed & restarted to finish its update - or is it just me?

Yes, yes, logically I know why it refuses to spawn new tab processes mid-way through its update, but it still irks me cos it interrupts my workflow.

[Ian Johnston]

Re: Nailed it

I ditched FF because of the God-awful mess the Ubuntu people made of the upgrade process. The most evil bit is that it updates itself in the background then demands that you restart it without giving any opportunity to save work in open tabs. That's GNOME levels of "Fuck the users", right there.

[David 132]

Re: Nailed it

@Ian J

Hmm. That’s puzzling. In my experience Firefox, when I give in and close it to finish its update, automatically saves the state of however many tabs I have open, and invariably restores them when the new version launches.

So I only lose a few seconds of time (which is why I said “irrational” in my original comment :) …) but fortunately no work.

I wonder if I’m just missing something? Or if you had some extension(s) installed that were interfering with the auto-tab-save mechanism?

[Ian Johnston]

Re: Nailed it

It never managed to reopen my tabs, let alone restore their state.

[Grogan]

Re: Nailed it

Well, here's the thing. You can compile Firefox yourself, disable features you don't like, including even compiling the updater in the first place. It takes a couple of hours for an optimized build (PGO+LTO) but then it's yours. Install it wherever you want. (I use /opt/firefox myself)

It's less onerous to build than Chromium and easier to customize.

Fuck containers, I find that highly offensive. Insulting, in our environment.

[kalibey]

Re: Nailed it

Isn't the point of packages maintainers sharing their time/work with the community? Doesn't a package save everyone the time and resources vs. everyone building everything from source? I share my package, you share yours, we both save resources. Telling someone to go compile their own OS when they complain about snap causing slow app starts and silly multi-version mount points is silly. It is not realistic to expect everyone who prefers apt over snap to build from source when apt has worked so well for so long.

[Cloudseer]

Re: Snap usefulness

A benefit is that the program you install with snap cannot access everything in your home directory, quite a benefit. And works when you’re distrobhopping.

[druck]

Re: Snap usefulness

Stuff in my home directory is there for the applications I run to access, so definitely not an advantage.

As for distrohopping, maybe I run a limited set of software, but it is all present on every distro I've tried.

[nhaines]

Re: Snap usefulness

But not your .ssh directory.

Snap guards against hidden file access in your home directory.

[Johannesburgel12]

After ten years I finally ditched Ubuntu for Debian Unstable and Flatpak on all my machines. Things haven't been so quiet for ages, and the laptops also have considerably better batter life on Debian.

[Allonymous Coward]

I ran some variation of an Ubuntu desktop for about 15 years. I finally gave up and moved to Debian stable when I realised most of the things that were annoying me were “value adds” that… didn’t add value.

I sidestepped Mint for the same reason, so it’s not just an Ubuntu thing.

Distro hopping is boring, learning new things for the sake of change is boring. At the end of the day I just want a desktop that’s easy to maintain, stays working in much the same way over time, keeps itself up to date and runs the applications I need. The last thing would be hard to achieve with Debian, but tools like snap and flatpak (my preference) make it easy.

[Allonymous Coward]

We briefly looked at snap at work

When it was first released, or not long after. The use case was packaging server-side applications for deployment.

It seemed…OK as I recall. I don’t think anyone was concerned about anything in the tech itself being “proprietary” but there didn’t seem to be a clear story around distribution outwith Canonical-provided infrastructure at the time. I’m fairly sure people said it was possible, but examples of it actually being done were a bit thin on the ground.

In the end I think the effort petered out though indifference rather than any particular objections. We could also solve deployment problems with tools like Ansible.

[Anonymous Coward]

Slow

All I know is that on my well specced modern Ryzen 4900 laptop with SSD and plenty of memory launching snap Firefox takes an age. If thats progress count me out.

[Ilgaz]

Re: Slow

Not just that, it looks like you can't get wayland while flatpak version can with a single exrra command.

[TVU]

Canonical shows how to use Snaps without the Snap Store

Personally, I still prefer to use Synaptic Package Manager and GDebi Installer.

[captain veg]

So, is this wrong?

https://linuxmint-user-guide.readthedocs.io/en/latest/snap.html

"The Snap client is designed to work with only one source, following a protocol which isn’t open, and using only one authentication system. Snapd is nothing on its own, it can only work with the Ubuntu Store."

The article isn't entirely clear on this. I read it as stating that after download from the Ubuntu store you are free to re-publish elsewhere.

Have to say, though, that Snap fixes problems that I simply don't have. APT and dpkg work just fine.

-A.

[BitGin]

Re: So, is this wrong?

I think the answer is both yes and no.

As snapd is shipped in Ubuntu it's all tied to canonical so from the basic user's perspective who just wants to use software as it's supplied that statement is true.

OTOH if you're a distro or an enterprise user who wants full control over your snaps and you're prepared to do some work yourself then the statement is false.

The only part of the snap stack that isn't freely available is the backend to the snap store which (I presume) is mostly just the mechanism for maintainers to submit updated packages.

If mint wanted to they could build their own snap packages, host them on their own server and patch snapd to work with that. They can even mirror any snaps they don't want to build themselves from canonical's store.

The reason snaps (and other alternative packaging systems) exist is to solve problems that debs etc mostly hide from you. They're problems someone else is spending a lot of time and effort solving so you don't have to. When canonical moved chromium to snap they did it because it's very hard to build a deb of it and they were just using the Debian deb which was usually months out of date. Mint decided to put the effort in to build their own up to date deb instead. Good for them and all users but IIRC this meant they had to dedicate someone and several servers to just building updated chromium debs. Just typing "apt install chromium" is easy for you but only because of all the effort put in by someone else.

Canonical should probably have made the snap store a separate entity that had representation from multiple distros. They could have maintained defacto control by being the biggest contributor without all the pushback.

[corb]

The trolling gets in the way...

When I see "proprietary software" I think branded closed-source products where access to the code is either impossible or requires payment of significant fees.

I don't see anything Canonical is doing re: Snap that fits that. Their Snap Store itself is an irrelevancy, as all such shops are. They're user-side programs to access a repo. "Store" is only a metaphor.

Hostile reaction to all-things Snap sure looks like kneejerk trolling intended simply to punish Canonical for not adhering to someone's demand that everyone in open source must abide by the notions in their head. Or maybe they're still mad about Gnome or whatever.

Snaps, flatpak, appimages and the technology surrounding them merit serious investigation, experiments, and testing. The trolling just makes that more difficult.

It is obvious that all the commercial Linux players are moving toward containerized/immutable/etc systems. It makes good sense for those kinds of markets. And, they're competitors in those markets so, of course, they're fielding different approaches to the same end in hopes of locking down market share.

For individual Linux users and enthusiasts, I don't think it will make much difference as long as debs, rpms, and other traditional package systems are supported. I suspect they will be supported for a very long time because Canonical, Red Hat, etc., will spend years, if not decades, trying to transition their existing paying customers.

For me, if I can tweak and fiddle with things as I currently do, I'm not sure I care about snaps vs flatpaks vs appimages. That's not the case, now, however. There are applications I use that I would not use if I couldn't do use an external tool to adjust one thing thing or another that the app itself does not expose to users. And that's why I don't use flatpaks or appimages.

[getHandle]

Re: The trolling gets in the way...

You are an AI and I claim my £5

[georgezilla]

My distro(s) already have a package manager(s). So why do I need(?) another one?

And they have worked just fine for as long as I've used them.

So why do I need another one?

Or do I need another, different package manager because it's just to damn complicated to click on the "install" button when asked?

And what do I do when an install breaks something? Well ....................

I fix it. Because ........ Linux. And I can. Which is one reason why I use Linus instead of OS's X and Y. You can't? Well there's always OS's X and Y.

[doublelayer]

"My distro(s) already have a package manager(s). So why do I need(?) another one?"

The reason these tools have been developed isn't hard to understand: distros that don't update every package immediately versus software that does update its dependencies immediately, but you want to run the latest version of that program on your older distro. If you don't want to do that, because you either have a distro that updates every package every time a new version comes out or you are comfortable using the old version of something that updates frequently, then you can cheerfully ignore this tool. Otherwise, that's why a second way of distributing the software makes this possible.

[corb]

*You* don't need another package manager. Neither do I.

We have things like snaps and flatpaks and appimages because developers want to package their products once, not repeatedly for every distro, and they want control over their software, rather than permitting what shows up on user hardware to be determined by distribution packagers.

And because distributions want to get out of the packaging business.

This will change the nature of distribution because packaging is most of what distributions do.

None of this will happen fast but I expect we will see developers only supporting their software when it's packaged in the format they released it in.

[Liam Proven]

[Author here]

> So why do I need(?) another one?

They solve a very specific problem which I have described in some detail already.

I carefully described it last year here:

https://www.theregister.com/2022/11/09/canonical_conference/

«

Canonical started packaging Firefox as a snap in Ubuntu 21.10, but that means that the company now need only maintain a single Firefox snap. Every time the Firefox snap is updated, the same package updates the Firefox version in Ubuntu 21.10, 22.04, 22.10, and those in the foreseeable future too. Each successive Ubuntu release means a modest reduction in Canonical's support burden.

»

[Ian Johnston]

Which of course opens up the question: why does Canonical think that introducing a new and at some level incompatible version of Ubuntu every six months is a good idea? Snap is a poor solution to a problem entirely of their own making.

[Gene Cash]

You can't use gzip/tar?

I untar Firefox into /opt or /usr/local and it works just fine. Same with Thunderbird, PrusaSlicer, BlueGriffon, and a bunch of other apps.

I've done this for at least a decade, and I've never had anything have an issue with the versions of libraries I have installed.

People don't seem to have a problem with providing a Debian repository for OpenSCAD and Brave that integrates into the native package manager by adding a line to a config file.

This is "solving" a problem that doesn't actually exist, just like systemd.

On the other hand, this is the first and only decent explanation of how snaps work that I've seen. I think a lot of the FUD might be because it's vague and nebulous and unknown.

[RedGreen925]

Re: You can't use gzip/tar?

"This is "solving" a problem that doesn't actually exist, just like systemd."

Indeed but doing it your way as I do with some programs too provides no vendor lock in. How else do you expect them to be like the parasite corporation they are. Just like Redhat and their whining I seen in another article about them "giving" away too much. By having to contribute back the changes they made and distributed as is required by the license they agreed to, to use all those other peoples work to build upon. These corporations are no friend to open source they seek to lock it away and control it for their own, best to stay as far away as you can from anything they do.

[doublelayer]

Re: You can't use gzip/tar?

I have experienced the problem of binaries refusing to run because I don't have a version of Glibc new enough for their tastes. I've experienced sites where there are eight different Linux packages for the same program for different distros, which is fine when I'm using something common, but not too helpful otherwise. I have experienced the problem of recompiling my software on something old so that it won't have that problem when someone who is still using an older distro tries to run it. This may not be a problem you've ever had, but it is a problem that shows up from time to time. If we want desktop Linux to appeal to other users, it is helpful for us to try to solve it, because it makes it much easier for software to exist for all of Linux, not just the developer's favorite distro and anyone else who wants to build it themselves (I don't mind that, but a normal user would).

[Richard 12]

Re: You can't use gzip/tar?

That only works if all your system libraries are compatible.

The fundamental issue with all software distribution is, and has always been, dependency hell.

Windows spent years there, eventually coming up with WinSxS (and later WoW64) to allow multiple versions of DLLs and ABIs to coexist. Plus of course MSI, MSI-X and whatever the heck it is that Windows Store uses, not to mention the myriad of third party install systems.

macOS has app bundles that claim to encapsulate everything except the core OS libraries, but it doesn't work - it genuinely doesn't notice if a bundle gains a few extra dylibs which do nefarious deeds. Or more commonly simply crash the application.

And of course, Apple change those core libraries every few years, making old software unusable.

Linus has done his best with the kernel - you don't break userspace - but Linux is more than a kernel, and userspace libraries do change. Binary incompatibility happens often - even (and perhaps especially) for statically-linked software.

Sure, if everything you use is open-source then you can recompile it, but that doesn't help when there is source - or compiler - incompatibility. C++23 is a thing, does your compiler support it?

TL;DR: Software distribution sucks.

[Liam Proven]

Re: You can't use gzip/tar?

[Author here]

> I untar Firefox into /opt or /usr/local and it works just fine.

Sure but there are multiple problems with this approach that I've laid out repeatedly.

* Your tarball apps don't get upgraded with the rest of the OS

* If they update themselves then they need to be in a directory writable by that user

* If they're shared by more than 1 user it needs to be globally writable

* The OS doesn't know they're there, so e.g. checks for the presence of a tool will fail.

* There's no desktop integration unless you DIY.

That's off the top of my head. There are a tonne of problems with this approach _which is why distros invented package managers_.

I used Linux before there was automatic dependency resolution and it was hellish and I very much do not want to go back.

[Ian Johnston]

I think the author does himself a disservice by dismissing - or appearing to dismiss - all criticism of snap as "FUD". I don;t avoid it because it's linked to Canonical. I avoid it because it's a resource hungry, insecure piece of crap. When a security problem is found and sorted with a library a quick apt-get update && apt-get upgrade fixes it for every application which uses it on my system ... unless it's a snap package, in which case I have to pray that the maintainer is on the ball, alive, responsive and ready to issue an update.

If you want to distribute your software as a monolithic bloc, just link it statically and stop pissing around.

Incidentally, the latest AppImage version of MuseScore doesn't on my updated Linux Mint because it requires a newer version of the C library than LM comes with. So there's the worst of both worlds: insecure and doesn't even include everything needed.

[Liam Proven]

[Author here]

> I avoid it because it's a resource hungry, insecure piece of crap.

So are all modern OSes. This is an inadequate justification.

*If* the app is available as a .deb then by all means use it. I do; I install `deb-get` and install native packages for all the apps I can, and for those that are not in there, like Panwriter and Logseq, I download the appimage.

I described deb-get here:

https://www.theregister.com/2022/10/13/zinc_ubuntu_remix/

I described why all this is being done in "the quest to make Linux bulletproof" and "the future of Linux packaging".

There is a huge amount of R&D going into this. That costs money. You don't think they are doing it for fun, do you?

[Ian Johnston]

So are all modern OSes. This is an inadequate justification.

There is no reason to make a bad situation worse. "Resource hungry, insecure pieces of crap non sunt multiplicanda praeter necessitatem", as William of Ockham put it.

[steelpillow]

What sucks most

"after a few decades working with all manner of software, this vulture hates it all."

Give that man a beer, ain't it th' truth!

What sucks most is people brought up in one tradition only (maybe Microsoft or Apple or *nix or RISC OS or...), are utterly brainwashed into believing theirs is the One Truth, and then move into software management. Whether they come from the user side or the dev side, they all end up the same.

[georgezilla]

I have some questions ...

Which package manager do I use to install a "cross distro" pack manager?

Which "cross distro" package manager do I use to install a "cross distro" package manager?

If my distro's package manager isn't good enough to install packages, what do I use to install a "cross distro" package manager?

Why is installing a "cross distro" package manage eaiser then just using the distro's package manager? And doing it all my computer and distros? I have many computers and distro's.

And the most important question ,.....

What is so difficult about clicking on the "install" button that my, most distro package managers use to install a package?

Aren't "cross distro" package managers NOT the answer to a problem that that DOESN'T exist?

Just asking these questions for a friend.

[Anonymous Coward]

Re: I have some questions ...

IMHO, SNAP is not the answer to any question yet posed to mankind.

SNAP is a 4-letter word and should die a quick death.

I've managed without this POS since Slackware 1.1.

The work needed to setup the various package flavours (eg .deb, .rpm) only need to be done once. When that is done, you drop the new version into the right place, update the release info which can be scripted and away you go.

The above is from 5+ years of releasing software with .deb and .rpm packages. It ain't rocket science people. You just need patience which seems to be sorely lacking in Devs these days.

[danielfgom]

Snaps are good for Enterprise

I can 100% see the benefit of Snaps in the Enterprise and running your own Snap server to control versions and make it secure and fast to get the on an end user pc. For that purpose it's a great solution.

However for home users I don't see the benefit, same with Flatpak, because they are so huge and often home users have limited storage. Especially laptops whose makers seem to think that 128GB is enough (thanks Apple, not).

The best would be if the distro repo had updated native packages. But from what I've seen it's the package developers who are pushing this because they don't want to compile separate binaries for each package type (deb, rpm etc) and maintain older versions for slow release distros as well as new releases for rolling distros.

Surely there must be some kind of automated packaging tool that could do this for the dev so they don't have to do it manually?

[doublelayer]

Re: Snaps are good for Enterprise

It's not about .deb and .rpm and the other ones, since those are not the only archives for Linux package managers out there. It's about what's in them. Here's a simple answer: I'll build a piece of software on my local box which has updated dependencies, and put the binaries in a .deb and .rpm file for you. You can just install that. If your system is like mine, it will work. If it's not but all the packages are new, you're probably going to be fine. If it's older, it will fail to install or run depending on your package manager and the flags you gave it when it decides that the version of your libraries is wrong for the software. Maybe those older libraries could run it, but my binary doesn't properly find them. Maybe they're actually lacking features that I made use of. Either way, it won't run.

Bringing your dependencies with your binary is a pretty old concept, and these packaging tools exist to make that work like traditional package managers have, without requiring package managers to manage the isolation.

[Kevin McMurtrie]

Broke with a Snap

Snap hate is well deserved. It's like a copy of everything that's a failure in Google's ecosystem.

I've never seen a Snap app install and just work. There are always missing features and random errors until you discover what fine-grained permission is incorrect. Even if you do know about the little permissions button in the Snap store, do you know what in that enormous dashboard needs to be toggled? And then there's Snap encapsulating settings and caches in who-the-hell-knows-where. Backing up settings but not caches is always manual work.

[jvf]

ouch

This is all way too complicated. I think I'll just keep using Windoze and complaining.

[Philo T Farnsworth]

~/snap

My own dislike of snaps is admittedly aesthetic.

I find the choice of creating a 'snap' subdirectory in my home to be more than a little annoying. It's *my* home directory and I should have the final choice in what goes into it, at least visibly. I'm perfectly happy with a hidden file, say ~/.snap, and why they chose to do otherwise simply baffles me.

Yes, it's a small thing but small things add up.

[weladenwow]

Other than Firefox. I've seen no examples of where any of the above have even tried to persist with attempting to keep an application they were more than fond of. My Flightgear, an AppImage 2023, still can access a great moving map, last updated 2006, which I rescued via imaging a Ubuntu 12 Install & launching via QEMU. Can anyone else who posted above tell me their story? And no TL;DR 'ers. My bet is that none have really tried.

Snap is brilliant. Canonical put in a huge effort, and then handed it over to you. You're still not happy & you never will be.

[Cardinal Fang]

But Snaps were so SLOOOOOOW

In the end I pulled everything Snap based so my machine wouldn't be sitting there for hours waiting for updates to complete.

The only pain I feel is from having to update firefox by hand now and then, the cumulative pain from that since I consigned snap to the garbage bin of history would still be less than that of one snap update.

Wasn't bandwidth from the larger packages AFAIK, I play games on Steam and multi-GB updates there are quite speedy.

Seriously, if you want something to succeed it has to not kill performance.

You can cross 'enterprise use' off the application areas for that reason alone, people do not like coming into work, turning the laptop on then having to wait hours before the day can start.

I have no idea why it was so slow in my case, not my problem beyond finding a cure.

Note: I actually like Ubuntu otherwise.

[shanecoughlan]

Ships in the fog

My goodness! I missed you in Bilbao. The conference center was a bit of a maze. Hope to catch you at another event.

Package manager religion always fascinated me. It reminds me of the aspect of the photography world (a hobby) where people count metrics.

Most stuff is good enough to get us to where we want to go: something running. It strikes me that we should be caring mostly about “using the running” rather than arguing the startup.

That said, application images are my favorite too. As Liam probably recalls, I was wondering 20 years ago why something like ROX could not gain traction.

And mea culpa: my package management on OpenGEM varied from bad to horrific.

[RAMChYLD]

Now let me set snap to not keep old packages at all and I'll accept it (begrudgingly).

My main problem with snap is that when it install a new version of a software, the old version is kept. Up to three previous copies are kept by default, you can cut it down to one, but never none, and for me that's not good enough.

I want zero old copies to be kept. As in, the old version gets vaporized for disk space immediately after the new version is installed. As far as I'm concerned the old copy is a vulnerability waiting to happen and if it's dependent on a server (ie Spotify), paperweight hogging precious NVMe disk space since it will no longer work anyway. Currently I need to have to run a manual script to clean up (can't figure out SystemD since there's no more cronjobs) but that is not good enough either.

ZERO old copies or no way.

[kalibey]

Users are not maintainers. A pompous snap proselytizer thinks users are "trolls" and complaints about changes to the software that they use are "trolling". If snap was such a game changing capability, it would not be so contentious... stop trolling the deb/apt users with senseless rationalizations about snap. Until users see a massive benefit from snap, there will be "trolling".