主页

免责声明： 本文涉及对 GPU 驱动的修改，作者不对任何因此产生的后果负责。

为了方便各类课程给学生提供开箱即用的 Python 环境，我在教学实验室的 Kubernetes 上（由杰哥强力驱动）部署了一套 JupyterHub，并进行了一些必要的自定义。本文介绍整个部署过程，并记录一些经验和踩过的坑。

最近组里新购入了一些杂牌 GPU 服务器，为了监控功耗，我部署了 Prometheus 社区的 ipmi_exporter 从 BMC 读取带外数据，并使用 Grafana 制作了 Dashboard。然而很快我就发现了奇怪的现象：

众所周知，在镜像站界，PyPI 是个难伺候的主：大量的硬盘占用、巨大的流量、频繁的更新，还有不靠谱的同步工具 bandersnatch。你说为什么不靠谱？听说过其他 没有能力 删除上游删掉了的文件的同步工具吗？

在高性能计算场景中，能有效地测量和控制 CPU 功耗对于优化性能和能效至关重要。硬件厂商（如 Intel、AMD）提供了一些接口和工具，允许用户在不依赖外部硬件的情况下，进行带内（inband）的 CPU 功耗测量与限制。本文将简述常用的方法和工具。

转眼间，2025 年已经快过去了（显然，我还没有毕业）。上周翻阅照片的时候，意识到我这两年还是去了不少地方，甚至有些地方都快忘记了。 正好有朋友催更我的博客已久，干脆挑选一些值得记录的，写一些流水账。也希望我在 2025 年结束前能写完它。

今天是研究生毕业论文提交初稿的日子（当然和我没什么关系）。中午有组里的同学来找我，说 GPT 老师找出了如下的问题：

我在为 Debian 打包 drat-trim 项目时，发现生成的可执行文件居然依赖 glibc >= 2.39，而我打包的另一个纯 C 项目 kissat 则只依赖 glibc >= 2.34。明明都只是用了简单的 C 标准库，怎么会有这样的差别呢？