| Linux on phones have been around since the late 00s (e.g. through Nokia's efforts). Why would this suddenly change? Heck, even after decades, the battery life of most laptops running Linux is still much worse than Windows, let alone macOS. I have had several generations of ThinkPads and to this day, battery life is typically ~50-60% of that of Windows, even with all battery optimizations applied. And Windows is terrible compared to Mac or Android/iOS phones. And I say this as a long-time Linux user (used Linux in some form since 1994). It's just a very hard nut to crack if you miss a certain amount of vertical of integration and coordination across the ecosystem. |
| |
| ▲ | apatheticonion 4 hours ago | parent | next [-] | | We are _not allowed_ to make it good. Without hardware documentation, you're looking at decades of reverse engineering effort just to get somewhere half as far as an engineer with hardware documentation can get in a weekend. Look at Asahi. Almost a decade in and we can use the GPU at like 30% of its ability on 6 year old hardware. That a project with major interest. No one cares about spending a decade reverse engineering the hardware on a Google Pixel or Samsung Galaxy. If they gave us proper full hardware documentation, we could create high quality alternatives. Again, we can't so you don't see it. Competition is good. We should always advocate for things that enable competition. | | |
| ▲ | ashirviskas 3 hours ago | parent [-] | | > Without hardware documentation, you're looking at decades of reverse engineering effort just to get somewhere half as far as an engineer with hardware documentation can get in a weekend. I'm not sure this is true anymore and it is becoming less true with each new LLM release. > No one cares about spending a decade reverse engineering the hardware on a Google Pixel or Samsung Galaxy. Actually, this might a cool idea - just get a few super cheap smartphones, connect them all to a PC, give LLM access and tell it "make linux gud like android pls" and just give it a weekend. | | |
| ▲ | adrian_b 2 hours ago | parent [-] | | Even if you have the binary driver and you decompile it with the help of a LLM, it does not provide most of the information from the documentation. You may see that the driver writes some hundreds of magic constants in some hardware registers, but you do not know what they mean. You may be able to do exactly what the binary driver, does, but you will not be able to improve it, e.g. to enable features that happen to be not enabled in that driver. So a LLM can speed up the initial part of reverse engineering if you have the files with binary drivers, which may be difficult to extract from certain phones, but a lot of work remains to discover all that the hardware can do. |
|
| |
| ▲ | hypfer 4 hours ago | parent | prev [-] | | > Why would this suddenly change? I see three aspects there. The first is that google is currently rugpulling via various means and _really_ playing those anticompetetiveness-cards. That wasn't the case previously. So there wasn't much motivation to care, because android was "open enough". The second is that the world is getting less geopolitically stable. So the whole ecosystem lockdowns are not just a personal preference thing but might be actually vital. The third is that LLMs are kinda good at these optimization loops if you hand them a framework in which they can sample good data. I also had a fourth thought but it left my mind :( | | |
| ▲ | microtonal 3 hours ago | parent [-] | | Android is still open enough. Worst case, AOSP can be forked and it will still be leagues ahead of non-Android Linux phones. That also applies to the sovereignty point. I see especially GrapheneOS and /e/OS grow because of this in local communities. LLM-driven optimization is a good point. However, Linux desktop communities tend to be quite aggressively anti-LLM. E.g. GrapheneOS has been heavily attacked by these people for only using an LLM for security auditing. But maybe these projects will fork into LLM-accepted forks who will then rapidly out-innovate. |
|
|