This article introduces how to use Podman and Quadlet to elegantly migrate traditional Compose configurations to the Systemd management system. Using Immich as an example, it details configuration conversion, environment adaptation, and automated deployment processes, helping you achieve declarative, system-level hosting of container services.
This article provides a detailed guide on how to generate and migrate GPG keys, helping you achieve Git commit signing across multiple devices and easily obtain the GitHub “Verified” badge.
This article explains how to quickly set up a lightweight private Git server with HTTPS support and basic authentication using Caddy2 and containers. It’s perfect for scenarios that don’t require full GitLab/Gitea functionality, offering simple configuration, security, and efficiency for personal or small team self-hosted code hosting platforms.
This article introduces a simpler and more efficient Syncthing multi-device synchronization solution: instead of building complex discovery and relay servers, simply run a standard Syncthing client on an always-online device (like VPS, NAS) as the ‘hub node’ for all devices. This approach not only greatly simplifies configuration and maintenance but also balances data redundancy, asynchronous synchronization, and security.
This article provides a detailed guide on how to build cloud storage direct links using Alist/Openlist/Rclone and combine them with Syncplay to achieve remote multi-person high-quality, millisecond-synchronized movie watching. Perfect for users who want to share viewing experiences with distant friends and family while pursuing the ultimate experience.
This article introduces how to enable Userspace Networking mode and built-in SOCKS5 proxy on Windows systems by modifying Tailscale service startup parameters, allowing specific applications to use Tailscale network proxy on demand while avoiding global traffic hijacking and improving usage flexibility
Create virtual displays using Virtual-Display-Driver, combined with Sunshine streaming server and Moonlight client, to turn Android phones, tablets, and other idle devices into wireless extended screens for Windows computers. This tutorial provides detailed configuration steps for all three tools to achieve an efficient screen extension solution within the same local network.
In Go, error handling is a core design philosophy. Through explicit error return values (the error type), developers must face potential problems head-on. However, many developers new to Go (and even experienced developers) often make a mistake: directly returning the original err. This seemingly simple behavior actually buries hidden dangers for code debugging and maintenance.
Problems with Directly Returning err 1. Opaque Error Information When you directly return err in multi-layer nested function calls, upper-level callers may have no idea where the error originated:
Recently, Deepseek released the R1 model, which has been extremely popular online. Having some free time, I decided to deploy the 7b version to play around with it.
Using ollama can simplify the deployment process. After installing ollama with yay -S ollama, start the service with sudo systemctl start ollama, then run the command ollama run deepseek-r1 to begin chatting.
However, I quickly noticed something was wrong - why was the generation speed so slow? Checking the task manager, I found that inference was running on CPU without any GPU acceleration, so I started troubleshooting.
Looking at the ollama service logs with journalctl -u ollama -f, I found a warning: no cuda runners detected, unable to run on cuda GPU, but I obviously have CUDA drivers installed.
So I searched online extensively and was speechless when I found the solution. In the AUR repository, besides ollama, there’s also ollama-cuda - you need to install both to enable CUDA acceleration.