go-appimage VS com.obsproject.Studio

Snap and flatpak run a daemon to integrate into your system. Appimage has an optional daemon to give you the same integration https://github.com/probonopd/go-appimage

Handles making it executable, automatic upgrades, no need to move it to your $PATH, and adds the application to your app list.

Only other thing you might want to do is symlink a friendly name for cli

It's possible to make appimages that bundle a libc, although most don't. The go-appimage project contains a static build tool that will bundle the linker and wrap executable invocation in that. The intention seems to be providing support on older systems for programs built with a glibc that is too new, but I'm using it to ship a musl binary that can run on glibc systems.

I look forward to watching the FOSDEM talk this weekend, so perhaps getting ahead of myself. But I'm curious whether you think the move in appimage toward static linking would solve some of the hairy issues you pointed out? For example: https://github.com/AppImage/AppImageKit/issues/1193 and https://github.com/probonopd/go-appimage/

AppImage This seems like a convenient way of keeping Wine isolated from rest of the system. However, the documentation is still in research phase for this: https://github.com/AppImage/AppImageKit/wiki/Bundling-Windows-applications https://github.com/probonopd/go-appimage https://github.com/TheAssassin/AppImageLauncher https://github.com/sudo-give-me-coffee/wine32-deploy

There's an automatic way to make .desktop entries from appimage, I use https://github.com/probonopd/go-appimage/blob/master/src/appimaged/README.md

There are helper programs to help you manage them and integrate them with the system like other package formats.

their is you can use appimaged https://github.com/probonopd/go-appimage

Would be great if most distros (including Ubuntu, Fedora, etc.) would include AppImageLauncher or appimaged by default. Would make it much simpler for most people.

The "see details" link takes you to: https://github.com/flathub/com.obsproject.Studio/graphs/contributors/

With official packages, I have even more questions. Example: OBS Studio. The publisher link points to this repo, which is currently archived, with the message "This repository is no longer used to build OBS. Issues should be reported at https://github.com/obsproject/obs-studio". After some digging, I found they're using Github Actions to automatically publish to Flathub on release, which is fine (and pretty cool), but I would still prefer that Flathub provide some kind of records on their end. What assurances do I have that the package installed on my machine from Flathub is the one that was built by upstream? Maybe they have something and I'm not looking in the right place.

Big news for Linux users: We now officially ship OBS Studio via Flatpak (in addition to the PPA), greatly expanding support for more distros and providing a much more consistent experience, no matter your environment. Download it from Flathub here - https://flathub.org/apps/details/com.obsproject.Studio

OBS (stream/rec): Flatpak, Steam(?)

There is obs-studio package in Debian, try using that. Alternatively, you could install it as a Flatpak via Flathub (there were also recent news of OBS Project is making it their official Linux package instead of Ubuntu PPA).

I'm not the only one. The issue tracker is full of people having serious issues like, y'know "Doesn't work at all" and "No fonts," and "Crashes on Alt-Tab," etc.