_piif

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.

Yes, they should.

(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.

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 common ones such as EAC, BattlEye and VAC don't prevent you from running the corresponding games in a VM.

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

I agree. It's hard for me to get excited about anything tech companies output nowadays as more than likely it will be surveillance, ad, upsell and subscription-driven with growth and profits triumphing any regards and respect for the end-user experience and privacy. I have zero reason to trust them not to abuse my health data for their own interests rather than use it for the greater good.

> But Apple does ship powerful GPUs. In fact, the M2 Max is probably the most or second most powerful GPU on laptops. But games aren't optimized for Metal nor ARM, so they run slower than Nvidia laptop GPUs.

The most powerful iGPU likely. It still won't come anywhere close to high-end dedicated laptop GPUs in the vast majority of benchmarks regardless of how much optimization you throw at it - that's just falling for marketing / hype.

There is a pretty big gap between only letting children play games all day and allowing them to participate in high risk labour unsupervised and without special protections.

The nix store in of itself should be highly compressible. Here's the output of "compsize -x /nix/store" on my BTRFS root with compress-force=zstd:6

  Processed 974464 files, 327323 regular extents (751261 refs), 598287 inline.
  Type       Perc     Disk Usage   Uncompressed Referenced  
  TOTAL       40%       11G          28G          60G       
  none       100%      2.7G         2.7G         6.2G       
  zstd        34%      8.9G          25G          54G

Nix also supports automatic deduplication using hardlinks which I have enabled in this case.