在 Raspberry Pi 5 的 AlmaLinux 10.1 aarch64 上，我將 NVMe SSD 的 root 分割區以 LUKS2 加密，並設定開機時略過輸入密碼片語。Raspberry Pi 韌體會讀取的 /boot 保持未加密，透過 initramfs 內的金鑰解除加密的 root。

參考先前寫的 在 Windows 上以 CUDA 建置 llama.cpp 的文章，這次在 Fedora 43 環境嘗試相同的做法。只有工具鏈不同，流程幾乎一樣。

這是一份在 Windows 11 環境下，將本機 LLM 推理引擎的代表作 llama.cpp 從原始碼編譯、啟用 NVIDIA GPU 的 CUDA 後端，並實際執行模型的紀錄。

依照上一篇文章的步驟建立了 SSH X11 轉發環境,xeyes 順利顯示在 Windows 端。然而 nautilus 卻怎麼都啟動不了。這是一篇記錄「明明 DISPLAY 已經正常運作,為什麼偏偏這個應用程式會當掉」的排查過程。

這台 Fedora 43 Server 既沒有安裝 X 伺服器,也沒有安裝桌面環境。現在想從這台機器把 GUI 應用程式顯示到 Windows 電腦上。這是一篇不安裝桌面環境,改用 SSH X11 轉發只傳送「單一應用程式」的紀錄。

為了讓自家 LAN 的名稱解析更快、同時封鎖廣告，架設了一台 DNS 伺服器。上游使用 Cloudflare 的 1.1.1.1。沒有使用 Pi-hole，而是用機器上早已安裝好的輕量 dnsmasq 就完成了整套設定。這篇記錄了整個過程，包括踩到的 SELinux 問題。

本文整理了將 document.tex(採用 ltjsarticle 文件類別，以 LuaTeX-ja 為前提)以 LuaLaTeX 轉換成 PDF 所需的環境建置步驟。以 Windows + winget 為前提。

為了應付想把 Markdown 撰寫的文件轉換成 Word (docx) 的情境，打造了完全在瀏覽器內完成作業的編輯器「DOC」。內文不會傳送到伺服器，轉換作業也全部在瀏覽器內完成。

「docx 說到底不就是 zip 嗎? 那把 XML 壓成 zip 再改個副檔名，不就變成 docx 了?」

抱著這個想法實際試了一下，結果理所當然地失敗了。docx 並不「只是」zip 而已，zip 裡的內容必須遵循一套固定的封裝結構，也就是 OOXML (Office Open XML)。既然都動手了，就順便實際驗證一下，到底要做到什麼程度才能做出貨真價實的 docx。

在嘗試透過 myhost.local (mDNS) 存取同一區域網路內的 Fedora Server 時,遇到了唯獨名稱解析失敗的狀況。透過 tcpdump 直接觀察封包進行排查後,發現原因是 firewalld 封鎖了 mDNS 的傳入流量。