监控工具边界
Prometheus、Grafana、Netdata、Uptime Kuma 的名字和流行度不能说明能力边界。等真实需求出现时,再比较部署形态、数据模型、权限和维护成本。
已经完成主机与容器监控的实际部署,轻量入口成立。自定义探针、临时进程观测和长期存储表现仍待验证。运行记录保留在本地 Beszel runbook。
记录尚未进入当前主线、但值得保留的学习主题与待验证线索。
每个主题只记录当前认知、已经验证的事实、仍然未知的部分和再次启动的条件。
条目顺序不代表学习顺序;背压限制的是同时展开的主题数量,不规定下一个必须学习什么。
状态更新:2026-07-13
Prometheus、Grafana、Netdata、Uptime Kuma 的名字和流行度不能说明能力边界。等真实需求出现时,再比较部署形态、数据模型、权限和维护成本。
已经完成主机与容器监控的实际部署,轻量入口成立。自定义探针、临时进程观测和长期存储表现仍待验证。运行记录保留在本地 Beszel runbook。
手动 build、tag、push、pull 已经验证。部署编排、拉取审计和自动化发布尚未启动,等手工流程产生真实维护成本后再判断。
Bun 的官方复盘展示了一种大规模迁移工作流:先把语言映射和生命周期判断固化成事实源,做少量文件试跑,再分片机械迁移;实现、对抗审查和修复使用独立上下文,编译错误与测试失败成为工作队列,最后经过跨平台 CI、canary、安全审查和持续 fuzzing 收口。
关键前提不是 Agent 数量,而是已有实现可以充当行为基准、测试套件能够作为 oracle、迁移期间尽量不同时改架构,并且有人持续校准生成流程和发布 gate。当前只记录结构,不复现 workflow;以后遇到有稳定旧行为、充分测试证据且手工迁移成本已经成为真实瓶颈的大型迁移,再从单个实现者与独立审查者的最小循环开始验证。
Garage 是用 Rust 实现的 S3 兼容分布式对象存储,面向中小规模、自托管和跨地域普通网络。它优先选择轻量、简单与故障韧性,明确不追求极致性能、完整功能、纠删码和 POSIX 兼容。当前只记录其边界取舍;出现跨站点 artifact、备份或对象存储需求时再评估。
eBPF 是 Linux 内核里的可编程挂钩:用户态加载经过 verifier 检查的受限程序,在网络、观测或安全事件发生时进入内核路径执行。它与 QUIC、Tokio 都在重新安排用户态和内核态的职责,但方向不同:前者把部分逻辑上移,eBPF 把受控逻辑送入内核。等 tcpdump、strace 无法解释真实路径时,再通过现成工具体验。
服务端 template 在服务器填入数据并返回 HTML,属于 SSR;浏览器原生 <template> 是暂不显示、可供 JavaScript 复制的结构样板;htmx 让服务端返回 HTML 片段并局部替换页面;Qite.js 在现有 DOM 上组织组件、事件和客户端状态;React、Vue、Svelte 一类更适合由客户端状态主导的复杂界面。内部小工具先从服务端 HTML 出发,局部刷新或客户端状态出现真实复杂度时再选择下一层。
MPA 在页面跳转时向服务端获取一份新的完整 HTML;SPA 通常只加载一次应用外壳,后续由 JavaScript 切换路由和界面。SSR / CSR 描述 HTML 主要在服务端还是浏览器生成,可以和 MPA / SPA 组合;hydration 是给服务端生成的 HTML 接上客户端行为;PWA 关注安装、缓存和离线能力,不是另一种渲染方式。htmx 能局部刷新,但不因此自动变成 SPA;toolgate 这类内部工具通常从 SSR + MPA 起步就足够。
Snowflake ID 把时间、worker ID 和同毫秒序列装进 64 位整数,能分布式生成并大致按时间排序,但依赖稳定且唯一的节点身份,也要处理时钟回拨。当前环境没有自动部署和可靠的 server ID 分配,这个前提尚未成立。
UUID 不是单一算法,而是一族无需中心注册的 128 位标识格式:v4 主要依靠随机数,v5 根据命名空间和名称确定性生成,v7 组合 Unix 时间与随机位,改善按时间排序和数据库索引局部性。常见带连字符文本有 36 个字符,实际值仍是 16 字节;唯一标识也不等于授权凭据或秘密。
Nano ID 用安全随机数生成紧凑、URL 友好的字符串,不需要节点协调,但不提供时间排序;SparkID 是较新的具体实现,把毫秒时间、单调计数和随机数组合成可排序的 Base58 ID,不需要显式 worker ID,但还不是通用标准。只有出现跨节点离线生成、索引顺序、公开 URL 或数据库写入热点等真实约束时,再连同 UUID v7、ULID 和数据库自增一起比较。
参考样例:Serving Large Language Models on Huawei CloudMatrix384。当前先保留工程文章方向;证据、对比、相关工作和可复现性足够时,再判断是否需要论文格式。
观察日期:2026-07-21
m 的情形给出一般构造,Knuth 随后整理并验证。这是机器参与搜索、建模和构造的样本。Knuth 原文这些事件不等于数学已经穷尽,但说明机器正在从整理、计算和验算进入候选生成、证明与反例发现。不同成果的可信速度取决于证书形态:显式反例可以很快验算,长证明仍需要同行理解和复核。
这里只作时代观察,不启动数学研究线。只有新的事件实质改变上述判断时才更新,不追逐每一条“数学被解决”的新闻。
记录日期:2026-07-16
当前主线只补 BFS 需要的普通图基础:邻接表、分叉、合流、环、重复边、节点生命周期、分层和路径证据。下面这些主题已经被看见,但不属于当前题目的前置条件,也不构成接下来的学习清单;记录名称不等于创建教程或启动练习。
先完成当前 BFS 题。之后只有基础五题走到对应结构、真实问题碰到某个概念,或者五题完成后兴趣仍然明确时,才一次选择一个主题,从一张图、一个问题和一个可验证结果开始;不按数据结构或算法题单整体推进。
更新日期:2026-07-26
linux-0.11-rs 以原版 Linux 0.11 和 rCore Tutorial 为参考,在固定的 i386 / QEMU 边界内重建可启动、可交互、可测试的 Rust 系统。基于前人代码与教学材料并不削弱其工程真实性;关键仍是如何选择语义基准、划定范围并完成验证。
rCore 不是阅读 linux-0.11-rs 的前置课程。它使用不同的体系结构和教学组织方式;未来只有在具体子系统卡住时,才把对应章节作为旁路解释,不先完整学习另一套系统。
阅读:内核,从地址翻译开始。先整理 VPN 到 PPN、page fault、x86 分段、RISC-V 页表,以及内存和驱动知识的当前边界。
已有 PoC 已验证:网络可达时,TCP、PTY 和 bash 可以组成一个可交互、可退出的远端终端。它尚未接真实串口,也没有认证和加密;代码与运行输出才是实现状态的事实源,后续系统语义仍按需消化。
阅读:tline,从 TCP 到远端终端。整理字节路径、PTY、session、setsid()、SIGCHLD、进程回收与生命周期测试。
SCM_RIGHTS 把已打开的文件、socket 或设备引用交给另一个进程。等权限分离、socket activation、master/worker、沙箱 broker 或热升级成为真实问题时再推演。script(1) 与 PTY 驱动程序:这里的 script 是终端会话录制工具,不是上传或执行脚本。它和 expect、交互式 CLI 测试共享同一模型:外层程序持有 PTY master,shell 或被测程序使用 slave。当前只保留这个联系,不实现录制和自动化。这三条都不属于当前 tline PoC 的完成条件,也不因记录在这里自动变成后续项目。
已经知道虚拟内存、用户态 / 内核态隔离和缺页的大意;尚未独立推演地址拆分、页表建立、缺页处理、引用计数与 CoW 的完整状态变化。
已经知道 fork、exec、系统调用和调度的基本位置;尚未手写进程状态迁移、任务选择、等待 / 唤醒以及退出 / 回收的不变量。
已经知道 inode、数据块和分层索引的大意;尚未独立推演直接块、一级 / 二级间接块、位图分配、buffer cache 与块设备 I/O 如何组成读写路径。
已经接触锁、条件等待、信号量和异步任务;尚未在内核语境下手写中断入口、上下文保存、临界区、等待队列、设备完成通知与恢复执行的完整过程。
当前没有在真实系统中实现、部署或排障 Raft,也还不能完整推演其安全性。已经知道它用于在节点故障和网络分区下复制控制状态,核心线索包括 leader election、term、日志复制、多数派提交和故障恢复;这些名称尚未形成自己的模型。
现有业务规模是实践证据的边界,不是能力上限;但学习 Raft 本身也不能替代更大规模的运行证据。以后只有真实控制面或元数据一致性问题出现、系统面试需要这层口述,或者注意力容量允许且兴趣仍然存在时,才从三节点故障与分区推演开始整理教程,不直接手写完整实现。
记录日期:2026-06-26
JWT、OAuth 2.0、OIDC、SAML 值得认真学,但不进入 dashboard / toolgate 第一阶段交付范围。
一种 token 格式,不是完整认证授权协议。重点是签名、claims、issuer、audience、过期、撤销和权限变更滞后。
授权协议。重点是 authorization code flow、access token、refresh token、scope、resource server。
建立在 OAuth 2.0 上的身份协议。重点是 id token、user info、JWK 验签、SSO 和身份提供方。
企业老系统里常见的单点登录协议。重点是 XML 断言、IdP/SP 模型、签名、证书和浏览器跳转。
dashboard / toolgate 第一版只解决内部小工具入口治理:
内部小工具不再靠口头授权、手改数据库和散落 token 维护;
入口、登录、授权、审计都能通过 dashboard 管起来。
| 问题 | 第一版处理 | 暂不处理 |
|---|---|---|
| 浏览器用户登录 | server-side session cookie | OIDC SSO |
| 服务入口权限 | Nginx auth_request + dashboard auth-check |
通用 API gateway |
| 服务身份信息 | 入口注入 X-Dashboard-* header |
JWT issuer / refresh token |
| 审计 | 登录、授权变更、入口访问记录 | 完整企业 IAM 审计体系 |
| 组织模型 | 用户、服务、授权关系 | 复杂 RBAC、多租户、组织架构、MFA |
不能用“我还没完全理解 OAuth / OIDC / SAML”当作不交付的理由。当前方案并不低级,它只是范围更小。
也不能因为第一版能跑,就假装已经掌握了身份系统。标准协议需要单独学习、单独验证、单独消化。
当前项目上克制,知识学习上认真。不把标准协议当装饰,也不把“不上标准”当自卑。