

Most people’s routers are already up 24/7.
We should be able to do our own DNS. Who cares if it is on the wider clearweb. You are paying for an IP address with your internet connection. If you are running a server with verified hardware and signed code, all we need is a half dozen nodes mirroring our own DNS. There must be a backup proxy for the few terrible providers that cause issues with IP. The addresses are not static, but they do not change very often. At worse, you hit a manual button to reset or wait 10 minutes before the DNS updates.






Not in terms of kernel supported encodings and long term kernel support, from what I have seen. I have not looked into this in depth. However, looking at git repo merged pulls, issues raised, and the lack of any consistent hardware commitments or consensus, implies to me that the hardware is very unstable in the long term. When I see any hardware with mostly only base Debian support, it screams that the hardware is on an orphaned kernel and will likely never get to mainline. The same applies to Arch to a lesser degree. Debian has the primary tool chain for bootstrapping and hardware hacking. When it is the primary option supported, I consider the hardware insecure and unsafe to connect to the internet. I’ve seen a few instances where people are talking about the limited forms of encoding support and the incomplete nature of those that do exist. It is far more important to have hardware that will be supported with mainline kernel security updates and is compatible with the majority of encodings. It would be terrible to find out the thing could not support common audio or video codecs. IIRC there was an issue along these lines with the RISC-V PineTab.
I know the primary goto for RISC-V is SiFive, but I have not seen a goto LTS processor from them in terms of third party consistent use.
Plus, while more open is mor betterer, RISC-V is not full proof from a proprietary blob either. The ISA addresses the monopolistic tyranny and extortion of players like Intel, but there is nothing preventing the inclusion of 3rd party proprietary module blocks. The entire point is to create an open market for the sale and inclusion of IP blocks that are compatible with an open standard. Nothing about these blocks is required to be open. I don’t know if such a thing could be set to a negative ring more privileged than the kernel, but I expect this to be the case.