从 Linux 到 Windows:复现 Rime 动态日期时间输入功能的完整实践

前言 Rime 本身是一套高度可定制的输入法框架。除了常规的拼音输入、词库管理和候选排序之外,还可以通过 Lua 扩展实现动态内容生成。 一个比较实用的例子,是输入特定拼音后直接生成当前日期、当前时间、星期等内容。例如: 可以分别得到类似: 这些内容不是提前写进词典的静态词条,而是在输入时调用系统时间动态产生。 这一功能最初在 Linux 环境下完成并稳定使用。之后需要将同样的能力迁移到 Windows 上的 Rime,也就是小狼毫 Weasel。 实际迁移过程并不是简单复制一个文件即可完成。Linux 与 Windows 的 Rime 前端、用户目录以及部署行为都存在差异,尤其是在 Windows 上还遇到了重新部署后 build 内容没有正确刷新的情况。 经过多轮检查和最小化修改,最终成功在 Windows 上完整复现了 Linux 下的动态日期时间输入功能。 一、Linux 下的实现结构 Linux 环境使用 Fcitx5 + Rime。 实际生效的 Rime 用户目录位于: 动态日期时间功能主要由三个部分构成: 完整调用链可以概括为: 这说明该功能本质上是一个 Rime Lua Translator。 二、rime.lua:注册 Lua 模块 Rime …

macOS 多系统硬盘启动时反复提示“磁盘不可读取”的处理方法

在一块外置 SSD 上同时安装 macOS、Windows 和 Linux 后,启动 macOS 时可能反复出现下面的提示: The disk you attached was not readable by this computer. 窗口通常提供三个选项: 与此同时,桌面上的 macOS 数据卷以及部分 Windows NTFS 分区可能仍然能够正常显示。这种现象并不一定代表硬盘损坏,更常见的原因是 macOS 扫描到了一个自己无法识别或无法挂载的分区。 使用场景 例如,一块 USB SSD 同时包含: 进入 macOS 后,桌面上可能正常出现类似: 这样的磁盘卷,但系统仍然弹出“磁盘不可读取”的警告。 这说明整块 SSD 并没有无法识别,而只是其中某一个分区没有被 macOS 正常处理。 为什么会出现这个提示 macOS 启动后,Disk Arbitration 会检测当前连接磁盘上的各个分区。 如果遇到 macOS 无法识别或无法挂载的文件系统,就可能弹出: …

Arch Linux KDE 笔记本电源模式配置:启用 Power Profiles 并设置插电与电池策略

在 Arch Linux + KDE Plasma 的笔记本环境中,任务栏的 Power & Battery 小组件可以显示电池状态,并提供 Power Profile(电源模式)切换。 不过在一套新安装或重新配置的系统中,可能会看到: 同时 KDE 还会提示安装 power-profiles-daemon。 这并不代表电池或硬件存在故障,而通常只是系统尚未安装负责提供标准电源模式接口的后台服务。 本文记录完整的检查、安装、验证和 KDE 刷新过程,并给出一套适合日常使用的电源策略。 一、问题表现 打开 KDE 任务栏中的 Power & Battery 后,电池本身可以正常识别,例如: 但是顶部显示: KDE 同时给出类似提示: 这种情况下,电池的充放电、睡眠等基本功能通常仍然正常,只是无法通过 KDE 切换: 三个标准电源模式。 二、首先检查现有电源管理软件 安装新的电源管理服务之前,先检查系统中是否已经存在 power-profiles-daemon 或 TLP: 如果没有任何输出,说明两者都没有安装。 这一点比较重要,因为多个电源管理框架同时运行并没有必要,还可能产生策略冲突。 如果系统已经使用 TLP,则不应在没有明确规划的情况下直接再叠加另一套电源管理方案。 三、安装 power-profiles-daemon 对于 KDE …

如何彻底清空 v2rayA 配置并重新初始化账号

v2rayA 在首次启动时会要求创建 Web 管理界面的用户名和密码。使用一段时间后,如果希望彻底清除旧账号、订阅、节点和路由配置,让 v2rayA 恢复到接近首次安装的状态,可以删除其持久化配置数据。 这种操作与单纯“重置密码”不同。清空配置会删除 v2rayA 中保存的全部管理数据,适合重新部署、设备迁移、清理旧环境等场景。 一、清空配置会删除什么 v2rayA 的持久化数据通常包括: 常见的数据文件包括: 不同版本并不一定同时存在这三个文件,因此删除时通常使用“文件存在则删除”的方式。 清理完成后再次启动 v2rayA,访问: 如果数据库已经成功重置,通常会重新进入账号初始化流程。 二、Linux 下清空 v2rayA 配置 1. 先停止服务 不要在服务运行过程中直接删除数据库文件。 2. 确认实际配置目录 不同发行版和安装方式的配置路径可能不同,因此不要在没有确认的情况下直接执行 rm。 首先检查 systemd 服务: 还可以查看: 常见配置位置包括: 如果路径不明确,可以搜索数据库: 这样可以先找到真正的数据文件,再决定删除哪个目录中的内容。 3. 删除配置数据库 假设实际配置目录已经确认是: 则可以执行: 如果实际目录不同,应将命令中的路径替换成真实路径。 4. 重新启动 如果需要设置开机自动启动: 或者同时启用并立即启动: 确认状态: 随后打开: 重新完成账号初始化。 三、Windows 下清空 v2rayA …

关闭 Intel MacBook Pro 开盖自动开机功能

部分 Intel MacBook Pro 在完全关机后,只要掀开屏幕就会自动启动。对于希望由电源键明确控制开机时机的用户来说,这种默认行为可能并不方便。 对于较老的 Intel MacBook Pro,可以通过修改 NVRAM 中的 AutoBoot 参数关闭这一功能。 适用范围 本文方法主要适用于带有自动开盖启动功能的 Intel MacBook Pro,例如 2016~2019 年前后的部分机型。 需要注意的是,Apple Silicon Mac 和较新的 macOS 已经存在另一套 BootPreference 设置方法,因此不要直接把新款 Mac 的命令套用到 Intel 机型上。 关闭开盖自动启动 进入 macOS,打开 Terminal,执行: 系统会要求输入当前管理员账户的密码。 如果命令执行后没有显示错误信息,通常意味着参数已经成功写入 NVRAM。 检查当前设置 可以执行: 如果返回类似: 则说明当前已经设置为关闭自动启动。 实际验证 最可靠的确认方式不是只看命令输出,而是进行一次实际测试: 如果此时 MacBook 保持关机状态,需要主动按下电源键才能启动,说明修改已经生效。 恢复默认行为 如果以后希望重新启用“开盖自动启动”,执行: …

用命令行恢复被 PE“隐藏分区”占用的 U 盘空间

制作 PE 启动盘之后,有时会遇到一种比较典型的情况:原本标称 32GB 的 U 盘,在 Windows 资源管理器中只显示二十多 GB,剩余空间既没有盘符,也无法直接访问。 一些 PE 制作工具会把这类结构称为“隐藏分区”“高端隐藏分区”或类似名称。实际上,从磁盘管理角度看,它通常只是 PE 制作工具额外创建的启动分区、隐藏分区,或者经过特殊处理的分区结构。 如果后续不再需要 PE,希望把 U 盘重新恢复成普通存储设备,可以直接使用 Windows 自带的 DiskPart 完成,不需要依赖第三方分区软件。 一、问题表现 例如,一块标称 32GB 的 U 盘: 这种情况下,问题通常不在文件系统,而在物理磁盘的分区结构。 例如: 但查看物理磁盘: 物理磁盘有 30GB,而可见卷只有 25GB,说明还有部分空间没有包含在当前可见卷中。 二、首先确认 U 盘对应的物理磁盘 这是整个操作中最重要的一步。 DiskPart clean 会直接清除目标磁盘的分区表。如果选错磁盘,可能导致系统盘或数据盘的分区全部消失。 因此不能仅凭“容量差不多”判断磁盘编号。 以管理员权限打开 Windows Terminal、PowerShell 或命令提示符: 首先查看卷: 找到 U …

iMac 2017 在 Linux 下的内置麦克风:它究竟是什么时候开始工作的?

一台 2017 年款 iMac 长期运行 Arch Linux。扬声器、无线网卡、蓝牙、摄像头和麦克风这些在 macOS 下理所当然可以工作的内置设备,到了 Linux 下却有着完全不同的兼容性表现。 其中最特殊的是内置麦克风。 摄像头的问题很简单:硬件年代较早,与现在的 2K USB 摄像头相比,画质已经明显落后。蓝牙同样受到硬件世代限制。无线网卡的情况稍有不同,硬件本身并不差,在 Windows 下表现仍然很好,Linux 下的问题更多来自驱动兼容性。 麦克风则完全不同。 这块内置麦克风本身的录音质量并不落后,实际测试甚至不逊于现在常见的 USB 摄像头集成麦克风。过去之所以长期被认为“不能用”,问题主要出在 Linux 驱动和音频栈,而不是麦克风硬件本身。 意外发现:拔掉 USB 麦克风以后,内置麦克风竟然还能工作 这台机器平时连接着一台 2K USB 摄像头,同时也把摄像头自带的 USB 麦克风作为录音设备使用。 一次系统完整升级后,系统依次更新了 Arch 官方仓库软件、AUR 软件以及 Flatpak 应用,并重新启动进入新内核。 这次升级后的声音输出完全正常。 随后在测试音频设备时,USB 摄像头被物理拔掉。本来预期系统应该因此失去可用麦克风,结果却发现录音仍然正常。 检查 PipeWire 后确认,正在工作的并不是已经拔掉的 USB 麦克风,而是 iMac 自己的内置麦克风。 …

Running Background Programs at Windows Startup with Task Scheduler

Windows applications do not always need to be installed as Windows Services to run continuously in the background. For lightweight command-line programs, agents, proxies, synchronization tools, and similar utilities, Task Scheduler provides a built-in and relatively clean way to achieve: This article uses a generic command-line program named agent.exe as …

Windows 11 and SSH: Understanding Remote Connections, Keys, and Authentication

Windows 11 includes native support for OpenSSH, which means it can work both as an SSH client and as an SSH server. This makes it possible to manage Linux servers directly from Windows, connect remotely to Windows from Linux, transfer files with SCP/SFTP, and use public-key authentication without installing third-party …

网站主页已经更新,浏览器却仍然跳转到旧地址:一次缓存问题的排查记录

网站改版之后,有时会遇到一种看起来很像服务器配置错误的问题: 服务器上的主页已经更换,旧的跳转逻辑也已经取消,但访问网站根地址时,浏览器仍然自动跳转到过去使用的旧页面。由于旧页面已经被删除或停止使用,最终看到的往往是一个 404 Not Found。 这种现象很容易让人误以为 Apache、Nginx、VirtualHost 或 Rewrite 规则仍然存在问题。 实际上,问题也可能完全发生在浏览器端。 问题场景 假设网站过去采用如下结构: 根目录中的主页负责判断访问设备,然后将桌面浏览器跳转到: 移动设备则可能跳转到另外一个页面。 后来网站进行了调整,新的主页直接部署到了根地址: 因此旧的: 已经不再需要,甚至已经被删除。 服务器配置也已经更新。 但某些此前访问过网站的浏览器再次打开: 时,仍然立即进入: 随后返回 404。 此时需要先判断一个关键问题: 跳转到底发生在服务器端,还是浏览器端? 最简单的判断方法:使用隐身窗口 可以先使用浏览器的 Incognito / Private Window 打开网站根地址: 如果隐身窗口能够正常显示新主页,而普通窗口仍然跳转到旧地址,那么服务器通常已经没有问题。 问题基本可以锁定在: 浏览器缓存。 隐身窗口不会直接使用普通浏览器 Profile 中已经保存的大部分站点缓存,因此相当于进行了一次相对干净的访问测试。 这个方法非常适合快速区分: 和: 使用 Chrome DevTools 强制刷新缓存 在 Chrome 中,可以使用开发者工具强制重新请求网站资源。 操作步骤: 此时 Chrome …