Generic notes on running local AI and reaching Windows Caddy *.local sites from an Omarchy (Arch) box.
What this note covers
Omarchy is an Arch-based desktop environment useful as a local AI and app-test box. These notes are generic setup learnings — not a machine inventory.
Local AI on Omarchy (Polaris-era AMD)
Omarchy ships first-party Ollama packages. On AMD Polaris GPUs (RX 400/500), prefer the Vulkan build (ollama-vulkan) over ROCm: ROCm often does not support Polaris, while RADV Vulkan does.
On very old CPUs without AVX, treat GPU offload as required for usable local LLMs; CPU-only modern builds are a poor fit.
Start with a small quantized model (~3B) when system RAM is ~8 GiB even if VRAM is 8 GiB.
Enable the systemd unit and use the OpenAI-compatible HTTP API on 127.0.0.1:11434 for app integration; non-interactive ollama run can hang without a TTY.
Reaching Windows Caddy *.local sites from Linux
.local is reserved for mDNS. If nsswitch.conf lists mdns_minimal [NOTFOUND=return] before files, entries in /etc/hosts for something.local will never apply. Put files first (or avoid .local and use .lan / .test).
When Caddy runs as a Windows service (LocalSystem), its internal CA root lives in the service data directory — not the interactive user’s AppData\Roaming\Caddy tree. Trusting the user-profile root.crt can look correct (same CN) but still fail TLS verify. Fetch the live root from the Caddy admin API (/pki/ca/local) or the SYSTEM profile PKI, then trust anchor + update-ca-trust on Arch/Omarchy.
HTTPS-only local stacks (no port 80) will time out on plain HTTP even when DNS/hosts and ping succeed.
USB Wi-Fi soft hangs under load on older EHCI hosts are a hardware/driver issue (rtw88), not Omarchy-specific — see USB Wi-Fi soft hang (Omarchy notes).
Ai disclosure: written with the help of AI (ChatGPT). You are encouraged to point out errors and omissions.
