@pmurphs @alexia maybe a fairphone and there are some other European alternatives too (one or two more but I can't remember).

Edit : I think one of them is a Shiftphone. But you should look into them (as I didn't bother with them cuz I can't get them shipped to my place).

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.

@King_of_Ooo @lumi @alexia

> 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?

@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.

@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.