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.

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.

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 as 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?

Godot maintains a fairly comprehensive documentation that can even be fully downloaded.

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.

The headphones you have don't have any actual surround sound capabilities. The only thing they do is have a software driver that maps a set of channels from 7.1 surround sound to the binaural sound mapping of the headphones.

The pipewire sound server can do the same thing as iCue with filter chains and specific plugins. See this post for some pointers and guidance if you wish to set it up for yourself.

Do note that unless you have content built with actual 5.1 or 7.1 surround sound, there won't be much actual benefit to using virtual surround sound on headphones in the first place.

As I found out recently myself, you should almost always set the minimum amount of reserved memory for the iGPU on modern hardware. The reserved memory is just that— reserved. The kernel still dynamically allocates memory for GPU usage as needed on iGPUs.

Alongside many others, I agree that using QEMU through GUI frontends like virt-manager or GNOME Boxes, or even server-focused solutions like Cockpit+VM plugin or Proxmox layered on top of your installation.

I just want to note a decent point against other solutions like VirtualBox or the VMWare products that work on Linux: these solutions that don't rely on QEMU almost certainly need the user to install out-of-tree kernel modules (that in some cases may also be proprietary). QEMU and its frontends don't need out-of-tree modules in a majority of distros and can work out of the box with all features (given BIOS configuration of the host and hardware supports them).

I started dual booting Linux after an upgrade to an insider preview of Windows 10 soft-bricked my Windows 7 install. I later stopped booting into Windows and eventually reclaimed the partitions to extend whatever distro was installed at that point when the actual release of Windows 10 decided to attempt automatically upgrading my Windows 7 system, soft-bricking it a second time. 2016 onwards, I haven't used Windows on my systems outside of occasionally booting LTSC in a VM.

Running the same memory constraints on a 1.18 vanilla instance, most of the stack memory allocation largely comes from ramping the render distance from 12 chunks to 32 chunks. The game only uses ~0.7 GiB memory non-heap at a sane render distance in vanilla whereas ~2.0 GiB at 32 chunks. I did forget the the render distance no longer caps out in vanilla at 16 chunks. Far render distances like 32 chunks will naturally balloon the stack memory size.

For clarification, this is Vanilla, a performance mod Fabric pack, a Fabric content modpack, Forge modpack, etc. that you are launching? If it's the modpack that you describe needing 8gb of heap memory allocated, I wouldn't be surprised the java stack memory taking ~2.7 GiB. If it's plain vanilla, that memory usage does seem excessive.

Depending on version and if modded with content mods, you can easily expect Minecraft to utilize a significant portion memory more than what you give for its heap. Java processes have a statically / dynamically (with bounds) allocated heap from system memory as well as memory used in the stack of the process. Additionally Minecraft might show using more memory in some process monitors due to any external shared libraries being utilized by the application.

My recommendation: don't allocate more memory to the game than you need to run it without noticeable stutters from garbage collection. If you are running modded Minecraft, one or more mods might be causing stack-related memory leaks (or just being large and complex enough to genuinely require large amounts of memory. We might be able to get a better picture if you shared your launch arguments, game version, total system memory, memory used by the game in the process monitor you are using (and modlist if applicable).

In general, it's also a good idea to setup and enable ZRAM and disable Swap if in use.

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.