标签： Ubuntu
-
在此前排查 ThinkPad T570 的 Type-C 转 VGA 无法识别副屏问题后，我最终放弃继续修复 USB-C / Thunderbolt 视频输出链路，重新购买了一台原生支持 HDMI 的显示器作为副屏。现在采用 ThinkPad T570 HDMI → HDMI 线 → 显示器 HDMI2 的直接连接方式，Ubuntu 双屏已经恢复正常。新的结果也进一步说明，之前的问题并不是 Ubuntu 本身无法正常使用双屏，而更可能集中在原来的 USB-C / Thunderbolt / DisplayPort Alt Mode 链路。相比继续研究 Thunderbolt 固件和底层硬件，使用 HDMI 直连最终以更简单、稳定的方式解决了实际需求。
-
2026 年 7 月 30 日，我尝试使用新购买的 Type-C 转 VGA 线为 ThinkPad T570 连接副屏，但 Ubuntu 始终无法识别外接显示器。排查过程中先后检查了 Wayland、DRM、USB Type-C、UCSI、BIOS 和 Thunderbolt Controller，并将 BIOS 从 1.23 升级到 1.54。即使在 BIOS 阶段将 Boot Display Device 设置为 USB Type-C，副屏仍没有反应；通过 boltctl 强制让 Thunderbolt 上电后，Controller 也没有被系统枚举。综合现象来看，问题更可能位于 T570 的 USB-C / Thunderbolt 底层链路，而不是普通的 Ubuntu 双屏配置。考虑继续修复的时间成本，最终决定暂时停止排查，后续更倾向于购买一台原生支持 HDMI 的显示器作为副屏。
-
为了让 Codex 能够在完成代码修改、离线测试和 Git commit 后直接推送到 GitHub，我在 Ubuntu 中安装并配置了 GitHub CLI。通过 gh auth login 完成浏览器设备授权和两步验证后，再使用 gh auth setup-git 将 GitHub CLI 配置为 Git 的 HTTPS 凭据助手。最终，Codex 成功将本地提交推送到 GitHub，并验证本地 HEAD 与 origin/main 完全一致。本文记录了完整配置过程、安全边界，以及自动推送与生产部署之间需要保持的明确区分。
-
针对 Ubuntu 26.04 桌面出现的 Firefox 卡顿和 OOM 问题，本文记录了从内存调度与应用负载两方面进行的性能调优过程。通过构建 RAM 与 ZRAM 的三层内存体系、降低 swappiness 值、限制 Firefox 多进程及开启 Clash Verge 轻量模式，有效降低了内存峰值与 Electron 应用负载。优化后系统运行稳定流畅，解决了日常并发场景下的卡顿与崩溃风险。
-
针对 Ubuntu 环境下 Clash Verge 内存占用过高导致系统卡顿的问题，本文记录了通过降低日志等级、关闭流量统计界面及冗余网络功能，并最终启用轻量模式的优化过程。经实测，该方案将后台常驻内存从 500MB 以上降至 200MB 左右，有效提升了桌面系统的稳定性，适用于需长期运行代理服务的 GNOME 桌面用户。
-
本文记录了在 Ubuntu 上使用 Thunderbird 连接 Gmail IMAP 失败的排查过程。通过排除客户端设置、代理及认证问题，并在 VPN 服务器端测试，确认服务商屏蔽了 IMAPS 端口。由于无法解禁端口，最终改用基于 HTTPS 的 Gmail API 客户端，成功绕过了网络限制，解决了收信问题。
-
本文记录了在 Ubuntu 26.04 使用中排查 Chrome 内存暴涨问题的全过程。经测试验证，发现 Flatpak 沙盒机制是导致重度应用资源占用过高的核心原因。通过回归原生 Deb 包，内存占用显著下降。基于此，作者更新了最佳实践：对于 Chrome 和微信等重度应用应坚决弃用 Flatpak 而选用原生 Deb 包，同时利用 GNOME Software 安装轻量应用、清理数据及统一管理自动更新。
-
针对 Ubuntu 26.04 系统自带截图工具功能不足，以及微信截图受窗口焦点限制的问题，文章介绍了使用 Flameshot 绑定全局 Alt+A 快捷键的解决方案。通过 APT 安装软件，在系统设置中配置自定义快捷键命令，并在 Wayland 协议下授予屏幕截图权限，最终实现了在任意界面高效调用功能强大的截图与标注工具。
-
本文记录了在 Trae CN 中尝试使用微软官方 Dev Containers 扩展的踩坑过程。在配置扩展市场地址并尝试安装官方扩展后，无论通过在线安装还是手动导入 VSIX 文件，扩展始终显示“用户已全局禁用”且无法激活。查阅官方论坛确认目前 Trae CN 尚不支持 Dev Containers，因此最终放弃该方案，计划改用宿主机 Go 配合容器内运行及 Docker 扩展辅助的混合模式进行后续开发。