this post was submitted on 05 Jun 2026
108 points (97.4% liked)

DeGoogle Yourself

16970 readers
108 users here now

A community for those that would like to get away from Google.

Here you may post anything related to DeGoogling, why we should do it or good software alternatives!

Rules

  1. Be respectful even in disagreement

  2. No advertising unless it is very relevent and justified. Do not do this excessively.

  3. No low value posts / memes. We or you need to learn, or discuss something.

Related communities

!privacyguides@lemmy.one !privacy@lemmy.ml !privatelife@lemmy.ml !linuxphones@lemmy.ml !fossdroid@social.fossware.space !fdroid@lemmy.ml

founded 6 years ago
MODERATORS
 

I Installed a Graphene-Based OS on Non-Pixel Phones… Here’s the Catch

https://www.youtube.com/watch?v=-RjGjqBAAgQ


"I was watching youtube(Invidious) and notied RestlessOS . Have you heard of this and are there people actually tried this on non-pixel phone?

"RestlessOS is an unofficial, unaffiliated fork of GrapheneOS packaged as a Generic System Image (GSI) for Project Treble devices. It is not endorsed by, sponsored by, or in any way connected to the GrapheneOS project or its developers."

https://github.com/cawilliamson/treble_restlessos

I'm very hesitant to give money to Google pixel so I'm going to experiment on this one."

you are viewing a single comment's thread
view the rest of the comments
[–] tapdattl@lemmy.world 38 points 1 day ago* (last edited 1 day ago) (4 children)

Looks like they put in a ton of effort to make this compatible with generic devices, but I have to ask, with all the features removed, why choose this over any other ROM?

Features removed

hardened_malloc — causes boot loops on devices with 39-bit virtual address space. replaced with AOSP Scudo.

Auditor — requires hardware attestation which > doesn't work on GSI

mtectrl / misctrl — Pixel-specific memory tagging control; breaks vendor TEE drivers

USB protection — the low-level USB port controls rely on Pixel-specific hardware and are non-functional on other devices

native debugging protection — not ported; breaks compatibility with root solutions and vendor debugging tools

Features disabled by default

These can be re-enabled in TrebleApp → Hardening or Settings → Exploit protection.

MTE/TBI for vendor processes — memory tagging breaks some vendor drivers

hardened thread stacks — non-standard memory layout breaks some vendor drivers

secure (exec-based) app spawning — breaks root solutions (Magisk / KernelSU)

[–] WhyJiffie@sh.itjust.works 1 points 9 hours ago* (last edited 8 hours ago)

Features removed

USB protection — the low-level USB port controls rely on Pixel-specific hardware and are non-functional on other devices

they don't need to outright remove that. I know that at least some fairphone models are capable of that, because another ROM makes use of it. it seems it was more important to have a much broader compatibility quickly, without testing what features do really need to be removed for what devices. there are probably other removed features too where tbis applies

but this is not all that graphene gives, I believe this does not make it worthless. they have other unique features too like sandboxed google play and the possibility to manage sensor access for apps separately, and more.

[–] grandma@sh.itjust.works 27 points 1 day ago

Sandboxed Google play I guess

[–] monovergent@lemmy.ml 5 points 1 day ago

Minimalism. Compared to AOSP, Google components and pings removed. Compared to other privacy GSI ROMs, no weird, quirky, or flashy functions or themes the author decided to bake in.

[–] slacktoid@lemmy.ml 4 points 1 day ago (1 children)

Still better than nothing? And more privacy centric options out there are better as it gives people a way to figure out how it can fit into their life vs the all private where nothing works and you need to know tech to get around or nothing private but at least things work, world people are in.

[–] schipelblorp@sh.itjust.works 5 points 1 day ago (2 children)

Why are a multitude of poor options better than a few good options?

There's this weird mix of free market capitalism and FOSS philosophy that says more and shallower forks = better ecosystem.

Not commenting on this OS specifically, but just questioning your blase assertions that more options is better. Maybe it would be have been better to invest more time into an existing project.

[–] WhyJiffie@sh.itjust.works 1 points 9 hours ago (1 children)

Why are a multitude of poor options better than a few good options?

because you see it wrong. it is not poor just because it is not shiny polished perfect. it is still an improvement over the factory rom, and if the maintainer is trustworthy then it's an improvement over lineage os too.

[–] schipelblorp@sh.itjust.works 1 points 8 hours ago

Re-read my comment?

[–] 0_o7@lemmy.dbzer0.com 0 points 19 hours ago (1 children)

Why are a multitude of poor options better than a few good options?

People make do with what they have.

It would be ideal if everyone had access to the "best" options, so a single approach makes sense, but we don't live in an ideal world.