Ubuntu

开场：告别内网穿透的“开盲盒”体验 在多设备办公和 HomeLab 运维中，远程访问内网资源一直是个痛点： frp / 端口映射：家宽没有公网 IP，或者公网 IP 隔三差五变动，还要针对每个端口配置穿透规则。 ZeroTier / Tailscale：虽然方便，但依赖第三方中央控制平面，国内网络偶发打洞失败或握手延迟飙升。 传统 OpenVPN / IPsec：配置繁琐、代码庞大，在笔记本睡眠唤醒或 Wi-Fi 切换后重连极慢。 WireGuard 的出现彻底解决了这些问题： 代码精简：仅约 4,000 行核心代码，直接集成进 Linux 内核，吞吐量接近线速。 现代密码学：基于 Noise 协议框架与 Curve25519、ChaCha20-Poly1305，没有臃肿的握手协商。 极简身份机制：每个节点一对公私钥，无状态（Stateless）UDP 通信，原生支持移动漫游（Roaming）。 本文将从零开始，手把手记录一套完整的 Ubuntu 云端中继 + 家庭设备 + macOS 终端极客接入 的生产级配置方案，并深度复盘在 macOS 上实现系统级 LaunchDaemon 开机常驻与事件驱动自愈重连的实战经验。 1. 架构设计与网络规划 WireGuard 在协议层没有严格的“客户端”与“服务端”之分，所有节点都是平等的 Peer。但在实际拓扑中，我们通常将拥有固定公网 IP 的云服务器作为汇聚与中继节点。 拓扑规划 ┌───────────────────────────────┐ │ Ubuntu 云服务器 (Node A) │ │ 公网 IP: 198.51.100.1 │ │ 虚拟 IP: 10.100.0.1/24 │ └──────────────┬────────────────┘ │ WireGuard UDP :51820 ┌────────────┴────────────┐ │ │ ┌────────┴────────┐ ┌────────┴────────┐ │ 家庭 NAS / PC │ │ MacBook 笔记本 │ │ (Node B) │ │ (Node C) │ │ 虚拟 IP: │ │ 虚拟 IP: │ │ 10.100.0.2/24 │ │ 10.100.0.3/24 │ └─────────────────┘ └─────────────────┘ 节点分配表 节点 角色 真实网络 虚拟 IP (wg0) 监听端口 / 对端 Node A 云端中继网关 拥有固定公网 IP 10.100.0.1/24 监听 51820 (UDP) Node B 家庭服务器（Ubuntu 24 Server） 家庭宽带内网 (NAT) 10.100.0.2/24 对端指向 Node A Node C macOS 办公本 移动办公 / Wi-Fi (NAT) 10.100.0.3/24 对端指向 Node A 网段选择提示：虚拟子网建议使用 10.100.0.0/24 等不常用网段，避免与家庭路由器默认的 192.168.1.0/24 发生网段冲突。 ...

一台 2017 年的 MacBook Pro，当年卖一万多，如今打开浏览器都喘。问题不在硬件——而在它身上的软件每年都在为更新的机器写作。给它换个轻量系统，等于把被系统吃掉的 3GB 内存还给自己。 开场：越更新越卡的"官方支持" 上周帮朋友收拾一台 2017 款 MacBook Pro：13 寸，8GB 内存，512GB SSD。当年这也是台主力开发机，现在开个 Chrome 加十几个标签页，风扇就开始起飞，切换窗口能感觉到明显的迟滞。 系统一路从 Sierra 升到了 Ventura——苹果对这台机器的官方支持到 macOS 13 为止，再往上（Sonoma、Sequoia、Tahoe）全都把它踢出了名单。也就是说，这台机器已经站在了 macOS 世界的尽头： 安全更新快断供：Ventura 的支持周期临近结束，之后就是裸奔 资源越吃越多：空闲状态下 macOS Ventura 自己就占掉 3.5–4.5GB 内存，留给应用的只剩不到一半 软件只往前看：新版应用默认你有 16GB 内存和新 CPU，没人再为 8GB 老机器优化 换掉它的理由很充分。但换什么？答案可能出乎意料地朴素：Xubuntu 24.04 LTS。 为什么是 Xubuntu：一张对比表说清楚 Xubuntu 是 Ubuntu 官方 flavors 之一，把桌面从 GNOME 换成了轻量的 XFCE。内核、软件仓库、apt、LTS 支持周期全都和 Ubuntu 一样，只是桌面开销大幅降低。 在同一台 2017 MBP（8GB / 512GB SSD）上实测对比： 项目 Xubuntu 24.04 macOS Ventura 这意味着什么 空闲内存占用 ~0.8 GB ~4.0 GB ✅ 多出 3GB+ 给浏览器和 IDE 安装体积 ~9 GB ~30 GB ✅ 磁盘压力小 开机到桌面 ~18 s ~35 s ✅ 日常感知明显 空闲 CPU <1% 1–3% ⚠️ Spotlight/iCloud 后台常驻 安全支持 到 2029（ESM 到 2034） 即将停更 ✅ 决定性差距 动画精致度 朴素但流畅 丝滑 ⚠️ 唯一让步 8GB 内存是这台机器的瓶颈。macOS 的内存管理很聪明（压缩 + swap），但巧妇难为无米之炊；Xubuntu 的思路简单粗暴——系统自己少用点，把内存还给应用。 ...

一次真实的升级记录。 从 Ubuntu 默认 Cluster 管理模式，迁移到 PostgreSQL 官方推荐目录结构。 全程使用 pg_upgrade，保留所有数据库，最终实现： PostgreSQL 18 官方数据目录 systemd 管理 MacBook 远程访问 完整踩坑记录 一、为什么升级？ 原环境： 项目 版本 Ubuntu 24.04 PostgreSQL 16.14 数据目录 /srv/data/db/postgres/16/main 希望升级到： PostgreSQL 18.4 PostgreSQL 18 vs 16 关键改进 特性 PostgreSQL 16 PostgreSQL 18 增量备份 ❌ 仅全量 ✅ pg_basebackup 支持增量，备份时间减少 50%+ 逻辑复制 基础支持 ✅ 支持序列和大对象复制 并行查询 有限并行 ✅ 更多场景支持并行（VACUUM、CREATE INDEX） JSON 处理 JSONB 基础 ✅ JSON_TABLE 增强，复杂查询更高效 SSD 优化 无特殊处理 ✅ 强制 I/O 调度优化（见下文） 连接池 需外部工具 ✅ 内置连接池改进 SSD 专项优化（重要） PostgreSQL 18 对 NVMe/SSD 做了底层优化，这是升级的核心理由： ...

m2硬盘安装ubuntu出现I/O错误: DMAR fault的排查记录（含解决方案） 在旧台式机安装Ubuntu24.04 的过程中，我遇到一个非常棘手的问题： 第一次安装失败; 安装过程中, 提示io错误 关机后, 再次安装, 安装成功 进入系统后, 硬盘灯持续规律闪烁, 频繁出现 I/O 错误、系统卡顿、硬盘灯间隔性闪烁、并伴随 DMAR/IOMMU 报错 最开始遇到这个问题, 我以为是硬盘问题, 更换为 sata硬盘后, 问题消失。似乎从某种程序上证明是此硬盘问题; 随后此”坏硬盘“, 就安静的放在角落; 今天整理物品, 发现这块硬盘, 突然想到, 让ai帮忙分析分析硬盘是什么原因导致的故障, 以后如何避免买到类似的硬盘; 这篇文章记录整个排查过程，希望给未来遇到类似问题的人提供一个可参考的解决思路。 1. 硬件与环境背景 主板：Gigabyte Z97X-UD3H（2014年） CPU：Intel i7-4790K（Haswell） NVMe：YMTC PC300 512GB（支持 HMB，NVMe1.4） 系统：Ubuntu 24.04 NVMe 安装在主析的m2硬盘槽位 这是典型的“老主板 + 新 NVMe 控制器”的组合，在 Linux 下非常容易触发兼容性问题。 2. 问题现象 （1）安装 Ubuntu 时随机 I/O 错误 系统安装过程中文件复制中断 安装流程偶尔直接失败 重试偶尔能安装成功 （2）安装成功后,进入系统, 硬盘灯持续规律闪烁 开机后系统明显不顺畅。 复制文件时，会出现卡顿, 此时硬盘灯一直有规律的闪烁; （3）复制大文件（如 ubuntu.iso 6GB）出现卡顿 传输速度会突然降到零，直到系统无响应。 （4）dmesg 出现 DMAR/IOMMU 报错 DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Write] Request device [01:00.0] fault addr ... DMAR: write no_pasid (5) 硬盘smart 检测无异常 使用 smartctl 读取 NVMe 健康状态： smartctl -x /dev/nvme0 ...