ESLauncher2 VS flathub

Or just download a certain mod's wonderful launcher.

Putting this top level, you need Endless Sky Launcher 2 from here: https://github.com/EndlessSkyCommunity/ESLauncher2

Haha, yeah! There is a pinned comment on this sub that already announced it, but it's such awesome news, isn't it? Of course, I won't personally be using it anyway since I'm deep into the 0.9.15 alpha content (not on Steam yet since 0.9.15 isn't finished, but it's updated frequently on github and is also available using the launcher). Still, having a 'stable' release on Steam for the first time in over two years is sure to attract a lot of new players! 😁

I'd really recommend downloading ESLauncher2 and using it to stay up-to-date with Continuous. There are rarely any bugs, especially anything major since all commits need to be approved by the devs in order to be pushed into continuous anyway, and there's a lot more story content. The Remnant have 20+ new missions, and the new ships are unlocked through the course of these missions.

You should download ESL 2 as u/Kadd115 suggested. Link in the clear: https://github.com/EndlessSkyCommunity/ESLauncher2 This will let you easily play the Continuous which has all the new content, all the time. And there's a lot, especially for the Remnant. The person who made the launcher also makes tons of other contributions to the game and shows up here from time to time.

While you could technically assemble and run the continuous on your own, it's far easier with a bit of code. Check out: https://github.com/EndlessSkyCommunity/ESLauncher2/

A couple of versions ago (in 0.9.13), but it's kind of an easter egg ship -- gotta jump through a lot of hoops to get it, and it's not really something you can find 'by accident'... Also, bear in mind that the Steam version is lagging pretty far behind. Steam still only offers 0.9.12 in the 'stable' branch, and 0.9.13 if you opt into the 'beta' branch, but 0.9.14 was released months ago and just hasn't made it into Steam yet (I'd recommend either getting it from the GitHub page directly or downloading the unofficial ES Launcher 2).

For people who want the super fresh stuff, you should download the Endless Sky Launcher 2 and use it to run the Continuous build.

But download ES Launcher 2 and get on the nightly. There is a TON of newer content, including almost as much Remnant as a full third of a whole story line, another really long and satisfying Deep line, and a whole bunch more (rewarding!) archeology missions, to name but a very few. And several very interesting moral dilemmas along the way. And you can play the newer Coalition intro, which is quite fun.

> 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