I am under the presumption that the current state of the Intel Arc Alchemist GPUs will likely remain about the same under Mesa even if support is dropped today by Intel. Am I mistaken in the amount of continued driver effort Intel has been putting in for the Mesa GPU drivers?
Obviously if this is true, one should probably remain wary of upcoming Battlemage GPUs.
Just took a couple minutes to install and setup the fork to try it out. Turns out there is a flatpak on Flathub under the id dog.unix.cantata.Cantata that looks to be maintained directly by nullobsi. I'll have to see where rough edges show up, but this fork looks good thus far. A full port from Qt5 -> Qt6 isn't a trivial amount of effort, so mad respect to everyone working on this ported version.
Both not possible and unnecessary on Wayland.
As I am teaching myself right now maintainable selfhost setups using popular apps (admittedly with Kubernetes vs something minimal in functionality like Docker Desktop), there is a lot of complexity involved in getting these services both functional and maintainable while also having to consider the security implications of various setups.
While I agree the concept of self-host is a good thing to advocate, I think the complexity and difficulty involved not just to do it, but to do it right is going to be a straight cliff of a learning curve for those not already technically inclined in databases, networking, and filesystems/block storage.
Honestly, taking the burden of being IT for a reasonable subscription cost for your efforts is a better way to go, especially if the setup allows for expanding your offerings to other members in a localized community.
Wouldn't this still be the superior solution? The article doesn't mention the setup for using ROCm for cards running on amdgpu.
The VRR problems are specifically related to either monitors not supporting Freesync over HDMI or the user running a monitor expecting HDMI VRR to work on HDMI 2.1 specs (>4k@60hz or equivalent bandwidth negotiation requirements). I would concur a small subset of users is correct for the use-cases where this becomes a problem.
What compositor (desktop environment) and distro are you running for things to behave that poorly?
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.
Bazzite pulls its kernel (fsync) from https://copr.fedorainfracloud.org/coprs/sentry/kernel-fsync/packages/. In this case, it is based on kernel 6.8.1.
For rpm-based immutable images, you can always check the project's Containerfile for what package is being pulled for the kernel. On most normal distros, you can also boot into the live image, pull the package cache and check the latest package version for the kernel.
EDIT:
An example for fedora in this instance of 'traditional distro' would be to dnf makecache && dnf info kernel.
This is render offloading, not GPU switching. GPU switching implies switching the primary rendering device (the one power the displays) entirely rather than rendering on a separate GPU and copying the output to the primary.
The desired alternative is not Matrix simply because privacy-conscious, open-source ecosystem vs. proprietary solution is not the goal. Matrix would still generally be terrible for support. What people want is publicly searchable content that is ideally indexed like a wiki. Many will happily settle for issue boards or even forums though. Discord has pathetic search capabilities in comparison to any search engine and has no way to properly and publicly backup information that is posted to the platform. With a website of any kind, one could clone the site for mirroring or simply get a web archive service to crawl relevant sections.
The best three brands with natively-supported hardware:
Pretty much everything else requires a lot more tinkering than just launching SteamVR/OpenVR applications.
Some helpful links for diagnosing compatibility: