Oddbean

Awesome to hear you want to come back around to GrapheneOS. At this point I can't imagine using any other mobile OS. QubesOS on desktop, GrapheneOS on mobile. The privacy and security benefits are too numerous. Nothing really comes close. Creating a private and secure mobile OS as usable as GrapheneOS was a near impossible task, and they did it, and they keep doing it.

@Mike Dilger In 2022 Graphene OS went as far as to announce their collaboration with a hardware vendor to have their own devices produced but in the end it fell through. As far as I understand the idea of a GrapheneOS phone is still on the table if they find the right manufacturer and agreement. @final [GrapheneOS] 📱👁️‍🗨️ am I correct in this understanding? Is the idea of a GrapheneOS phone still something GOS is considering? https://i.nostr.build/O49KA.jpg

Always has been. It's just it never goes well so far because the OEMs always want gimmicks, implement security features improperly or don't want to at all to cut the cost. Having less security than the baseline in our documentation is unacceptable to us. If we supported devices that are less or improperly secured then it ends up with us being the blamed party for these devices rather than the OEM who slacked off. People would then say it's the fault of GrapheneOS as a whole when the secure devices don't get affected by such problems. Supporting existing devices is also on the cards but OEMs don't play fair, like Samsung crippling security features and even cameras permanently. I am personally not the type to have the law step in on things like this, but I totally think there should be some litigation about this.

💯 that's more than BS on Samsung's part. There should absolutely be litigation. It's definitely not acceptable to sacrifice security just for the sake of not using Pixels until the right OEM comes along. Good on GOS for refusing to do so. Thanks for the reply :)

IMHO far too early. RISC-V processors aren't competitive yet. I suspect it is like this: 1. RISC-V instructions are simple and have short decode paths, meaning clock cycles could be faster, but 2. Higher frequency clocks create hard to deal with electromagnetical effects, so they can't do that 3. Instead they get low power, which is good for the phone, but not if the CPU is too slow. 4. They also can scale up to lots of cores 5. SiFive has done a lot of multi-issue out-of-order work to optimize their chips, but still not competitive for phones I think, and that kind of thing might lead to Spectre-like bugs. There probably will need to be some kind of hybrid.

+10 years or so for software optimizations to catch up to the new arch. The amount of work done on both the software side and the hardware side to make these things performant and power efficient is insane.

I don't have the technical knowledge about it as you apparently have. But it seems promising seeing that there are a few SBC in the market already working. There's also the pinetab 2 which is a quad-core @1,5Ghz. Not superfast, but yes lacking a lot of software support yet. Also the Linux phones running on arm lack a lot of battery optimization, but it's very interesting how fast some problems were solved like standardization of OS images by using tow-boot. A problem android wasn't able to solve in more than a decade.

I hadn't seen tow-boot. Was familiar with u-boot though. This is interesting: https://wiki.pine64.org/wiki/PineTab-V I have a SiFive HiFive Unmatched running ubuntu. I tried to write low-level code to do what u-boot should do on that hardware (wind up the PLLs, flip some switches, etc, the stuff the HW manual says must be done at power on) and then print something to the screen. But it just printed garbage to the screen and I never figured out why my code wasn't working... and then I discovered nostr and my life changed.