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.
jrgd
joined 9 months ago
It was indeed carrier locked, which was why I used it as trade-in value for a phone rather just selling it and later buying a newer phone.
In my case, AT&T sent me a Galaxy Note 9 to replace my Google Pixel XL, which I ended up never using and just used a trade-in value to get a Pixel 5a.
The easiest ways to run custom executables for Proton titles is either going to be SteamTinkerLaunch or my shim script.
The potential common cause points toward the GPU drivers (note of games in Proton, libgtk4 segfaults, and libnvidia-glcore segfaults). What nvidia driver version is in use. A quick search found a rough match to shown symptoms, but is recent and matches the hardware (NVidia Polaris desktop). Perhaps the driver version in use exhibits a similar showing of a regression for such GPUs?
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?
Both not possible and unnecessary on Wayland.
The flatpak documentation has a semi-relevant page on setting up a flatpak repo utilizing gitlab pages and gitlab's CI runners on a pipeline. Obviously, you'd need to substitute Gitlab Pages for a webserver of your choice and to port the CI logic over to Gitea Actions (ensuring your Gitea instance is setup for it).
A flatpak repo itself is little more than a web server with a related GPG key for checking the signatures of assembled packages. The docs recommend setting up the CI pipeline to run less on-commit to the package repos and more on the lines of checking for available updates on interval, though I imagine other scenarios in a fully-controlled environment such as a selfhosted one might offer some flexibility.
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.
I know ArchLinuxArm (a fork of the ArchLinux project) supports the Hisense C11. It does seem to be a fairly involved procesd, and (potentially?) requires using external media rather than the onboard eMMC storage to boot a Linux system.
Your particular Chromebook contains the same SoC (Rockchip RK3288) as an Asus C201, which Debian has an install guide for. Once again, a fairly involved process and this one may not be guaranteed to work if the C11 has some quirks not present in the C201.