color management is actually super hard to do, so making sure it's done right is very important, so this is one of the few times it actually makes sense. I mean, just take a look at windows, it still looks like shit over there.

I disagree, making your own packages is nice, but it's not like it's needed. I know multiple people who don't touch the AUR or custom pkgbuilds at all

Note that in oars git repo itself a lot of tags were removed because of idiots calling it "problematic" https://github.com/hughsie/oars/commit/bbb10186cbecb49252610e5604ed025df8f4c8b7

the actual gitrepo explained why it's neccessary, not wanted

* `sex-homosexuality`: As of 2020,
   [various countries](https://www.humandignitytrust.org/lgbt-the-law/map-of-criminalisation/)
   have laws which criminalise lesbian, gay, bisexual or transgender (LGBT)
   people. In order for software and content to be distributed in those
   countries without breaking the law, and possible reprisal, it is necessary to
   be able to tag software and content which contains LGBT references, so that
   it can be hidden in those countries.
   However, in other countries (for example, the EU), discrimination laws
   explicitly prohibit discrimination on the basis of gender or sexuality. So
   while LGBT tagging may be available in OARS data, consumers of that data must
   only apply it in countries where the law requires that.

I find that fair, but at the same time, proton has a rocksolid history at this point. OFC they will likely add their features to it, and maybe remove some. But im the end its still open source and under gpl licence, so its not like proton cam change that unless they remove all other commits.

I hate that I just read the words " back in the day" in the context of chromebooks. this feels too new for me xD

I agree with a lot of the points LTT had, I was pretty excited for this video when I saw it. But the response was just complaing and excuses instead of just being nice and simple "here's the issue you had, We can either fix it, or can't for these reasons..."

for me it's been a lot better, I currently run arch without any issues (other then wine but thats because I never bothered to config it right when I setup bottles)

this is a wayland issue. Due to how wayland works, it cannot drop messages, this means if the messages stop being accepted (IE. the program becomes very slow and not very responsive) the application will wind up dying. EEVDF helped resolve a lot of these issues. but they arent gone yet.

a fairly easy replication cause is to start a large rust project compile since cargo will thread to oblivion if it gets the chance, then use the PC on wayland. Applications can frequently die, Firefox, MPV, Kate, gnome web, chromium, games, etc. it also doesn't matter what compositor you use right now as gnome, kde sway all share the issue

EEVDF really does help stop a lot of these crashing though

Keep in mind that other reputable repos like izzyondroid still work, fdroid is more then one thing. We wont loose the apps, nor the 3rd party repos, the only thing really "at risk" here is the official fdroid repos.

this isn't like some closed source stuff, the entire fdroid ecosystem is fully foss so anyone can sweep in at any time and do their own thing while still being mostly or completely compatible

Love his content, he is quite entertaining, even when just doing a cooking video, has some good takes and some bad takes but who doesnt at this point.

not sure how relevant these may or may not be, but there are some client device implementations

EDIT: paste didnt work https://github.com/openairplay/open-airplay

Ldac is not actually that good, it's actually fairly rare that LDAC beats out something like SBC XQ let alone AAC

EDIT: for elaboration, LDAC works at 3 main data rate ranges 990/909, 660/606 and 330/303. Ldac is only high res at the 990 range, and even at that range, it still often looses when pipewire is compiled against libfdk. keep in mind that it's hard to get real numbers on LDAC because decoding is proprietary, meaning I had to disassemble headphones and connect those for verification, but typically AAC on supported headphones beat out 990kbps LDAC (which is hilarious btw considering LDAC can rarely actually work at 990kbps anyways) and both SBC-XQ and LC3Plus (both of which are usable with pipewire) regularly beat 660kbps LDAC.

TLDR LDAC is crap and SBC-XQ is typically more accurate and lower latency, and LC3Plus is even better then that. and if you have AAC compatible headphones assuming latency isnt a major issue (which you are using LDAC so it's not) just use AAC, both fidelity and latency is better

EDIT: I should mention, it is known that vendors will tune codecs, I believe Valdikks article in habr briefly goes over this. so it's very possible that tuning could mean that x codec, including LDAC could be the only good codec, however with how badly LDAC maintains 990kbps, I doubt it will make much of a difference