CoMaps - Hike, Bike, DriveIf you're looking for a map & navigation app on your Linux Desktop: You can now also find CoMaps on Flathub! https://flathub.org/apps/app.comaps.comaps
Ærion@CoMaps
Is there a way to install this without using Flatpak? I avoid Flatpak like the plague.
Papa Exmatrikulatus 🏴🏳️🌈@aerion
Quick question: Why do you avoid Flatpaks?
Quick question: Why do you avoid Flatpaks?
Bastian@Papaexmatrikulatus @aerion I personally avoid flatpaks (snaps not as much) because of limited system access and therefore usability. The two main things I noticed:
- Missing subpixel anti-aliasing led to worse readability of text in e.g. LibreWolf
- Filesystem access: LibreWolf file downloads failed, KiCad could only open the files when directly opened from the file manager, FreeCAD could not save any files at all (fixed in newer versions though)
Can I fix some of those issues with permission management? Maybe, but I tried for a few minutes and then realised one should just install the native version from whatever package manager one uses
- Missing subpixel anti-aliasing led to worse readability of text in e.g. LibreWolf
- Filesystem access: LibreWolf file downloads failed, KiCad could only open the files when directly opened from the file manager, FreeCAD could not save any files at all (fixed in newer versions though)
Can I fix some of those issues with permission management? Maybe, but I tried for a few minutes and then realised one should just install the native version from whatever package manager one uses
@bas_spr
Exactly, more fiddling required to achieve (partial) parity with native versions. It should make things easier, not harder.
Flatpak, Snap, and AppImage (and Electron) primarily benefit developers, while offering little benefit to users.
Furthermore, it scatters packages over multiple installation sources, instead of just one: the native package manager..
And finally, yet again we have multiple, incompatible, approaches trying to solve the same problem. Until there is a single, unified method for package distribution, that addresses all the shortcomings of the current ones, I'm steering clear of all of them.
@bas_spr @aerion
I don't really understand the part of your argument abour a unified approach: The package manager is a unified approach for Distributions, but not for Linux as a whole. So, here you have Flatpak, where you can install the same version of Delta Chat or other apps the same way accross different distribitions.
I don't really understand the part of your argument abour a unified approach: The package manager is a unified approach for Distributions, but not for Linux as a whole. So, here you have Flatpak, where you can install the same version of Delta Chat or other apps the same way accross different distribitions.
@Papaexmatrikulatus
Unified as in: a single, universal method to install packages, as opposed to Flatpak vs Snap vs AppImage, mixed with native packages. They all try to be that, but none of them actually achieves its goal.
Take CoMaps, for example.
Ubuntu users would, I imagine, prefer a Snap package, but since only a Flatpak (*) is offered, they're either left out or forced to install Flatpak, learn how to use it, and now they have three app sources to maintain: .deb (via apt), Snap, and Flatpak. That's not what I'd call unified.
(*) I don't use any of the *buntus, or their derivatives, so I don't know if someone's made a Snap package. It's more to illustrate the problem.
@bas_spr
@bas_spr @aerion
Ok, but the method you are prefering isn't a unified approach either, because it depends on your distro, so...
I mean, the link you posted above criticises the de jure (Snap) and de facto (Flathub) centralization of these packaging systems, which is a valid.
But why then, do you want a unified approach? Honestly i would only use Snaps if i really had to... But Flatpaks are in my mind at least more or less the standard packages for sandboxing on Linux. Who uses Appimages?
Ok, but the method you are prefering isn't a unified approach either, because it depends on your distro, so...
I mean, the link you posted above criticises the de jure (Snap) and de facto (Flathub) centralization of these packaging systems, which is a valid.
But why then, do you want a unified approach? Honestly i would only use Snaps if i really had to... But Flatpaks are in my mind at least more or less the standard packages for sandboxing on Linux. Who uses Appimages?
@Papaexmatrikulatus
But that has been my point all along: I don't *want* Flatpak et al. I prefer staying with native packages.
*If* there is to be a unified approach at all, it has to address the current issues, the biggest one of which is competing systems. Until then, as I originally stated, I am not interested.
They do not solve a problem for me, they *create* problems.
Also, as previously stated, they primarily benefit devs, as they only have to package their apps once. Just like Electron apps primarily benefit devs.
As for who uses AppImage: https://aur.archlinux.org/packages?O=0&K=Appimage