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

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

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