@tylnesh I've tried both Flatpak and Snap, and I rejected #Snap because you couldn't really change your snap repository away from Canonical's repository; that's really bad and is strictly against the Unix and Linux way.
I don't remember Snap's containerization being very versatile anyway, but this is a big step up in that regard since I last tried it. If they fix the Canonical-repo-only flaw, I'd like to try it again actually. I have to use Flatseal to edit file access permissions with Flatpak.
@golemwire the thing is I can empathize with you wanting that, but on the other hand I don’t know why the hell i would ever want to change the repo… If I’m using Ubuntu, I’m already trusting them with root access to my system every time I do “apt upgrade”. And I don’t see people switching out their apt sources to third party repos.
@tylnesh That makes sense security-wise. But on principle I believe one should be able to add/remove software repositories. I could see a distro having a Snap repo to itself for distro-specific apps, for example. I've noticed that a lot of software repositories end up with distro-specific software. That's just an example, though, I'm thinking of the principle.
Nonetheless, Snap is a good idea in many ways; I just believe they should have the option for freedom's sake.
@tylnesh I guess you have a point; that's the power of open-source there!
@golemwire yeah, I get that. Lucky for us, nobody can prevent somebody from forking the snap client, implementing its server component according to the docs here https://dashboard.snapcraft.io/docs/index.html and pointing the patched client there. Since the client is open source and the servers protocol is public, all that’s missing is somebody with some free time and incentive.