4 ms·

Flatpak is awful, i tried install software from it a few times and not only it always in a ton of unnecessary stuff (practically an entire distro!) but also the

Flatpak is awful, i tried install software from it a few times and not only it always in a ton of unnecessary stuff (practically an entire distro!) but also the software doesn't integrate seamlessly with the rest of the system. GUI software looks wrong (themes do not apply, font rendering is wrong), command line software doesn't show up in PATH. Example in [0] for the GUI bits (Bless for theme, Notepadqq for font rendering) as well as the disk usage for two simple programs like a hex editor and a text editor. Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system. Nowadays i simply avoid anything related to flatpak. If something doesn't provide normal binaries and i really want it, i'd rather compile it from source (and if the source language is something exotic or the program needs a ton of dependencies i'd just skip it). [0] https://i.imgur.com/9tmo26J.png https://i.imgur.com/9tmo26J.png

Vogtinator 4y ago
> (practically an entire distro!) Practically most container images literally are their own distro install. In the case of flatpak, this becomes obvious when looking at flathub and the provided "runtimes". At that point they just reinvented packages.
- badsectoracula 4y ago
  Flatpak is much worse than packages because if i install a package from my distro it doesn't make duplicates for libraries and other software i already have installed. If Flatpak checked to see what i have already available and downloaded only the dependencies i do not have already installed while also providing seamless integration (a large part of which wouldn't be an issue if it used the system libraries/software), it'd actually be very useful and a solution to every distro having to package every program under the sun and keep it up to date (which IMO is also a bad thing because obviously not all distros can do that, it is just that Flatpak is a worse solution).
- robertlagrant 4y ago
  To my understanding Nix solves this pretty well: just install a flat list of every dependency + version combination any of your software needs. No duplication, all dependencies.
Wowfunhappy 4y ago
I understand your issues but I don't think they're as bad as you're making them out to be. Moreover, I don't see how you could resolve them without either (A) all the distros agreeing on overarching UI and desktop frameworks and sticking them or (B) every software developer customizing their app for each individual distribution. On the "unnecessary stuff" side, do note that Flatpak uses a diff'ing algorithm for the runtimes such that if you install several, they won't take up duplicate space. This is a a reason I prefer them to AppImage.
- ilammy 4y ago
  Open-source developers are not supposed to customize their applications for distributions. Leave that to distro's maintainers, they know more about that. Closed source? Your users are paying you for the headache of making your software run wherever the users need it to run. The differences aren't really that big unless you're shipping something deep in the stack or have to support ancient systems. And you still have to test software everywhere.
  - Wowfunhappy 4y ago
    > Open-source developers are not supposed to customize their applications for distributions. Leave that to distro's maintainers, they know more about that. That's great when the distro maintainers are packaging the software I want—and a problem when they aren't! > Closed source? Your users are paying you for the headache of making your software run wherever the users need it to run. "Okay, then I'll ignore Linux because the users who need it there are too much effort to support."
- deleted 4y ago
  [deleted]
- badsectoracula 4y ago
  They are as bad as i am making them out to be, at least for me :-P. The core of the issue really - and Flatpak is just an attempt to work around it, not solve it, but just work around it - is that unlike the kernel the majority of foundational libraries do not provide stable ABIs. As i wrote in another comment in this post, you technically can run software from the late 90s as long as that software is either statically linked or dynamically links only to the GNU C library and X11 (for GUI stuff), since the kernel and those two have stable ABIs since the 90s. However you do not get much functionality from those libraries even for a notepad-like application and anything beyond that tends to not provide stable ABIs. And that is a cultural problem, not a technical one as there are several examples (including Windows as one of the most obvious) showing that you can have backwards compatibility and stable ABIs while also being able to extend the functionality of the underlying libraries (e.g. an app i wrote and compiled in WinVista got support for an emoji input box automatically in Windows 10 even though i never did anything for that beyond just using the functionality for text input that Windows provided since the late 80s). Because of this the "(A)" solution you mentioned wouldn't even work since, say that everyone agreed to use -for example- GNOME. But that would only work until the Gtk developers decided to break Gtk's ABI yet again for their newest version, forcing everyone that decided to depend on them to waste time "upgrading" (the issues of which can be seen with XFCE or even better, Gimp that still depends on Gtk2 until at some point in the future when the Gtk3 is done - an move that a Gtk developer once described as upgrading from an abandoned version to a deprecated version). I'm not singling out GNOME/Gtk though, the same issues apply with KDE/Qt since Qt also breaks their ABI every major version. If anything KDE/Qt are at a worse position by relying on C++ since despite how many promises GCC developers might make, with the C++ standard not providing a stable ABI promise, there is always the sword of ABI breakage looming over the head of any program that rely on dynamic libraries written in C++ (or any other language that doesn't have a stable ABI). Technically this could be solved by providing proxy dynamic libraries that use the old ABIs to forward calls to the new libraries but i am not aware of this being done in practice (i think Haiku does this to support BeOS binaries compiled with gcc2 but i'm not sure). I do not expect any C++ library to do that on Linux though. So that is the root cause. It requires a cultural shift from often not even acknowledging the problem exists to actually considering ABI breakage something to avoided by all foundational libraries. Flatpak is just a workaround that relies on the kernel at least not breaking its ABI, but even as a workaround it isn't that good for the reasons i mentioned. As i wrote in another reply, it could be improved - as a workaround, not a real solution - by only installing the libraries and software that doesn't already exist in the system and having better integration with it (with a large part of the latter being solved by doing the former). Fortunately so far most libraries do not break their ABIs every year, so at least chances are when i decide to download Notepadqq, it will use the Qt5 installation i already have in my OS instead of downloading its own copy.

Vogtinator 4y ago

> (practically an entire distro!) Practically most container images literally are their own distro install. In the case of flatpak, this becomes obvious when looking at flathub and the provided "runtimes". At that point they just reinvented packages.

badsectoracula 4y ago
Flatpak is much worse than packages because if i install a package from my distro it doesn't make duplicates for libraries and other software i already have installed. If Flatpak checked to see what i have already available and downloaded only the dependencies i do not have already installed while also providing seamless integration (a large part of which wouldn't be an issue if it used the system libraries/software), it'd actually be very useful and a solution to every distro having to package every program under the sun and keep it up to date (which IMO is also a bad thing because obviously not all distros can do that, it is just that Flatpak is a worse solution).
robertlagrant 4y ago
To my understanding Nix solves this pretty well: just install a flat list of every dependency + version combination any of your software needs. No duplication, all dependencies.

Wowfunhappy 4y ago

I understand your issues but I don't think they're as bad as you're making them out to be. Moreover, I don't see how you could resolve them without either (A) all the distros agreeing on overarching UI and desktop frameworks and sticking them or (B) every software developer customizing their app for each individual distribution. On the "unnecessary stuff" side, do note that Flatpak uses a diff'ing algorithm for the runtimes such that if you install several, they won't take up duplicate space. This is a a reason I prefer them to AppImage.

ilammy 4y ago
Open-source developers are not supposed to customize their applications for distributions. Leave that to distro's maintainers, they know more about that. Closed source? Your users are paying you for the headache of making your software run wherever the users need it to run. The differences aren't really that big unless you're shipping something deep in the stack or have to support ancient systems. And you still have to test software everywhere.
- Wowfunhappy 4y ago
  > Open-source developers are not supposed to customize their applications for distributions. Leave that to distro's maintainers, they know more about that. That's great when the distro maintainers are packaging the software I want—and a problem when they aren't! > Closed source? Your users are paying you for the headache of making your software run wherever the users need it to run. "Okay, then I'll ignore Linux because the users who need it there are too much effort to support."
deleted 4y ago
[deleted]
badsectoracula 4y ago
They are as bad as i am making them out to be, at least for me :-P. The core of the issue really - and Flatpak is just an attempt to work around it, not solve it, but just work around it - is that unlike the kernel the majority of foundational libraries do not provide stable ABIs. As i wrote in another comment in this post, you technically can run software from the late 90s as long as that software is either statically linked or dynamically links only to the GNU C library and X11 (for GUI stuff), since the kernel and those two have stable ABIs since the 90s. However you do not get much functionality from those libraries even for a notepad-like application and anything beyond that tends to not provide stable ABIs. And that is a cultural problem, not a technical one as there are several examples (including Windows as one of the most obvious) showing that you can have backwards compatibility and stable ABIs while also being able to extend the functionality of the underlying libraries (e.g. an app i wrote and compiled in WinVista got support for an emoji input box automatically in Windows 10 even though i never did anything for that beyond just using the functionality for text input that Windows provided since the late 80s). Because of this the "(A)" solution you mentioned wouldn't even work since, say that everyone agreed to use -for example- GNOME. But that would only work until the Gtk developers decided to break Gtk's ABI yet again for their newest version, forcing everyone that decided to depend on them to waste time "upgrading" (the issues of which can be seen with XFCE or even better, Gimp that still depends on Gtk2 until at some point in the future when the Gtk3 is done - an move that a Gtk developer once described as upgrading from an abandoned version to a deprecated version). I'm not singling out GNOME/Gtk though, the same issues apply with KDE/Qt since Qt also breaks their ABI every major version. If anything KDE/Qt are at a worse position by relying on C++ since despite how many promises GCC developers might make, with the C++ standard not providing a stable ABI promise, there is always the sword of ABI breakage looming over the head of any program that rely on dynamic libraries written in C++ (or any other language that doesn't have a stable ABI). Technically this could be solved by providing proxy dynamic libraries that use the old ABIs to forward calls to the new libraries but i am not aware of this being done in practice (i think Haiku does this to support BeOS binaries compiled with gcc2 but i'm not sure). I do not expect any C++ library to do that on Linux though. So that is the root cause. It requires a cultural shift from often not even acknowledging the problem exists to actually considering ABI breakage something to avoided by all foundational libraries. Flatpak is just a workaround that relies on the kernel at least not breaking its ABI, but even as a workaround it isn't that good for the reasons i mentioned. As i wrote in another reply, it could be improved - as a workaround, not a real solution - by only installing the libraries and software that doesn't already exist in the system and having better integration with it (with a large part of the latter being solved by doing the former). Fortunately so far most libraries do not break their ABIs every year, so at least chances are when i decide to download Notepadqq, it will use the Qt5 installation i already have in my OS instead of downloading its own copy.