I never presented this as a dichotomy. You know, people prefer things in a certain order, right? I prefer Flatpaks and native packages over snaps and I prefer snaps to building from source.
There are plenty of use cases that snap provides that flatpak doesn’t - they only compete in a subset of snap’s functionality. For example, flatpak does not (and is not designed to) provide a way to use it to distribute kernels or system services.
I don’t think that the distribution of system packages is the issue. People need a way to easily distribute and obtain everyday applications, and to keep them up to date in the same manner. Linus spoke about this: https://www.youtube.com/watch?v=Pzl1B7nB9Kc
It depends what you’re trying to accomplish. For me, having the ability to essentially use Lego to put together my system is one of the great features of both snap and nix that Flatpak doesn’t cover.
I just can’t… like maybe I’m too old and that’s why I still can’t wrap my head around how we went from “./configure && make & make install scripts are almost the de facto way to install software in linux” to “a sketchy install script”. We’re living interesting times at Linux
In a job interview I asked a CIS grad what the steps are to compile something on the command line and they had no clue. If it’s not “sudo apt install” they are lost.
Last time I ran a corporate-made installer, it caused massive graphical glitches and lock-ups after waking from sleep. It basically gave my system computer-AIDS.
That’s why I never run scripts which are too long for me to easily understand outside a sandbox. Official distro repositories and Flatpaks are the only sources I have some level of trust in.
I remember those times too. The difference today is that there are so many more libraries and projects use those libraries a lot more often.
So using configure and make means that the user also has the responsibility of ensuring all those libraries are up to date. Which again if we’re talking about not using binary install, each also need a regular configure/make process too. It’s not that unusual for large packages to have dependencies on 100+ libraries. At which point building and maintaining the build for all of them yourself becomes untenable really. However I think gentoo exists to automate a lot of this while still building from source.
I understand why binaries with references to other binary packages for prerequisites are used. I also understand where the limits of this are and why the AppImage/Flatpak/snaps exist. I just don’t particularly like the latter as a concept. But accept there’s times you might need them.
The updates download in the background and will install when you exit the snapped app. If you really don’t want automatic updates, you can run snap refresh --hold to hold all automatic updates or add a snap name to hold updates for that snap.
Nope. There have been multiple times where I have my browser open, in the middle of something and when I go to open a new tab/window I get a blank screen telling me I need to restart FF to continue.
That is the behaviour that’s built for when an upgrade through a “classic” package manager (e.g. apt, dnf) updates Firefox while it’s still running. The only way I can think of that you’d get that with a snap is if you’re intentionally bypassing the confinement (e.g. by running /snap/firefox/current/usr/lib/firefox/firefox directly, which can also massively mess with other things since Firefox won’t be running in the core22 environment it expects).
If you’re using the snap as expected (e.g. opening the .desktop file in /var/lib/snapd/desktop/applications/, running /snap/bin/firefox or running snap run firefox), snapd won’t replace /snap/firefox/current until you no longer have any processes from that snap running. Instead you’ll get a desktop notification to close and restart Firefox to update it, and two weeks to either do so or to run snap refresh --hold firefox to prevent the update (or something like snap refresh --hold=6w firefox to hold the refresh for 6 weeks). Depending on what graphical updater you have, you may also have the ability to hold the update through that updater.
Are you sure you’re running the Firefox snap? Because that sounds pretty much precisely like the expected behaviour if someone had gone to lengths to avoid using the snap.
I’m 99.999% sure it was, as it was within kubuntu using the default FF install (Canonical only provides the snapped version), and opened from either the taskbar icon or through its menu. Discover’s auto-update feature was also manually turned off. (was a system at work, so I wanted the config to be relatively basic but controllable)
I did at some point completely remove snap and switched to flatpak. Eventually though, I went with the Mozilla Team’s PPA, as the sandboxing was adding too many complications with the addons along with printing documents.
Unpopular opinion: snap is not so bad and genuinely useful for many things
I would rather have a snap than building from source or use some tar.gz archive with a sketchy install script
I agree, but that sounds like false dichotomy to me because snap competes with flatpak.
I never presented this as a dichotomy. You know, people prefer things in a certain order, right? I prefer Flatpaks and native packages over snaps and I prefer snaps to building from source.
True, but your post did kinda read like this:
There are plenty of use cases that snap provides that flatpak doesn’t - they only compete in a subset of snap’s functionality. For example, flatpak does not (and is not designed to) provide a way to use it to distribute kernels or system services.
I don’t think that the distribution of system packages is the issue. People need a way to easily distribute and obtain everyday applications, and to keep them up to date in the same manner. Linus spoke about this: https://www.youtube.com/watch?v=Pzl1B7nB9Kc
It depends what you’re trying to accomplish. For me, having the ability to essentially use Lego to put together my system is one of the great features of both snap and nix that Flatpak doesn’t cover.
deleted by creator
I just can’t… like maybe I’m too old and that’s why I still can’t wrap my head around how we went from “./configure && make & make install scripts are almost the de facto way to install software in linux” to “a sketchy install script”. We’re living interesting times at Linux
Blame the thousands of supply chain attacks.
In a job interview I asked a CIS grad what the steps are to compile something on the command line and they had no clue. If it’s not “sudo apt install” they are lost.
Last time I ran a corporate-made installer, it caused massive graphical glitches and lock-ups after waking from sleep. It basically gave my system computer-AIDS.
That’s why I never run scripts which are too long for me to easily understand outside a sandbox. Official distro repositories and Flatpaks are the only sources I have some level of trust in.
yeah idk a multi thousand line
configurescript seems sketchy to me, like what happened with xzI remember those times too. The difference today is that there are so many more libraries and projects use those libraries a lot more often.
So using configure and make means that the user also has the responsibility of ensuring all those libraries are up to date. Which again if we’re talking about not using binary install, each also need a regular configure/make process too. It’s not that unusual for large packages to have dependencies on 100+ libraries. At which point building and maintaining the build for all of them yourself becomes untenable really. However I think gentoo exists to automate a lot of this while still building from source.
I understand why binaries with references to other binary packages for prerequisites are used. I also understand where the limits of this are and why the AppImage/Flatpak/snaps exist. I just don’t particularly like the latter as a concept. But accept there’s times you might need them.
Very unpopular
I would prefer manually writing each software using butterflies over having
snapdinstalled on my system.obligatory “there is always a relevant xkcd”
🫣
snap would be better then installing from manual archives, but it’s comparisons are actually to your distro’s package manager and flatpak.
And what do they offer over flatpak?
Nothing useful for me. Given the choice I will usually pick the flatpak.
Better cli experience and the permission prompts are two that come to mind.
A built-in way to have services running (which is why openprinting can make a snap of CUPS but AFAICT can’t make a Flatpak).
I’d rather be able to use my web browser uninterrupted without it being updated while using it and be forced to restart it.
The updates download in the background and will install when you exit the snapped app. If you really don’t want automatic updates, you can run
snap refresh --holdto hold all automatic updates or add a snap name to hold updates for that snap.Nope. There have been multiple times where I have my browser open, in the middle of something and when I go to open a new tab/window I get a blank screen telling me I need to restart FF to continue.
That is the behaviour that’s built for when an upgrade through a “classic” package manager (e.g. apt, dnf) updates Firefox while it’s still running. The only way I can think of that you’d get that with a snap is if you’re intentionally bypassing the confinement (e.g. by running
/snap/firefox/current/usr/lib/firefox/firefoxdirectly, which can also massively mess with other things since Firefox won’t be running in thecore22environment it expects).If you’re using the snap as expected (e.g. opening the
.desktopfile in/var/lib/snapd/desktop/applications/, running/snap/bin/firefoxor runningsnap run firefox), snapd won’t replace/snap/firefox/currentuntil you no longer have any processes from that snap running. Instead you’ll get a desktop notification to close and restart Firefox to update it, and two weeks to either do so or to runsnap refresh --hold firefoxto prevent the update (or something likesnap refresh --hold=6w firefoxto hold the refresh for 6 weeks). Depending on what graphical updater you have, you may also have the ability to hold the update through that updater.Are you sure you’re running the Firefox snap? Because that sounds pretty much precisely like the expected behaviour if someone had gone to lengths to avoid using the snap.
I’m 99.999% sure it was, as it was within kubuntu using the default FF install (Canonical only provides the snapped version), and opened from either the taskbar icon or through its menu. Discover’s auto-update feature was also manually turned off. (was a system at work, so I wanted the config to be relatively basic but controllable)
I did at some point completely remove snap and switched to flatpak. Eventually though, I went with the Mozilla Team’s PPA, as the sandboxing was adding too many complications with the addons along with printing documents.