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.
King_of_Ooo@GrapheneOS @lumi @alexia The current default software stack for desktop Linux is kind of terrible and the lack of coherent threat model or proper ecosystem of sandboxed applications are major issues with desktop right now. What I am still questioning is whether it is even possible to make a proper competitor to ChromeOS (if we ignore the hardware insecurity of basically all PCs).
So example software choices:
systemd -> dinit or s6
sudo -> s6-sudo (setuidless)
glibc -> muslc
glibc malloc or jemalloc -> hardened_malloc, malloc-ng, or mimalloc-secure (which supports more CPU architectures)
bubblewrap (sandbox used by Flatpak) -> #syd (it's written in Rust, has many important exploit protections, and can even be the user login: https://gitlab.exherbo.org/sydbox/sydbox)
GNOME or KDE -> XFCE (when their new Rust Wayland native WM is finished)
gnutils -> *BSD or uutils
The issue of course with most of these alternatives is that they are separate projects and therefore dont have the same goals, methods, or threat models. Also most of these projects are written in C which does not help at all. Also there is of course the lack of a proper chain of trust from the hardware to loading the kernel and userspace.
It may just not be reasonably possible to provide a alternative without millions of dollars of funding and a decade of development. It would be nice for there to be an alternative to AOSP/ChromeOS or even MacOS for desktop computing which actually takes security seriously. It doesnt even need to have be completely on par when it comes to security, just do better than current Linux distros (not a very high bar).
What are your thoughts on what to do in case the day comes that Google kills AOSP?
> systemd -> dinit or s6
Lots of these are giving up even more security features.
> hardened_malloc, malloc-ng, or mimalloc-secure
These aren't the same classes of allocators at all. Neither the musl malloc or mimalloc is a hardened allocator. mimalloc is performance focused and musl's is focused on low memory usage.
> What are your thoughts on what to do in case the day comes that Google kills AOSP?
What about when IBM decides to kill systemd, GCC and GNOME?
LisPi@GrapheneOS @King_of_Ooo @lumi @alexia
What about when IBM decides to kill systemd, GCC and GNOME?
systemd
Between GNU Shepherd, supervise-daemon and runit? 
GCC
You'll have to explain why/how IBM owns GCC. Fairly sure it's an actual FSF project. 
GNOME?
RIP lol 
Other than the accessibility stuff most of it I don't care much about, and with the ensloppification going on & Red Hat apparently insisting on it, it might well die anyway.
What are your thoughts on what to do in case the day comes that Google kills AOSP?
This however has real chances of happening and already has a largely closed development process with no community.
Which means it doesn't even need a poison pill contributor agreement, all the necessary rights are probably already in Google's possession for malicious license changes.
Not to mention that the main useful part of Android, the drivers & their documentation, aren't even included anyway. Everything else could be replaced by something better with some work.
@lispi314 @King_of_Ooo @alexia @lumi AOSP has a far larger development community than desktop Linux. There are a huge number of both corporate and community AOSP-based projects. There's a massive community of people working on all kinds of projects related to it. Desktop Linux is assembled out of a bunch of barely maintained or developed projects with one of two developers each. It has nearly non-existent systemic work on almost anything aside from systemd gobbling up components into itself.
@GrapheneOS @King_of_Ooo @alexia @lumi So, how many of those community projects aren't simply downstream like the Mozilla Firefox ones?
How many are actually credibly in a position to take development over entirely with a dead upstream?
How many are actually credibly in a position to take development over entirely with a dead upstream?
@lispi314 @King_of_Ooo @alexia @lumi systemd won not because it's good but because it actually exists as a somewhat coherent basis for an OS providing the features which are wanted. It didn't have to be a sensible or good implementation of almost anything. It's far from only an init system and the overall desktop and server ecosystems are increasing based around it. All the non-tiny desktop Linux stack ports to mobile are heavily using systemd. They're bringing systemd to mobile, not Linux.
@GrapheneOS @King_of_Ooo @alexia @lumi You know, if you're just going to avoid the question you could simply not answer that post, like you did with my mobile modem isolation question.
The overwhelming majority of the BSD tooling that isn't systemd could be ported with a modest effort if systemd died. Note that I linked daemon supervisors earlier, because session managers and init systems are a lot easier to come by.
edit: Ah, my bad, I confused the subthread. You did ignore it and replied to the prior post.
@lispi314 @King_of_Ooo @alexia @lumi
> You know, if you're just going to avoid the question you could simply not answer that post, like you did with my mobile modem isolation question.
Don't know what you're talking about. You're one of hundreds of people.
> The overwhelming majority of the BSD tooling
It has little to do with the desktop software stack. That increasingly only has an incomplete port over to BSD with a growing amount of hacks. It would just roll it back even further.
@GrapheneOS @King_of_Ooo @alexia @lumi
You know, if you're just going to avoid the question you could simply not answer that post, like you did with my mobile modem isolation question.
Don't know what you're talking about. You're one of hundreds of people.
This would be the one (started here).
It has little to do with the desktop software stack. That increasingly only has an incomplete port over to BSD with a growing amount of hacks. It would just roll it back even further.
In conjunction with the daemon supervisors? Very little would be lost that cannot be recovered with some work.
It would be somewhat tedious but hardly catastrophic or deadly, unlike the loss of upsream AOSP for every AOSP derivative.
Or Mozilla upstream for all the downstream. Which with slop is looking increasingly likely to happen.
LisPi (@[email protected])
@GrapheneOS By the way, I'm still very interested in your input on this part.I would hope that such isolation is part of the GrapheneOS safety requirements.@greenpete @bobkmertz @joe9nf