...and while the overhead might seem trivial when you're running a single instance on a single laptop, it doesn't scale nicely. I hate to even imagine how much memory and CPU power we're wasting running this sort of thing in datacentres that might be host to literally millions of instances of SnapPackagedSuperFutureApplication compared to running it natively.

And that's before you start worrying about the compound performance because SnapPackagedSuperFutureApplication is now running in a container because someone decided that would be cool - and of course that container is running in a VM because we don't do bare metal these days... all these layers of abstraction add up.

It's a cute technology for the desktop, but it's really not viable everywhere. The concern a lot of us have is the same as we had with systemd - yes, it benefits desktop users in a whole bunch of ways, but it comes with unintended side effects once it proliferates enough to become "the standard" and now it's sitting on my servers getting in the way.

I have my suspicions about systemd, but no expertise: can you give a simple example of it getting in the way?

I'd be more curious about ways in which it benefits desktop users.

As far as I'm concerned systemd resembled Snap & the rest in that they attempt to solve non-existent problems.

The problems Snap fixes are only ”non-existent” to you because of the countless unpaid hours of labour by package maintainers.

Free as in speech, not as in -loading.

A real world example I witnessed more than once: a long (minutes) delay after issuing a shutdown/reboot, while systemd presumably tried to unwind some part of its dependency tree which had gone sideways.

When I tell a system to shutdown, I expect it to go down -- not sit there spinning for (literally) minutes at a time. Worse, I couldn't even tell what it was actually hanging on -- the shutdown progress dialog list on console wasn't helpful, and the tools for triaging systemd's dependency tree are convoluted and frankly not very helpful. It's not like the system was in a bad way to begin with, either. No hung mounts, runaway procs, or other usual suspects.

Perhaps in the systemd dev's haste to make startup faster, they did the opposite to shutdown. But shutdown is every bit as important.

Thankfully I haven' seen that behavior again in a while, hopefully it's been fixed properly, by accident or otherwise.

That's a "getting in the way" example. My bigger problems with systemd are in other categories like "feature creep", "KISS violation", and "unhelpful developers".

This. Exactly this. I've had servers taking 5 minutes to initiate a shutdown, and also servers actually *never* shutting down, having to be rebooted from the vCenter. It gets old real fast when you are trying to automatically reboot systems during off-hours to update kernels and the shutdown never completes. Add to this login timeouts on older versions of libnss-systemd, mount point supervision that doesn't detect network mounts going down... Systemd was utter sh!te in the days of Debian 8/9, it's getting a little better now, but still far from being as reliable as, say, runit. The shutdown bugs are mostly a thing of the past though, not really seen in the versions shipped with Debian 10+. The only good bit is unit files, and they're miles better than the old sysvinit. The file watchers are OK (not perfect, but OK). The unit override directory tree is just weird and confusing, and the private /tmp has caused me quite a lot of headaches, but overall creating systemd services is really painless, which is not always the case (though, well... runit).

I see this weekly with debian and systemd it could be boot or shutdown and it is random. It does not happen everyday and does not indicate the same service start or stop each time. This inspired me to find non-systemd distros. Too many apps seem to use or call to systemd making it hard to get away from.

Like herpes it just keeps spreading.

Mark Bannister (of Jane Street) documented one on Linkedin a few years ago while I still had an account on it.

People assume Snap/Flatpak/etc-packaged apps are just "drop-in" replacements for existing apps.

This is only the case where the app and package maintainer have a good understanding of what is going on and have made it work for you.

What do I mean by this? Take hidden files - files prefixed with a dot/period - as a real-world example that has issues with Snap.

Did you know that Snap apps can't see hidden files? When you execute "curl" on a fresh Ubuntu install you will find it is not installed by default anymore. However, the shell will suggest you can use snap and apt to install it. Given that the Snap version is often updated first, people will install the Snap option (to get the latest version).

But... then it won't read your ~/.curlrc file.

Full disclosure: I've not picked a great example with curl, as I'm not sure I've ever used ~/.curlrc, but the point is that ~/.blahrc files won't be read by Snap apps, and requires user/system config changes to let it (i.e. it is NOT a property on the Snap package in question that needs to be declared to let it read the .rc file, there is no feature like this).

"I run my Linux desktops on modern systems with powerful processors, 16GBs of RAM, and speedy SSDs. "

I don't.

My main box is an elderly Viglen desktop with 6GB of RAM and a couple of HDDs.

It works for me and does all I need it to do in a fashion that I find acceptable.

Are you suggesting that we all go the Win 11 route and splash out on the latest kit just so the the OS will boot?

There are many reasons why people run Linux and the ability to run the OS on what others might regard as obsolete resource starved systems is one that I have seen mentioned many times on El Reg and other sites.

Just because you have access to top of the line kit does not mean that everyone else has.

There is an old saying "I'm alright Jack."

"Waahwaaah I like my ancient computer, things shouldn't progress for anyone because I wont buy a new one".

I you want an old computer, you are free to use old software. Not everyone else's problem.

It is not just old computers.

I have a bunch of Raspis doing various tasks, 2GB RAM, plus a Raspi 400 with 4GB RAM. Those are newish computers (all under 4 years old).

At work, our standard PC is a Core i3 with 4GB RAM. Most laptops have 8GB, but a majority of the desktops are still on 4GB.

I have a lot of Raspberry Pis running Linux, most have 2GB RAM and a slow ARM processor...

A computer running 4 cores at GHz speeds with RAM in the gigabytes is not slow. It's a sodding supercomputer that would have had a Cray 1 user going, "You what?!

If it seems slow, the attitude of the author and AC above is why.

Its true. And it has enough power to be able to run ~20x home PCs from the late 90's.

The mindsets of IT consumers today is just wrong frankly. They are effectively ruining it.

YES! For many of us, one of the attractions of Linux is that it runs well on older machines where Windows won't run. I am typing this on a 2015 Lenovo W500 that I inherited when my wife tried to move from Windows 7 to Windows 10 but found it unusably slow. And this is not my oldest Linux laptop.

Whilst I can see the attraction whenever I install a snap app on Ubuntu it takes an age to start every time, and this is on a respectable AMD Ryzen 4700 system with SSD.

Then some snap apps can only access home directory.

Is Flatpak any better?

"Is Flatpak any better?"

Not in my experience. I removed the whole thing a couple of months back, saved 11 GB.

As so often seems to happen, the end user is the least important person in design decisions - whether Windows or Linux.

The management of Snap that goes on in the background is not free... ie, it uses CPU cycles.

This is the output of /var/log/messages that contain the word 'snap'. This is an Alma Linux system that runs a wordpress site. Snap is used to manage the 'certbot' key renewal process.

Why does it need to check to often for updates?

Seeing all this has made me very anti-SNAP.

With previous versions of certbot, your ran a cron script every week. The key was renewed well before expiry. It worked and was very simple. Now we get this crap sandwich.

Jun 8 12:18:02 TSE snapd[31695]: storehelpers.go:769: cannot refresh: snap has no updates available: "certbot", "core", "core20"

Jun 8 12:18:02 TSE snapd[31695]: autorefresh.go:551: auto-refresh: all snaps are up-to-date

Jun 8 20:03:03 TSE snapd[31695]: storehelpers.go:769: cannot refresh: snap has no updates available: "certbot", "core", "core20"

Jun 8 20:03:03 TSE snapd[31695]: autorefresh.go:551: auto-refresh: all snaps are up-to-date

Jun 8 21:28:02 TSE systemd[1]: Starting Service for snap application certbot.renew...

Jun 8 21:28:03 TSE systemd[1]: snap.certbot.renew.service: Succeeded.

Jun 8 21:28:03 TSE systemd[1]: Started Service for snap application certbot.renew.

Jun 9 05:53:02 TSE snapd[31695]: storehelpers.go:769: cannot refresh: snap has no updates available: "certbot", "core", "core20"

Jun 9 05:53:02 TSE snapd[31695]: autorefresh.go:551: auto-refresh: all snaps are up-to-date

Jun 9 08:25:00 TSE systemd[1]: Starting Service for snap application certbot.renew...

Jun 9 08:25:01 TSE systemd[1]: snap.certbot.renew.service: Succeeded.

Jun 9 08:25:01 TSE systemd[1]: Started Service for snap application certbot.renew.

Jun 9 08:33:02 TSE snapd[31695]: storehelpers.go:769: cannot refresh: snap has no updates available: "certbot", "core", "core20"

Jun 9 08:33:02 TSE snapd[31695]: autorefresh.go:551: auto-refresh: all snaps are up-to-date

Jun 9 11:53:34 TSE systemd[158479]: Listening on REST API socket for snapd user session agent.

By contrast, this is the output for 'flatpack'

Jun 7 08:30:19 TSE systemd[7834]: Starting flatpak document portal service...

Jun 7 08:30:19 TSE systemd[7834]: Started flatpak document portal service.

Those entries were made when the system rebooted after an update to the kernel.

When I build the next iteration of this server I will do everything possible NOT to let SNAP anywhere near the system. It is 1,000,000,000 steps backward IMHO.

The people responsible for this POS in Canonical can go suck on this --> [see icon]

Adding the entry "127.0.0.1 api.snapcraft.io" to /etc/hosts tends to disable it all very effectively I've found, with no ill effects.

The "for" argument in favour of snaps, etc is ease of use and dependency management.

The "against" argument is bad performance and having to download and install half an OS of dependencies with each application.

Considering the fact that SSDs are still quite expensive, and massive downloads are still not all that fast for me, filling them up with huge bloat to avoid having to type "apt install program_name" in a terminal is not attractive for me at all.

It also takes a lot of space. I run small VMs for different purposes (general browsing, secure browsing, dev, etc).

I noticed I started running low on HDD space on them. Culprit? SNAP. It was keeping old versions of libraries that were not even needed. I couldn't find a way to remove them. So I nuked whole Snap (which was pretty much only used by Firefox) and replaced with Firefox from launchpad. Space saving: 5GB.

This is just ridiculous, considering that whole OS with LibreOffice and stuff is 11GB.

Snap also creates tons of mountpoints (one per app) slowing down startup/shutdown considerably. Yes, it may not be visible on dev workstation, but is as hell on quad core VM.

Ok, all the packages are snap/flat/this/that/docker/dumbler or whatever system. Now imagine that one (1) library needs an update. Lets say a library used quite a lot. For example the SSL/TLS library. Now you need to update N packages at multi-Mega-size instead of the one affected library.

You can say, well, on my desktop, what is the problem. Yes, now imagine the server with 30+ instances.

Then you can say, well, storage is cheap... bandwidth is cheap, etc. But remember: Good, Cheap, Fast, pick two, you cannot have all three.

Not to mention when said library has a critical must-patch-yesterday vulnerability, you're now reliant on *every single* application application developer that uses it to quickly update their package (assuming they're organised enough to even know it's been inherited 5 levels deep) rather than just 1 maintainer.

Only developers build from source code these days. The vast majority of users use package managers.

I'm rarely a dev these days, but build from source to create packages then use the package manager to install across my various machines depending on what they do. I do this because I want different compilation options from the standard. That's the great thing about FreeBSD, you can mix and match as you like without some self proclaimed expert telling you how you will do things their way.

"Flatpak and its rivals can also run on any Linux distribution"

So can Windows, any version, and all of its applications. What's the miracle in that? Just run a virtual machine with pre-installed pieces, because that's what it is.

You could run flatpak et al on Windows too, they only need to adapt them to use Windows APIs.

May I refer the honourable gentleman to the analysis of my LibreOffice installation in /opt https://forums.theregister.com/forum/all/2023/06/07/red_hat_drops_libreoffice/#c_4676282

This is an application for which the download site provides 1 DEB and 1 RPM archive* for amd64 Linux for each version**. The vast majority of the file it contains are what might be summed up as "resources" almost certainly cross-platform.

There are 10 times as many html help files that would need translation for language as .so files that might conceivably need adapting to compile on a particular Linux distro.

There are about half as many again XML & XSLT files as .so and .jar combined.

Anyone who's been using Linux for such a long time must surely be familiar with the notion of installing applications along with a selection of libraries and resources in /opt. It's the problem that Snap, Flatpak & the rest of them set out to solve. It was solved long ago without the extra baggage that those bring along. In terms of baggage I find it particularly ironical that some time ago I decided to have a look at Flatpak and tried to install it on whatever vintage of Debian I was running at the time. It failed to install because some dependency wasn't satisfied by the Debian's version of some library, a notable failure of the KISS principle.

* A tgz archive that expands to 42 individual .deb files, In addition there is language pack, a further archive bundling 3 .debs(including dicitonary and readme files) and a help pack containing a further .deb

** Currently 7.5.4 and 7.4.7. The two files per version is the same as are provided for Mac (Intel & Apple silicon) and for Windows (32 & 64 bit).

"You can still do it that way today, as in this example of how to install Node.js v8.1.1 to your Linux desktop." with a link to a build from git-hub repositories The alternative is simply:

apt install nodejs

No idea when, or if that will happen for anyone else.

I know when it will happen for me:

When I see a good reason for an extra layer of abstraction/virtualization between the application and my OS. So far, I haven't seen one.

I can see some value in shipping large, monolithic and especially commercial software in Snap or Flatpak format, but I think of it as something you hold your nose and tolerate, an ugly compromise that should be a painful reminder that the compatibility problem turned out to be too hard to solve - it certainly shouldn't be a long-term ideal for software distribution.

Snap in particular offends my sense of elegance and minimalism, with its littering of loopback mounts, and inability-by-default to access files in the home directory. (Yes, I know there's some magic incantation to make that possible; whatever it is failed to work for me when I tried to use OpenSCAD recently - I eventually gave up and used the AppImage instead.)

Is that at least some of us like to keep our backups in a known state. This is easy to do if you run a backup followed immediately by a system update: in my case this means running rsync followed immediately by dnf (I'm running Fedora) and a system restart to make sure that new libraries etc. are now in use. Handling backups this way ensures that, after a disaster such as a disk failure, you *KNOW* that simply restoring the most recent backup will leave you with a runable system in a known state. This is a problem regardless of whether the backup+upgrade sequence is manually sequenced or run by a script.

The problem with flatpak and friends is that there's apparently no way to avoid getting force-fed a an update at a time chosen by the developer. Murphy pretty much guarantees that at some point an application push upgrade WILL coincide with a backup run and that this will result in a backup that, if restored, will contain incompatible software modules and/or configuration files.

AFAIK there is currently no mechanism provided that can prevent developer-originated push backups from running when the recipient system is taking a backup. I've certainly not seen any mention of such a backup integrity protection feature, so it seems unlikely to have been provided.

Another cause of problems would seem to be the case where the push update replaces application configuration files that have been modified to suit local requirements, e.g. sshd security settings. At least dnf, apt etc tell you when this happens and you can edit the revised configuration as required before rebooting the system: do flatpak etc even tell you that a new set of configuration files has replaced your customised ones?

Disconnect from network then do your volume or filesystem snapshots. Reconnect to network to copy them to other storage.

Pardon my language but there's a well known quote very appropriate for this question:

"You there: F*ck off. And when you get there, f*ck off from there too. Then f*ck off some more. Keep f*cking off until you get back here. Then f*ck off again.”

Redhat and Ubuntu can whip their dead horse "packs" and "snaps" till the end of time, but no self-respecting sysadmin's gonna allow those things onto a enterprise server. I've only ever seen it once on a corporate instance, but it was only allowed as no one would have to support it and no one cared if it stopped working. As for desktop, it feels largely irrelevant as Linux on the desktop has such low usage, but do people really want a system that doesn't work anything like a normal server? Half of the point of Linux on desktop is to give you a place to develop on a like-to-like system.

Wrong! Windows self-respecting sysadmins will do just that. :)

And all because the whole Linux community cannot come up with one definitive way to package apps and libraries. So instead there are the worst options of the immense bloat of fully packages apps + libraries. It sounds good but it isn't. It is bloat and lazy. Backups come to mind? If you can't do a bare metal recovery you do not have a backup.

The Linux crowd, me included, used to laugh at the NT people whose backup/recovery process was reinstall the OS, reinstall all the apps, reinstall the data, because in those days handling open files on NT was a real PITA. If anyone tells me now that Linux recovery is reinstall the OS, download all the apps again like it's some kind of smartphone, put back the data then get lost. App bloat (due to containerisation) = backup bloat.

I have run into this on Macs too. NamelessImageApp stores its thumbnails as well as all the metadata in a SQLITE database. Very good when you have a few photos. But when your SQLITE database is 2GB in size, if you so much as tag a photo that means a 2GB backup. Now multiply that by the number of people who have the same NamelessImageApp. This idea of backups is lost on people who it seems to me do not do backups or have endless backup disk space.

Gnome is bloated. Why? Perhaps because the people who code Gnome don't understand about using resources wisely. I have seen Yum update crash due to using too much memory on a small system. The solution is not 'get a bigger boat'.

Packaging has never been the problem, even when we only had to decide between deb and rpm (not forgetting you slack, just no-one's ever cared). Packaging is a symptom caused by the real problem which can basically be summed up as CADT and the pathological inability of developers to Leave The Code Alone.

Flatpaks and their ilk will just create Yet Another Standard.

This is an age old argument that will never go away. Haven't looked but I am sure you can find a chart that attempts to show all the pros and cons of each philosophy. The comments so far have done a good job of pointing out the issues and in the end it boils down to personal preference. Start up time, memory usage, disk usage, stability? Plenty of hills to go stand on and defend.

I have 4 flatpak apps that I use. Perhaps fortunately 3 of them share the Nvidia driver library kits. All 4 needed updating for (I dont recall precisely) a glib or glibc change.

a) when the kernel I'm running gets updated, this brings in new nvidia drivers at the hardware level, and thus the flatpak version needs updating. It pulls those drivers *ONCE*, that gets used by all three flatpaks.

b) the glib/glibc change, the flatpak package, only one was pulled and applied to all 4 flatpacks.

Being sandboxed, in order to correctly *use* two of those flatpaks, I did have to add disk paths to the "allow" list. It does add some complexity to the deployment process, but it is certainly manageable. Its *not* something I'd hand to a youngster with less overall compute experience, but perhaps having dealt with VAX to Mainframe data transfers, TCP over SNA, BNC (both) to ethernet, and about 12000 other weird and wonderful moves from (type x to type y) of computing functionality I'm just not that intimidated.

Yes, they chew up more disk space for similar code. But then my Gentoo vm uses 28% of the disk space that my fedora vm uses with pretty much identical software stacks. The Gentoo instance takes about 150 *times* the build time of the fedora one, but it gets there eventually. What I will note is that the flatpak versions of specific apps I'm using are far easier on my mental health than what would be involved with deploying them without flatpak. None of the 4 are ...... common linux applications, 3 pertain to video games I play and one is for managing a (now) rather extensive library of music on our household NAS. (I've been digitizing my mothers 800+ LPs over the last few months). All are only available directly from github, and there are not currently rpms for them in fedora, or rpmfusion. Flatpak gives me the package in a format I can be *reasonably* assured is functional and mostly current.

I do *not* think that in it's current structure and form that (at least) flatpak is *complete and ready for prime time* but I do think that it has enormous potential to make far more non distro based software consistent and available than is currently out there. I would suggest that within reason, it would be possible for *cough* certain large video game producing companies *cough* to package their product with a tweaked and tuned version of wine, making it possible for them to reach a (admittedly currently small) niche market that stands a chance of growing.

Having been working in the Computer/IT industry for 40 years I too got Linux and other Open Source things since the beginning also. I must say I respect your opinion...but face it - it's your opinion that Flak/Snaps et al are more secure.

In my opinion they haven't been around long enough to see or even realize the true impact on security... sure, we already see the impact when a few simultaneously run are having on localized performance but not security.

Back in the day I felt safer when I knew many other eyes were reviewing and seeing what people were contributing to open source. But not now. Now we are assuming developers are acting in the consumers best interest.

The primary advantage of closed source is you have a primary source to bitch and and complain to when things go sideways ... but not in open source. I for one am trying strongly avoid Snaps and the like. I do not need to be bleeding edge - I just want crap to work...work securely and be consistent.

I truly understand I am imaging a world where consistent security happens - without a huge amount of customer involvement ... but hey :) a guy can dream. ;)

Yes, more layers of abstraction that make doing anything a PITA. But the isolation what about that amazing thing? The thing that you usually have to turn off or grant the normal permissions to the second you install a program because OBS needs to access a cam or something needs the GPU? And why not just install 2 more version of NVIDIA drivers, one always leads to such stability. No, no, you use a portal to access stuff, see? We want to introduce the intentionally obtuse and over engineered way of Red Hat thinking coupled with the Microsoftian over control of Canonical to everything, you will love it. Or else.

"What I think is really going on is there's one group that favors Red Hat, while the other loves Ubuntu. In the meantime, I'd like to remind both sides that Windows users are snickering at them from the mountains as the Linux distro fans fight over molehills".

This. 1000x This. Stop shooting each other in the foot.

...downloaded in 1991....

Oh crap I'm old aren't I....

Would be interested to hear why (some code at least) can't be distributed as a big, old statically linked execs (no dependency hell)? I certainly do this with scientific code (that is bounced around various machines).

The arguments against concerning size/start up times don't seem to be an issue when Snap etc have similar issues. Updates require a full replacement, but (again) that's what the container systems seem to do anyway.