Fan of Flatpaks ...or Not?
-
one of my least favorite things about arch and other rolling distros is that yay/pacman will try and recompile shit like electron/chromium from source every few days unless you give it very specific instructions not to - which is annoying as shit bc compiling the entirety of chrome from source takes hours even with decent hardware.
granted, i fucking hate google products too but if you’re doing any web dev it’s necessary sometimes.
idk im definitely willing to admit i might be the idiot here. managing your packages with pacman might just be routine to some people. to me arch is the epitome of classic bad UX in an open source project. it’s like they got too focused on being cmatrix-style terminal nerds and forgot to make their software efficiently useable outside of 5 very specific people’s workflows. it’s not even the terminal usage that is bad about arch. plenty of things are focused on that and… don’t do it shittily? idk…
edit: yes to all the arch fanboy’s points in response to me. i used to be super into arch and am aware of the fact that this isn’t explicit behavior but to act like it doesn’t happen in a typical arch user experience is disingenuous. i also disagree with the take that arch doesn’t endorse this outright with its design philosophy, bc it does. the comparison of the AUR to other, similar things like PPAs doesn’t land for me bc PPAs aren’t integrated into the ecosystem nearly as much as AUR is with arch. you can’t tell people to just grab the binaries or not use AUR whenever it’s convenient to blame the user, when arch explicitly endorses a philosophy amicable to self-compilation and also heavily uses the AUR even in their own arch-wiki tutorials for fairly basic use cases. arch wants to have its cake and eat it too and be a great DIY build it yourself toolkit while also catering to daily driver use and more generalist users. don’t get me wrong, it’s the best attempt at such a thing i’ve seen - but at a certain point you have to ask if the premise makes sense anymore. in the case of arch, it doesn’t and it causes several facets of the ecosystem to flounder from a user perspective. the arch community’s habit of shouting “skill issue” at people when they point out legitimate issues with the design philosophy bugs the fuck out of me. this whole OS is a camel.
I get that with NixOS even if I use a tablet as my release. It's pretty annoying if it is too new and not cached yet.
-
one of my least favorite things about arch and other rolling distros is that yay/pacman will try and recompile shit like electron/chromium from source every few days unless you give it very specific instructions not to - which is annoying as shit bc compiling the entirety of chrome from source takes hours even with decent hardware.
granted, i fucking hate google products too but if you’re doing any web dev it’s necessary sometimes.
idk im definitely willing to admit i might be the idiot here. managing your packages with pacman might just be routine to some people. to me arch is the epitome of classic bad UX in an open source project. it’s like they got too focused on being cmatrix-style terminal nerds and forgot to make their software efficiently useable outside of 5 very specific people’s workflows. it’s not even the terminal usage that is bad about arch. plenty of things are focused on that and… don’t do it shittily? idk…
edit: yes to all the arch fanboy’s points in response to me. i used to be super into arch and am aware of the fact that this isn’t explicit behavior but to act like it doesn’t happen in a typical arch user experience is disingenuous. i also disagree with the take that arch doesn’t endorse this outright with its design philosophy, bc it does. the comparison of the AUR to other, similar things like PPAs doesn’t land for me bc PPAs aren’t integrated into the ecosystem nearly as much as AUR is with arch. you can’t tell people to just grab the binaries or not use AUR whenever it’s convenient to blame the user, when arch explicitly endorses a philosophy amicable to self-compilation and also heavily uses the AUR even in their own arch-wiki tutorials for fairly basic use cases. arch wants to have its cake and eat it too and be a great DIY build it yourself toolkit while also catering to daily driver use and more generalist users. don’t get me wrong, it’s the best attempt at such a thing i’ve seen - but at a certain point you have to ask if the premise makes sense anymore. in the case of arch, it doesn’t and it causes several facets of the ecosystem to flounder from a user perspective. the arch community’s habit of shouting “skill issue” at people when they point out legitimate issues with the design philosophy bugs the fuck out of me. this whole OS is a camel.
I've been on Garuda for 4 years or so, not once has this happenoed to me
-
Certainly a fan, and I don't understand the hate towards it.
Flatpaks are my preferred way of installing Linux apps, unless it is a system package, or something that genuinely requires extensive permissions like a VPN client, or something many other apps depend on like Wine.
The commonly cited issues with Flatpaks are:
- Performance. Honestly, do you even care if your Pomodoro timer app takes up 1 more megabyte of RAM? Do you actually notice?
- Bloat. Oh, yes, an app now takes 20 MB instead of 10 MB. Again, does anybody care?
- Slower and larger updates. Could be an issue for someone on a metered traffic, or with very little time to do updates. Flatpaks update in the background, though, and you typically won't notice the difference unless you need something newest now (in which case you'll have to wait an extra minute)
- Having to check permissions. This is a feature, not a bug. For common proponents of privacy and security, Linuxheads grew insanely comfortable granting literally every maintainer full access to their system. Flatpaks intentionally limit apps functionality to what is allowed, and if in some case defaults aren't good for your use case - just toggle a switch in Flatseal, c'mon, you don't need any expertise to change it.
What you gain for it? Everything.
- Full control over app's permissions. Your mail client doesn't need full system permissions, and neither do your messengers. Hell, even your backup client only needs to access what it backs up.
- All dependencies built in. You'll never have to face dependency hell, ever, no matter what. And you can be absolutely sure the app is fully featured and you won't have to look for missing nonessential dependencies.
- Fully distro-agnostic. If something works on my EndeavourOS, it will work on my OpenSUSE Slowroll, and on my Debian 12. And it will be exactly the same thing, same version, same features. It's beautiful.
- Stability. Flatpaks are sandboxed, so they don't affect your system and cannot harm it in any way. This is why immutable distros feature Flatpaks as the main application source. Using them with mutable distributions will also greatly enhance stability.
Alternatives?
AppImages don't need an installation, so they are nice to see what the program is about. But for other uses, they are garbage-tier. Somehow they manage both not to integrate with the system and not be sandboxed, you need manual intervention or additional tools to at least update them/add to application menu, and ultimately, they depend on one file somewhere. This is extremely unreliable and one should likely never use AppImages for anything but "use and delete".
Snaps...aside from all the controversy about Snap Store being proprietary and Ubuntu shoving snaps down people's throats, they were just never originally developed with desktop applications in mind. As a result, Snaps are commonly so much slower and bulkier that it actually starts getting very noticeable. Permissions are also way less detailed, meaning you can't set apps up with minimum permissions for your use case.
This all leaves us with one King:
And it is Flatpak.
Changed my mind. Thanks.
-
I've been on Garuda for 4 years or so, not once has this happenoed to me
is garuda like endeavorOS or manjaro where it’s technically still an arch-based rolling release distro but the OS maintainers hold packages from upstream mainline arch?
i don’t hate that model, it’s more fun to use as an end user for sure, but i feel like it kind of defeats the point of arch’s entire ethos lmao.
-
I've been working on Linux for 15 years now and I perfectly remember the origin of many concepts. If you look at it through time, what would it be like:
- We can build applications with external dependencies or a single binary, what should we choose?
- The community is abandoning a single binary due to the increased weight of applications and memory consumption and libraries problems
- Dependency hell is coming
... - Snap, flatpack, appimage and other strange solutions are inventing something, which are essentially a single binary, but with an overlay (if the developer has hands from the right place, which is often not the case)
- Someone on lemmy says that he literally doesn't care if the application is built in a single binary, consumes extra memory and have libraries problems. Just close all permissions for that application...
Well, all I can say about this is just assemble a single binary for all applications, stop doing nonsense with a flatpack/snap/etc.
UPD: or if you really want to break all the conventions, just use nixos. You don't need snap/flatpack/etc.
Flatpak is not single binary, Flatpaks have shared runtime (For example Freedesktop, GNOME, KDE runtimes)
-
one of my least favorite things about arch and other rolling distros is that yay/pacman will try and recompile shit like electron/chromium from source every few days unless you give it very specific instructions not to - which is annoying as shit bc compiling the entirety of chrome from source takes hours even with decent hardware.
granted, i fucking hate google products too but if you’re doing any web dev it’s necessary sometimes.
idk im definitely willing to admit i might be the idiot here. managing your packages with pacman might just be routine to some people. to me arch is the epitome of classic bad UX in an open source project. it’s like they got too focused on being cmatrix-style terminal nerds and forgot to make their software efficiently useable outside of 5 very specific people’s workflows. it’s not even the terminal usage that is bad about arch. plenty of things are focused on that and… don’t do it shittily? idk…
edit: yes to all the arch fanboy’s points in response to me. i used to be super into arch and am aware of the fact that this isn’t explicit behavior but to act like it doesn’t happen in a typical arch user experience is disingenuous. i also disagree with the take that arch doesn’t endorse this outright with its design philosophy, bc it does. the comparison of the AUR to other, similar things like PPAs doesn’t land for me bc PPAs aren’t integrated into the ecosystem nearly as much as AUR is with arch. you can’t tell people to just grab the binaries or not use AUR whenever it’s convenient to blame the user, when arch explicitly endorses a philosophy amicable to self-compilation and also heavily uses the AUR even in their own arch-wiki tutorials for fairly basic use cases. arch wants to have its cake and eat it too and be a great DIY build it yourself toolkit while also catering to daily driver use and more generalist users. don’t get me wrong, it’s the best attempt at such a thing i’ve seen - but at a certain point you have to ask if the premise makes sense anymore. in the case of arch, it doesn’t and it causes several facets of the ecosystem to flounder from a user perspective. the arch community’s habit of shouting “skill issue” at people when they point out legitimate issues with the design philosophy bugs the fuck out of me. this whole OS is a camel.
Is there no -bin version available for those packages?
-
Flatpak is not single binary, Flatpaks have shared runtime (For example Freedesktop, GNOME, KDE runtimes)
Provided that flatpack has a common parent container, which is not always the case. More precisely, it almost never does. Because someone updates flatpack to new versions of the parent containers, and someone else does not.
-
This post did not contain any content.
I have used rpms, AppImages, Flatpaks, and source. I have even used a snap or two when I had no other choice.
If you can't work with them all, can you even say you Linux Bro?
-
This post did not contain any content.
Flatpaks suck
Ubuntu has turned to dogshit
-
All these applications will never work in flat pack.
They don't have to! Flatpak doesn't remove all other ways to install software. But for 95% of use cases, it will do just fine.
Firejail is good, but it only solves sandboxing part of the equation, and there's so much more to Flatpaks than that. Also, it's more painful to configure and is more sysadmin-oriented.
wrote on last edited by [email protected]They don't have to! Flat pack doesn't remove all other ways to install software. But for 95% of use cases, it will do just fine.
Tell this to canonical, they even firefox put in the snap. You know that when choosing "quickly compile something for a flatpack" and "support 10+ distributions", the developers will choose a flatpack. Which in general looks fine, until you realize that everything is just scored on the mainline of libraries and molded on anything. The most striking example of this is Linphone. just try to compile it...
-
No, I wouldn't. It's how I can tell if the setting actually took!
Is there no other way on your system to see what the default browser is? On Gnome you can see a few of your default applications in the settings. And what happens if you open an html file for example? Does it open in Zen? If yes then it appears that Zen is set as your default browser, what more is there to check?
-
Is there no -bin version available for those packages?
sometimes you’re working with particular releases or builds that don’t, but like i said i might be the idiot lol.
i like the concept of arch. i don’t like the way i need to come up with a new solution for how im managing my packages virtually every few days that often requires novel information. shit, half the time you boot up an arch system if you have sufficient # of packages there is 9/10 times a conflict when trying to just update things naively. like i said it’s cool on paper and im sure once you use it as a daily driver for awhile it just becomes routine but it’s more the principle of the user experience and its design philosophy that i think might be poor.
arch is for techies in the middle of the bell curve imo… people on the left and the right, when it comes to something as simple as managing all my packages and versions, want something that just works^TM^ - unless i specifically want to fuck with the minutiae.
-
Provided that flatpack has a common parent container, which is not always the case. More precisely, it almost never does. Because someone updates flatpack to new versions of the parent containers, and someone else does not.
More precisely, it almost never does.
I don't know any flatpak in my system that don't use runtime (I have around 50 flatpak apps installed), or am I misunderstanding your point
-
More precisely, it almost never does.
I don't know any flatpak in my system that don't use runtime (I have around 50 flatpak apps installed), or am I misunderstanding your point
wrote on last edited by [email protected]runtime have versions too. If one runtime version use only one flatpack than exactly same as just static linking binary. Flatpack have just docker layeredfs and firejail in base.
id: org.gnome.Dictionary runtime: org.gnome.Platform runtime-version: '45' <- here sdk: org.gnome.Sdk command: gnome-dictionary -
This post did not contain any content.
never tried flatpak, snaps were so bad as to never consider non-native installs or just use docker instances when I need to run something weird. so dunno.
whats the use case for a flatpak exactly? maybe im not the target audience???
-
This post did not contain any content.
./configure
make
make install -
I've been working on Linux for 15 years now and I perfectly remember the origin of many concepts. If you look at it through time, what would it be like:
- We can build applications with external dependencies or a single binary, what should we choose?
- The community is abandoning a single binary due to the increased weight of applications and memory consumption and libraries problems
- Dependency hell is coming
... - Snap, flatpack, appimage and other strange solutions are inventing something, which are essentially a single binary, but with an overlay (if the developer has hands from the right place, which is often not the case)
- Someone on lemmy says that he literally doesn't care if the application is built in a single binary, consumes extra memory and have libraries problems. Just close all permissions for that application...
Well, all I can say about this is just assemble a single binary for all applications, stop doing nonsense with a flatpack/snap/etc.
UPD: or if you really want to break all the conventions, just use nixos. You don't need snap/flatpack/etc.
Old guy here too, used un*x before linux existed in the 90s. I still use a Debian based distro (MX) without systemd and no snap/flatpak/whatever. Just build/compile or install .deb and dependencies. Lastly unfortunately I had to install a flatpak to test "deskflow", the first time I installed one, I feel dirty now
-
Flatpaks suck
Ubuntu has turned to dogshit
i agree ubuntu is corpo drivel now but flatpaks are actually quite useful for some applications.
the sandboxing is nice to not have to setup manually for every little thing, and i say that as someone who avoids flatpaks generally.
sometimes you just wanna get things up and running, not everything needs to be a unix circlejerk.
-
runtime have versions too. If one runtime version use only one flatpack than exactly same as just static linking binary. Flatpack have just docker layeredfs and firejail in base.
id: org.gnome.Dictionary runtime: org.gnome.Platform runtime-version: '45' <- here sdk: org.gnome.Sdk command: gnome-dictionaryI see problem in that only in unmaintained apps (like org.gnome.Dictionary), I have only GNOME 47 & 48 for example and both of them still updating
-
I see problem in that only in unmaintained apps (like org.gnome.Dictionary), I have only GNOME 47 & 48 for example and both of them still updating
In the initial stage of shared library support, everything was exactly the same. Let's look at it in 5 years... When some soft will archived and die, some stop maintaining, some new crated and brakes old dependencies...
