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 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.
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.
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.
Generally, yes. It’s not nearly as bad as say 2015 but NVidia has a long standing history of being difficult to deal with, and users having to make constant compromises. For instance, NVidia hasn’t had properly working Wayland support on most environments until recently due to the awful flickering that many users experienced. Things like power saving, dual GPU handoff, general OpenGL performance, frame stability and tearing (X.Org), etc. have been either historical and/or current pain points for using NVidia GPUs vs AMD or Intel GPUs.
For many with unstable ISP connections, http downloads can get corrupted. Torrents are superior in this regard as the file gets split into blocks that each get checksummed for integrity after completion. This helps to ensure that the large iso is actually complete and won’t just be garbage on an attempted install. Even if you checksum the iso from http download, you have to pull the entire thing again if it is damaged whereas the torrent would just repull the damaged blocks automatically.
2-2-1 still insinuates having a remote backup. I don’t see how this particular threat destroys a 2-2-1 setup.
I’d imagine mpd with one of many frontends would work well enough. You’d just need to use a dummy music library directory with symlinks to your four music storages for mpd to pick up and catalog everything.
On my Fedora KDE install on 40, hibernate is now an available power option. The install has been in upgrade cycles since 35 at this point. I would imagine that barring different DEs showing different power options being a possibility, it is more on detecting hardware compatibility for functional hibernation.
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.
In general, Microsoft doesn’t support many filesystem formats at all. In the same way you shouldn’t attempt to cross-run a steam library from Windows on Linux, you really shouldn’t do from Linux to Windows. It’s in part due to how permissions, execution flags, filesystem case sensitivity, file metadata, is interpreted by Windows applications vs. Unix-like applications. There will be issues going either way when using foreign filesystems in complex tasks.
While it should be expected that the files will have the same contents where they are actually the same (i.e. a Proton game will be the same as a Windows game as it comes from the same steam depot), there is a good chance that translation of interpretation isn’t to be 1:1 on either side. Furthermore with using Steam libraries, Steam includes additional data beyond just the game files, which is likely why they are invalidated. A significant portion of visible cross-os portability issues is due to many applications like Steam using OS-specific file structures. More than likely Steam is going to intentionally make the library metadata not fully compatible between Linux and Windows Steam and force validation before launch because there is a good chance the games aren’t even compatible builds or otherwise have additional compatibility content dragged along (such as Proton WINE prefixes that are to be completely ignored when launching from actual Windows or having additional libraries, modded executable binaries that have platform-oriented patches).
If you seriously want to run a cross-share of a Steam Library between Linux and Windows, you should really utilize Steam Cloud save. If you want to “deduplicate” your games, your best bet would be if you can open the foreign fs and have a compatible copy of the game, to simply clone the game files to the current filesystem and remove from remote rather than attempt to force a multi-os single-partition shared library. You are less likely to destroy your Steam library if you treat the actual libraries separate, but move the games like they were downloaded externally. Barring being able to do that, just don’t cross-share games. Simply reboot into the OS that has the game you want to play instead.
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.