A couple things to check using a quick bash script:

#!/usr/bin/env bash

cd /sys/class/power_supply/BAT*/
echo "Charge cycles: $(cat cycle_count)"
printf '%s\0' 'Health: ' &
bc <<< "scale=3; ($(cat charge_full) / $(cat charge_full_design)) * 100"

That should print out the wear cycles the battery has endured and its reported capacity over design capacity. If your battery has less than 1000 cycles and the health reported from the battery is less than 80%, it might be best to contact Framework for warranty replacement as the battery is likely defective.

Just note that with Bambu printers about past data collection practices and their in general mid to atrocious after-sales support. If this doesn’t deter you, then go ahead and get one.

I do a lot of my functional parts in ABS, ASA though printing such material may be difficult on an open-air machine. The two obvious choices will generally be PLA or PETG. PLA is one of the most common printed materials, and is fairly balanced in material strength. PETG parts are more likely to permanently deform heavily before fully snapping, as well as they have a but more temperature resistance than PLA. Additionally most PETG plastics hold up decently well to UV, often making them more suitable for parts that need to be outdoors.

PLA takes not much consideration on surface to print, as most printers come with a smooth PEI build sheet by default. It will however need more cooling than printing with PETG at equivalent speeds. If you use a PEI sheet for PETG, make sure it is textured. You will destroy a smooth sheet if it doesn’t have some kind of release coating to lower its adhesive properties to PETG.

There is no guarantee for spools of filament to actually arrive dry, so a filament dryer isn’t a bad idea. I don’t have any particular recommendations for a good filament dryer. I have a Filadryer S2 from Sunlu, but am not impressed by it.

For multi-monitor: use Wayland. For 2.5Gbps Ethernet NICs, they never work properly on any system in regard to performance, but I presume you are referencing the subpar Realtek NICs not connecting? Depending on the distro, you likely won’t have the driver and/or firmware package preinstalled to make it work.

As I understand it, this driver isn’t ready for personal use unless you don’t care about the contents of your btrfs partitions mounted on Windows.

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.

The easiest ways to run custom executables for Proton titles is either going to be SteamTinkerLaunch or my shim script.

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.

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.

The specific patent links seem to be broken. All return 403. Here are functional alternatives.

• 9421713
• 9592660
• 7555357
• 9168698 / 10556381

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.