GrapheneOSWe're happy to announce a long-term partnership with Motorola. We're collaborating on future devices meeting our privacy and security standards with official GrapheneOS support.
https://motorolanews.com/motorola-three-new-b2b-solutions-at-mwc-2026/
🌸 Ⓐnarkitty lumi-nhac 
@GrapheneOS does this mean i will be able to get a degoogled motorola device in the future?
Alexia 
@alexia @GrapheneOS yeah, ofc the end goal is using a proper linux phone, to get maximal freedom and security
but having a degoogled android device is a step along the way. though i have been stuck at that step since around 2014
but having a degoogled android device is a step along the way. though i have been stuck at that step since around 2014
@lumi @alexia GrapheneOS and the Android Open Source Project are Linux distributions. We strongly disagree with the premise that glibc, systemd and GNOME are preferable to the much more private and secure AOSP software stack. Moving to the desktop software stack would be a huge regression for nearly everything we care about and focus on improving. It's already possible to run desktop Linux apps in GrapheneOS including GUI apps via the hardware virtualization support and there's a desktop mode.
witch_t *navi@GrapheneOS @lumi
me with a musl, openrc, and sway system looking over -- i think you're starting with the wrong premise here
me with a musl, openrc, and sway system looking over -- i think you're starting with the wrong premise here
@navi @lumi Where's the application sandboxing, memory safe languages, modern exploit protections, deep integration of powerful hardware-based security features and everything else we focus on in GrapheneOS?
Aside from any of that, the concept that the Android Open Source Project isn't a Linux distribution is wrong. Linux isn't the userspace software that's largely portable to other operating systems. There was a Debian variant using the FreeBSD kernel which is clearly not Linux.
Luci ☯⚛@GrapheneOS @navi @lumi That doesn't take away from what navi said. Either way. What of the concern that AOSP might not be open anymore at some point? The whole ecosystem is being closed down. I think that's definitely a genuine concern. What's your plan when that happens, if you can disclose? Will you maintain a fork of AOSP with Motorola, or by yourselves? That's kind of what I would like to know so I can feel reassured that there's a future for the platform even if Google further alters the deal.
Edit: This comment was followed up by the type of activity we've all come to expect from whoever seems to run GrapheneOS' social media, but they since deleted their side of it and blocked me... :') I summed it up here:
zivi@quantumsys @GrapheneOS @navi @lumi AOSP should not be relied on if you give any amount of fucks about freedom. sure it’s technically a linux distribution, but that says little when you have to plead OEMs for what little up to date source code is available. it’s being actively crippled by google into a complete dead end.
zyxhereðŸ’
@zyx @quantumsys @GrapheneOS @lumi
that mentions relying less on linux, and more... on aosp tools, which is the opposite of safeguarding things against google
that mentions relying less on linux, and more... on aosp tools, which is the opposite of safeguarding things against google
@GrapheneOS @lumi
where's your vetted package repository and actually end-user verifiable system booting and bootstrapping (aosp taking 3 days to build on a fairly high end personal hardware makes it fail at that, hard, not to mention the cursed build system), and open community based development model (which google is dead set on removing from aosp)
where's your vetted package repository and actually end-user verifiable system booting and bootstrapping (aosp taking 3 days to build on a fairly high end personal hardware makes it fail at that, hard, not to mention the cursed build system), and open community based development model (which google is dead set on removing from aosp)
LisPi@navi @GrapheneOS @lumi > (aosp taking 3 days to build on a fairly high end personal hardware makes it fail at that
How was that ever considered reasonable? Astonishing and appalling.
How was that ever considered reasonable? Astonishing and appalling.
David Heidelberg@GrapheneOS @navi @lumi let me disagree here. Android is fork of Linux.
Fork with huge change-set - hard to review.
With drivers written to "get to market fast", not quality.
With other closed drivers in userspace to avoid open sourcing.
Naaaah, this ain't Linux I'm running on my laptop.
I won't argue — security features of AOSP may be superior. But what runs beneath these features isn't!
> let me disagree here
Okay, but you're objectively wrong.
> Android is fork of Linux.
No, Android isn't a fork of Linux. Android works fine with mainline, stable and longterm Linux kernels from kernel.org. It doesn't have any required downstream patch set.
> Fork with huge change-set - hard to review.
It's not a fork and has no required changes to the kernel.
> With drivers written to "get to market fast", not quality.
Hardware vendor drivers aren't Android.
> With other closed drivers in userspace to avoid open sourcing.
That's not part of Android and is in no way required to use it. Desktop Linux distributions ported to the same hardware nearly entirely relying on the same drivers regardless.
> I won't argue
You're just making objectively inaccurate claims to promote massively rolling back privacy and security by moving to legacy desktop software. Replacing vendor drivers has nothing to do with that whatsoever.
> No, Android isn't a fork of Linux. Android works fine with mainline, stable and longterm Linux kernels from kernel.org. It doesn't have any required downstream patch set.
Show me one vendor of phone shipping clean kernel. One.
Hardware vendor drivers are part of Linux I use, are you implying Android != Linux? 😉
HybridStaticAnimate@okias @GrapheneOS @navi @lumi They do not need to show you that. Your subjective criteria for this is invalid. An example doesnt need to exist for it to be accurate. It just means Phone vendors decided not to do it.
@okias @GrapheneOS @navi @lumi That is incorrect. Android and GrapheneOS are Linux distros and are perfectly capable of running mainline linux kernels. Linux is not a badge of honor that you apply to what you like about a distro and what you dont.
d@nny disc@ mc²@navi @GrapheneOS @lumi hate seeing people fight over this as if sandboxing is something that can never be made freedom-respecting. i consider it a distinct lack of imagination not to re-evaluate and seek to virtualize OS interactions which impose relatively generic models of trust and access that are heavily overloaded in the standard linux userspace and cannot be simply reused
@hipsterelectron @GrapheneOS @lumi
> i consider it a distinct lack of imagination not to re-evaluate and seek to virtualize OS interactions which impose relatively generic models of trust and access that are heavily overloaded in the standard linux userspace and cannot be simply reused
well grapheneOS is trying something like that https://grapheneos.org/faq#roadmap -- aosp only, but it feels like the same vibe to me?
> i consider it a distinct lack of imagination not to re-evaluate and seek to virtualize OS interactions which impose relatively generic models of trust and access that are heavily overloaded in the standard linux userspace and cannot be simply reused
well grapheneOS is trying something like that https://grapheneos.org/faq#roadmap -- aosp only, but it feels like the same vibe to me?
@navi @GrapheneOS @lumi linux is in fact a corporate project and has been for a while and it's ridiculous and unserious to me to portray it as the apex of "freedom-respecting" because of the many vested corporate interests who are inextricable from the linux governance structure. linus demonstrated that you can get corps to invest in your open source code like this but the coercion and inertia works both ways
@navi @GrapheneOS @lumi i'm working on bootstrapping build and packaging logic atm and sandboxing mechanisms like unshare paired with virtualization like overlayfs is a tool that enables surgical precision in constructing dependency graphs that don't make overly broad assumptions about the user environment, enabled by crafting OS interfaces to model the trust and access specific to my application context.
@navi @GrapheneOS @lumi it is just remarkably obtuse to claim (as the fdroid entourage is so fond of doing) that the interaction model advanced by mainline linux distros is inherently freedom-respecting when it is being specifically invoked to rule out R&D into e.g. privacy-respecting models of trust and access that are simply not interesting to mainline linux
@navi @GrapheneOS @lumi "freedom-respecting" is not a measure of how closely it hews to the vision of linus torvalds but a measure of how much a software ecosystem precludes alternative imaginings of the user's relationship to their computing hardware. no one in this discussion would argue that android is not a corporate project, but the implicit and ridiculous assertion that goes unchallenged is that when linus torvalds got corps to work for him that he was necessarily still working for you the user. systemd too seeks to apply corporate computing models to distros with actual users and was notably to blame for enabling the xz-utils vuln. we can do so much better! this should be an exciting new frontier where we can push each other to shake off the chains that bind us to hierarchical power relations! linux is the floor!