Category: Tech

有些应用没有正式的 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. …