Detecting if the device has 20 cores or whatever like he says if possible would be more invasive of privacy. They would be criticized for that too. There's just no winning lol
Asahi Linux is a comparatively small project with few real users. It's pretty arrogant to assume Google is intentionally targetting them specifically.
If anything, the bug here is that Chromium uses x86 on arm systems, although for Asahi specifically that's probably the right choice, it's a lot less clear to me that's the right choice for all systems.
(I'm guessing those report aarch64 correctly.)
The Asahi Linux developers have a history of taking everything personally. If Apple adds a new way to start an ELF in macOS 12.3, it's because of them. If someone criticizes them publicly on Hacker News and isn't immediately shamed, it's because the actual leadership at Hacker News hates them (not an exaggeration considering their public stunt here where they blamed @dang for everything). If someone doesn't quite agree with their politics in perfect lockstep, they will publicly try to force you to resign (look at what happened with Dlang). And, more recently, threatening to keep changes downstream and out of the mainline Linux kernel as retaliation for what they call inappropriate conduct (which, well, if the COC of Linux hasn't been violated, I'm guessing it's probably them). And of course, if it's found out that the M2 has a technical bug with audio processing that literally nobody noticed until now, it's proof that Apple is full of incompetent idiots, unlike them.
It's also why, if I were running a corporation, I would almost require that anyone using Asahi on their Mac use a corporate fork for their own protection. I wouldn't rule out retaliation.
Any corp worth their salt issues standard locked down machines, not letting employees install whatever they want, especially as an OS.
He's a hotheaded spaniard who happens to live up to the stereotype perfectly. Except the part where he doesn't live in Spain anymore.
Very talented hacker. Best to watch from the back seats and enjoy the drama without getting any on yourself.
Just in general it's hard... for many things I find. There's perpetually a bunch of seemingly reasonable "yeah but" for almost every default once you hit a certain number of variables / use cases / differing users / customers and etc.
It sounds less like "let's help the poor Raspberry Pi users" or "let's make Asahi's experience worse" and more like "workaround for a buggy TV that nobody bothered to implement correctly".
Depending on the implementation, what it returns can be based on the presence of optimized software decoders for a platform, presence of hardware, resolution and other characteristics of the video, it can also be based on a decoding benchmark that the web browser runs, etc.
https://w3c.github.io/media-capabilities/
https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab...
> Why does this not affect Chromium? Because chromium on aarch64 pretends to be x86_64
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/h...
> Detecting if the device has 20 cores or whatever like he says if possible would be more invasive of privacy.
What he claims though is that they do already do that at least if it's not aarch64:
> Quality 1080 by default. If your machine has 2 or fewer cores, quality 480. If anything ARM, quality 240.
Probably, but it's pretty poor UX if videos start super-choppy by default and slowly downscale to a playable resolution over several seconds. Having a good default is still important.
https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab...
That way you can fall back for anything too old or weird to support that API, and if the vendor complains there’s a simple response: implement the standard.
This was a well understood problem in the 80s if two sides need to establish a commonality one offers options and the other picks. Google controls both YouTubers and the most common browser making it uniquely positioned to handle this well.
For instance, the RPi5 cut out the H.264 decoders versus previous gens, and now only do H.265 decoding in hardware.
If spoofing the user agent fixes the issue despite being on ARM, then this does sound like a legitimate issue.
> Chrome is not affected even if it claims to be aarch64.
Disclosure: currently (as a personal project) slowly building an alternative to Android
I can't imagine someone @-ing me because when they were 18 years old and status insecure, someone sold them a corporate identity and feel entitled to maintain their edge case.
I need to stop giving away my stuff for free.