-
Notifications
You must be signed in to change notification settings - Fork 1
4. 3rd‐party Applications
You can try to use distroboxes, but it's still not reliable imo for daily usage & it's the reason it's not deeply integrated into Gidro-OS.
I don't like how it clutters the home directory, where it's hard to clean redundant files with random names.
However, I follow the container development closely & I am investigating on using better solutions for GUI & CLI apps.
Homebrew & Bluefin-CLI is something that I'm closely following for CLI apps.
For GUI management of distrobox apps, I follow the development of BoxBuddy, as I like simple UI.
Initially, I shipped Pods for distrobox GUI usage, but I find it too complicated, so I removed it.
Regarding AppImages, it's not the ideal app-format & it's hard to integrate it to the system for ease of use.
It's also less secure & has full access to the system as it's not sandboxed. So I don't recommend to use it.
It's up to the developer to make the application in superior flatpak app-format
(also up to flatpak maintainers to make app creation process easier, as AppImage is much easier to make).
AppImage claims this statement: "Linux apps that run anywhere", which is absolutely false.
It only includes small part of dependencies inside the binary, which are only tested on specific older version of Ubuntu.
So good amount of the libraries are used from the host (OS), if they're available.
The version of the libraries used from the host (OS) are not tested with the application & it can cause app to malfunction.
If some library is not available either in the app or in the host (OS), but the app expects it, than app will fail to work.
Result: Some AppImages fail to run on Fedora Silverblue/Gidro-OS.
Some distributions don't ship libfuse2 by default anymore, like Ubuntu.
Result: Every AppImage fails to run.
It's not excluded that Fedora will do this too.
If they do, I can manually include libfuse2 from official repository or COPR, but what's the point if the app-format is flawed.
While some experimental libfuse3 AppImages exist, those are very rare & if libfuse4 gets announced, you see the same scenario mentioned above.
Another thing that is bad with AppImages is the distribution method itself.
It expects you to download the binary from the website, in the Windows way,
while having a repository of apps as a distribution method is more secure & simpler to use.
You would need to manually integrate AppImage into desktop & update it when downloaded from the website,
while with the dedicated repository & AppImage manager, you don't need to worry about that at all.
Some projects like AM or Zap exist to mitigate this issue,
but I don't trust their reliability.
Gear Lever also exists to mitigate easy AppImage integration into desktop if you don't want repo & auto-update functionality.
Overall, I don't recommend using AppImages at all.
This app-format is interesting.
It tries to be portable & universally compatible by shipping a Linux distribution, application & its dependencies inside a compressed image.
This is a much better & truly working approach compared to the AppImages.
It partially integrates with the system by recognizing default apps through mime.
It also uses sandbox & has some permission management.
FlatImage can use Arch, Ubuntu or Alpine images as a base (Alpine is known to be small in size, which makes it greatly suitable to use as a base).
However, FlatImage binaries are very big in size & it's still a relatively new format that is work-in-progress, so it takes time for it to mature in terms of features & reliability.
Of course, FlatImages are not aimed to replace flatpaks, but to be used aside from flatpaks.
Especially if you need the app portability, which flatpaks can't offer.
My opinion is that the future of this app-format is bright, as it's a good concept.
Conty also exists, but it's focus is not to be the new app-image format, but to be used as an app-container for specific purposes.