Just use Ente instead.
I think I’ve landed on Flatpak as my favourite between Snap, Flatpak, and AppImage. AppImage, when it works, is nice though. Snaps are just kind of inconvenient (auto-updates are a no for me) and bloated and the things Canonical are doing as an organization put a bad taste in my mouth.
I’ve had bad experiences with AppImages. For universal format they do a really poor job at that. And it’s a huge step back into Windows direction that you’ll have to manually download, update etc your shit. Makes managing a bunch of apps a pain.
The thing with appimages is that they expect the developer to have full knowledge of what libraries need to be bundled with their app, which makes it difficult to make truly universal appimages. In flatpak you just select one of a set list of runtimes and add any additional dependencies on top of it. Flatpak also re-uses the files for each runtime in between the different apps that use it, which saves a lot of disk space.
But isn’t appimage the closest one to the app-system from Android? Since things could be really different on many clients an “app-container” is the best solution.
Why not containerise everything? You need libreoffice? No problem, here is a docker or podman container.
BTW. I like flatpak, too. It’s the most stable, but I never understand it’s mechanics. There is always another pack installed, freecode, gtk, qt whatever. Even if the system has already the correct gtk version, nope, the dev decided to use the gtk image from Ubuntu.
Why not containerise everything? You need libreoffice? No problem, here is a docker or podman container.
Flatpak is basically GUI-optimized containers. It uses the same technology (namespaces) as docker and podman, just with some extra tools to make GUI-related things work properly. That’s why flatpak apps don’t use the system’s gtk version – they’re running in a sandbox with a different rootfs. You can spawn a shell into the sandbox of a specific app with
flatpak run --command=sh com.yourapp.YourAppand poke around it if you want to.Thx, looks like that’s the info I’ve missed.
If you’re interested in another approach to containerizing GUI applications, also checkout out x11docker. It’s a small independent project maintained by one guy, nothing big like flatpak, but also pretty cool. The name is actually a bit limiting – it supports both docker and podman, and can run wayland apps as well. One of the coolest features, in my opinion, is the ability to run a separate X server inside every sandbox and forward individual windows to the “host” X server. That way you can prevent apps from spying on your keyboard or other apps’ windows.
It uses bubblewrap for sandboxing under the hood, right?
I’m not too familiar with whatever Android is doing with apks these days tbh. I just don’t like how AppImages fails at the one thing it should do (universality) and doesn’t have the repo model built in. You can have third party solutions to that but it’s just not the same experience.
Why not containerise everything? You need libreoffice? No problem, here is a docker or podman container.
I’ve heard people suggest such a solution. Everything is a container and stuff is just exported out so that it shows up to the system like a normal program. Can’t really say I’m the right person to judge the pros and cons.
There is always another pack installed, freecode, gtk, qt whatever. Even if the system has already the correct gtk version, nope, the dev decided to use the gtk image from Ubuntu.
It can be both good and bad and sometimes it’s necessary. The whole system relies on being able to use different versions of libraries. But having them as separate packs can help in that programs can share those packs so as a dev you can just target one common base and have your stuff work everywhere. And sharing those runtimes has the benefit of someone else keeping it up to date while you can just test if the updated version works for you and switch to that if it does and so on. And with deduplication, runtimes and stuff share the parts that are common to both afaik.
It’s a bit more complicated than just shoving everything in but also it’s less work than same thing having to be packaged separately for every distro.
Yeah, same here, that’s why I specified that they’re only nice when they work. Often they just don’t work, so Flatpak is better.
Auto-updates are a hell-no for me.
There was a perfectly good user interface for updates. Then Ubuntu decides “wait… What if we made updates compulsory and effectively random and skipped the UI. The user can do system updates whenever they want, because those don’t matter for security or something, but these apps must be updated whenever snap determines they must.”
Oh, snap!
I used to use flatpak for everything, but I just dont have the hard drive space to store duplicates of my graphics drivers.
Oh come on, mesa is only (checks) 112 megabytes!
you know what, carry on!
Last I recall, my drivers for Flatpak took up an extra 20 gigs of my 256 gig hard drive.
at 112 megabytes per instance that amounts to about 178 flatpaks. Which sounds pretty standard
Fun fact: there used to be an Authy flatpak that just installed the snap inside
Oh, what the fuck!?
TBH I wouldn’t mind it that much. The whole point of flatpak is that the developer can do whatever demented satanic rituals they want inside of the sandbox, and it won’t contaminate the rest of the system.
Yo dawg, I herd you like containers so I put snap in yo flatpak, so that u can sandbox in your sandbox
Flatpak has long had the ability to dump the contents of a snap into it, because snaps had already solved many of the build issues flatpaks were struggling with and they used similar runtimes for their sandboxing. It’s also a convenient way to convert apps over, since many apps got packaged as snaps before flatpak was really usable.
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
some tar.gz archive with a sketchy install script
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.
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.
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.
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 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 would prefer manually writing each software using butterflies over having
snapdinstalled on my system.obligatory “there is always a relevant xkcd”
And what do they offer over 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).
Nothing useful for me. Given the choice I will usually pick the 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.
🫣
snap would be better then installing from manual archives, but it’s comparisons are actually to your distro’s package manager and flatpak.
Ente Auth > Authy
Yep. I’m selfhosting it now. Works great but selfhosting isn’t straightforward yet, still the best Authy/Google/Microsoft Authenticator drop in replacement with sync.
Is self hosting even worth it for auth? I self-host ente Photos myself, because that way I don’t need to pay for a subscription, but auth is free anyway, and the backups are entirely e2ee, right?
Probably not but hey I like doing it.
Just an FYI Auth and Photos use the same server program. I think you can already self host Auth just point the app at your Photos server.
I know, but I use the cloud hosted ente auth backup method on purpose, because I don’t trust myself with selfhosting and I’m too scared to accidentally
rm -rfmy server and lose my 2FA seeds. That’s also why I don’t selfhost bitwarden, even though Vaultwarden is pretty great, and even offers Bitwarden Premium features for free (and I love it cause it’s written in Rust lol)Can I have a moment of your time to speak about our Lord and Savior, 3-2-1 Backups?
I’m too lazy… Yeah I am pretty nerdy, but I still don’t want to spend that much time caring about my selfhosting setup and building a homelab. But I’m glad it works for you, and I’m glad ente created their authenticator in the first place. I would have never expected it from them, since they only used to make ente photos, but there we go, they casually just created the best FOSS auth app.
Yeah, I mean the snap app shown above is being deprecated so there’s not even a choice. If you’re using Authy on PC you have to switch.
2FAuth. On the web so you can check it anywhere you want and supports passkeys.
How about https://2fas.com/?
Or just use Keysmith and import your keys there.
If you really need that software couldn’t you just use the Windows version?
Guys they’re doing a bit.
Whoosh?
Yes, it was a whoosh. I’m not gonna say it’s a funny bit, but they’ve said in previous comments that it’s a bit.
Once you discover you can just install the nix package manager with one command and then install everything with another, snap is out of the game. Even if you just use nix for like 2 packages, it’s already much better
