Category: Linux

在 Linux 桌面环境中，字体显示异常有时并不是某一个软件本身的问题，而是系统字体目录、fontconfig 缓存、默认字体匹配顺序、位图字体配置等多个因素共同造成的。本文记录一次字体系统整理过程：在确认异常字体残留已经清除后，对本地手动安装字体进行分类整理，并清理 fontconfig 缓存，使字体系统恢复到比较干净、可维护的状态。 一、确认本地字体目录现状 首先查看 /usr/local/share/fonts 下手动安装的字体文件： 最初的目录结构比较临时化，例如： 这些目录本身并不会导致字体异常，但从长期维护角度看，可读性较差。进一步使用 fc-scan 查看字体实际识别情况： 扫描结果显示，这些字体主要包括： 也就是说，这些并不是未知字体或远程控制软件残留字体，而是手动安装的 Ubuntu、微软雅黑、Windows 中文字体、Times New Roman 和方正字体等。 二、检查位图字体配置 继续检查 fontconfig 中与 bitmap font 相关的配置： 最初只看到： 这并不是禁用位图字体，而是和位图字体缩放有关的配置。系统中同时存在 /usr/share/fonts/100dpi 和 /usr/share/fonts/75dpi 这类老式 X11 位图字体目录。现代桌面环境、浏览器、GTK、Qt、Electron 应用通常不需要它们参与字体匹配。 因此后续启用了： 启用后再次检查： 结果变为： 这表示禁用位图字体的配置已经生效，可以减少老式位图字体干扰现代桌面显示的可能性。 三、整理本地字体目录结构 为了让字体目录更自然、长期可维护，将原来的临时目录名整理成更清楚的分类目录。 创建新目录： 移动字体文件： 删除空目录： 整理后，本地字体目录结构变为： 这样的结构比单字母目录更清晰： 四、刷新 fontconfig …

在 Linux 桌面环境中，中文显示正常，并不代表日文显示也一定正常。中文、日文、韩文虽然都属于 CJK 字符范围，但同一个 Unicode 汉字在不同语言环境下可能有不同的字形习惯。如果系统或网页错误地使用中文字体显示日文内容，页面虽然不会缺字，却会出现字形不协调、假名与汉字风格不统一、整体阅读感很别扭的问题。 本文记录一次日文字体显示异常的排查过程。最终确认，问题并不是系统缺少日文字体，而是由字体优先级、第三方字体残留、网页 CSS 强制指定中文字体等多个因素叠加造成。 一、问题现象 在 Arch Linux 桌面环境中，中文网页显示正常，但日文网页显示明显不自然。具体表现包括： 这种问题容易被误认为是“没有安装日语字体”，但实际情况往往更复杂。 二、先确认系统是否安装了日文字体 可以使用 fc-list 查看系统中支持日文的字体： 如果系统中已经存在类似以下字体，说明日文字体本身并不缺失： 这时问题通常不是“没有字体”，而是“系统实际选择了错误的字体”。 三、检查 fontconfig 实际匹配了什么字体 比 fc-list 更关键的是 fc-match。它可以显示当程序请求某种语言和字体族时，fontconfig 实际返回哪一个字体。 检查日语字体匹配： 异常情况下，结果可能显示为中文字体，例如： 这说明系统虽然有日文字体，但日语 sans-serif 或 serif 实际被中文字体抢走了。 理想状态应该接近： 四、清理不再需要的旧中文字体 如果系统中安装了较旧的中文字体包，例如文泉驿字体，它们可能会参与日文字符匹配。 可以先检查： 如果已经安装了这些包，并且系统中已经有 Noto CJK 或 Source Han CJK，可以考虑卸载： 卸载后刷新字体缓存： 再次检查： …

Thunderbird 是 Linux 桌面上常用的邮件客户端。默认情况下，它启动后通常显示在任务栏中；如果关闭窗口，程序也会直接退出。对于希望长期后台收邮件、但又不想让 Thunderbird 一直占用任务栏空间的用户来说，把它封装成一个“可最小化到托盘”的应用会更符合日常使用习惯。 本文记录一种相对干净的做法：不修改 Thunderbird 本体，不改 profile，不覆盖系统自带启动器，只额外创建一个通过 KDocker 启动 Thunderbird 的 desktop 文件。 基本思路 目标不是改造 Thunderbird 本身，而是在外层加一层启动方式： 这样做的好处是： 确认 Thunderbird 的二进制路径 首先确认 Thunderbird 的实际可执行文件路径： 如果返回： 说明 Thunderbird 是系统原生安装，后续可以直接使用这个路径。 这一步很重要，因为 .desktop 文件里的 Exec= 最好写清楚实际启动的程序，而不是完全依赖环境变量搜索。 不指定 Thunderbird profile Thunderbird 的 profile 通常位于用户目录下，由 Thunderbird 自己管理。虽然可以查看 profiles.ini，但这里不建议手动指定 profile。 原因是：如果系统里有多个 profile，或者 Thunderbird …

有些应用没有正式的 Linux 原生客户端，但提供了浏览器扩展版，或者可以通过 Chromium 系浏览器运行。直接在浏览器里使用当然可以，但体验上总觉得不够独立：它会混在普通浏览器标签页里，也不方便固定到任务栏，更不像一个真正的桌面应用。 这次尝试的目标是：把一个浏览器扩展版的即时通讯工具封装成一个独立的桌面应用。点击图标后，它以单独窗口打开，有自己的图标、自己的浏览器 profile、自己的桌面入口，并且可以最小化到 KDE 系统托盘中。最终效果接近一个原生聊天软件。 一、目标 目标不是安装一个真正的原生 Linux 客户端，而是通过以下方式实现类似体验： 最终希望达到的行为是： 这样它就不会和普通浏览器混在一起，也不会占用日常浏览器 profile。 二、基本架构 整体架构可以分为四部分： 逻辑链条是： 这里的重点是：浏览器程序本体仍然使用系统已经安装好的浏览器，真正独立的是 profile 数据目录和启动方式。 三、项目目录命名 为了长期维护，目录名不建议直接使用过于通用的名字，比如： 这些名字可能和官方应用、浏览器自身 profile、第三方客户端产生混淆。 更合适的是使用一个本地项目式名称，例如： 这个名字不绑定具体浏览器，也不绑定具体技术实现。以后即使从 Brave 换成 Chromium，或者从某个扩展换成另一个 Web App，目录名也不需要改。 目录结构大致如下： 四、启动脚本 核心启动脚本是 launch.sh。 示例： 这里有几个关键点。 –user-data-dir 用来指定独立 profile。这样这个应用不会和普通浏览器共享登录状态、扩展、缓存、历史记录。 –app 用来让浏览器以接近独立应用窗口的方式打开页面，而不是普通浏览器窗口。 –class=ChatApp 用来帮助 KDE / KWin 识别窗口身份。否则这个窗口可能会被归类到普通浏览器下面，任务栏图标也会和普通浏览器叠在一起。 …

在 Linux 桌面环境里，有些应用本身支持“最小化到系统托盘”，比如聊天软件、下载工具、密码管理器、音乐播放器等。但也有很多应用没有这个功能：窗口一最小化，就仍然占在任务栏里；关掉窗口，又可能直接退出程序。KDocker 解决的就是这个问题：它可以把大多数普通应用窗口“停靠”到系统托盘里，让它们像托盘程序一样隐藏、恢复和常驻。 KDocker 的官方描述很直接：它可以把多数应用停靠到系统托盘中，启动 KDocker 后用鼠标选择一个窗口，这个窗口就会被 dock 到托盘里。 它不是 Docker，也不是容器工具 KDocker 这个名字容易让人误会。这里的 “Docker” 不是容器领域的 Docker，而是 “dock” 的意思，也就是把窗口停靠到某个地方。 它的作用不是运行容器，不是管理镜像，也不是服务器工具。它是一个桌面小工具，面向的是 Linux 图形界面用户，尤其适合 KDE Plasma、Xfce、LXDE、Cinnamon 这类有系统托盘区域的桌面环境。 KDocker 能解决什么问题 KDocker 最典型的用途，是让一些需要长期开着、但又不希望占用任务栏空间的应用变得更安静。 比如邮件客户端、聊天软件、浏览器封装的 Web App、同步工具、音乐播放器、RSS 阅读器、笔记软件等。有些应用本身没有托盘功能，或者托盘功能在某些桌面环境下表现不好，这时 KDocker 就可以作为一个外部补丁。 它的思路很简单：不改应用本身，不改应用配置，只是从窗口管理层面把这个窗口收起来，并在系统托盘里放一个图标。需要时点托盘图标恢复窗口，不需要时让它安静待着。 基本使用方式 最简单的方式是直接运行： 然后鼠标指针会进入选择窗口的状态，点击想要收进托盘的应用窗口即可。 也可以直接指定程序启动，例如： 或者指定一个自定义图标： -i 参数用于指定托盘图标路径；Ubuntu manpage 中也列出了其他常见选项，例如 -f 表示 dock 当前获得焦点的窗口，-t 表示从任务栏移除该窗口，-l …

Arch Linux 的软件管理非常灵活，但正因为灵活，系统里一旦启用了多个第三方仓库，就容易出现几个问题： 这次整理的核心，就是围绕 pacman.conf 中的第三方源进行排查、分析和优化，最终把系统源结构从“能用但不清楚”，整理成“官方源优先、第三方源必要保留、镜像线路更合理”的状态。 一、先确认当前启用的软件源结构 Arch Linux 的软件源配置位于： 典型结构如下： 这里最重要的是顺序。 pacman 在查找同名包时，会按照仓库顺序决定优先级。当前结构中，优先级大致是： 也就是说，只要官方源里有同名包，通常优先使用官方源。第三方源只有在前面的源没有同名包时，才会参与选择。 因此，不能简单看到某个包在 archlinuxcn 或 arch4edu 中存在，就直接判断它是从这个第三方源安装的。 二、区分“软件来源”和“包来源” 整理过程中首先需要区分几个概念： 例如 Brave 浏览器： 所以不能说： 更准确的说法应该是： 这个区别非常关键。否则很容易把“软件开发者”“Arch 打包者”“第三方仓库”“镜像服务器”混为一谈。 三、查看哪些包在 archlinuxcn 中存在 可以用下面命令查看当前系统中，哪些已安装包也存在于 archlinuxcn 仓库： 或者只输出包名： 这类命令的含义是： 本地已安装这个包，并且 archlinuxcn 仓库中也存在同名包。 但这并不等于： 这个包一定是从 archlinuxcn 安装的。 因为如果官方源也有同名包，而且官方源排在前面，那么 pacman 默认仍然优先官方源。 更准确的判断方式是排除官方源中也存在的包。 例如，查找“已安装、archlinuxcn 有、但官方源没有”的包： …

背景 在 Arch Linux 系统中，Google Chrome 并不在官方仓库内。常见安装方式通常有三种： 如果系统长期使用第三方源，Google Chrome 可能会出现一个问题：本地已经安装了 Chrome，但版本长期停留在旧版本，无法随系统正常更新。 这类问题表面上看像是 Chrome 本身没有更新，实际往往是包来源发生了变化，或者第三方仓库中的包已经停止同步最新版。 现象 系统中查询当前 Chrome 版本： 输出类似： 而当前 AUR 中的 google-chrome 已经是更高版本，例如： 说明本地 Chrome 已经落后多个大版本。 继续检查外来包： 如果有输出，说明当前这个包已经不属于系统同步数据库中的官方仓库或当前启用的第三方仓库，属于“外来包”。 问题来源 Arch 上如果曾经配置过类似这样的第三方源： 或者其他个人维护源，例如： 那么 google-chrome 可能并不是从 AUR 构建安装的，而是来自某个第三方二进制仓库。 第三方二进制仓库的优势是省去本地编译或打包过程，使用体验接近官方仓库。但问题是：如果该仓库不再及时维护某个包，本地版本就会停滞。 实际升级时可能出现类似情况： 输出却显示： 这说明 yay 并没有去 AUR 获取新版，而是优先使用了同步仓库里的旧版 google-chrome。 关键点在于： 这里的 alerque …

一、问题背景 某台安装 Arch Linux 的 MacBook 在系统升级后再次出现没有声音的问题。 机器使用的是 Cirrus Logic CS8409 相关声卡，需要依赖第三方驱动 snd-hda-macbookpro 才能正常驱动内置扬声器和耳机。此前系统中安装的是 AUR 包： 系统升级后，内核版本变为： 重新安装 AUR 包后，声音仍然无法恢复。因此问题重点不再是“软件包是否安装”，而是要确认： 二、先确认内核、headers 和 DKMS 环境 首先检查当前内核版本： 输出为： 继续检查内核、headers 和 DKMS： 结果为： 再检查当前内核的 build 目录： 结果为： 这说明基础环境没有问题： 因此可以排除 headers 缺失、内核和 headers 不匹配、DKMS 环境缺失等常见问题。 中间曾出现过一个无关报错： 这只是复制命令时把两段命令粘连在一起导致的，不是系统故障。 三、问题真正原因 这次问题的关键在于： Linux 6.17 以后，内核 sound 相关源码目录结构发生过变化。旧版构建脚本可能仍然假设旧路径，因此在新内核上会出现构建流程不稳定、模块生成位置不符合 …

背景 桌面系统的性能检查，最怕两件事： 第一，测试命令散落在历史记录里，下次想复测时已经找不全。第二，只盯着单个跑分数字，却没有把系统信息、存储健康、启动链、图形栈和持续负载一起记录下来。 更稳妥的做法，是把整套检查流程写成脚本，统一输出到一份文本报告里。这样做的价值不只是“测一次”，而是把性能检测变成可重复、可对比、可长期复用的方法。 这篇文章整理的是一套 通用桌面 Linux 硬件性能检测脚本方案。重点放在脚本本身，包括： 这类脚本要解决什么问题 一套真正有用的检测脚本，至少应该回答下面这些问题： 如果只是临时跑几个命令，得到的是“当时的一串输出”。如果做成脚本，得到的是“以后还能重复使用的一套流程”。 设计原则 这类脚本的核心原则并不复杂。 1. 先补工具，再跑测试 脚本不应该假设测试环境已经完整。像 fio、sysbench、smartctl、glmark2、vkmark 这类工具，经常会缺一个或几个。更合理的做法是： 2. 所有输出落到同一个报告文件 统一报告文件的好处非常大： 3. 测试覆盖桌面环境最关键的几类能力 建议至少覆盖： 4. 不做破坏性操作 桌面性能检测不需要对真实设备做清盘式测试。裸设备破坏性写入、无保护的低层级覆盖，不应该默认进入脚本。 5. 环境相关的信息要和分数一起保留 单看一个分数意义不大。同样一次 sysbench，如果不知道： 那后续就很难解释结果。 一份可直接改造的通用脚本 下面给出一份可复用的 Bash 脚本模板。它的思路是： #!/usr/bin/env bashset -uE -o pipefail# 通用桌面 Linux 硬件性能检测脚本# 目标：# 1. 检查必要工具# 2. 缺失时尝试安装# 3. …

一、背景 这台 iMac 的实际用途非常明确： 目标： 将 macOS 收敛为「极简维护环境」，只保留 Apple + Google 二、问题 macOS 删除应用后不会自动清理残留，主要集中在： 包括： 长期使用后，这些数据会不断堆积。 三、初始状态 清理前： 特点： 四、清理策略 核心原则： 五、第一轮清理（结构性清理） 清理内容： 结果： 节省： 约 3.8GB 六、第二轮清理（缓存级清理） 目标： 执行： 结果： 七、最终状态 当前系统： 结构： 特点： 八、关键经验 1. macOS 不会自动卸载干净 删除 App ≠ 删除数据必须手动清理 ~/Library 2. Application Support 是最大头 优先清： 3. …