For sure, but these days the main offenders are online multiplayer games with restrictive anti-cheats.
I would go so far as to say if those specific types of games are not your thing you aren't likely to experience any issues gaming on Linux.
I'm sure there are exceptions, but every time I think "oh this game for sure won't work" I have eaten my words.
And it's like a night and day difference from the last time I tried to do this about a year and a half ago. The progress I've seen is almost more impressive than the performance gains. π€·
And from what I've looked through so far of the pypush code it seems pretty legit.
IMessage being only for iPhones is officially over.
This isn't something Apple can just block or patch without also affecting every iPhone that doesn't download the patch update beforehand. Any device that isn't patched in advance will also lose access to iMessage.
It's actually quite impressive how it is done and it's truly innovative.
It's very much a significant step forward compared to the implementations we have seen before.
Here's a simple picture with minimal reading required.
This is very different to the technology used in the free/wait-list Beeper Cloud app and all the other previous attempts at an iMessage for Android app.
To summarize:
All messages are sent directly between your device and Apple's servers. You do not even need an AppleID. There is a cloud server involved but it's only job is to send push notifications to Android so they app knows when to download new messages (securely with iMessage encryption) from Apple's servers.
No message contents are sent through the cloud server, it just notifies your device when there are new messages. This is necessary because Apple servers obviously do not support Android push notifications.
All messages/etc are sent using iMessage encryption directly between your phone and Apple's iMessage servers.
But there is no Android push notifications from Apple's servers.
So in order to be notified about new messages in a timely manner without killing your battery/data plan a cloud server is required to trigger your phone that a message has arrived so your phone can then request the message from Apple's servers.
This is actually a really common implementation, many apps use Firebase or similar to handle push notifications that are only used to trigger a "pull" of a larger chunk of data.
The push notifications being used here don't contain any private data, they just tell your device when to collect that private data securely.
Having recently switched myself I actually have experienced less issues and better game performance from Linux than I did on Windows, at least with the games I play and the hardware I have.
Notice how in the article they say "we're not the middle man... Any more"? That's because, up until now, Beeper has been working on a system where they operate as a middle man for your data.
To be fair they never claimed otherwise and all of the code for the bridges are open-sourced and can be run on your own servers so that those servers you control (as opposed to Beeper-owned servers) act as a "middle man" and none of your messages need be trusted to a 3rd party.
To put it simply: only the actual bridge on Beeper Cloud has access to unencrypted messages and you do have the option to run the bridge yourself while continuing to use the Beeper app. You can use as many or as few self-hosted bridges as you'd like.
No, with this new app messages are encrypted between you and Apple's iMessage servers using iMessage encryption more or less the same way an iPhone does.
The push service simply notifies your device it has a message waiting, no message content passes through Beeper servers.
A modern Pixel phone could probably run the AI models locally but they would likely be more limited and it wouldn't be particularly battery-friendly.
An old iPod touch wouldn't be able to so I think it's safe to assume those functions were happening on Apple's servers.
In fact I would be confident claiming that no mobile devices are currently running these models locally, whether you are using Google, Apple, or some other photo app.
Like I said, it may be possible for some modern devices with TPU chips to run them locally but that is not happening currently and would probably not be as good as experience if they were
This is exactly why I was motivated to start using Immich instead. Using any of these corporate services you are giving away your privacy for convenience.
No, this stuff actually requires somewhat heavy ML processing that most phones probably couldn't do locally.
I think many people don't consider or overlook the fact that by "necessity" we allow companies like Google/Apple/Facebook full access to our photo libraries for the convenience of these features.
If you have the technical skill to I highly recommend trying out immich. It has all those features you are looking for: face matching, memories, photo maps, object recognition, etc. but those models are run locally (on your self-hosted server) instead of depending on Google/etc so your privacy is protected.
But at least for my personal experience the kinds of issues I encounter gaming on Linux are typically less frustrating than the ones I encountered gaming in Windows.
To pretend that either experience is pain-free would be dishonest but I've had less difficulties since switching fully to Linux and actually seen a noticeable improvement in performance on many games as well.
I think in reality if stability and never having to "fix" issues or bugs is your biggest concern you are probably more suited to console gaming
Might want to make an install script and/or define some dependencies.
Edit:
Once I gave it pygame it works fine on Python 3.11.5
Edit Edit:
I noticed that if you select "open folder" and then cancel out it throws an error in the console. You might want to add some error catching in there as well for scenarios like that.
I am big into self-hosting and would be happy to run my own Headscale server (I have actually) but imo it's not worth the effort.
It can be done but it requires a lot of effort and consideration to ensure the relays and routing work for when your clients are in challenging NAT scenarios. And the user experience is not as good.
Instead what I do is continue to use Tailscale but I use the Tailnet Lock feature to give signing authority to my own specified devices so any new devices must be signed off by one of those other devices.
This effectively eliminates the last point of trust where you had to trust tailscale's servers to manage authorization. The result is you don't have to worry about trusting tailscale at all, the entire system is zero trust.
The catch is if you lose those devices and the recovery keys you lose the ability to trust or add to your tailnet and your only real option is to delete all the devices and start fresh.
They also have the option to send a recovery key to their servers when you enable Tailnet Lock so support can rescue you in that scenario, but I think if you are using this feature on the first place it's because you don't want to do that so I imagine most choose not to lol
I linked to their blog post above because I think it explains the feature well. If you just want the docs they are here
Check out my reply
I posted some links that get into the details of how the tech works