Only if they make use of the same version of electron. Also apps tend to statically link their libs nowadays to reduce the amount of runtime dependencies from what I've seen. And I'm pretty sure apps distributed through flatpak and the like come with their own copy of the corresponding .so and won't share anything either - unless I'm wrong and electron does get shipped in a shared runtime.
I understood it as them turning down an offer despite the lucrative salary, not because of it. Probably because the circumstances were not quite what they were hoping for.
Considering Meta presumably wouldn't be able to advertise alternative sources for downloading their app inside the app store (which is also the case on the play store) I simply can't imagine them or any of the other big developers doing so. Removing their app from the app store would completely annihilate discoverability and would likely lead to either some third party app taking their spot.
Also I can already imagine Apple throwing a bunch of scary warning popups at the user, requiring them to enable this and that in the settings and likely also not allowing to update an app originally installed through the app store using an app file downloaded from another source to make it even more tedious - requiring a reinstall of the app in that case. Can't imagine many users would be willing to go through that chore.
I may be wrong but considering we haven't seen any similar behavior on a significant scale on the play store I just don't see that as an eventual issue - especially considering Android makes installing apps from other sources very easy, necessiting only clicking on a button in a popup and toggling a switch to allow sideloading from within a specific app and even allowing you to update an existing app installed through the play store that way given that the signatures of both match.
I think developers will still be heavily incentivized to either change the behavior of their app or worst case attempt to sue Apple to force them to allow that specific behavior on the app store before moving their app outside the app store will even cross their mind.
There is a shortage of primary driver-ready mobile computing devices which respect the user's privacy. The choices here are Android devices with custom ROMs + microG and daily prayers that Google doesn't go out of their way to break it (which they can very well do since it breaks ToS) or go nuts with SafetyNet or hardware attestation features and lock you out of a lot of (crucial) apps - or worst case just nuke your account if they detect you use such programs. Or alternatively iPhones.
I'm unsure why side loading would break the dynamics of their walled garden either. All that does is give both customers and developers the choice of forfeiting the benefits like discoverability, comfort and likely a bunch of App Store-exclusive APIs like IAPs and in return allow access in cases where Apple doesn't approve. I can already guarantee that most developers won't budge an inch from the App Store as the lack of discoverability and the annoyance of downloading an app file and clicking through Apple's warning popups just to install it would effectively kill their app.
> And no sandboxing isn’t the solution here. Facebook will just find ways around it. They did some pretty egregious bullshit and had consumers side-loading privacy-violating apps via their corporate account. Apple very publicly revoked their certificate for it. Without the walled garden, Apple would have no leverage to stop bad actors like Facebook.
Apple could still explictly disallow that behavior on the app store and also disallow them from linking to another source directly from the app, just like on the Play store. Meta could be free to live their desires outside the app store (inside the existing app sandbox obviously) and take the hit on discoverability and willingness from users to budge.
(Obviously not but OP's argument is moot anyways as waterproofing and a replaceable battery are not mutually exclusive, we already had phones and other devices with both)
Not everyone does everything with the expectation of seeing their bank account inflated in return. Sometimes people work on things just for the gist of it and I always appreciate seeing something driven solely by legitimate enthusism. :)
Not sure I understand. Zram allows you to store pages in a compressed fashion to memory to prevent or at least delay until the OOM kicks in and to keep hold of cached files for longer to prevent needless disk reads. Considering the tradeoff is a marginal amount of CPU resources it seems like free extra space and a no-brainer to enable if swap on disk isn't desired, at least in my mind.
I remember having issues with system starvation if it started to make excessive use of zram but that has been pretty much levitated with the introduction of MGLRU.
Hmm, as I've seen topics like this[1] for EAC, though a comment from a different result[2] mentions EAC can be configured to optionally block VMs so maybe it varies by game.
> Today, I purchased and installed Dead by Daylight with the intention of playing with some friends, only to start the game and find a message from Easy Anti-Cheat stating that the game "cannot run under a virtual machine."
You are right. I've heard similar stories about BattlEye in the past which I assumed might just have been a decision they've reverted since but could've very well been an option up to game devs to enable. Thankfully not many of them do seemingly.
The fact that we have normalized that behavior to the point of having to explain the concept of not wanting to give out data like candy is so wild to me
