Not advertising here on the forum, as there is no information about the Flatpak in this post.
Flatpak is doing quite well without any advertising.
We wish to get substantially more user installs of the Flatpak.
Does anyone here know how to best promote this Flatpak?
Free methods are preferred, but paid(within reason) are also ok.
Let us know here, thank you!
I specifically hate and avoid all flatpak installs and the distributions (Canonical/Ubuntu) which push it against user preferences.
Instead, I truly enjoy and support and benefit from AppImage.
For example,
AppImages only require one command to prep for running (make executable; a very simple procedure)
AppImages donāt require any other installs nor dependencies.
AppImages can be easily stored wherever the user prefers.
AppImages can be easily updated or deleted without leaving odd dependency stalemates (leftovers).
AppImages are relatively straightforward for developers as they can put all that the program needs into the bundle.
AppImages only require ONE download and usually arenāt too big.
AppImages are NOT tied to any particular organization.
AppImages do NOT require any type of subscription nor subscription-like model.
For all these reasons, to me, thereās no reason to use Flatpak or SNAP as long as thereās the traditional alternatives not limited to AppImage. I like using the other traditional means too.
Flatpak (and SNAP) are purely an annoyance to users like me, and Iām not alone.
Flatpak offers sandboxing that I do not believe AppImage provides. I do prefer AppImage over Flatpak due to the simplicity and lack of bloat, but only for trusted things like well established emulators. Some random AI doodad whachamacallit I would not run via AppImage. Flatpak in this case would make more sense.
The thing is, AppImages donāt always work since the packager picks what dependencies should be included, and most only test if it works on Ubuntu. So they are only as āuniversalā as the packager has made them to be (by hopefully including any distro specific packages used when building the app that would not be present on all reasonably recent distros).
itās important to point out that this is not obligate sandboxing. Thereās only as much isolation as the packager configures unless you go in and change things.
I get what youāre saying. However, Iāve NEVER had an AppImage fail on me, although I donāt do gaming. I use AppImages for stuff like Krita, Ocenaudio, LMMS, Reaper, etc.
As for the dependencies, thatās not an AppImage concern, thatās a programmerās concern. Programmers are always needing to make sure that they get correct the dependencies so they donāt pass the problems to their end users. I find that various techniques of distributing programs donāt solve this problem. Either the program is a mess or it isnāt. I suspect that something about the procedure for making AppImages might be easier on programmers since they seem so reliable (for me, anyways).
But if a programmer is sloppy, their program is probably going to be sloppy as well.
Personally, if I see spelling/grammar errors in the programās release notes, then I donāt use the program since there might be syntax errors within the program as well.
umm if you package software in a manner such that it uses only self-contained and declared dependencies this absolutely does solve the problem of dependencies. That might create other undesirable effectsā¦but if the developer is required to BYODependencies that problem is pretty much solved
And in the case of ānormalā packaging its not the programmers concern so much as the packager/maintainer for said repository.
If not packaged at all then the dependencies are up to the user to manage themselves. The programmer/developer may take such dependencies into consideration during their development or may make such information available to end users .. but the consideration in order for the software to run in any given environment would be the responsibility of that user.
If some github project says āyou need go to build thisā then that may have been written by the programmer but it is something the user would manage.
While I agree with both of you guys, I do feel that programs/programming/programmers/package managers that DONāT require the end user to hunt for missing libs, etc are going to be wildly more popular than those that do.
Also, for people like me, I donāt want to āsubscribeā to manage DLL hell, I just want to install something, and move on. I donāt like entangled installs. I donāt mind if thereās a few mainstream dependencies revealed and auto-installed via pacman, but if it gets wierd, then Iām out.
Thankfully, I do feel that for some reason package management (as a user) is easier using pacman/paru/yay/octopi and the like than using apt/synaptic/nala/etc. On the side I mess with Debian and the repo management can get wierd sometimes.
Statements like this sound as if there is some misunderstanding.
Repository packages .. or even those from the AUR .. should have their dependencies and optional dependencies included as part of the packaging. So you would not be going to go look for anything in those examples either.
Again the package manager and packages should already handle this for you.
And for the most part we do not do .dlls. Thats some windoze thing.
( You will find some in the wine/mono packages though. )
Does it better meet the needs of people and solve their problems?
Call me old fashioned but Iām most interested in good software thatās well-documented and does something different or better than alternatives. And isnāt tied to flatpak. No one weird trick, just quality useful software.
Flatpaks are fine. And preferable if the app has complex dependencies like in the case of Bottles. The hatred is just specific to this community (I also donāt understand it).