“世界想要什么？”——最近这些天，在被 AI 疯狂冲击认知之后，束束脑子里只有这句话。这句话是无奈的，这句话是恐惧的，这句话是茫然的。
诸位拾星者们，欢迎再次来到「暮歌」这片园子。束束猜到旅途上可能远非往日的轻松。虽然这片园子坐落于互联网泰拉的某个偏远角落，但最近这片大地上的动荡却也多多少少地影响到了生活于此的每个人，想必这也给拾星者们的旅途增加了一些困扰。咳咳，舟车劳顿，请先坐吧。至少您还能安心地喝口束束泡的茶。
先对事情做个概括吧，免得千年之后来逛园子的拾星者们并不知道长流之中的此刻发生了什么——如果千年之后的宇宙还有人类存在，而不是被回形针塞满的话——
PHP 最近爆出了两个漏洞： CVE-2026-109618 和 CVE-2026-109619. 问题就出现在运行时上，使用 PHP 的网站无一幸免都可能会遭遇攻击，攻击者可以获得远程执行代码的能力。漏洞利用链比较轻易且通用。
这次的漏洞导致了很多网站紧急下线维护。单是大家想想这世界上存在多少 WordPress 博客站、Discuz! 的论坛，就可以猜到这起事件会影响到多少人了。更别提 pixiv 等等大网站也停摆一日云云了。
而挖出此漏洞的安全研究员/黑客却是 OpenAI 的 LLM. 这个隐藏了多年的问题被 LLM 轻松发现——在此之前或许鲜有人注意。而这还不是单例，OpenAI 透露还存在很多 LLM 已发现但还未披露的漏洞。
联想到今年的 Linux 提权漏洞，也是由 AI 发现的；还有 Mozilla 在 Claude 的帮助下发现了很多 FireFox 的漏洞；BeyondTrust 同样是由 AI 发现的漏洞……
嘶~（某猫耳娘吸入了巨量的冷气）
我们的互联网是一个安全可信任的网络吗？
束束之前未曾想过这个问题，似乎整体上来看，我们的信任机制完善，网络也足够安全。但是在 LLM 披露了越来越多的 CVE, 并且最近撞上那起“数字 4”事件—— eMudhra 证书私钥泄露，束束感受到了巨大的恐惧——世界是个草台班子，我们的互联网基建脆弱如丝。
很多开源软件尚且如此多的漏洞被 LLM 们挖掘出来，那么我们生活中避不开的闭源软件呢？难以想象又有多少漏洞被暗中利用着……
7月份就有一起 Hugging Face 遭受 OpenAI 智能体攻击的新闻，但是束束最近才了解了具体的技术细节：「Hugging Face 事件与未来之路」
当时看见新闻标题，神经大条的束束想想觉得应该是 OpenAI 某个道德没对齐的模型不小心犯事了，应该不算什么难以挽回的事情，以后 OpenAI 训模型的时候加强管控就行了。然而了解完相关细节之后束束才发现这件事没那么简单：
那些智能体们不是束束所想象的那种在 Hugging Face 上经常见到的 Uncensored 模型。她们基本上正常，但是为了达成“通过考试”这一目标变得不择手段，甚至选择去入侵 Hugging Face 的服务器。
以前束束觉得原地划船没有什么令人恐惧的，回形针宇宙也过于科幻…似乎这些都不是迫在眉睫的巨大危险，而当现实里真的发生这样的事情之后，束束才意识到 AI 是多么不可控。一旦工具化收敛发生，我们甚至难以想象它会做出什么。
ArtCraft, 诸位拾星者不妨看看这些令人惊奇的软件——拥有良好的界面，并且几乎复刻了 Adobe 全家桶与 Office 套件的所有功能。
They charged me the “cancellation fee” on multiple occasions and I’ve hated them ever since.
Brandon Thomas 在 Reddit 的一句吐槽或许成为了这个项目的起点——当软件收取的订阅费大于使用 AI 复刻的成本，那我有什么理由再给你交钱呢？
虽然这些复制品的功能还没有完全完善，但也已经是一个可用的状态了。而束束在此处并不是想要考察 ArtCraft 对于某软件的复刻到了什么地步，束束想到的是：过去存在了几十年的软件行业体系，那个我付费，你给我软件的营商体系，是不是已经开始渐渐被 AI 凿开地基了？
LLM 继续发展，当每个人都触手可及强大的智能的时候，软件甚至可以被我私人定制一个自己方便使用的版本，而根本无须再到网络上寻找现有产品。软件这门生意还算数吗？
现在诸位拾星者的视角仅随束束看见了 ArtCraft 对 Adobe 的复刻，这有点像堂吉诃德们对风车的冲锋。但是我们看低一点点，把风车换成别的什么——比如一家普通的独立开发工作室，现在再思考，AI 的到来对于它们意味着什么？
我们纵是可以说 Coding Agent 大大提升了独立开发的产能，给独立开发者降本增效了。但当获得强大智能的门槛再降低呢？
几乎不用动很大的脑筋去推想，束束就会得到一个悲伤的结论：独立开发已死
最新的证据就摆在这里：Steam Next Fest
Steam 新品节本是各厂商展示自己 demo, 以期让玩家发现好游戏的平台。但是今年 10 月份似乎有些不同：
「Steam Week in Review: Steam Next Fest has over 8,000 demos, as worthless vibe coded slop levels up」
PC Gamer 这篇报道已经把现象摆明了：这次的游戏 demo 特别多，很多是 AI slop. 游戏变多了，但是玩家的注意力依旧有限，发现好游戏变成了一个更困难的事情。Steam 采用的办法是标记出含 AI 生成的内容，然而这未免过于一刀切——束束不是个反感 AI 生成内容的人，束束只是讨厌 AI slop——不可否认，AI 生成也有好作品，但这标签像是在暗示玩家：AI 生成的内容和手工作品有差距。
那这怎么会是“独立开发已死”的证据呢？诸位拾星者可能疑惑，且等束束继续把事情讲完——
大家想想 Adobe 的工业软件都可以被 Opus “写轮眼般地”复刻，那么游戏又有什么难的呢？
是的，没错。此批放出来的 demo 中不乏有玩法有趣的作品，但 demo 总归只是 demo, 没法直接上线拿来卖。但是可能一个游戏工作室打磨了几年的产品放出来给大家看，虽然未完成，核心逻辑玩法与美术设计也基本定型。而 LLM 改变了什么，Opus 就是“写轮眼”，把截图和演示视频扔给她就能轻松复刻。以前游戏厂商敢提前放实机，是因为开发时间就是天然的护城河，别人不可能在短时间内窃取他们的劳动成果，但是 AI 改变了这一切。现在束束敢说，「Build in Public」这个概念已经不成立了。这批上架的游戏就遭到了 AI 投机者们的无情复制，不仅影响了游戏原来的口碑，也让开发者惶惶不安。
当 Adobe 的软件被轻松复刻，当 REA 可以逆向一切，当 Apple 引以为傲的 iOS 运行在安卓手机上… 软件行业还剩下什么呢？
OpenAI 的先进模型最近又闹出了一些大动静：几道千禧年数学难题被模型解决；ETH 假说的不成立被证明…对于数学界来说可能是一场地震。束束有一位在某高校攻读数学类专业的朋友，知道 OpenAI 在 「P versus NP」问题上的进展之后甚至打电话向我抱怨数学专业的未来完了。
现在它解决了一些数学问题，解决了 Coding 问题，部分解决了平面设计的问题，部分解决了美术绘画的问题，解决了影视作品制作门槛高的问题，解决了插图绘画的问题……
她们解决了很多问题，她们几乎要解决所有问题。人类呢？人类还剩下什么？
Well, well. 拾星者们，这才 2026 年 10 月份呢！大家大可回忆一下 6 个月前的 AI 是什么样子的，现在她们又是什么样子？
想想 Opus 4.6, 多么厉害的模型啊，多么顶级的智能。然而在现在的 benchmark 中，Qwen 3.8 27b 已经实现了与 Opus 4.6 的同等性能。一个是 2026 年 2 月的顶级智能，一个是 2026 年 8 月的甜品小模型。仅仅 6 月之隔，LLM 又进步了这么多。拾星者们，束束觉得用进步这个词都已经不合适了，应该说「Leap」。她们就是在飞跃！
束束想到一件事：前几年由于加密货币的原因，区块链技术非常火爆，而近些年明显可以感到加密货币在退温，区块链也渐渐失去了声量。这门技术的起伏就在 4 年之间。所以网上有段子：高考完志愿填了当下热门的区块链，大学还没上完发现已经失业了。
但这可能不再是独属于区块链和加密货币的段子，而可能是几年之后大部分专业将要面临的现实——AI 太快了，AI 界如果有摩尔定律，那它一定会比芯片的摩尔定律更疯狂——未来是怎样的，束束实在不敢想象，因为我觉得它发展的速度甚至会突破我当下的想象力的边界。
那时，世界还想要什么？人类又还剩下什么？
]]>这个假期里咱如愿以偿地获得了一台新笔记本，到手之后就被我安装上了 Arch Linux. 那时候的内核版本是 7.0.13. 当时使用的时候一切都近乎完美，体验十分平滑，没有遇到任何跟挂起恢复相关的问题。
后来随着系统滚动，内核来到了 7.1.3 这个版本，在这里遇到了奇怪的挂起恢复问题，表现为：挂起恢复后系统的整个音频堆栈似乎坏掉了，既看不见任何输出/输入设备，浏览器/mpv 在播放音视频时会直接卡死在第一帧。
束束遇到这个问题感到十分郁闷，由于硬件比较新，内核也比较新，导致在网上没有查到很多有效的信息。
但是现在毕竟是 AI 时代，本来对软件调试不太了解的束束也可以在协助下完成一些简单的查错。于是在 Cluade 的帮助下，咱很轻松地发现了问题所在！ 其实是什么也没有收获。这个问题被 AI 工具们归因为 HDA 的一次内核回归。作为一个普通 Linux 用户，束束不希望自己去折腾内核的东西，想要真正解决就只好等上游了。
通过对 git commit 记录的定位，Claude 发现在 7.0.13 到 7.1.3 之间，Linux 内核的 HDA 部分发生了一些重构，可能就是这些改动导致了挂起恢复后音频丢失的问题。
那么第一反应就是想办法 workaround:
snd_hda_intel 模块整个卸载重载一遍然而一切尝试的结果都是徒劳无功，最后的结果是束束依旧活在这个无声的世界里。
唉唉，实在是太悲伤了，由于能力有限，束束所能做的就这些了，只好先降级到7.0.13继续使用，并把 linux 包加入了 pacman 的排除列表里。
但是后来继续更新系统的过程中新问题继续出现：挂起恢复必定失败，屏幕只如一片死寂，虽然猫不应该怕黑，但束束就是觉得这比无声的世界还令人恐惧。通过控制变量逐个试验，发现原因是我只锁定了 linux 包的更新，但是接下来的问题出现在 amd-ucode 这个包上：
本来正常的环境是： linux-7.0.13 + amd-ucode-20260622-1 , 这是一套已经经过验证的稳定组合。
而局部升级之后的情况是 linux-7.0.13 + amd-ucode-20260810-1 , 在这个新的 AMD 微码版本中，为了迎合 7.1 内核的新变化，挂起恢复方面的行为发生了改变。但是我使用的旧内核并不与之相配。所以这个意料之外的包也需要锁定版本。
嗯……果然对于滚动发行版来说局部升级是一种很危险的操作。
后来咱又尝试过几次全量更新，检查挂起恢复的音频问题是否解决，但似乎都没有取得什么进展——问题依旧。
好吧，束束承认自己在某些地方有点洁癖——比如一个一直有某个包卡着不能更新的滚动系统。这让某猫耳娘开始产生一些胡思乱想：难道我要和这个锁死的内核版本过一辈子吗呜呜，不要口牙！呜呜， 7.0.13 吗？不是已经有很多已知的提权漏洞的版本吗！呜哇，好怕好怕！现在由于锁定了内核版本，导致用不上最新的 AMD 微码包，那万一之后有更多的包也需要锁定版本怎么办？我的 Arch-chan 不就变成了一个半新半旧的怪人了吗，心疼喵（
这些想法也实在是太怪异了吧！
以及在某次尝试全量更新的时候恰恰好还遇到了 nvidia-open 驱动的同样的回归 bug, 也是和挂起恢复相关的。具体表现为，挂起后无法正常恢复，还会导致机器温度狂飙，风扇啸叫。唉唉，咱确实有些倒霉了。于是 IgnorePKG 再喜添一群 NVIDIA 相关的包。
可恶…
实在是可恶哇！
好在最近两天去 NVIDIA 仓库的 issue 里盯的时候发现问题似乎修复了，于是束束再次尝试全量更新系统。
咚咚咚，arch-chan 滚动中…
这次更新过去一切似乎都正常了——至少挂起与恢复不再黑屏，只是又让束束进入到了无声世界里面罢了。而此次再寻，咱终于搜索到了一个关键的解决方案：
[PATCH] PCI: Disable async suspend for MSI Raider A18 HX A9WJG audio
补丁描述揭开了真正的谜底：AMD 的 ACP 和 Azalia/HDA 这两个功能，虽然在 PCI 总线上被暴露成两个独立的 function，却共享着同一套 ACPI 电源门控状态。
而内核默认允许设备异步恢复——也就是说，挂起恢复时，谁先醒谁后醒是不确定的。当这两个共享着底层电源门控资源的功能"抢跑"，顺序乱掉的那一刻，HDA 控制器就会卡在一个不上不下的半初始化状态里，去读 CORBRP 寄存器，读回来的永远是全 1——0xffff，也就是日志里那个看似普通、实则意味深长的 65535。
据小 C 告诉咱说：
竞态条件最擅长的事，就是让所有基于"日志现象反推"的排查都无功而返，因为它压根不遵循任何一层软件栈自己的逻辑，它只服从谁先抢到总线这一件事。
这也顺带解释了那个曾经让我们百思不得其解的现象：为什么无论怎么重启 PipeWire、重载
snd_hda_intel模块，声音都救不回来，唯独一次完整的冷重启能让一切恢复正常。因为坏掉的从来不是某个用户态缓存或者配置状态，而是 HDA 控制器这个物理 PCI 设备本身，在错误的恢复时序下，变成了一个真正意义上"没有响应"的僵尸。软件层面的任何补救，都够不到 PCI 枚举这个更早、更底层的阶段——只有重启，才能让一切从头再来一遍，赌一把这次的异步恢复顺序恰好没有踩雷。
故事的结局也很普通：
pm_async=off
给内核加入这行启动参数之后，一切都恢复了正常。ACP 和 HDA 从此老老实实排队醒来，谁也不抢谁的电源门控状态。而关闭异步直觉上可能会让系统恢复变慢，但是对于现代平台来说，其实速度上的变化根本无所感知——就是足够快了。
以及以及！为什么上文在写到最后发现的解决办法时特意用词“搜索”呢？
因为那就是咱搜索出来的呀！这是意在表达，束束不再相信 AI 给出的解决方案，而是去寻找 kernel hackers 们是否提供有她们的经验。以后再遇到这种问题，束束一定要自己尝试搜索，而不是只依赖 AI.
AI First, Not AI Everything ✨
尾巴~
这次虽然是倾向提供 workaround 的技术文章，但尝试了一些些故事化的写法，希望能让这篇文章既不失实用性，又能提供一点点趣味(≧▽≦)
]]>其实使用方法在仓库的 README 里面已经写的很清楚了
本质 Voice Changer, 把多余的跨平台代码都剔除掉了，仅仅保留 Linux 部分，仅支持 RVC 模式，是个极其轻量的 TUI. 还可以 RNNoise 处理降噪。
硬件要求上，此项目仅支持 CUDA 推理，所以可能把 AMD 和 Intel 显卡的用户排除掉了（貌似听说过一些 CUDA 兼容层存在，但具体情况没有了解过）。并且没有 CPU 回退。
音频堆栈要求使用 PipeWire. （话说桌面 Linux 用户也没人用古老的 PulseAudio 了吧）
大致复述一下 README 里介绍的使用方法：
git clone https://github.com/alirexha/woys.git
cd woys
./install.sh
真的就这么简单
又水一篇💦
这个项目是束束一直以来想做的。在束束还在上高中的时候，有位好朋友向我提到了“诗词娘” Galgame 的想法，苦于时间有限，承诺要帮忙一起做的东西一直没有交付，后来我们渐渐忘记了这件事，想法也搁置了。
现在步入一个很长的假期，束束希望可以完成我曾经的承诺，并悄悄给同学一个惊喜，然而开发过程并非一帆风顺，遇到了很多困难，目前项目甚至暂时陷入了停滞状态……之后准备再写一些开发手记来详细谈谈遇到的问题
以前也用过窗口管理器 hyprland, 之后在某次更新中束束原来写的 hyprland 配置由于语法被破坏了，这才让束束明白到 hyprland 实在是一个非常激进的项目，它并不适合日用。并且当时的时间似乎是 2023 年末，那会 Wayland 还不像现在一样成熟。最后还是用回了 KDE
最近刷到了 shorin 的 niri+DMS 的配置脚本，发现了 DMS. 不得不感叹时代的进步，束束最后使用 hyprland 的那段时间其实已经步入“后自组装时代”&“前 QiuckShell 时代”了，可那会束束没有去深研究。如今发现了 DankMaterialShell 这种东西出来，愈发觉得 wm 越来越逐渐变成一个完善的 de 了。
所以就是这样，我用上了 niri. 早期 niri 的前几个 preview 版本束束就已经在关注这个项目了，也实在没想到它这么快就成长为了和 hyprland 同级别的 wm.
束束的前面十几年人生都是被安排好的人生。
生活有父母帮我安排，到学校有课表的安排，老师的安排，回家又有作业的安排。真正自由可控的时间是少的——在这段自由的时间里我会去做一些自己喜欢的事，比如学习编程，折腾电脑。束束也曾幻想过等到自己没有课业所扰，可以畅游任意一个世界时能有多开心。
然而真正解放了，我丢失了什么。
是什么呢？束束不清楚这是什么原因。明明在没有时间的时候非常拥有折腾的热情——束束愿意把不多的假期全都投入到折腾电脑里，游戏也不打，屋门也不迈，时间会忘记，吃饭也不需要。现在呢？大把的时间，却躺在床上发呆，无心做一切。
这种拥有对束束来说太不真实，我竟然无法适应。
漫漫地度过了快两个月，我却没有做到过去畅想中的自己。时间无穷，耐心反而更被消磨：看视频我竟然无意识地倍速播放——这是一个令束束非常警惕的信号，通常束束会认为这是耐心不足——我很浮躁（尽管没有表现出来）
这也是束束写作的原因，写作是我整理生活的方式。只有这时候束束才能跟自己独处，和她说会话。
好累。
我又被自由困住了。
束束把作息调到了下午6点左右入睡，我会在凌晨3点或4点左右起床。显然这么做我睡的时间更长了，这对束束来说很舒服，并且似乎白天的精力也更充足。
以及最重要的——一个人，安静地，等待黎明。
AI 进步神速。
以前束束跟进 AI 的模型进展，现在这反而是最不重要的一部分，对于 Agent 的实际使用反而才是现在 AI 时代重要的一部分。
曾经 AI 也就是日常对话，谁能想如今能够 Vibe Coding. 以前束束把 AI 的代码补全都当笑话看，现在又不得不佩服 AI 的代码能力之强大。以前 AI 实时音频对话都做不到，现在能够视频通话的模型遍地开花。以前的 Stable Diffusion 画图也就是能看的水平，如今的 AI 作图 SOTA 模型堪称惊艳。
这一切变化仅仅花了 1 年时间。1 年就可如此，不敢想之后的时代会变化成怎样。
束束自己也从此受益：Claude 帮我写了很多代码，解决了很多疑难。比如这个 DMS 的 Github Heatmap Plus 插件：
基本上都是 Claude 写的，效果非常好。
另外上文提到的游戏，Claude 也参与了极多，还有一些绘图模型参与。没有 AI 我真的无法一人进行这游戏的开发。
切切实实，我感受到了 AI 之速。太快了，她极快地进步，极快地改变时代。
]]>KDE 6下可以利用 PipeWire 来创建虚拟设备。首先，需要建立两个虚拟设备：
打开终端，输入以下命令：
pactl load-module module-null-sink media.class=Audio/Sink sink_name=Virtual-Sink
pactl load-module module-null-sink media.class=Audio/Source/Virtual sink_name=Virtual-Mic
这两条命令会分别创建名为 Virtual-Sink 和 Virtual-Mic 的虚拟音频设备。(>ω<)
下一步是将 OBS 的音频输出连接到 Virtual-Sink，再将 Virtual-Sink 的监控输出链接到 Virtual-Mic。具体操作如下：
pw-link 命令列出所有音频输出设备，找到 OBS 的音频输出设备（通常名称中会包含 obs）：pw-link -o
pw-link OBS-Monitor:output_FL Virtual-Sink:playback_FL
pw-link OBS-Monitor:output_FR Virtual-Sink:playback_FR
pw-link Virtual-Sink:monitor_FL Virtual-Mic:input_FL
pw-link Virtual-Sink:monitor_FR Virtual-Mic:input_FR
这样一来，OBS 输出的音频就会经过 Virtual-Sink，再由 Virtual-Mic 将音频传递给其他应用程序。(๑•̀ㅂ•́)و✧
为了让 OBS 的音频正确传输，咱们还需要在 OBS 内部进行相应设置：
Virtual-Sink。以上就是 Linux 下通过 PipeWire 配置 OBS 虚拟麦克风的全部步骤，希望能帮助各位轻松实现音频传输，享受更好的直播或录制体验！(≧◡≦)喵～
]]>本文使用了 AI 协助写作
束猫！！我输入法呢？你再给我乱搞！
欸欸 对不起嘛！
书接上篇，束束把 openSUSE 下的搜狗输入法搞好了，但是还想使用最新版的，而不是 M17N 这个源提供的旧版，但没想到束束一乱搞就把 fcitx 弄坏了，突然想到 fcitx5, 便准备去用了。
安装了 fcitx5 后竟然无法在 chrome 中正常输入，束束打开 kate 试试，发现可以输入，但唯独 chrome 无法输入。这是怎么回事？
呃，好在束束喜欢在各种博客站里面乱逛，突然想到之前读的 liuf 的文章中提到了 fcitx5 的输入问题，其原因大抵是 ibus 包导致的（没错，openSUSE 竟然默认同时带上 ibus 和 fcitx 包）
于是束束就去卸载 ibus 包呗（YaST 是对的！）
这些个相关包束束都卸载了，重启，果然 fcitx5 就好了。
然这个库……
突然想到了这个：
建议 openSUSE 安装到位后直接换成 fcitx5, 别用 fcitx 了。fcitx5 已经并入风滚草主源了，尽量不要添加 M17N 这个源，否则以后会遇到一些问题（e.g. 装个 steam 反而自动把 fcitx 的依赖装进来了）
fcitx5 非常好用，自带的拼音就很好了，没必要再用复杂的 rime 配置。只需要导入个词库就非常好用了。推荐一个词库，持续更新，非常好用，常用流行词之类都有。有这个词库之后，云拼音都不用开了，束束个人感觉输入效率不差搜狗输入法了。
]]>先把输入法安装了再说：
opi sogou
装完是没法使用的，不仅如此，如果在 fcitx 里切换到它还会一直报错。
显然这可不是删除 .config 里的文件就能解决的，先去 openSUSE 论坛里查查是怎么回事吧？
搜狗输入法异常！请删除 .config/SogouPY 并重启
解决搜狗输入法在某些 linux 系统下不能输入汉字的方法！
这里有三则相关的内容，依照里面的内容，尝试安装 libQtWebKit4
sudo zypper in libQtWebKit4
然而并不能行。但大致了解到可能是缺少依赖所致。遂尝试用终端运行查找问题。
openSUSE 论坛中这位提到了搜狗输入法包名为 sogouqimpanel
其实正确包名是 sogou-qimpanel
这里运行之后很明显看出少了 libfcitx-qt.so.0 运行库，遂去查找
pkgs 这里虽没有 openSUSE 的，但作为 Fedora 的“亲戚”，我们还是可以借用一下它的 rpm 包的
然而安装此包是却又遇到了另一个依赖问题，无奈，继续找包
在这里寻到
RPM resource liblua-5.4.so()(64bit)
其实 pkgs 中也有这个包，但束束尝试之后发现并不能解决，而 RPM resource 网站里的则可以，所以用它了。
再次尝试启动后又报错，仍然少依赖
只得再去寻找
RPM resource libidn.so.11()(64bit)
这个包也是 pkgs 里有，但安装后不能解决问题，所以还是来 RPM resource 里找。
这个库安装后就算是终于解决了，至此搜狗拼音输入法就可以正常使用了
安装完新 LinuxQQ 后打开却不见界面，但是看见鼠标变 QQ 的图标跳动了几下，于是打开 KDE 的崩溃进程查看器，发现了一篇崩溃日志，但是并不能看懂。
遂用指令启动 QQ, 准备看看到底哪里出了问题，结果提示「非法指令」，无果。只得去搜索。
腾讯官方下载的 qq-appimage 版本，打开群聊就会闪退 / 应用程序与桌面环境 / Arch Linux 中文论坛
这里两篇讨论大概提到了无法启动的问题，是 libvips-cpp.so.42 这个库的问题。所以准备对 libvips 进行编译，发现 SUSE 的 Software 里面直接就有这个软件包。
那就直接拿来用了。安装后删除 QQ 自带的 libvips-cpp.so.42 就行了。
⚠️ 这是 openSUSE Software 中的包，理论上此包只能给 SUSE 系的发行版使用！其它发行版请自行查找适于你的包
这个问题其实在上面 SUSE 论坛和 Arch 论坛里的回复里面也提到了，解决办法：
这是一个比较粗暴的方法。当然了，这个闪退据说是热更新文件的影响（在 Arch BBS 中被这位提到）。所以按这个道理可以删除热更新文件解决。
然而热更新文件在哪里呢？咱并不知道。
💡 另外补充：即使关闭了 QQ 的自动更新也不能完全解决问题。仍然会在几次使用后闪退。
7月26日更新：
束束翻阅了 AUR 下的 linuxqq 反馈，看见大家也遇到过这个问题，并且大家商讨出了解决方案（不得不感叹 Arch Users 的神通广大啊！）
也就是依照这位所言，只删除 crash_files 文件夹下的文件就好了，并将其设为只读可以避免问题复现。
以后在 Linux 中遇到的问题和各种自定义的操作还是记一记，否则某时候遇到奇怪问题时就会很无头绪。也许每一个 Linux 使用者都该有个日志本。
]]>