Semi Successful Flatpak With No Advertising - Best Method To Advertise The Flatpak For More User Installs?

Hi,

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!

SS

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.

You are probably thinking of SNAP?

Its similar technology but from Canonical and .. worse. :laughing:

LOL. I hate snap too. Both of them are NOT my thing.
CsCs, thanks for clarification about that though.

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.

But I digress.

And this is why I wrote anything at all..

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. )

so flatpak, not appimage? (among non-native packages. obviously native packages also handle this)

I was just using ā€œDLLā€ as ā€œslangā€ for ā€œlibraryā€. But yeah, I agree.

To be honest, I don’t understand the OP at all. What is not being advertised here? :thinking: and why is there a gaming tag? :person_shrugging:

…And i got carried away with my repsonse(s).
But yeah, I get what you’re saying too, HardCode4All.
Good point.

Hi, original poster here…

Was just asking how to promote a Linux Flatpak?
Wishing for more installs and higher popularity.

Currently the Flatpak is installed about 250 times a month.
In the same category, the top Flatpak has about 1100 installs a month.

SS

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.

Source code is MIT open-source.
It is a video game that uses SDL2.

My team made a couple of games already, and this is my personal favorite.
Don’t understand the hatred of Flatpak?

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).

I do not know about hatred.
Or that criticism/dislike/etc of flatpak is isolated to Cachy.

But there are certain things about Cachy that makes containerized apps extra less attractive here.

For example we have architecture-optimized packages and repositories .. and when you use a containerized app you miss out on those things.