技术圈正在讨论的分享链接。
xzutils 后门事件是近年来最具代表性的开源供应链攻击案例之一。本文不是重复介绍漏洞原理，而是从 FreeBSD 维护者的角度，复盘这一事件如何影响系统发行版的第三方软件引入流程。
文章指出，FreeBSD 最终没有受到实际影响，很大程度上来自其重写 build 部分、删除用例代码等工程实践。但作者也坦承，这并不意味着流程无懈可击，尤其是在使用上游签名 tarball、比较 git 内容、运行构建脚本等环节，仍然存在被攻击者利用的空间。
最值得关注的是，文章把供应链攻击的目标从“最终用户系统”前移到了“维护者本人”。如果维护者在本机、非隔离环境中执行下载来的代码或生成脚本，攻击者完全可能先攻破维护者环境，再进一步污染下游生态。
这篇文章适合关注开源治理、发行版维护和软件供应链安全的读者阅读。它的价值不在于给出复杂技术细节，而在于提醒团队重新审视日常维护流程中的默认信任。
这篇文章记录了 soluna/ltask 在移植到 wasm 和非 Windows 平台过程中遇到的一个典型工程难题：如何在主线程事件循环中执行特定任务，同时仍保留原有多线程调度模型。
问题的核心来自图形 API 和平台约束。sokol 并非线程安全，OpenGL 又依赖当前线程状态，而 wasm 环境下主线程、worker、pthread API 的边界进一步放大了调度复杂度。
作者的解决思路不是重写整个调度器，而是在 ltask 中“打洞”：让某些必须在主线程回调中执行的 Lua 任务，临时从调度表中移出，由主线程接管执行，完成后再归还给调度器。
文章最有价值的地方，是把 coroutine、Lua 虚拟机、C 栈、主线程事件循环和图形 API 约束放在同一个工程场景中分析。它不适合泛泛阅读，但对做游戏引擎、wasm 移植或复杂运行时调度的开发者很有参考价值。
很多团队在拆分大型 Git 仓库时，都会遇到 submodule 和 subtree 的选择问题。本文围绕两种方案的实际维护体验展开分析，而不是只停留在命令层面对比。
作者认为，submodule 更符合“仓库独立治理”的设计目标，适合需要清晰边界、独立版本管理和长期维护的大型项目；而 subtree 虽然使用门槛更低、clone 更方便，但容易造成代码冗余和仓库持续膨胀。
文章比较有价值的地方在于，它没有单纯强调“哪种更简单”，而是从架构治理、团队协作和长期维护成本角度讨论问题，适合已经进入中大型工程阶段的团队参考。
如果你正在做 monorepo 拆分、多仓库治理，或者维护复杂依赖关系，这篇文章值得一读。
新的 C++ 标准中 不允许给 main 指定 linkage-specification 了。
当然，考虑到原本 main() 也是 C 运行环境在开始运行程序的时候调用的， 而 C 运行环境自然也预期 C linkage，即不按照 C++ 的习惯对符号根据参数增加名字前缀， 因此大部分编译器在遇到 C++ 程序定义全局 main() 的时候也会按照习惯采取 C linkage 方式去翻译。这一规则首先被 GCC 采纳，随后 LLVM 也跟进了。
然而我今天遇到一个奇葩彻底把我雷到了。
一个使用 Golang 构建的轻量级 CAN 管理服务：CAN-Bridge。作者把复杂的 CAN 配置、端口初始化、状态检测、报文收发封装成 HTTP API，不用再写脚本和记 SocketCAN 指令，还支持自动恢复、Prometheus 监控和容器化部署。适合机器人、工业控制、车载设备等场景做稳定化改造。
这份时间线，是从 v2026.1.5 开始往后捋。按 release 命名和说明来看，这一版基本可以当成项目正式进入 clawdbot 阶段的起点。后面它先经历了 clawdbot、Clawdbot 这几个写法上的变化，中间还短暂改名成过 Moltbot，直到 v2026.1.29 前后才真正把名字切到 openclaw。
文章系统解析 Go 协程池的实现原理和实践，包括为何需要协程池、基本实现方式、协程数设置依据及性能对比测试。示例代码演示如何手动构建协程池，并推荐三种高性能第三方库（如 ants、tunny）。适合进行高并发控制和资源管理优化的场景。
本文介绍了合成控制法（Synthetic Control Method，SCM）原理及其扩展：首先通过选择多个未受干预单位并加权构建一个“合成对照组”，以模拟受干预单位在无干预情况下的表现；然后详细推导了权重 W 与协变量权重矩阵 V 的嵌套最优化过程；最后介绍了“合并损失函数 + 正则化（Lasso/ElasticNet）”的扩展方案，以增强模型稳健性。适用于政策或市场活动影响评估。
