yjftsjthsd-h

I really do wish the pinetime had more RAM; it's really really small and a pretty painful bottleneck.

Edit: Oh, once the "pro" version is out I guess there's an easy answer to that: https://pine64.org/2026/03/28/pinetime_march_2026/

I guess that's also a plausible possibility. Honestly I mostly don't think sr.ht has enough market share to matter either way.

> Android has a massive app ecosystem including the largest open source mobile app ecosystem. Those apps are nearly entirely available for GrapheneOS. Very few apps are unavailable for GrapheneOS. It's nearly entirely banking and government apps, but as we said 90% of those work on GrapheneOS.

> AOSP and GrapheneOS have hardware-based virtualization usable to run desktop Linux software. It even provides opt-in GPU acceleration with gfxstream and will likely have native GPU virtualization support similar to NVIDIA's paid vGPU in the near future. AOSP and GrapheneOS have a very usable desktop mode which will be getting much better. Android is replacing ChromeOS and was already heavily improved for desktop use as part of being included within ChromeOS. We have that app ecosystem available too.

There was really no need to write 2 paragraphs to agree with me.

>> the existing apps largely do run on other Linux systems via waydroid

> A large portion of Android apps do not work via Waydroid. It has drastically lower compatibility than GrapheneOS and there are fundamental issues with how it approaches it.

What is a "large portion"? It's worked fine for me but I suppose if you have hard data that might be meaningful. Could you describe the "fundamental issues"? My impression is that they just run the whole Android userspace in a container, which seems like a reasonable approach.

> The approach they take also severely harms privacy and security through throwing away most of the privacy and security model used by Android. That would not be the case for running AOSP in a hardware accelerated virtual machine, which is what we would recommend doing. It would still have greatly reduced compatibility due to apps using hardware APIs such as the hardware keystores and many apps actively trying to stop themselves being run in a virtual machine or other weird environment. It would work a lot better than using namespaces but would require modern hardware with virtualization acceleration.

Again, I know security/privacy is your talking point, but this isn't actually the argument at hand.

>> apps refusing to run on non-stock systems are likely to refuse GOS as well

> A very tiny subset of overall Android apps entirely ban using a non-Google-certified OS. Most only have checks for the security model being intact and anti-tampering code interfering with running the apps in an atypical environment. We run into these issues with our privacy and security hardening features so we've done a lot of work to maintain compatibility.

So, yes.

>> GOS is supported by some apps that would refuse other non-stock systems.

> GrapheneOS exceeds all of the security and attestation expectations of these apps. They have no reason to ban using it and we make sure to avoid that being the case. It's only a tiny number of apps banning using GrapheneOS in the first place and a growing number of those are beginning to permit it since they don't actually have a reason to ban it. They do have a reason to ban an OS not providing the security model and attestation functionality they want. We disagree with attestation being used this way, but they can do that while supporting GrapheneOS and a growing number of these apps are doing so.

Which is a lot of words to agree that yes, many apps only allow stock and therefor block you just like any other OS.

>> yes you're probably ahead

> GrapheneOS provides drastically better compatibility.

I'd like evidence for "drastically", but again we mostly agree.

>> waydroid is also 90% AOSP

> It's a fork of outdated LineageOS with a compatibility layer to make it run as part of a non-AOSP host OS. It has SELinux disabled which means the app sandbox and other protections aren't intact along with many other major differences. Apps can see these differences and many apps ban it because they can see the security model isn't intact or detect what's happening as a form of tampering.

Right. So it's 90% AOSP. Old AOSP with worse security properties, but for compat purposes that's not important.

> In practice, GrapheneOS only gets banned by services enforcing the Play Integrity API device or strong integrity level without permitting GrapheneOS via hardware attestation. A growing number of apps are permitting it since they don't have any real reason to ban it. It's easy for them to stop endless negative reviews and customer support complaints from GrapheneOS users by simply implementing Android hardware attestation with Google's open source library for it and permitting GrapheneOS. They can also simply delete the code banning using non-Google-certified operating systems which is what we'd prefer over them hard-wiring permitting GrapheneOS and specific other alternatives.

You and I have different impressions of how apps approach attestatoin.

>> yes GOS has gotten some buy-in, but if 90% is good enough

> That was only about banking apps. Over 99.99% of overall Android apps work on GrapheneOS. The vast majority of apps are not banking or government apps.

And most apps work on waydroid. Of course the apps that go out of their way to block non-stock are the pain point.

>> compatibility as your advantage

> It has an immense compatibility advantage along with far better privacy, security, usability and battery life.

(You've carved out 3 words in a way that doesn't make sense alone; this is part of either the previous or next bit)

>> Basically, either users want 100% app compat - in which case GOS is out - or they don't, in which case waydroid is likely to be an option

> Most users have 100% compatibility since most people don't use the around 10% of banks banning GrapheneOS. Our userbase is also growing large enough that apps cannot ban using it without it being a huge hassle for them. They have no actual reason to ban it, so that's why a growing number of apps are removing the ban on using it. They're usually not willing to stop using the Play Integrity API but once this is on their radar due to complaints they often become willing to implement using the Android hardware attestation API to permit GrapheneOS and other alternatives meeting their requirements. It's not a full solution since it won't allow people's self-signed builds or forks of GrapheneOS but it's progress and it enables the apps to easily permit more operating systems in the same way. They can just add more to their list. We would prefer the Play Integrity API being banned by regulators but this is good enough for now.

90% of the time, it works 100% of the time. Anyways, you aren't 100% compatible, so my point stands.

>> since GOS is missing vitally important features compared to other Android ROMs let alone "normal" Linux systems

> GrapheneOS has similar functionality to mainstream Android smartphones. We highly prioritize providing missing functionality not available through apps.

I'm not comparing to stock, and you refuse to give apps root access so the shortcomings that they can fix are limited. (Yes, I know your threat model demands that the stupid helpless users can never be allowed to control their device. That's actually defensible if security+privacy is your #1 goal, but it does undermine the features that your OS can provide.)

> GrapheneOS is an operating system, not read-only memory firmware. There's a boot ROM which loads the main boot firmware from the SSD, verifies it and transfers control to it which then does the same with the OS. GrapheneOS is simply a regular OS installed on an SSD. Verified boot protects it from modification but it's not in read-only storage or anything like that. We don't misuse the term ROM to refer to it and prefer if others avoid it too.

I love pedantry as much as the next guy, but ROM has not meant read-only memory in like 20 years.

>> how long has GOS been without full backup functionality now?

> GrapheneOS has much better backup support than the stock Pixel OS and most Google Mobile Services Android devices.

> GrapheneOS has a built-in encrypted backup system. It backs up the same data as Google's device-to-device transfer for moving between Android devices. Every app targeting Android 12 or later gets backed up since allowBackup="false" was redefined to only disable cloud backups. Every Play Store app has been required to target Android 12 or later since under a year after the release of Android 12. The issue of apps opting out of backups has been in the past for years.

> Backing up more of the system settings and other system data is planned and requires gradually expanding what gets converted into a portable format transferable between devices and OS versions.

So, you're trailing, say, Debian, and have done for years, and have at most a plan for someday being able to compete.

>> What other secure options are those?

> It's up to these companies to define their security requirements. GrapheneOS is far more secure than anything permitted by the Play Integrity API device or strong integrity levels. It supports hardware-based attestation and we publish a signed JSON object providing our verified boot key fingerprints for use with it. They can easily use that and permit GrapheneOS. Other operating systems preserving the Android security model can do the same. Once they allow GrapheneOS, it's easy for them to allow more in the same way. It would be nicer if they stopped using the Play Integrity API and left OS security up to users but most of these apps are not open to doing that. A small portion of apps adopting the Play Integrity API didn't understand what it does and are willing to stop.

So when you wrote "GrapheneOS and other secure options", you just meant GOS because nothing else matches your definition of security. Again, I don't exactly mind that, but it's disingenuous to gesture at other options that don't exist.

1. Android has existing apps.

2. A subset of existing apps will refuse to run on various shades of non-stock/unofficial system.

I pointed out that 1. the existing apps largely do run on other Linux systems via waydroid, and that 2. apps refusing to run on non-stock systems are likely to refuse GOS as well.

If I cut down your page of text to the relevant points, I believe it amounts to:

1. GOS has better app compatibility than waydroid.

2. GOS is supported by some apps that would refuse other non-stock systems.

3. GOS is more secure/private. (This is unrelated and should at most have been a reply to the root comment.)

On 1. compatibility, yes you're probably ahead, though I have to question how much since waydroid is also 90% AOSP. Somewhat similarly on 2. yes GOS has gotten some buy-in, but if 90% is good enough, then again you shouldn't be holding up compatibility as your advantage over waydroid. Basically, either users want 100% app compat - in which case GOS is out - or they don't, in which case waydroid is likely to be an option. Point 3. is irrelevant to the conversation, and you probably don't want to start an argument about general features since GOS is missing vitally important features compared to other Android ROMs let alone "normal" Linux systems (how long has GOS been without full backup functionality now?).

> We've also had to actively convince apps to stop banning non-Google-certified operating systems or to permit GrapheneOS and other secure options alongside doing it.

What other secure options are those?

- https://en.wikipedia.org/wiki/Device_driver

Is using a VM running another operating system as part of a driver weird, yes. Is it still a driver? Also yes.

Isn't that true of human authored code?

What security problems does waydroid have that a VM wouldn't?

Also, I daily drive Alpine Linux (using musl) and I'm quite happy to assure you that glibc really is only one option, not at all mandatory for desktop Linux.

We have waydroid for that.

> You can't have a bank account on a Linux phone* because they won't let you, but you can on Android including on Graphene.

Unless of course it uses those stupid integrity apis to block anything that isn't stock.

As in, Mobile NixOS? How was that?

The text at the top of the screenshot is

> Eric Roston

> @eroston.bsky.social

So it's pretty easy to tell IMHO.

Is there any precedent to believe that such a thing is in fact possible?

> and volunteers have to use hacks

I have terrible news for you about how the official firmware works.

> to unofficially implement basic Android 1.0 functionality years after a device was released?

Conversely, in other places it's far better than Android 1.0. But yes, if you can only start developing against the device after it's released, then your software will be released after the hardware ships plus development time.

> That's sad to see. This is just lame, drivers should be implemented by those who work on them..

My general understanding of the Android ecosystem is that they do write drivers, and you don't want those drivers. I like to imagine that somewhere that out there somebody must be making phones with high quality software, but I've never heard of them.

I assume this is addressing

> and since all the RISC-V SBCs I'm aware of have significantly worse performance and efficiency than comparably priced ARM SBCs.

If so, could you point at specific SBCs that beat ARM SBC perf?

Oh, right. I forgot about that part. Thx.

> libhybris allows glibc Linux programs to load the standard Android graphics drivers

I don't quite follow why you need that? This runs on a real full Android, so surely drivers already work?

I assume it's suggested precisely because people use passwords. Which, granted, they shouldn't.