最近在折腾自己的阿里云 2G 小鸡。
一开始只是觉得机器越来越紧张，free -h 看了一眼，发现有点不对劲：
free -h输出大概是这样：
total used free shared buff/cache available
Mem: 1.6Gi 1.4Gi 67Mi 5.6Mi 385Mi 275Mi
Swap: 4.0Gi 0B 4.0Gi这就很奇怪了。
服务器明明是 2G 内存规格，为什么系统里 Mem 的 total 只有 1.6Gi？
一开始我还以为是云厂商的 GB / GiB 口径差异。毕竟 2GB 按十进制换算成 GiB，本来就不是完整的 2GiB。
但这差得还是有点多。
最近学 HiveD，第一感觉是：它的算法很朴素。
核心分配逻辑很像 buddy allocator：申请资源时找合适的 cell，找不到就从更大的 cell 拆；释放资源时，如果 buddy cell 都空了，就再合回去。
这套东西不难。HiveD 有意思的地方不在“分配算法多复杂”，而在它先把 GPU 集群里的资源重新抽象了一遍。
Note
普通 quota 问的是：用户有多少张 GPU？这两个问题看起来只差几个字，但在多 GPU 训练里差很多。
最近发现 Windows 的 C 盘空间又快满了。用 SpaceSniffer 扫了一下，发现一个非常离谱的大文件：
C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\db-wal它竟然占了二十多 GB。
这显然不是普通的用户文件，也不像是可以直接删除的软件缓存。于是这次记录一下完整排查和修复过程。
今天发现一个问题：Mac 合盖放了一会儿，拿出来的时候非常烫。
这事挺吓人的。正常来说合盖之后应该睡眠，最多温温的，不该像还在跑什么任务一样发热。尤其是如果放在包里，散热条件很差，时间长了肯定不太好。
karpathy佬提出的一个长期的，更好的利用LLM的记忆的方式。
具体使用方法：把下面的内容替换到GEMINI.md或claude.md或其他md文件，指示agent读取即可
下面是用Sonnet生成的～我感觉提取效果很不错
