Have to agree with this. Not saying the check should be there, but the majority of non-mobile/server ARM devices are generally underpowered, especially with per-core performance.

Hmmm, serving low resolution videos to ARM devices running Linux also makes harder for a competitor to build an alternative to Android.

True, but any competing operating system could just falsely report that it is running x86-64 and therefore trick YouTube into serving high-res content.

Disclosure: currently (as a personal project) slowly building an alternative to Android

Can you share it?

At the same time Chromium is not affected:

> Why does this not affect Chromium? Because chromium on aarch64 pretends to be x86_64

Could it not tell if it's actually managing to play and keep up with time? Similarly to how (I believe) it'll degrade if the network is such that it's not loading 4k say quickly enough, it'll switch (if 'auto') to 1080p or whatever.

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

> Could it not tell if it's actually managing to play and keep up with time? Similarly to how (I believe) it'll degrade if the network is such that it's not loading 4k say quickly enough, it'll switch (if 'auto') to 1080p or whatever.

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.

The test can be during the advert before the video that you want to watch.

Worse than stuttering if it's the network? Anyway, it could go up.

They already check the core count via the hardwareConcurrency API[1], check the second screenshot.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/h...

Figuring out good defaults for this is really hard. In general, "Linux + aarch64 = lower performance = let's do lower resolution by default" seems like a reasonable thing, although not fool-proof obviously. Also note that the "is_arm()" is followed by "|| is_android()"-bit in his screenshot.

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.

>Figuring out good defaults for this is really hard.

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.

And the primary targets for that are probably ARM Chromebooks which tend to be underpowered by quite a bit.

(I'm guessing those report aarch64 correctly.)

Well, that and also when you set "Desktop site" in mobile Chromium it will report a user-agent which matches that of desktop Linux on ARM. So it is most likely trying to target those devices as well.

> It's pretty arrogant to assume Google is intentionally targetting them specifically.

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.

I see you've met marcan :)

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.

> corporation, I would almost require that anyone using Asahi on their Mac

Any corp worth their salt issues standard locked down machines, not letting employees install whatever they want, especially as an OS.

You are assuming incorrectly. The bug report linked in the thread the user filed with Mozilla indicates that 4K resolution isn’t available even though once he changes the user agent string it was and it worked without issue.

Yes I prefer to find the actual facts in a situation and pick sides (if at all) in that situation based on those facts not a predetermined "corporation bad, billionaire bad". Criticism loses all meaning if not based on fact and actually hurts the cause because then even meaningful criticism can be dismissed as baseless.

Gotta be fair about it. There's plenty of reasons to hate Google but this doesn't seem like one of them.

That sounds reasonable but it's weird that Chrome lies by pretending to be x86_64. The same performance concerns that apply to Firefox should apply to it.

they keep serving me 380p by default that I have to change and I've got a gigabit fiber with a modern ryzen and a monster gpu running the latest windows. So whatever they are doing auto quality wise has some screws loose.

If you want to know the media decoding capabilities of a Web Browser, you can use the MediaCapabilities API. In Firefox, when flipping the "resist fingerprinting" flag, it's spoofed appropriately based on a study of what the most common results are. This is available on all engines, desktop and mobile.

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

Drives me crazy how regressive Apple is with computing. While it seemed to shake out that GPU AI was the only real solution, earlier this year people were(and still are) putting resources into CPU based.

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.

simping for google in order to "own" apple fanboys is just an embarassing position for an adult.

According to the followup toot, Youtube seems to assume Firefox + Linux + aarch64 = HiSense 65a67gevs. This was reported elsewhere too: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+... ; that issue was then forwarded to Chrome's bugtracker (https://bugs.chromium.org/p/chromium/issues/detail?id=150011...) which was closed with the comment "I'm hopeful they'll eventually get around to fixing the bug that you've reported".

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

> So they are serving lower resolutions to ARM... Doesn't sound like deliberately crippling Asahi Macs to me.

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.

Virtually all arm devices do GPU decoding they kind of have to.

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.

Eh, there's pretty famous examples that don't.

For instance, the RPi5 cut out the H.264 decoders versus previous gens, and now only do H.265 decoding in hardware.

They don’t need to detect the number of cores, although hardwareConcurrency is right there, but rather simply to ask the browser what it supports:

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.