flathub VS steam-runtime

> Nobody ever even audits the binary contents of flatpaks on flathub (were they actually built from the source? the author attests so!).

IME/IIRC There aren't (or shouldn't be) any binary contents on Flathub that are submitted by the author, at least for projects with source available? You're supposed to submit a short, plain-text recipe instead, which then gets automatically built from source outside the control of the author.

> The Flathub service then uses the manifest from your repository to continuously build and distribute your application on every commit.

https://docs.flathub.org/docs/for-app-authors/submission/#ho...

Usually the recipes should just list the appropriate URLs to get the source code, or, for proprietary applications, the official .DEBs. Kinda like AUR, but JSON/YAML. Easy to audit if you want:

https://github.com/orgs/flathub/repositories

I also don't believe third parties maintainers packaging software on flathub is a big issue but I'm also not familiar with how other distro repos trust their maintainers. Hopefully more developers maintain their flatpak themselves (or someone they trust) and get their apps verified. If most apps are verified, warning users of unverified apps might be a good idea.

There's ongoing discussion about splitting open source and proprietary apps in to seperate repos [1]. Additionally having seperate repos for verified and unverified apps might make it more obvious where an app comes from in the cli.

But I don't know how seamlessly an app could transition between being in the third party repo and being in the official repo. Having the user quietly stop receiving updates seems like a bad idea, but automatically migrating might not be desirable either.

I also think flatpaks cli interface needs some work. It is functional but far from distro package managers.

Being verified is especially important for critical apps. Recently someone added malicious versions of apps to the snap store [3]. This lead to people getting their cryptocurrency stolen.

[1] https://github.com/flathub/flathub/issues/691

[2] https://docs.flathub.org/docs/for-app-authors/requirements

[3] https://forum.snapcraft.io/t/temporary-suspension-of-automat...

That means Linux users can now install Bforartists on any Linux distro easily, regardless of glibc version! https://github.com/flathub/flathub/pull/4295

Still having some problems with the flathub build, see https://github.com/flathub/flathub/pull/4082 for the current status.

Here is the flathub draft pull request: https://github.com/flathub/flathub/pull/4082

i assume you dont know how flathub works , theirs little or no QC , done flathub is just get told theirs an update for the package , if yo go look at the github repo pes https://github.com/flathub/flathub/pull/4164 for example , only updates the link to the girt repo , theirs 0 code checked

It all should be written in pages for contributors, read the docs for fusion, and the docs for flathub.

These are criticisms of the flatpak ecosystem as it stands today. Currently, the Firefox ESR package on flathub seems to be caught in limbo or maybe dead. Mozilla publishes both a snap and a flatpak of Firefox latest, but only a snap of the ESR version. This raises the question of why. Have Mozilla chosen to invest more in snaps than in flatpaks? If so, what's their reasoning? (More users on snaps, making it similar to why they put more investment into Windows than Linux? Something else?) If they haven't invested more into snaps than flatpaks, is this a sign that it's harder to maintain flatpaks (or at least on flathub) than snaps? If that's true, I would hope that flatpak/flathub would be soliciting feedback from Mozilla about it.

Because that may be very hard to sandbox: https://github.com/flathub/flathub/issues/3366

> It turns out that unless the game is explicitly marked (by Valve reviewers), Steam Deck will use the Windows build + Proton even if a Linux version is available.

I found this which sounds like it's not the default, but is in fact a result of compatibility testing:

> If your game has gone through Steam Deck compatibility testing and the testers reported that the native Linux version didn't work (because of #579), then it might have been flagged to run the Windows binaries via Proton by default, instead of the native Linux version.

per https://github.com/ValveSoftware/steam-runtime/issues/585

> Where is it written that steam-run will magically execute most binaries without patching them?

Somewhere in here: https://github.com/ValveSoftware/steam-runtime

:p

But I do get what you're saying. Once Flakes are default, I hope people start a proper push to clear up documentation and streamline the development process. The end-result is amazing, and the perfect OS/packaging system for my needs. The means of getting there... need a lot of work. I'm along for the ride either way.

I think they have something a bit like a container built into Steam: https://github.com/ValveSoftware/steam-runtime

this is for steamworks API, my understanding is there's a separate SDK for consuming Linux dependencies like glibc. Like Soldier runtime, Sniper runtime, and so on. Am I wrong in thinking these are two separate SDKs? here's the link to the other SDK I'm talking about: https://github.com/ValveSoftware/steam-runtime

I'm not sure we can distribute a flatpak or an appimage through Steam. They have their own controlled environment called Steam Runtime (https://github.com/ValveSoftware/steam-runtime) in which I should compile to be sure it runs everywhere (very similar to what I am doing). Last time, I look at this, it wasn't very clear and they supported only old versions of GCC. But it seems the documentation improved and now that I succeeded in building a modern version of GCC in my own container, maybe I could do that in theirs.

I believe it's usable outside of Steam: https://github.com/ValveSoftware/steam-runtime though the instructions are not particularly clear. There's also a link to the APT repo they use as a reference: https://repo.steampowered.com/steamrt/

Looking at the Flatpak version, if you want to use Proton versions 5.13 or newer with Steam in Flatpak, you need to install Flatpak from backports https://github.com/ValveSoftware/steam-runtime/issues/294 . Using Flatpak saves having to install i386 if that matters to you.

> Game developers would be fine to target a single distro like Ubuntu 22.04.

Valve has its own container-only Linux distribution, called "Soldier Runtime" (https://github.com/ValveSoftware/steam-runtime); especially for games distributed on Steam, it probably makes more sense to target that distribution instead of Ubuntu.