一位长期做企业 IT 的撰稿人分享了一套解法：用开源的 FOG（Free Open-Source Ghost）搭一台网络镜像服务器，让电脑像有了「撤销键」——他把一台故意弄崩的 Linux 机器，16 秒就还原回了原样。

一、准备 FOG 服务器

1. 装一台 Ubuntu Server 24.04 LTS，分配 2 个 vCPU、2GB 内存、20GB 系统盘，再挂一块独立的 80GB 数据盘，专门用来存镜像。
2. 把数据盘挂载到 /images 并写进 /etc/fstab 持久化：

sudo mount /dev/sdb1 /images

在 fstab 中加入：LABEL=fog-images /images ext4 defaults 0 2

1. 安装 FOG 1.5.10.2254，它会自动拉起 Dashboard、数据库、TFTP、NFS 与存储等组件。

二、把恢复网络隔离出来

PXE 网络启动依赖 DHCP 分配地址。若不隔离，客户端会从你家里局域网的 DHCP 取地址，根本进不了 FOG。做法是单独建一个仅主机网络（如 VMnet7）并关掉它的 DHCP，FOG 服务器一块网卡走 NAT 下软件包，另一块接这个隔离网（例如 192.168.77.2/24）。

这里有个坑：FOG 用的 Kea DHCP 在 Ubuntu 上可能被 AppArmor 拦住——因为 /etc/kea 目录属主是 _kea:_kea，而以 root 启动的守护进程却被拒读配置。修正只需两句：

sudo chown root:_kea /etc/kea

sudo chmod 750 /etc/kea

三、注册并抓取「黄金镜像」

1. 客户端从网络启动，Kea 分配地址与引导文件，TFTP 传入 iPXE，进入 FOG 菜单选「Quick Registration and Inventory」，按网卡 MAC 自动注册。
2. 在 Dashboard 把该主机关联到一枚镜像（如 linux-mint-golden），镜像设置选「单盘-可调大小」、包含所有分区、用 Partclone 加 Zstandard 压缩。
3. 排程「立即」捕获。FOG 只复制已用区块，一块 32GB 的盘实际只占约 3GB，抓图不到一分钟。

四、崩了就一键还原

在 Dashboard 给注册主机建一个「部署」任务——注意别误建「捕获」任务，否则好镜像会被覆盖。下次 PXE 启动，FOG 自动重建分区表与 EFI，把文件系统原样写回。前面那位撰稿人把 EFI 引导目录改名弄崩后，正是靠这一步 16 秒救回。

注意事项：FOG 需要服务器、独立存储、DHCP/TFTP/iPXE/NFS 和隔离网段，不是几分钟能搞定的轻量方案；还原会重启客户端、中断当前系统；它也不是增量备份，同名镜像再次捕获会覆盖，可在 Dashboard 改名做版本管理。物理机还要额外处理驱动、固件与 Secure Boot。但它换来的是：一台坏掉的电脑，只要网启正常，就能退回你上次存好的状态。

来源：MakeUseOf

一台没人要的 2021 款 Fire 平板，被一位作者刷上 Linux、接上 Docker 和开源菜谱库，变成了厨房里专属的「菜谱终端」。这个项目不需要把找菜谱的事外包给大模型，也不用在长文里翻找做法，是旧设备再利用和家庭实验室入门的好例子。

动机：给爱做饭的人一个干净界面

作者戴维·巴克（David J. Buck）的妻子很会做饭，但找菜谱一直麻烦。她手头有一台不再使用的平板，市面上有不少在线菜谱，也攒了几本纸质菜谱，但都谈不上「顺手」。巴克不想把找菜谱这事儿交给聊天机器人，更不想打开一个菜谱前先读完博主的人生故事，于是想做一台联网的专属菜谱终端当礼物。

他最初的计划是用一台 Kindle Fire HD7，连 Fastboot 线都试了，设备始终不配合，只好放弃。备用方案是一台 2021 款的 Fire Tablet——这台机器刷 Linux 顺利得多（刷机细节他留到后续文章细说）。

三件套：Docker、Python 与 Mealie

整套方案跑在一台常开的 Windows 电脑上：装好 Docker Desktop，再用 Python 的 Textual 框架做界面。平板上运行 Linux，后端则由 Docker、在线资源和 Python 共同组成。

核心是一个叫 Mealie 的开源菜谱管理工具（项目托管在 GitHub 的 mealie-recipes/mealie）。它既能从网址一键导入菜谱，也能手动录入。巴克把妻子常做的几道菜加进去，又从开源菜谱库 Open Stove 抓了一些自己喜欢的方子。接着他在 Mealie 里生成一组 API 令牌，接进终端脚本。

脚本本身用 Python 的 Requests 库发请求、用 Textual 搭界面，取名 STEVE——取自妻子的一位旧上司，也是帮巴克解答 Python 问题的朋友。

跑起来：左选右看，三小时搞定

在平板的 Linux 环境里建好虚拟环境（venv）后，用 ./.venv/bin/python steve.py 启动即可；连接其他设备时，他把 Wi-Fi 设为「专用」（Private）以防被随意访问。

界面很简单：左边栏选菜谱，右边栏显示内容。每次往 Mealie 里新增菜谱（常常一次加好几道），重开 STEVE 就会同步更新。巴克说，除去折腾 Textual 界面和往 Mealie 里录菜谱的时间，真正搭起来也就三小时左右。

旧物复活的意义

这台原本打算回收的平板，最终成了妻子在厨房随手查方的专用终端；巴克自己也借着项目多写了 Python、用熟了 Textual。他认为这是家庭实验室「一举两得」的典型：设备不浪费，家人得便利。

想照做的读者要注意，Fire Tablet 需要先「改装」（解锁引导加载并刷机）才能装 Linux；Kindle HD7 在本例里难以搞定，2021 款 Fire Tablet 则顺利得多。刷机有变砖风险，动手前务必确认机型与教程对应。

来源：How-To Geek（作者 David J. Buck）

手边那台被淘汰的旧安卓手机，与其丢在抽屉里吃灰，不如改造成一块常亮的网络监视屏。一位长期折腾硬件的作者在家中实验室里就做了这样的尝试：用一台旧手机实时盯着电脑的中央处理器占用率和网络流量，不必再在干活时反复切换终端窗口。

为什么需要独立的监视屏

这位作者的日常离不开联网，无论是写代码还是跑项目，都很吃内存和算力。起初他直接在正用的电脑上开终端看系统状态，时间长了却越来越烦——为了盯一下资源占用，得在不同终端实例之间来回切，项目做到一半总要被打断。

他试过几个方案，最后落在两个轻量工具上：用 htop 配合 ssh 搭建中央处理器实时监控，用 bmon 做网络流量监视。

用 bmon 搭起网络监视

作者原本想用 Uptime Kuma 做网络监视，但手机上跑的是 Termux 终端模拟器，它原生并不支持 Docker 容器，Uptime Kuma 的非容器版本又始终没能顺利跑起来，于是暂时搁置，改用了更简单的 bmon。

bmon 是一款轻量的监视工具，可以看带宽、数据包速率，也能追踪流量用量，在老手机上跑起来毫无压力。作者的习惯是在安卓设备上用 proot-distro 装一套 Ubuntu，主要走命令行操作。他在 Ubuntu 里用 sudo apt install bmon 完成安装，再用 ifconfig 找到正在用的网卡和地址——但 bmon -p wlan0 在手机本地只会监视手机自己，要监视家里的电脑，还得靠 ssh。

具体做法是，在手机和电脑之间建立一条加密通道：在手机上执行 ssh 电脑用户名@电脑IP地址，并按所用 Linux 发行版的指引在防火墙放行对应端口。连上之后，bmon 就能把电脑那端的网络情况投到手机屏幕上。

用 htop 盯住中央处理器

htop 作者用得熟，便顺手拿来监视电脑的进程号、中央处理器占用和内存。它在 Termux 里用 pkg install htop 即可安装，但默认只显示安卓设备自身的信息，必须连到电脑才能当监视器用。

他把刷新间隔设为 3 秒（命令里的 30 代表 3 秒而非 30 秒），再用终端多路复用工具 tmux 把 htop 和 bmon 并排摆在同一块常亮屏上。起初遇到过显示空间不够的问题，把手机横过来就解决了。

让旧手机一直亮着

老手机电池早已不如当年，要变成常亮屏得做几处调整。作者开启了大部分应用的省电模式，但把 Termux 排除在外，既不让后台乱跑，又防止它休眠；又在 Termux 里执行 termux-wake-lock 锁住唤醒状态。他还顺手精简了不必要的预装应用，关掉了定位、同步等用不上的服务。

有些机型自带常亮显示，可按型号开启。由于空间所限他不打算一直插着电，于是把充电上限设到 80%，电量掉到约 10% 再补电，既保常亮又不伤电池。

除了 htop 和 bmon，作者也考虑过 Glances 这类小部件，留待以后尝试。把一台没人要的旧手机变成专属监视器，这件事本身，就已经相当划算。

来源：How-To Geek（作者 David J. Buck）

How-To Geek 一位长期维护 Home Assistant 服务器的撰稿人发现，AI 给的方案往往过度复杂：有人只是想搭个全屋去广告，AI 却建议买两台设备各跑一个 Pi-hole，再用 Nebula Sync 做同步。对新手来说，这完全是杀鸡用牛刀——大模型既学过小型家庭实验室，也学过大量企业级方案，给出的答案常常偏向后者。

一、给 AI 加上”简单优先”的约束

提问时不要只说”要搭个 XX”，而是明确压低复杂度。可以在提示词里加上下面任意一句：

1. 请给出最简单可靠的方案
2. 除非必要，不要新增软件
3. 给纯新手最简单的方案
4. 最快达成目标的方法是什么
5. 只给让它能跑起来最少步骤

复杂度更多取决于你怎么问，而不是用了哪个模型。加上约束后，AI 通常会收敛到单台 Pi-hole、AdGuard Home 这类轻量方案。

二、强制 AI 先联网搜索，别让它凭记忆瞎猜

遇到具体故障，AI 容易钻牛角尖，让你跑一堆无关测试。解决办法很简单：第一条提示词就让它”去查一下”。它往往能在论坛或 Reddit 帖子里找到别人解决过同类问题的现成方案，省下大把试错时间。

三、不要接受第一个答案，要求”二次意见”

如果方案看起来还是复杂，让 AI 重来一次或重新评估方案。可以输入：把提问者当成完全的家庭实验室新手，想用最快最省事的方式搭建，请批评你上一条方案，并给出改进或替代方法。这样常能逼出更简洁的版本。

注意事项

最终仍需自己判断方案是否合适——你对家庭实验室了解得越多，越容易看出 AI 的方案是否恰当。约束、二次意见都只是辅助，关键还是动手前多想一步。

来源：How-To Geek

Proxmox 虚拟环境（Proxmox VE）把原本属于企业级的虚拟化能力带进了家庭实验室：它同时提供 KVM 虚拟机、LXC 容器、快照、集群，以及对 ZFS 文件系统的支持。纸面上看，它几乎是每一个自托管方案最理想的地基。

但现实是，很多人的家庭实验室是从一台迷你主机、一台旧工作站，或一台从公司电子垃圾堆里捡回来的旧电脑起步的。这台机器上跑着 Jellyfin、Home Assistant、Pi-hole、Immich 或 Nextcloud 等少数几个服务，所有事都靠它自己完成。而 Proxmox 大多数高级能力，本是为协调多台机器设计的，而不是让单台机器突然变强。

真正的好处要从第二、第三台物理机加入才开始显现。集群让多台服务器看起来像同一个虚拟化平台，可以从一个界面统一调度；只要存储共享，虚拟机就能在不同节点间迁移，换内存、装硬盘、做固件升级时，别的节点可以临时接管服务。

高可用则是另一道门槛。它要求法定票数（quorum），而不只是多一台机器：标准双节点集群在其中一个掉线时无法形成多数，会出现「脑裂」。要杜绝这种情况，要么上第三台节点，要么引入一个轻量的外部仲裁设备（QDevice）做平票裁决。缺少这套机制，高可用就只是菜单里一个用不上的选项。

存储与资源调度也同理：NFS、iSCSI、ZFS 数据集复制让工作负载能在服务器间流动；分布式块存储 Ceph 则至少需要三节点才安全。不同硬件也能各司其职——低功耗迷你主机常驻轻量基础设施，多核工作站负责转码、构建或测试。

备份同样受益于分离部署：Proxmox 备份服务器在单节点上也能用，但当它独立于一台宿主机时，即便虚拟化主机整体宕机，备份依然存在。

一句话总结：单台机器跑 Proxmox 完全可行，只是它真正独特的价值，藏在多台主机彼此协作之中。

来源：How-To Geek

一、单机阶段：先把基础跑稳

1. 单台机器上，本地 NVMe 或 ZFS 存储性能已经足够，虚拟机放在本地盘，备份另存一块盘或 NAS，管理简单直接。
2. 这个阶段重点是跑稳服务，不必急着折腾集群、高可用等高级特性。

二、加第二、第三台：集群才显价值

1. 引入第二、第三台物理机后，多台服务器在 Proxmox 里表现为同一个虚拟化平台，可从单一界面统一管理。
2. 共享存储就位时，虚拟机能在节点间几乎无中断地迁移；换内存、装新硬盘、刷固件时，由其他节点临时接管服务，维护更轻松。

三、高可用与存储的硬门槛

1. 高可用依赖法定人数（quorum）：标准双节点集群若一台掉线，另一台无法形成多数投票，自动故障转移不成立。真正可靠的 HA 要么上第三台节点，要么接一个外部 QDevice（qnetd）做轻量裁判，否则高可用只是菜单里的一项。
2. 共享存储可用 NFS、iSCSI 或 ZFS 数据集自动复制；分布式块存储 Ceph 至少需要 3 台节点，不适合起步阶段。

四、备份与资源规划

1. Proxmox Backup Server 单机也能用，但放在独立硬件上收益最大——宿主整机故障时，备份服务器依然存在。
2. 多节点后资源调度更灵活：低功耗迷你主机常驻轻量服务，多核工作站负责转码、构建或测试，按需增量扩容，不必一次性买更贵的机器。

注意事项：单机用 Proxmox 并非错误选择，只是其独有之处——集群、迁移、法定人数高可用、共享存储复制——都依赖主机之间协作。上多节点之前，先用单机把服务跑顺。

来源：How-To Geek

Lewis 目前手上有好几块显示输出接口损坏的显卡，其中包括两块 RTX 50 系产品。之所以敢买，理由很简单——这些卡只用来做计算，而计算根本不需要视频输出口。

“坏”往往只坏在一个点上

在二手市场上流通的所谓”坏卡”，很多并没有真正报废。常见情况是某个接口被扯坏——有人拽 HDMI 线用力过猛；或者风扇轴承磨损，导致显卡在负载下无法正常散热、运行不稳定。

Lewis 认为，这两类故障对特定用途的买家来说都不构成障碍。无法输出画面，不等于无法进行运算。对游戏玩家而言这卡确实一文不值，但对自建服务器、折腾家庭实验室的人来说，它的功能是完整的。至于风扇损坏这种物理问题，只要愿意订一个替换件、重新涂上硅脂，处理起来并不复杂。

真正需要警惕的是另外两类信号：电容鼓包爆浆，以及显存故障。这两种问题在缺少专业诊断维修设备、缺少足够经验的情况下很难解决，属于应当直接放弃的情形。

显卡的价值不只在于画面

尽管消费者习惯把显卡等同于游戏和显示设备，但渲染画面从来不是它唯一的用途。事实上，A100、H100 这类高端计算卡压根就没有视频输出接口——对它们来说，输出口毫无意义。

显卡的设计核心是”高度并行”，也就是同时处理大量小规模运算。玩游戏时，这种能力体现为实时完成路径追踪光照、物理对象模拟和数百万个三角面的渲染而不掉帧。

同样的并行能力在其他场景里一样管用。许多科学模拟本质上就是在计算大量对象之间的相互作用力——可能是星系中恒星之间的引力，也可能是两个分子之间的电磁力；具体问题不同，但并行运算的价值始终存在。

现代显卡还专门针对 AI 场景做了优化，配备了处理低精度运算的专用硬件单元，而低精度运算恰恰是 AI 计算的关键。想在本地跑 AI，需要的不是一颗靠液氮压制的高频处理器，而是一块显卡。哪怕用 RTX 5060 Ti 这样的”入门级”产品，也足以支撑实时语音合成、自然语言处理、图像生成、声音合成和视觉识别等任务，还可以运行各类开放权重的大语言模型，在自己的硬件上复现 ChatGPT 或 Claude 的不少功能。

Lewis 自己就以相当可观的折扣拿下了一块 RTX 5070 和一块 16GB 版 RTX 5060 Ti，原因都是无法正常输出画面。这两块卡此后一直在他的机器里稳定工作。

折扣不够大就不值得赌

Lewis 强调，买”坏卡”的目的很明确：用折扣价买到算力和显存。他见过因为风扇轴承损坏、或者接口被拽坏而被打上”故障”标签的 RTX 3090。

作为参考，同等显存规格的正常 RTX 3090 目前售价可以超过 1300 美元，而”损坏”版本的价格往往不到其一半。类似的机会在其他型号上也时常出现。

但他也给出一条警告：如果折扣幅度不大，这个险就不值得冒。轻微降价的”故障卡”是一笔糟糕的买卖——买家真正应该等待的，是那种足以反映”这卡对游戏玩家毫无价值”的深度折扣。

它们能干的活比想象中多

按 Lewis 的说法，”坏”显卡最适合放进无显示需求的家庭实验室服务器。自从开始使用这些卡，他已经把它们用在了这些地方：

• 驱动一套自动为截图生成描述文字的 AI 视觉系统
• 承担自然语言处理、语音合成，以及为一个 AI 聊天机器人提供大语言模型支持
• 搭建一个自托管的语音助手替代方案
• 运行一个能自己玩游戏的《我的世界》AI

在他看来这些只是开始。消费级显卡确实不具备旗舰 AI 设备的原始算力，但这不代表它们干不了正经活。诀窍在于把任务拆得足够具体、把参数约束得足够明确，这样才能得到理想的结果。

来源：How-To Geek

然后第一张电费单来了——涨到平时的近九倍。

我的判断是：这类硬件的账不能只算购机款，待机功耗才是真正的长期支出。

先把待机瓦数量出来

Pande 在主板固件里把处理器频率全部调低之后，这台机器 24 小时不关，待机仍然稳在 170 瓦。做过两处调整才降下来：拔掉插着的独立显卡，再把 Proxmox 的处理器调度策略切到省电模式，待机落到 120 瓦，尖峰 135 瓦。

对比一下就知道差距在哪：用嵌入式处理器的高端迷你主机和 NAS，待机 20 到 30 瓦；便宜的小主机不到 15 瓦。同样挂机一整年，差的是好几倍的电。

还有一笔隐藏成本：配件

Pande 还提到一个很少被说起的坑：企业级二手件坏了不好补。兼容特定至强处理器的主板尤其难找，杂牌产品几乎没有可查文档。整机低价收还行，单独配主板要碰运气。

什么情况下仍然值得

他并不主张一棍子打死。真要做重度虚拟化实验，低功耗轻薄本平台确实顶不上；电价便宜、或者一时买不到新配件，收一台老企业机改成虚拟机主力也说得过去，前提是省电选项全部打开。他自己现在的做法是：平时关机，要用才开。

买之前先查清这台机器的实测待机功耗，再乘上你家的电价和挂机小时数。你有在用二手服务器攒家庭实验室吗？

来源：XDA Developers