> I have read your marketing materials
GrapheneOS is a non-profit open source project. We provide documentation and other information on the project.
> Android is not a Linux distro nor is it directly derived from Linux
Android is a family of Linux distributions. Linux is a kernel without a specific userspace and there are many different choices of libc, shell, init system, command-line utilities and far more. There are even more choices for the high level user interface. Android's userspace is largely specifically written to run on top of the Linux kernel with extensive use of SELinux and other Linux-specific APIs. A lot of the software you're considering to be Linux also runs on FreeBSD and elsewhere. FreeBSD is not Linux and the traditional desktop software stack largely shared with FreeBSD isn't Linux either.
Android Open Source Project uses the upstream Linux LTS branches. The upcoming devices with GrapheneOS support from Motorola use latest Linux 6.18 LTS branch. We plan to port to newer Linux kernel branches throughout the lifetime of the devices. Google already does that for Pixels and it needs to start happening for other devices too.
The upstream Linux LTS branches largely exist for Android with Google contributing a lot of the resources for it. Ubuntu and RHEL make their own LTS branches rather than using the ones from the Linux project. The lifetime for the upstream branches was increased from 2 to 6 years alongside Pixels increasing the support time to 5 years with the Pixel 6. It was decreased from 6 to 2 years because Pixels have been smoothly moving to newer kernel branches in production. It demonstrated the lack of need for the longer LTS branches not only for Android but more broadly. Pixels moved to 7 years of support with the Pixel 8 which wouldn't have been possible sticking to 1 kernel branch without a further lifetime increase.
> Mobile phones are not "personal computers".
Mobile phones are absolutely personal computers and should be treated as such. Many people use a mobile phone as their main personal computer. In large parts of the world, mobile phones are people's only personal computer.
GrapheneOS can even be hooked up to a monitor, mouse, keyboard, game controller and other accessories. It has a very functional desktop mode. It can also run desktop Linux applications via the hardware accelerated virtualization support. It even has opt-in GPU acceleration via gfxstream. That's all standard functionality from the Android Open Source Project.
> Trying to act like it being "mainstream" or "common" relative to desktop distros matters is just laughable.
There are billions of Android users. Each of those users is a Linux user. Linux is the dominant OS family on personal computers due to Android.
> And I take issue with the notion that a monolithic kernel cannot be secure.
A monolithic kernel written in C with an extreme focus on performance at the cost of having immense complexity is not reasonably secure. Piling on better exploit protections is useful but has a limited impact and those protections don't work as well in the Linux kernel as they do in the much more security-oriented userspace. Everything in the kernel being in the same address space with no isolation for regular code is not a good setup for security and severely hinders the usefulness of many exploit protections.
Further reducing attack surface even more than Android does is possible but is difficult while maintaining app compatibility. Hardware-based virtualization is the most realistic approach to dealing with the insecurity of the Linux kernel to properly protect it from userspace.
Protecting drivers from exploitation largely involves moving most of the code to userspace which is the norm in the mobile world and should expand much further. Bluetooth, Wi-Fi and other code can be largely moved out of the kernel. Moving TCP/IP, filesystems and many other drivers out of the kernel is entirely possible. However, it starts to run up against the Linux kernel having a culture and approach strongly against doing it. The same thing has happened with the attempt to introduce Rust in the Linux kernel with immense resistance and obstruction to simply providing bindings to write non-core drivers in it. There's no current attempt to use Rust in the core kernel and it would be an immensely slow process even if that was happening.
Hundreds of severe vulnerabilities being found per month with only a subset of those getting fixed is not a sustainable approach to making a reasonably secure OS.
> then why arent you guys working on the next kernel for personal and high-performance computing
We're doing initial work on expanding use of hardware-based virtualization to further reduce reliance on the Linux kernel for security. We're also building up our resources to be able to take on much bigger projects. Aside from that, we don't need to be doing things entirely on our own.
A lot of what we want aligns with where AOSP is already headed and many others want the same things. AOSP added hardware-based virtualization with the userspace code written in Rust and a more secure approach to handling it in the kernel (pKVM) without our involvement. AOSP also began to make very limited use of this for OS sandboxing itself. We want to do much more with it and use it for sandboxing apps, which are not things Android is currently working on as far as we know but likely will be in the future.