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

To not force every user to build (potentially all) derivations which is very time consuming, especially considering the way Nix derivations work which requires a rebuild each time a dependency changes in any way meaning something like a glibc update results in a recompile / redownload of the entire userspace.

So it's not a necessity per se but constantly rebuilding a significant amount of packages would easily turn the majority of users away. I'm not sure how many Nixpkgs revisions the Hydra build server keeps hold of or if they even clean up older revisions at all - perhaps it might be time to start doing so at this point. That would be an issue for ancient Nixpkgs revisions which point to broken urls though as the archival of sources is out of the scope for the NixOS infrastructure. Nix is only concerned about the state of a given source using checksums, not the availability itself. So in that sense "full source reproducibility" is only a guarantee that the input doesn't differ (and optimally should result in the same output bit-for-bit which is a completely different beast and something that is being tackled not only by NixOS but by several other distros). It's not a guarantee for "I will be able to grab this Nix derivation in 30 years and be able to get an output out of it" unless you have a mirror of the original sources.

Which I'm glad has been the case here since it results in the most stable and trouble-free Linux distro and package manager I have ever used. Complete with full source reproducibility for everyone to top it off. It'd be hard to convince me to switch back to a traditional distro at this point.

> I joined a gym 4 years ago, and a lot of my friends now I've met through that gym.

Is it common for strangers to actually approach each other in the gym? At least here everyone goes from machine to machine listening to music and making as little contact as possible and the few times I've been approached was just to ask how many sets I have left. I've been surprised just how much that seems to differ from place to place.

They're currently on sale for a few bucks on Steam too.

Not particularly easy when they're the only ones who have even the slightest bit of respect for the privacy of their users in the mobile market. The other choices that come to my mind are either:

- Normal Google Android, which is just spyware

- Android but without any GApps, which barely runs anything relevant

- Android with either MicroG / sandboxed Play Services, which AFAIK breaks Google's ToS and is at the mercy of them not breaking those

- GNU/Linux phones, which I can not in good conscience call primary daily-driver ready

- Dumb phones I guess?

Doesn't leave us with many options. At this point it's choosing the lesser of two evils.

Also /usr/bin/env bash is required on NixOS and Guix, neither of which have /bin/bash.

The entire point is that yes, all of them are doing it and Apple isn't this golden savior among them that some make them out to be. They trump everyone else in certain aspects like longevity of software updates and privacy, doesn't mean they don't partake in costumer-hostile actions nor does it mean we should excuse those.

Considering Valve's track record with the Index and its build quality issues I'm not sure I fully trust them to build something that's lasting either. It's only been a year, guess I will see if my Deck spontaneously falls apart eventually.

I was not aware this was the case, TIL!

It's what allowed me to make the jump to NixOS without having to give up much - every userspace program that isn't packaged up or has quirks along with anything gaming related where I consistently want the newest and greatest runs inside an Arch distrobox container. Can highly recommend!

Also it's actually only a 15% cut for the vast majority of developers. Shouldn't matter either way once Apple is forced to allow sideloading.

I wish. I will certainly do my part the next time I consider buying a printer but it's been shown again and again that the vast majority of people will always put comfort (and productivity) over ideology. I don't expect any meaningful loss of sales on their part from this.

The issue is that also disables many of the interesting features of BTRFS for those files. No checksumming, no snapshots and no compression. In comparison ZFS handles these features just fine for those kinds of files without the enormous performance / fragmentation issues of BTRFS (without nodatacow).

Block cloning support has indeed recently landed in git and already allows for reflinks under FreeBSD. Still has to be wired up for Linux though.

> It’s not opt-in, it’s the default.

I meant Screen Time which lets you disable in-app purchases for children, not authentification which just requires you to enter your password for validation against accidental purchases. That was a mistake from my part.

> What people do with their money is none of your business.

Sure it isn't but what exactly is it that makes the App Store especially protective of users then in comparison to the competition? Play Store also gives the same controls and the same premise of guarding users from malware - which does still slip through, don't get me wrong, but so does it on the App Store - without having to block sideloading. Apple is fine with psychological mechanics designed to get particularly children to dump money into a game over and over as long as the developers paid their cut to them - which as you mentioned is fine in the context of individual responsibility, but it really does not scream "protective" to me. At that point why not give me freedom to install apps from wherever I'd like?

> The reason Epic got fined was because people whose credit cards were saved and charged didn’t consent to the purchases and Epic refused to refund even when their virtual currency wasn’t used, or they locked out the accounts entirely when the transactions were charged back.

Yes and never have I defended that. I am very glad they got zapped for that. I am simply against the idea that any corporation is a trustworthy guardian angel which only has the customers' best interests in mind. Any of the tech giants are more than happy to employ anti-competitive and customer-unfriendly tactics in the name of profit and siding with either one because of favoritism or holding a grudge against the one instead of on a rational case-by-case basis is just silly.