this post was submitted on 02 Oct 2023
813 points (95.6% liked)
linuxmemes
24384 readers
730 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn, no politics, no trolling or ragebaiting.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
5. π¬π§ Language/ΡΠ·ΡΠΊ/Sprache
- This is primarily an English-speaking community. π¬π§π¦πΊπΊπΈ
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed. Β
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I just started tinkering with Ubuntu a week ago. What's wrong with snap?
Canonical is doing the same thing Microsoft is doing with Edge - using its dominant position to push its other products and force out competition, and to lock users (and potentially developers) into its own ecosystem.
Saying that Edge is Chromium is like saying that Manjaro is Arch or diamond is just coal. They're related, but there's significant material difference.
When it was introduced in Windows 10, Edge had an immediate and massive surge in its adoption rate. That wasn't natural growth based on the application's merits -- it was simply a result of Edge being present in new installs.
Wait, but doesn't it result in more copies of the dependencies being installed locally because they're duplicated for each application?
It's actually less about the library being obscure, and more about version conflicts, which is actually more a problem with common libraries.
For example, let's say you want to install applications A, B, and C, and they each depend on library L. If A depends on Lv1, and B depends on Lv2, and C depends on Lv3, with traditional package management, you're in a predicament. You can only have one copy of L, and the versions of L may not be compatible.
Solutions like snap, flatpak, appimage, and even things like Docker and other containerization techniques, get around this issue by having applications ship the specific version of the library they need. You end up with more copies of the library, but every application has exactly the version it needs/the developer tested with.
The age and obscurity of the library is irrelevant - you could always include libraries bundled with the app, if they didn't exist in system repos. For example, in deb packages, you could include it in the data.tar portion of the package (see https://en.m.wikipedia.org/wiki/Deb_(file_format)).
Libraries with version names baked in are one solution to the dependency hell problem, but that requires support from the language/framework/tooling to build the application, and/or the OS (or things get hacky and messy quickly).
If you read that dependency hell page, you'll see another solution is portable apps, which specifically mentions Appimage, Flatpak, and Snap.
Additionally, if you read the Debian docs on How to Cope with Conflicting Requirements, the first solution they give is to "Install such programs using corresponding sandboxed upstream binary packages," such as "Flatpak, Snap, or AppImage packages."
This is incorrect. The target audience for Flatpak is desktop users: https://docs.flatpak.org/en/latest/introduction.html#target-audience. Flatpaks are explicitly for consumer, graphical applications.
I'll give flatpak and snap one thing: they did make some concession to avoiding duplication, unlike docker which utterly duplicates everything.
With flatpak and snap, applications can depend on/pull in a maintained external layer. So you might want 'gnome environment, version 43' and other applications that want that can all share. That layer can be updated independently of dependencies. You might have two instances of the gnome layers (say 43 and 44) due to different applications declaring different versions, but it's not too bad.
Now there is some duplication, some libraries that an app says "oh, no particular layer for this one, fine I'll just bundle it". But at least there's a mechanism to not necessarily do that for everything.
I'll add that the 'pseudo-sandbox' is of some dubious value, as far as I can tell the app declares how much or little sandboxing it wants and the user doesn't really get the opportunity to consent or even know that a snap has full access versus limited access.
I'll also say that some functionality is broken in snaps (and flatpak). For example I used KeepPassXC browser integration, and then when snap was used instead of native, it broke. A number of extensions broke and the development attitude was everyone pointing fingers everywhere else and ultimately saying "just find a ppa with a browser ok?"
I'll second the "screw it, I give up on packaging, my app is now a monolithic flatpak, snap, appimage, or docker container" mindset of a lot of developers.
It's a bad, slow and inefficient solution for a problem that is already solved. And because nobody would use their proprietary shit over flatpack, they force the users to use it. Even for things that exist natively in the repositories and would need neither snap nor flatpack.
Itβs slow, forced by Canonical, and starts a pointless format war with Flatpack.
Flatpack isn't without its own quirks and flaws. There is no One True Way. Being open-source, there shouldn't be one.
It is definitely slow though, mostly on first run.
deleted by creator
There should be one way for sandboxed shit, since the alternative of package managers already exists
We don't need snap, app image, flatpak all to compete. We need shit that just works
There's a bunch of different package managers too. It all just kinda works.
Okay, we tried appimage and it didn't work, so the second iteration as flatpak is mostly functional
you don't need ENDLESS competition of formats
Gotta be honest, as a dev I tried to make a Flatpack of my app and gave up. Making a snap was much easier. Of course, I also offer it as a .deb, .rpm, Pacman package, etc. too
I still don't even know what problem snap and flatpak were intended to solve. Just apt or dnf installing from the command line, or even using the distro provided store app, has always been sufficient for me.
Modern Linux distros tend to have configuration and dependency issues where certain packages if installed the "Linux Way" doesn't completely work as desired at times depending on the distro or even a desktop spin (which might have different default libraries installed than the "main" one). Flatpak is a single configuration meant to work one single way across all distributions and has become more of a standard, usable way for Linux applications to just work.
Use Flatpak. Easy to install and easy to tweak from flatseal or similar GUI Flatpak permission tweakers if you want more flexibility at the possible cost of security.
The idea is that the application may want libraries asynchronously of the distribution cadence. Worse, multiple applications may have different cadence and you want to use both (some app breaks with gnome 45 and so it needs gnome 44, and another app requires gnome 46).
Or some pick forks of projects that neglected to change the shared object name or version, so you have two multimedia applications depending on the same exact library name and version, but expecting totally different symbols, or different 'configure' options to have been specified when they built the shared library.
So we have this nifty mount namespace to make believe the 'filesystem' is whatever a specific application needs, and for that to be scoped to just one.
There's also an argument about security isolation, but I find that one to be unfulfilled as the applications basically are on the honor system with regards to how much access it requests of the system compared to a 'normal' application. So an application can opt into some protection so it can't accidentally be abused, but if the application wants to deliberately misbehave it's perfectly allowed to do so.
This computer idiot would also like to know why snap bad.
The main reason is that it is completely controlled by Canonical, with no way to add alternative repos.
It's worth noting you can bypass the repo, and install snaps that you downloaded from some other source - see https://askubuntu.com/questions/1266894/how-can-i-install-a-snap-package-from-a-local-file.
That doesn't give you a separate "repo," but it does allow you to install snaps from anywhere.
You can, but that completely negates the reasons why you'd want to have a repo system in the first place. You gotta do the legwork to get updates, for example.
And to be explicit about it, zypper, dnf, apt, flatpak all have a specific mechanism to declare repositories and one 'update' check will walk them all.
snap does not, and manually doing a one off is useless. AppImage also has no 'update' concept, but it's a more limited use case in general, it's a worse habit than any repository based approach.
This isn't necessarily true - a developer choosing to not include their app in a repo can always opt for a self-updating mechanism.
Don't get me wrong - repos and tooling to manage all of your apps at once are preferred. But if a developer or user wants to avoid the Canonical controlled repo, I'm just pointing out there are technically ways to do that.
If you'd question why someone would use snap at all at that point... that would be a good question. The point is just that they can, if they want to.
No, it does not just work. It removes the option to install updates manually through GUI. If Firefox was running, the only GUI solution is to close it and wait 6 hours or whatever.
My wife was perfectly fine installing updates from the tray with Synaptic. The PC is always connected to the TV with Jellyfin left open in Firefox where she was watching.
So I switched to Manjaro to have a pretty OS that isn't getting rid of their package manager controlling the most used program.
I didn't know they fixed it now, good to know.
deleted by creator
I hate it for the refresh nag messages alone.
The default Firefox in Ubuntu is a snap and I only knew that because due to nagging and having to restart constantly while I was using it and had to learn about snaps and how to install Firefox without them on Ubuntu.
If something exists in native form, use that. If it doesn't or you want some sandboxing (and there is at least some argument for a containerized version that brings all its needed dependencies, for developers not having to test for every linux for example) there's flatpack or appimage. Snap is just Canonical's proprietary alternative to flatpack. And also worse in basically any aspect. So they shove it down their users throat instead. Even for stuff that would be available natively and should just be installed via the normal package manager. And to make really sure, nobody is avoiding their crap, they also redirect commands, so for example using apt to install your browser automatically redirects your command to snap install...
If snap had another store, eg Fdroid to play store, all would be fine. So that's that!
cuz flatpak better