←back to thread

OpenGL 3.1 on Asahi Linux

(asahilinux.org)
512 points simjue | 1 comments | | HN request time: 0s | source
Show context
zamadatix ◴[] No.36213299[source]
From a follow up post on Mastadon https://social.treehouse.systems/@AsahiLinux/110497512340479...:

"Also in this update:

We now have a cpuidle driver, which significantly lowers idle power consumption by enabling deep CPU sleep. You should also get better battery runtime both idle and during sleep, especially on M1 Pro/Max machines.

Thanks to the cpuidle driver, s2idle now works properly, which should fix timekeeping issues causing journald to crash.

Also thanks to the cpuidle driver, CPU boost states are now enabled for single- and low-threaded workloads, noticeably increasing single-core performance.

Thermal throttling is now enabled, which should keep thermals in check on fanless (Air) models. There was never a risk of overheating (as there are hard cutoffs), but the behavior should now more closely match how macOS works, and avoid things getting too toasty on your lap.

Random touchpad instability woes should now finally be gone, thanks to bugfixes in both the M1 (SPI) and M2 (MTP) touchpad drivers.

A bugfix to the audio subsystem that fixes stability issues with the headphone jack codec.

New firmware-based battery charge control, which offers fixed a 75%/80% threshold setting. To use this, you need to update your system firmware to at least version 13.0, which you can do by simply updating your macOS partition to at least that version or newer. This new charge control method also works in sleep mode.

U-Boot now supports the Type A USB ports (and non-TB ports on the iMac), so you can use a keyboard connected to any port to control your bootloader.

And last but not least, this kernel release includes base support for the M2 Pro/Max/Ultra SoCs! We are not enabling installs on these machines yet as we still have some loose ends to tie, but you can expect to see support for this year's new hardware soon."

replies(6): >>36213477 #>>36214241 #>>36215165 #>>36216598 #>>36217305 #>>36226845 #
brohee ◴[] No.36226845[source]
Another follow up on Mastodon is about the ban evasion that HN does specifically for Asahi. https://social.treehouse.systems/@marcan/110503050993279759

I find it pretty tasteless for HN to do that.

replies(2): >>36226946 #>>36234860 #
e40 ◴[] No.36226946[source]
It’s a little hard to understand what is going on. Can you explain? Thanks.
replies(1): >>36227103 #
pyrox ◴[] No.36227103[source]
Asahi Linux's site previously redirected any site with the Referer header set to 'news.ycombinator.com' to google.com. They did this because they believe that Hacker News' community fosters a hostile environment, and thus it was blocked. Setting `rel=noreferrer` on an `a` tag means that the browser will not submit this header, thus meaning this sort of redirect will not occur. Also(as per Marcan's Mastodon account), this rel tag has only been added to asahilinux.org links, not any other links on HN. This means that the moderators of HN believe that the commentary that has in the past been quite misinformative should be allowed, and they are deciding to bypass the block that was put in place by the Asahi team. Now, as per https://social.treehouse.systems/@marcan/110503331622393719 , they're adding an HTML header to anyone who has submitted a post to HN(or has the submit page in their history), as they have no other way of doing anything, as they no longer have the Referer header.
replies(2): >>36227457 #>>36228230 #
101011 ◴[] No.36227457[source]
This raises interesting moral questions that I'm not sure I have an answer to.

For one, I don't believe this place fosters a hostile environment, although it's definitely a place where people love to tell you how you're technically wrong about something.

For another, I would guess that there are a very limited number of websites that would opt into this sort of anti-traffic behavior. Hacker news could certainly choose to honor it, but it also feels within their right to bypass the block.

I wonder if there's a sort of middle ground, where HN alerts the user of the redirect that would have occurred, but still shoots the user to the desired location.

But now you're getting into user flows and begging the question as to why the redirect is there in the first place.

I'd love to know more about the perceived hostility, even reading up on Mastodon left me with more questions than answers.

replies(3): >>36228274 #>>36229753 #>>36234392 #
sussmannbaka ◴[] No.36228274[source]
there is constant transphobia against Asahi contributors on display on this site. Every single article that gets to the frontpage will have dozens of vile posts in the deads and a couple sprinkled inbetween. I’m not sure if HN staff doesn’t care about it, agrees with them or simply isn’t aware.

It’s not limited to the Asahi project, either. The site isn’t safe for queer folks.

replies(9): >>36228979 #>>36229227 #>>36229505 #>>36229527 #>>36232562 #>>36234840 #>>36234984 #>>36235902 #>>36238916 #
1. arp242 ◴[] No.36238916[source]
> vile posts in the deads and a couple sprinkled inbetween. I’m not sure if HN staff doesn’t care about it, agrees with them or simply isn’t aware.

So basically you're judging a community by the posts the community and moderators deemed inappropriate and moderated away? Rather curious metric.

If you don't want to see dead posts then turn showdead off (which is the default). That you get some transparency in the moderation is a feature, IMHO, but it's also opt-in.

Maybe there should be a "verydead" for these kind of outright idiotic posts so they just won't display at all for anyone, but then how do you prevent abuse and keep the mod workload reasonable marking endless posts as "verydead"?