一周热榜

前几天我查看了我的 Framework 笔记本上的 iio 设备，结果发现 Framework 12 的铰链角度传感器相当准确！所以我制作了一个 LidAngleSensor (<a href="https://github.com/samhenrigold/LidAngleSensor" rel="nofollow">https://github.com/samhenrigold/LidAngleSensor</a>) 的版本，适用于 Linux 上的 Framework 12，这样你就可以让你的铰链发出嘎吱嘎吱的声音了。

你好 HN， 这是一个我为了解决工作中遇到的问题而临时编写的简单命令行工具。 我们遇到的问题是，一台 Linux 服务器连接了多个 USBIP 设备，而我们很难分辨出是谁连接了哪个设备。 这时 `usbatlas` 就派上用场了。它是一个基础应用，运行在 Linux 设备文件系统之上，并且依赖于 `usbip` [0][1]。它可以让你查看连接到你的 Linux 服务器上的 USB 设备以及它们的来源。目前，设备源 IP 地址解析功能还有一些问题，我正在努力解决这些细节。 下面是一个示例输出： ``` $ usbatlas --usbip xHCI Host Controller [serial: xxxx:xx:xx.x] +- USB2744 +- Lenovo New Calliope USB Keyboard +- /dev/hidraw0 +- /dev/hidraw1 +- /dev/input/event3 +- /dev/input/event4 +- /dev/input/js0 +- Lenovo USB Optical Mouse +- /dev/hidraw2 +- /dev/input/event5 +- /dev/input/mouse0 +- Bluetooth 9460/9560 Jefferson Peak (JfP) +- USB2.1 Hub +- USB2.1 Hub +- Saleae Logic +- FT4232H MiniModule [serial: xxxxxxxx] +- /dev/ttyUSB4 +- /dev/ttyUSB6 +- /dev/ttyUSB7 +- /dev/ttyUSB8 +- USB2.1 Hub +- USB2.1 Hub +- FT4232H MiniModule [serial: xxxxxxxx] +- /dev/ttyUSB0 +- /dev/ttyUSB1 +- /dev/ttyUSB2 +- /dev/ttyUSB3 xHCI Host Controller [serial: xxxx:xx:xx.x] +- USB3.1 Hub +- USB3.1 Hub +- USB3.1 Hub +- USB3.1 Hub +- J-Trace PRO [serial: xxxxxxxx] USB/IP Virtual Host Controller [serial: xxxxxxxx] +- FT4232H MiniModule [serial: xxxxxxxx] [usbip] +- /dev/ttyUSB9 +- /dev/ttyUSB10 +- /dev/ttyUSB11 +- /dev/ttyUSB12 +- FT232R USB UART [serial: xxxxxxxx] [usbip] +- /dev/ttyUSB13 +- FT4232H MiniModule [serial: xxxxxxxx] [usbip] +- /dev/ttyUSB14 +- /dev/ttyUSB15 +- /dev/ttyUSB16 +- /dev/ttyUSB17 USB/IP Virtual Host Controller [serial: xxxxxxxx] ``` [0] https://github.com/dorssel/usbipd-win [1] https://wiki.archlinux.org/title/USB/IP

作者在此。从一个私有的 Obsidian 库（8360 条笔记，300 万字）中发布了约 660 条笔记。大约在 2011 年开始使用 OneNote，2021 年迁移到 Obsidian [1]，并使用 Python 脚本导入了所有内容 [2]。 笔记会随着时间累积，我的写作也由此而来。“语义层”笔记始于 2022 年，后来发展成一个四部分的博客系列，再后来成为我书中的一个章节。“物化视图”、“大表”、“dbt”和“OLAP”是分开的笔记，写作时间相隔数年。我直到后来才注意到它们是相同的模式，于是又形成了一个新的章节。 发布：在笔记中添加 `#publish` 标签，然后运行 `make deploy`。使用 Quartz + Hugo，通过 rsync 同步到我自己的服务器 [3]。代码 [4]。基于图谱的语义搜索 [5]。

我研究了如何以 a) 结构化的方式存储代理状态，b) 在没有专用 MCP 内存/状态服务器的情况下运行，并且我能够获得 c) 一条清晰的、可差异化的审计日志，记录所有随时间变化的状态。我没有找到任何符合要求的方法。 在 [https://github.com/commitspark/demo-agentic-mcp](https://github.com/commitspark/demo-agentic-mcp) 中，我演示了一个实现，该实现通过将 Claude 代理与我之前发布的 Commitspark 库及其完全由 Git 支持的 GraphQL API 相结合，满足了这些要求。 在此演示中，模拟了两个独立的 Claude 代理，它们共同完成一个任务跟踪器。第三个代理会审查任何任务更改，并回滚明显不正确的更改。完整的演示记录包含在 README 文件中，包括代理的原始工具调用。 任务代理通过一个小型 MCP 服务器访问数据，该服务器公开了两个 Commitspark API（GraphQL API、Schema API）。然后，这些代理可以获取 schema 并自行编写 GraphQL 调用，GraphQL 会自动强制执行写入的数据符合 schema。验证器代理还可以访问基本的 Git 功能，以查看 diff 和撤销提交。 我正在寻求关于以下方面的反馈：共享代理状态的 schema 验证是否是人们实际遇到的问题，或者在实践中，松散类型的 JSON + 重试是否足够。

在看到自由