Hacker Newsnew | past | comments | ask | show | jobs | submit | imcritic's commentslogin

What answer to that question and in this situation would make any sense?

The motivation/justification from the author why they believe removing lisp but adding Electron somehow sums up to being "lightweight"?

Maybe the author thought of the UX/baggage/legacy or something else when they thought about "lightweight", rather than how much memory/cpu cycles something is using? Not sure, but maybe there is a more charitable reading of it out there.


Probably none. Still I’m curious what is the authors understanding. Whether he actually thinks it is a lightweight solution or whether that’s kind of advertising phrase, like ‘blazingly fast’

I believe it's called a rhetorical question.

None, just another Electron hater.

HCLK mode needs some knob to control intensity of the effect.

Is it working so slow (like 0.5-1 fps) only for me or is this intended?

Also, you mention video, how to switch to video from photo?

Other than that - that's pretty fun, just like others I love that everything is local on client.


How about they start supporting more devices instead?

You should probably be asking Android OEMs why the requirements listed here https://grapheneos.org/faq#future-devices are unreasonable.

There are currently no other devices meeting the update and security requirements. GrapheneOS is partnered with a major Android OEM working on making devices meeting all of those requirements along with providing official GrapheneOS support. The devices are planned for 2027 but is being announced by the OEM in March 2026 so people will know which OEM it is soon.

Good news they are making their own devices. But until then pixels are technically the most secure android devices and graphene would not be as robust on other devices.

Small correction, GrapheneOS are not making them. They are partnering with an existing large OEM to ensure one or a number of future flagship devices meets their security, privacy and support requirements.

No, there are no such news yet, only hearsay.

It has been officially stated that GrapheneOS is partnered with a major Android OEM working on making devices meeting all of those requirements along with providing official GrapheneOS support. The devices are planned for 2027 but is being announced by the OEM in March 2026 so people will know which OEM it is soon.

Asahi project looks barely alive, almost abandoned. I know that their explanation of low activity is that they are being active elsewhere, supposedly pushing all their work upstream, but this has been happening for months and they don't give any reports about their progress, so I'm worried it will all die soon. And given that the project barely brought some Linux compatibility for m1 and m2 hardware and no prospects for bringing similar compatibility for newer generations - I fear it all will be kinda useless in the end.

> this has been happening for months and they don't give any reports about their progress

This seems a bit exaggerated, their latest progress report is barely two months old: https://asahilinux.org/2025/12/progress-report-6-18/

They inarguably have slowed down, but this should be expected as the project matures. It has also inevitably now faced the time when new generations of contributors are needed as existing ones retire/ move to other projects.


>as the project matures

How can it be mature if it can't even boot on newer MacBooks. The slowness does not seem to be due to running out of impactful work that needs to be done.


The new leadership team blogged last year that their priority would be on upstreaming their existing work.

> Our priority is kernel upstreaming. Our downstream Linux tree contains over 1000 patches required for Apple Silicon that are not yet in upstream Linux. The upstream kernel moves fast, requiring us to constantly rebase our changes on top of upstream while battling merge conflicts and regressions. Janne, Neal, and marcan have rebased our tree for years, but it is laborious with so many patches. Before adding more, we need to reduce our patch stack to remain sustainable long-term...

Where do the M3 and M4 fit in? Until upstreaming and CI progress, the core team cannot prioritize new hardware.

https://asahilinux.org/2025/02/passing-the-torch/

I think the majority of that upstreaming work (that isn't on hold until the kernal is ready for the Rust graphics driver to land) has happened and additional features like DP alt mode for USB C have been demoed.

The next update from the team should land on their blog after 6.19 ships


That's some weird gatekeeping. The hardware they do support is supported well.

Activity has died down as a result of general Linux kernel developer drama, petty in-fighting, and other factors, but that doesn't change the results they did produce during their most prolific phase so far.

Without proper support from upstream like AMD, Intel, and Qualcomm (to some extent) are doing, Linux will never work as well on Apple's hardware as it does on normal hardware.


Wasn't it just a couple of weeks ago that they started supporting M3? That smells like progress to me.

One can start working on creation of a teleportation device. Doesn't mean we have it.

https://asahilinux.org/docs/platform/feature-support/m3/

What do you see as progress here? Nothing is supported, everything is "to be announced" (i.e. unsupported).


they likely meant this progress post showing a desktop booting on an M3 mac: https://www.reddit.com/r/AsahiLinux/comments/1qnddjd/m3_now_... albeit with software graphics

Looks believable that they are indeed the devs behind the project, but it's weird to post stuff like that to... reddit? They have a site for the project, why not post there?

You could read the updates... https://asahilinux.org/2025/10/progress-report-6-17/

Not marketing a not yet complete feature on their website makes total sense. People on internet hating Asahi linux just cause seems like weird to me.


Similarly, if you place enough cars near each other - you can start jumping over one and then just float around those cars indefinitely without ever touching ground and risking off getting arrested.

However, if cops or anyone else start shooting at cars - they will eventually explode and thus get you WASTED.


It's chinky and not opensource.


After reading the header - I had a glimmer of hope.


I love articles like this and companies with this kind of openness. Mad respect to them for this article and for sharing software solutions!


Since when does cooling get measured in watts?


It's the SI unit, what else do you want to use lol?

Americans measure it in bald eagle wing flaps per football fields but that's just an American thing


> It's the SI unit, what else do you want to use lol?

HVAC companies in the US exclusively use ‘tons’ to describe the amount of heat a chiller or heat pump can move. Trane, Daikin, and more all use ‘tons’ on both their marketing and engineering material.

1 ton ~= 3.56kW, but a 1-ton chiller will use ~= 1kW of electricity to remove 3.56kW of heat due to the COP of 3-4 for an air cooled chiller.

Daikin Chillers: https://www.daikinapplied.com/products/chiller-products

Trane Chillers: https://www.trane.com/commercial/north-america/us/en/product...


That's really not appropriate for the topic at hand. And what happens when the technology improves and the 1 kW ~= 3.65 kW relation changes?


The COP isn't constant either. I can drop to 1:1 or even lower if you need to run the anti frost resistance

Good marketing gimmick though


Since every cooler review took payola to pump bogus performance charts so they never settled on scientific measurements.

For those wondering, the standard measure is thermal resistance in degrees per watt, for linear systems - doubling the heat that needs to be transferred doubles the temperature difference between the sides. Adding in heat pipes, liquid convection, etc is going to make the system non-linear, so then it makes sense to talk in terms of the delta-T at given wattages. And then since there are phase-change materials, the working temperature should be specified as well. Yes, there are three scalars before you even get to things like scaling fan speed.

(I'm not a mechE so I'm sure there's something I'm missing still)


But/hr is convertible to watts. It's how much energy per hour gets removed from the space.


Shouldn't small trivial changes be easier to review (and thus maybe even have higher prio)?


If there is a single maintainer of the project, sure.

If it's such a massively huge project like OpenJDK, then not really.

You might also check how non-trivial it is to get a change into the Linux kernel.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: