But if there is competition for Flatpak then the whole problem that Flatpak is solving comes to the scene again: Package integrity. Right now an app should be maintained and hosted by the distribution repository and that requires man power to update the package and dependencies and check them for compatibility, which is horrible since thousands of programs are in the repository. But if the Flatpak version is maintained by the original developer (which is the case for many apps) then there's no worry for the package manager about that app. That app is updated by its own developer and hosted on a single repository and its dependencies are always fulfilled. Flatpak can share dependencies between the apps in its own platform. That Mesa library is duplicated because each app needed a specific version of the dependency. It's the fault of the developer who did not update its dependencies to the latest version. Maybe Flatpak needs to implement a feature which an app with older dependency version can use the already installed latest dependency if possible, that would be good.
I rather use source then flatpack or snap or appimage. In fact, some software works better from source then the distro package managers. I am not saying its the safest way. Because they all have the same upstream vulnerability. The maintainers. That seems to be how most things are getting messed up these days. So, it is just about as much about how you want to do your packaging.
I only use flatpaks if there is absolutely no other choice or if compiling of a native package is so convoluted that it would take multiple hours to troubleshoot. If you compare flatpaks to appimages, there is simply no valid reason why flatpaks need to be the size of UY Scuti, especially since they still install additional dependencies. Appimages, on the other hand, are *entirely* self-contained and don't require a server farm for space.
@@thedeemon One would assume as much, yes, but they're a fraction of the size of their flatpak counterparts. Inkscape's appimage, for example, is less than 5% the size of its flatpak counterpart. It's absolutely insane.
Thanks for the thoughtful commentary. I'm most likely to choose a flatpak when it offers a much newer version than the .deb in my distro's repo. SSD storage cost/GB has declined so much I usually don't worry too much about the extra storage required (although it is an issue for machines with non-upgradeable storage, like the old netbook with a 64 GB eMMC I used to use. No flatpaks on that computer!). The lack of integration with other packages can be a pain, I agree. Interestingly, Linux Assistant is available only as a flatpak in the Linux Mint software center, and it's an older version than on your Github.
For the problem with permissions the answer is it depends ...... If the application uses the designated portal by default it will work without any trouble because the explorer on your host systen will be able to provide access to the file without any issues..... However some application are deeply integrated in their native graphical environment especially old apps which means they will try to open their own explorer which might be theme broken and using one not of you desktop environment breaking your habit with shortcuts but in my POV those apps should be rebuild to use portals for the exact reason they have the same problem even when installed on host system ! The only application really impacted with that are the ones with their own explorer like blender/aseprite wich have their own explorer with theme, and in the case of blender also add choices about how to import a file, forcing it into a two-step process on a proper flatpak version.
anything that i would consider system important (DE, kernel, ect.) should be dealt with via distro. but like discord should be installed by flatpak. infact flatpaks really let arch work as your system core will be the newest and greatest wile your apps still run. one of the things I always hated with arch is updating the kernel, DE, and dependencies then apps would just break. now i don't have to worry about that and still keep the important parts of my system up-to-date.
dependency recycling could potentially make the storage problem go away, think of it like installing directx once and it works with every game you install later
It became a little bit ranty with the "it eats resources" like. cmon, really? Tell me again how a 1TB is so expensive today. 3GB is 0.3% of that... But your dev viewpoint was interesting to hear. Also, malware stealing bitcon in snapstore MULTIPLE times should maybe be mentioned. Not like it was ages ago, it happened again this year if I'm not mistaken.
in order to be distro-agnostic it needs to bundle the entire runtime for things like gnome and kde which takes up a lot of space, they set them up as dependencies so you only have to install those massive runtimes once.
I love flatpaks when there is absolutely no other way but obs is flatpak only due to the original package doesnt include ability to record broswer window independently as well as a few other items not working when using the original but the author is the same for both original and flatpak version
Flatpaks also don't do a good job of separating out user and application data from the sandbox. making it hard to do backups with backing up everything. Personally i prefer appimages. while larger, and have the same man page issue. your not fighting the sandbox. and it's easier to separate them out from your backups.
A good improvement is for updates in flatpak: They also provide only the diff, which takes usually about a few MB. But if you install a new flatpak then you don't have this effect.
I appreciate your insights on the pros and cons of using Flatpak in Linux, especially regarding the increased disk space usage due to bundled dependencies. I have a suggestion to improve this situation: The Flatpak development team could implement a new feature that allows Flatpak to utilize existing libraries and dependencies already present in the distribution. This feature would work by maintaining a database that tracks which libraries and dependencies each application requires. Flatpak could then compare this information with the libraries and dependencies available on the system. If the required library or dependency is already present, Flatpak would use it directly. If it isn't, Flatpak would download only the missing libraries or dependencies. This approach could significantly reduce the disk space used by Flatpak applications.
This would be a great idea, but I guess technically for so many distributions also very hard to accomplish. But to let flatpaks use some more system resources by default (resulting in smaller runtime packages) would be awesome :)
And then the system updates all its libraries, or the user uninstalls some system libraries. What then? Do you expect Flatpak to just use the Internet to download all missing libraries?
@@khai96x Thank you for your response. Here’s a solution to address your concern: If the system updates its libraries or the user uninstalls some system libraries, there would be no issue. Flatpak would maintain a database with the specific versions of all required libraries and dependencies. Any change or removal of these libraries from the system could be easily managed by Flatpak. It would download and integrate the necessary libraries or dependencies into the Flatpak environment, ensuring the application continues to run smoothly. This approach combines the efficiency of using existing system resources with the robustness of Flatpak’s isolated environment.
@RationalBeing-rh1zf Thank you for your comment. The key difference lies in how Flatpak isolates applications in a bundled environment, akin to a virtual machine. While a package manager installs applications and their dependencies directly into the system, Flatpak encapsulates the entire application along with its dependencies, ensuring it runs in a consistent environment regardless of the host system's libraries. This isolation helps prevent conflicts and ensures compatibility across different Linux distributions, providing a more robust and consistent experience.
@@RedaHaskouri It would add a cost to startup time to check for missing libraries (the cost is still there even if the system hasn't changed, because Flatpak doesn't know if the system has changed, it has to check them every time). It would also make offline mode for offline apps defective, damaging user experience.
Snap also fill the mount table like docker (it was not even on demand when I was using it don't know if it is the case now, but it made reading the mount table really annoying) maybe part of why it take so much time to start at least on the first time the app is launched
But if there is competition for Flatpak then the whole problem that Flatpak is solving comes to the scene again: Package integrity. Right now an app should be maintained and hosted by the distribution repository and that requires man power to update the package and dependencies and check them for compatibility, which is horrible since thousands of programs are in the repository. But if the Flatpak version is maintained by the original developer (which is the case for many apps) then there's no worry for the package manager about that app. That app is updated by its own developer and hosted on a single repository and its dependencies are always fulfilled.
Flatpak can share dependencies between the apps in its own platform. That Mesa library is duplicated because each app needed a specific version of the dependency. It's the fault of the developer who did not update its dependencies to the latest version.
Maybe Flatpak needs to implement a feature which an app with older dependency version can use the already installed latest dependency if possible, that would be good.
I rather use source then flatpack or snap or appimage. In fact, some software works better from source then the distro package managers. I am not saying its the safest way. Because they all have the same upstream vulnerability. The maintainers. That seems to be how most things are getting messed up these days. So, it is just about as much about how you want to do your packaging.
I only use flatpaks if there is absolutely no other choice or if compiling of a native package is so convoluted that it would take multiple hours to troubleshoot. If you compare flatpaks to appimages, there is simply no valid reason why flatpaks need to be the size of UY Scuti, especially since they still install additional dependencies. Appimages, on the other hand, are *entirely* self-contained and don't require a server farm for space.
AppImages are self contained because they include their dependencies inside them, so in theory they shall be larger than flatpaks.
@@thedeemon One would assume as much, yes, but they're a fraction of the size of their flatpak counterparts. Inkscape's appimage, for example, is less than 5% the size of its flatpak counterpart. It's absolutely insane.
Thanks for the thoughtful commentary. I'm most likely to choose a flatpak when it offers a much newer version than the .deb in my distro's repo. SSD storage cost/GB has declined so much I usually don't worry too much about the extra storage required (although it is an issue for machines with non-upgradeable storage, like the old netbook with a 64 GB eMMC I used to use. No flatpaks on that computer!). The lack of integration with other packages can be a pain, I agree.
Interestingly, Linux Assistant is available only as a flatpak in the Linux Mint software center, and it's an older version than on your Github.
For the problem with permissions the answer is it depends ......
If the application uses the designated portal by default it will work without any trouble because the explorer on your host systen will be able to provide access to the file without any issues..... However some application are deeply integrated in their native graphical environment especially old apps which means they will try to open their own explorer which might be theme broken and using one not of you desktop environment breaking your habit with shortcuts but in my POV those apps should be rebuild to use portals for the exact reason they have the same problem even when installed on host system !
The only application really impacted with that are the ones with their own explorer like blender/aseprite wich have their own explorer with theme, and in the case of blender also add choices about how to import a file, forcing it into a two-step process on a proper flatpak version.
anything that i would consider system important (DE, kernel, ect.) should be dealt with via distro. but like discord should be installed by flatpak. infact flatpaks really let arch work as your system core will be the newest and greatest wile your apps still run. one of the things I always hated with arch is updating the kernel, DE, and dependencies then apps would just break. now i don't have to worry about that and still keep the important parts of my system up-to-date.
dependency recycling could potentially make the storage problem go away, think of it like installing directx once and it works with every game you install later
If you ask me best practice is balance between flatpaks and packages.
i really REALLY hate this size part of flatpak. its so lazy and wasteful
I'll say it over & over:
AppImg or similar.
It became a little bit ranty with the "it eats resources" like. cmon, really? Tell me again how a 1TB is so expensive today. 3GB is 0.3% of that...
But your dev viewpoint was interesting to hear.
Also, malware stealing bitcon in snapstore MULTIPLE times should maybe be mentioned. Not like it was ages ago, it happened again this year if I'm not mistaken.
Flatpak apps are frigging HUGE! WTF? Edit to say, love the idea but d@nm.
in order to be distro-agnostic it needs to bundle the entire runtime for things like gnome and kde which takes up a lot of space, they set them up as dependencies so you only have to install those massive runtimes once.
@Pax.Alotin .deb packages only work on Debian and its derivatives. Flatpaks run everywhere, therefore distro-agnostic.
I love flatpaks when there is absolutely no other way but obs is flatpak only due to the original package doesnt include ability to record broswer window independently as well as a few other items not working when using the original but the author is the same for both original and flatpak version
No flatpaks on my MX Linux Xfce. Just the .debs.
I would love to know your solution that you mentioned.
Flatpaks also don't do a good job of separating out user and application data from the sandbox. making it hard to do backups with backing up everything.
Personally i prefer appimages. while larger, and have the same man page issue. your not fighting the sandbox. and it's easier to separate them out from your backups.
Ridiculously inefficient. Not everyone is on unmetered accounts. Not to mention the stupid waste of bandwidth and power in making this happen.
A good improvement is for updates in flatpak: They also provide only the diff, which takes usually about a few MB. But if you install a new flatpak then you don't have this effect.
I appreciate your insights on the pros and cons of using Flatpak in Linux, especially regarding the increased disk space usage due to bundled dependencies. I have a suggestion to improve this situation:
The Flatpak development team could implement a new feature that allows Flatpak to utilize existing libraries and dependencies already present in the distribution. This feature would work by maintaining a database that tracks which libraries and dependencies each application requires. Flatpak could then compare this information with the libraries and dependencies available on the system. If the required library or dependency is already present, Flatpak would use it directly. If it isn't, Flatpak would download only the missing libraries or dependencies. This approach could significantly reduce the disk space used by Flatpak applications.
This would be a great idea, but I guess technically for so many distributions also very hard to accomplish. But to let flatpaks use some more system resources by default (resulting in smaller runtime packages) would be awesome :)
And then the system updates all its libraries, or the user uninstalls some system libraries. What then? Do you expect Flatpak to just use the Internet to download all missing libraries?
@@khai96x
Thank you for your response. Here’s a solution to address your concern:
If the system updates its libraries or the user uninstalls some system libraries, there would be no issue. Flatpak would maintain a database with the specific versions of all required libraries and dependencies. Any change or removal of these libraries from the system could be easily managed by Flatpak. It would download and integrate the necessary libraries or dependencies into the Flatpak environment, ensuring the application continues to run smoothly. This approach combines the efficiency of using existing system resources with the robustness of Flatpak’s isolated environment.
@RationalBeing-rh1zf
Thank you for your comment. The key difference lies in how Flatpak isolates applications in a bundled environment, akin to a virtual machine. While a package manager installs applications and their dependencies directly into the system, Flatpak encapsulates the entire application along with its dependencies, ensuring it runs in a consistent environment regardless of the host system's libraries. This isolation helps prevent conflicts and ensures compatibility across different Linux distributions, providing a more robust and consistent experience.
@@RedaHaskouri It would add a cost to startup time to check for missing libraries (the cost is still there even if the system hasn't changed, because Flatpak doesn't know if the system has changed, it has to check them every time).
It would also make offline mode for offline apps defective, damaging user experience.
2:00 My guess was four. I'm so proud of myself. It probably helps that I abuse docker.
Good guess!
Oh, that's also a cool topic. Docker with desktop applications? Very interesting :)
there seems to be no good solution to flatpaks ;-; appimages are great but integration problems and all, snaps open slow i feel
Snap also fill the mount table like docker (it was not even on demand when I was using it don't know if it is the case now, but it made reading the mount table really annoying) maybe part of why it take so much time to start at least on the first time the app is launched
@@HinaraTyeah i heard it shows many loop devices and thats something because of its conatinerization thingy
nix? ...
But just to be clear app images are a way better way to go
They have sometimes a little different use case, but yeah: From an technical perspective these do feel a lot better 👍