GrapheneOS only publishes updates for devices with active security updates. Your device is EOL and therefore won’t receive any further mainline updates. It still will receive extended support from the Android 14 legacy branch with whatever security patches arrive in upstream AOSP, but unlikely to see device-specific patches nor firmware patches. Your device isn’t getting the same care and attention that active devices are receiving nor will it receive any future versions of Android through GrapheneOS.

I believe it’s mostly drawing tablet support in Qt and in turn porting to Qt6 that’s holding native Wayland builds back.

The question that I have to ask: what category of CLI apps (or even some examples) exist that are too complex to maintain a few versions simultaneously as native packages but are not complex enough to just use an OCI container for them instead?

Largely things look good. It might be a good idea looking for a motherboard that has Intel ethernet rather Realtek. I’m also a bit curious if the barebones VRM design on the board is adequate as well.

We are well beyond the point of a majority of common hardware having built-in kernel drivers and userland software for extra stuff like RGB control that the best advice is rather avoiding Linux, to instead avoid the trash hardware (NVidia for the time being, GoXLR, Broadcom, etc.). My GPU, audio hardware, network interfaces are both popular products and have worked out of the box for years now.

The worst gotchas and limitations I have seen building my own self-host stack with ipv6 in mind has been individual support by bespoke projects more so system infrastructure. As soon as you get into containerized environments, things can get difficult. Podman has been a pain point with networking and ipv6, though newer versions have become more manageable. The most problems I have seen is dealing with various OCI containers and their subpar implementations of ipv6 support.

You’d think with how long ipv6 has been around, we’d see better adoption from container maintainers, but I suppose the existence of ipv6 in a world originally built on ipv4 is a similar issue of adoption likewise to Linux and Windows as a workstation. Ultimately, if self-rolling everything in your network stack down to the servers, ipv6 is easy to integrate. The more one offloads in the setup to preconfigured and/or specialized tools, the more I have seen ipv6 support fall to the wayside, at least in terms of software.

Not to mention hardware support and networking capabilities provided by an ISP. My current residential ISP only provides ipv4 behind cgnat to the consumer. To even test my services on ipv6, I need to run a VPN connection tunneling ipv6 traffic to an endpoint beyond my ISP.