It looks like there are instructions here about hosting your own flatpak instance: https://docs.flatpak.org/en/latest/hosting-a-repository.html
CMahaff
Doubling what Klaymore said, I've seen this "just work" as long as all partitions have the same password, no key files necessary.
That said, if you needed to use a key file for some reason, that should work too, especially if your root directory is one big partition. Keep in mind too that the luks commands for creating a password-based encrypted partition vs a keyfile-based encrypted partition are different, so you can't, for example, put your plaintext password into a file and expect that to unlock a LUKS partition that was setup with a password.
But the kernel should be trying to mount your root partition first at boot time where it will prompt for the password. After that it would look to any /etc/crypttab entries for information about unlocking the other partitions. In that file you can provide a path to your key file, and as long as it's on the same partition as the crypttab it should be able to unlock any other partitions you have at boot time.
It is also possible, as one of your links shows, to automatically unlock even the root partition by putting a key file and custom /etc/crypttab into your initramfs (first thing mounted at boot time), but it's not secure to do so since the initramfs isn't (and can't be) encrypted - it's kind of the digital equivalent of hiding the house key under the door mat.
I really enjoyed my time with it, even though I've not played many games in this "style".
The campaign is quite lengthy even though it's not finished yet, so you'll definitely get your money's worth.
Another solution to this situation is to squash your changes in place so that your branch is just 1 commit, and then do the rebase against your master branch or equivalent.
Works great if you're willing to lose the commit history on your branch, which obviously isn't always the case.
I'll just add that another, albeit smaller, category of games that don't work are really new, demanding titles. There's not a lot of them for now, but naturally the deck wasn't the most powerful device to begin with and over time less titles will work well.
Starfield was pointed out to me as an example of one that can't run on the deck for performance reasons (not that Bethesda is known for their optimization) and BG3 was only barely playable at the lowest settings in the more demanding areas of the game (i.e. Act 3).
That said, for its price point, and considering most games are using the proton compatibility later, I was actually very impressed with its performance.
Out of curiosity, what content are you looking for? Discovery on Lemmy can be a problem, but sometimes the communities are there and even active, just buried.
But may I also suggest searching by Top Day/12-hour/6-hour to see the most active posts. Lemmy's scaled algorithm still doesn't get it quite right IMO.
The CEO said they were going to add pay-walled subreddits at an earnings call.
So... Yep.
I know for me, at least with gnome, toggling between performance, balanced, and battery saver modes dramatically changes my battery life on Ubuntu, so I have to toggle it manually to not drain my battery life if it's mostly sitting there. I don't know if Mint is the same, but just throwing out the "obvious" for anyone else running Linux on a laptop.
Found a blog post that gives a quick overview of how to do git via email in general: https://peter.eisentraut.org/blog/2023/05/09/how-to-submit-a-patch-by-email-2023-edition
So at least from my understanding you'd make your changes, email the contents of the patch to the maintainer, and then they'd apply it on their side, do code review, email you comments, etc. until it was in an acceptable state.
There's also the full kernel development wiki that goes into all the specifics: https://www.kernel.org/doc/html/v4.16/process/howto.html
(I never got through the whole thing)
I'll also throw out: aging infrastructure, build systems, coding practices, etc.
I looked into contributing to the kernel - it's already an uphill battle to understand such a large, complex piece of software written almost entirely in C - but then you also need to subscribe to busy mailing lists and contribute code via email, something I've never done at 30 and I'm betting most of the younger generation doesn't even know is possible. I know it "works" but I'm really doubting it's the most efficient way to be doing things in 2024 - there's a reason so many infrastructure tools have been developed over the years.
The barriers to entry for a lot of projects is way too high, and IMO a lot of existing "grey" maintainers, somewhat understandably, have no interest in changing their processes after so much time. But if you make it too hard to contribute, no one will bother.
I'm surprised by Helldiver's. Has there been some performance patches? I tried playing that on my deck near launch and it really struggled even at minimum settings - I can't imagine how it would run at higher difficulties.
Really incredible that the thrusters still function at all after all this time - and that it has any fuel left / usable fuel after all this time.