fcitx5 自带的拼音对日常够用，但词库薄，长句和专业词差点意思。换成 fcitx5-rime 中州韵搭配雾凇拼音开源方案，词频和补词明显更好，而且不用换框架,Rime 作为引擎和现有拼音并存，想用哪个切哪个。
这篇记录在 Ubuntu 26.04 上装 fcitx5-rime、部署雾凇拼音方案、预编译词库、自定义配置的完整流程，以及几个容易踩的点。顺带把字体和候选框外观一起整理了：装 Maple Mono 编程字体，给 fcitx5 候选框换 catppuccin 主题和中文字体。
fcitx5 输入法框架是怎么工作的理解框架和引擎的区别，能帮你定位大部分输入法问题。
fcitx5 是输入法框架,本身不提供具体输入逻辑。它通过环境变量挂接到应用：
GTK_IM_MODULE=fcitx 让 GTK 程序把按键事件交给 fcitx5
QT_IM_MODULE=fcitx 对 Qt 程序同理
XMODIFIERS=@im=fcitx 是 X11 层的兜底
这几个变量都指向 fcitx,所以 GTK、Qt、X 应用都会走 fcitx5。如果某个程序输入法不生效，第一步就是查它们有没有 ...
内网部署 Jenkins 时一旦启用 HTTPS 并用自签证书，Windows 节点基本连不上。原因是 JVM 不读 Windows 系统证书库，自签证书必须手动导入 Java 自己的 trustStore。加上中文 Windows 下 PowerShell 和 JVM 默认都是 GBK 编码，构建日志里的中文很容易变成乱码。下面是我在生产环境用过的一套流程，包含背后的机制和踩过的坑。
为什么会出问题三个问题都源于同一件事：Jenkins 节点是一个跑在 JVM 里的 Java 程序，而 JVM 的证书和编码体系跟操作系统是两套。
证书体系是独立的。 Windows 把自签证书放进「受信任的根证书颁发机构」后，浏览器和 .NET 程序就认了。但 Java 不读 Windows 证书库，它有自己的 trustStore，默认在 $JAVA_HOME/lib/security/cacerts（JDK 8 是 jre/lib/security/cacerts）。节点连 HTTPS 的 Jenkins 时，JVM 用这个 trustStore 验证证书链，自签证书不在里面就直接报 unable ...
WSL 2 跑在轻量虚拟机里，有自己的 Linux 内核，自然也有自己的 USB 设备树。插在 Windows 上的 J-Link、USB 转串口模块,WSL 2 默认看不到。这不是 bug,是架构使然。要在 WSL 里烧 STM32、看串口日志，得想办法把 Windows 侧的 USB 设备塞进 WSL 2 这台虚拟机。
微软官方给出的答案就是 usbipd-win。它是一个开源项目，在 Windows 上实现 USB/IP 协议服务端，把 USB 设备通过网络转发给 WSL 2 内核。下面记录我用它共享 J-Link 和串口做 STM32 开发的完整流程，以及踩过的几个坑。
为什么 WSL 2 看不到 USB 设备先说清楚问题来源。WSL 1 和 Windows 共享内核，所以 COM 口能直接映射成 /dev/ttyS*。WSL 2 不一样，它是一个真正的 Hyper-V 轻量级虚拟机，跑着自己独立的 Linux 内核(微软维护的 WSL2 内核)。一个 USB 设备要么挂在 Windows 的驱动上，要么挂在 WSL 内核的驱动上，不能同时挂两边。Windows 拿着 ...
管理多台 Windows 服务器时，通过远程桌面逐台登录执行重复配置，低效到让人难以忍受。Linux 那边有 SSH 配合脚本就能批量操作，Windows 长期以来缺少顺手的方案。Ansible 的 Windows 支持通过 WinRM 协议打通了这条路，控制机留在 Linux，被管机器不需要装 agent。
WinRM 是什么，为什么不用 SSHWindows 没有 SSH（直到 Server 2019 才原生支持 OpenSSH），但自带了一套远程管理协议 WinRM（Windows Remote Management）。它是 WS-Management 标准的微软实现，基于 SOAP over HTTP，默认监听 5985（HTTP）和 5986（HTTPS）两个端口。Ansible 对 Windows 的支持就建立在 WinRM 之上。
和 Linux 那边 Ansible 通过 SSH 调 Python 模块不同，Windows 被管节点上不需要装 Ansible 客户端，也不需要 Python。Ansible 把模块代码通过 WinRM 推过去执行，依赖的是 Windows ...
系统自带的 Python 是给 apt、yum 这类工具用的，版本由发行版钉死，想升级或装一个仓库里没有的版本，基本只能源码编译。内网隔离环境下更是连 apt install 都连不上仓库，把源码包带进去编译几乎是唯一可靠的路子。
下面是我常用的流程，重点说清楚几个关键点：为什么不用包管理器、--prefix 和 make altinstall 各起什么作用、离线环境怎么处理依赖。
为什么不用包管理器Debian/Ubuntu 的 python3 跟发行版绑定，Ubuntu 22.04 默认是 3.10，想跑 3.13，apt 仓库里多半没有。即便有 deadsnakes 这类 PPA，内网也访问不了。
更关键的是系统 Python 不能动。apt、yum 和一堆系统脚本都依赖 /usr/bin/python3，一旦覆盖或改了它的软链接，包管理器先坏，连锁反应能把系统搞瘫。新版本必须装到独立目录，跟系统的彻底隔开。
源码编译能同时解决这两件事：精确指定版本，安装到任意路径，跟系统 Python 互不干扰。
准备工作
root 或 sudo 权限
至少 500MB 磁盘空间，编 ...
问题：节点必须登录才能拉起自动化测试环境里有 5 台 Windows 10 机器作为 Jenkins 节点，Master 是一台 Ubuntu。公司安全策略要求服务器必须设密码，所以我之前试过的开机自启方案都用过：计划任务、shell:startup 启动文件夹。这俩有同一个毛病，必须有用户登录到桌面才会执行。
结果是每次服务器重启之后，不管定期维护还是意外断电，我都得手动 RDP 上去敲一次密码登录，Jenkins 节点才会起来。凌晨三点重启一次，第二天上班发现整夜的自动化测试全没跑。
这种依赖登录的方案本质就不对。要彻底解决，得让节点以系统服务的方式开机即起，跟用户会话脱钩。
第一次尝试：sc 命令注册服务Windows 服务正好满足需求：开机自动启动，不需要用户登录，跑在后台会话里，还能配失败重启策略。
用管理员身份开 cmd，sc 命令注册服务：
1sc create "JenkinsNodeService" binPath= "\"[Java安装路径]\bin\java.exe\" -jar \"[Jenkins工作 ...
ESP32 开发绕不开 ESP-IDF。在 Windows 上原生机装一套也能跑，但 CMake、Python、make 这些工具在 Windows 下总有些水土不服，碰到组件脚本里写死 Linux 路径就更头疼。这篇文章记录我在 WSL2 Ubuntu 下搭 ESP-IDF 的过程，顺便讲清楚工具链机制和串口烧录这块的取舍。
为什么选 WSL 而不是原生 Windows 或虚拟机先说结论：ESP-IDF 官方提供 Windows 安装器，能用，但开发体验不如 Linux。原因有几方面。
第一，ESP-IDF 的构建系统基于 CMake 加 Ninja，大量组件脚本（Python、shell）按 POSIX 假设编写。Windows 下偶尔会遇到路径分隔符、符号链接、shell 调用之类的问题，排查起来打断节奏。
第二，ESP-IDF 的文档和社区示例默认 Linux/macOS，复制粘贴一条命令就能跑的概率更高。
虚拟机方案能解决工具链问题，但开销大：要分配独立内存和磁盘，文件在宿主机和虚拟机之间来回拷，启动慢。WSL2 给的是真正的 Linux 内核，启动几乎瞬时，和 W ...
国内用 pip 装 Python 包，默认从 pypi.org 拉取，速度常常只有几十 KB/s,甚至直接超时。根因是请求要绕到海外的 CDN,换个国内镜像源就能解决。
下面讲清楚镜像源到底改了什么，以及临时、永久、用户级三种配置方式的区别和各自的坑。
默认源为什么慢pip 安装一个包时做两件事：先从 index-url 拉取该包的版本列表(有哪些版本、每个版本的下载链接),再从列表里的链接下载真正的 wheel 或 sdist 文件。
默认 index-url 是 https://pypi.org/simple。PyPI 本身只是个索引，实际包文件托管在 files.pythonhosted.org,CDN 节点主要在海外。所以哪怕你带宽够，单连接到海外节点的延迟和丢包就足以把速度压下来。
换成镜像源后，镜像站既提供版本列表，也直接提供文件下载，两步都走国内服务器，这是速度差别的来源。
临时换源：只对单次命令生效1pip3 install requests -i https://pypi.tuna.tsinghua.edu.cn/simple
-i 参数只对这一条命令生效 ...
Jellyfin 是一个开源的媒体服务器，把 NAS 里的电影、剧集、音乐整理成可以在手机、电视、浏览器上直接播放的流媒体库。本文记录我在飞牛 OS 上用 Docker Compose 部署它的过程，顺带聊聊硬件转码和权限这块的取舍。
为什么用 Docker 部署直接装在系统里也不是不行，但媒体服务跑久了会涉及依赖升级、用户隔离、日志位置之类的问题。用容器隔离更干净，更新就是重新拉镜像，迁移到别的机器只要带走 compose 文件和配置目录。飞牛 OS 自带应用商店里的 Jellyfin 版本偏旧，这也是我选 Docker 的直接原因。
准备工作下面几个条件需要先满足：
已配置好 Docker 和 Docker Compose 环境
NAS 已开启 SSH 并能正常连接
国内网络环境下，给 Docker 配好国内镜像加速，否则拉镜像会超时
如果还没装 Docker,以 Ubuntu 为例：
123456789101112# 更新软件包列表sudo apt update -y# 安装 Dockersudo apt install -y docker.io# 安装 Docker Com ...
C/C++ 项目里代码风格之争是个没完没了的话题。与其在 Code Review 里逐行争论大括号该放哪、缩进用几个空格，不如用 clang-format 把规则固化成文件，让工具自动处理。这篇文章讲清楚 .clang-format 的文件机制、几种预设风格的取舍、关键配置项的含义，以及怎么在团队里真正落地。
clang-format 解决什么问题clang-format 是基于 Clang 的代码格式化工具，支持 C、C++、Objective-C、JavaScript、TypeScript 等语言。它通过读取 .clang-format 配置文件决定格式规则，既能命令行调用，也能集成到编辑器和 CI 里。
它的核心价值不是”格式化得好看”,而是”规则可复现”。同一份配置在任何机器上跑出来的结果一致，这消除了格式争议的根源。手动格式化耗时且容易遗漏,Code Review 里格式问题占用大量精力，这些痛点工具都能覆盖。
.clang-format 文件机制这是很多人没搞清楚的部分。clang-format 在格式化某个源文件时，会从该文件所在目录开始向上逐级查找 .clan ...
