最新

我构建了 Synx，一个连接硬件、系统编程和现代 Web 开发的实时温湿度监测系统。<p>架构： - ESP8266 + DHT11 传感器通过 MQTT 发送数据 - Go 后端用于数据摄取，写入 InfluxDB（时序数据库） - Next.js 前端，具有实时 WebSocket 更新（零延迟）和历史图表<p>关键工程决策： - MQTT over HTTP 实现真正的实时推送 - 服务器端时间戳（ESP8266 没有 RTC） - InfluxDB 用于高效的时序数据存储 - 双通道：WebSocket 用于实时数据，REST API 用于历史数据<p>我作为一名初级 Go 工程师构建了这个系统，希望能够超越 CRUD 应用，并使用物联网协议、系统编程和实时数据流。<p>欢迎对架构选择提出反馈！

您好， 我开发了 Stos，因为它想拥有一个专门用于浏览 StackOverflow 的应用程序，而不会受到浏览器的干扰。它使用 Compose Multiplatform 构建，这使我能够跨平台共享代码。 我很想听听您对这款应用的看法。欢迎提出反馈！

WebAssembly 使得在浏览器中运行大规模计算成为可能。我想看看我们是否可以将浏览器视为 Kubernetes 的工作节点。 Kuack 是一个虚拟 Kubelet 提供程序，它将 Kubernetes 工作负载调度到浏览器标签页中。访问者的浏览器连接、报告容量并成为临时工作节点。它看起来像一个常规的 Kubernetes 节点——相同的 kubectl 命令，相同的 OCI 镜像，相同的工作流程。区别在于 Pod 在浏览器中而不是服务器上执行。通过多平台 OCI 镜像，如果没有任何代理可用，Kubernetes 可以回退到常规节点。 它专为短时、无状态、CPU 密集型作业而设计：来自真实网络的负载测试、本地数据预处理、边缘计算场景、机器学习任务等。 它不是您集群的替代品——只是对那些受益于浏览器执行的工作负载的额外选择。

各位 HN 用户， 我一直在开发一个 Python 库和正式框架，旨在降低 Agentic AI 系统的脆弱性。 核心前提是，生物细胞本质上是分布式的信息处理器，它们在数十亿年前就解决了“幻觉”（噪声）、“无限循环”（癌症）和“资源耗尽”（缺血）等问题。我没有仅仅将其用作松散的比喻，而是使用应用范畴论（特别是 Poly 中的多项式函子）来严格地将基因调控网络映射到软件 Agent。 该库中实现的关键概念包括： * 代谢余代数：我们将 token 预算建模为热力学资源。这使得 Agent 的“停机问题”可以被解决，通过强制执行严格递减的资源状态（如 ATP 耗尽），从而防止失控循环。 * CFFL（相干前馈回路）：一种用于“双密钥执行”的拓扑模式，可以在数学上降低幻觉概率（假设模型多样性）。 * 分子伴侣：部分验证器，将模式不匹配视为需要主动修复回路的错误折叠蛋白质，而不是“未定义”错误。 这是一个从“提示工程”向“拓扑工程”转变的早期尝试。 论文（预印本）：[https://github.com/coredipper/operon/blob/main/article/main.pdf](https://github.com/coredipper/operon/blob/main/article/main.pdf) 我特别感兴趣的是关于代谢余代数定义的反馈，以及是否有人尝试将 Poly 应用于生产 AI 系统。

原帖作者。 大多数用于解决 TSP（旅行商问题）的深度学习方法都依赖于使用大规模数据集进行预训练。我想看看一个求解器是否可以在没有任何来自其他问题的先验知识的情况下，针对特定实例“即时”学习。 我使用 PPO 构建了一个求解器，它针对每个实例从头开始学习。它在单个 A100 上，大约 5.6 小时内，在 TSPLIB d1291 上实现了 1.66% 的差距。 核心思想： 我的假设是，虽然最优解主要由“最小边”（最近邻）组成，但实际的难点在于少数几个超出局部范围的“例外边”。 我没有进行预训练，而是设计了一种基于这些例外边的拓扑/几何结构的归纳偏置。智能体会根据微观/宏观结构接收关于哪些边可能具有前景的指导，而 PPO 则通过反复试验来填补空白。 看到强化学习在没有数据集的情况下达到这种水平，这很有趣。我已经开源了代码和一个 Colab 笔记本，供任何想验证结果或尝试“例外边”假设的人使用。 代码和 Colab：[https://github.com/jivaprime/TSP_exception-edge](https://github.com/jivaprime/TSP_exception-edge) 很乐意回答关于几何先验或 PPO 实现的任何问题！

最近我遇到了一个问题，好几天都无法在 sms-activate 上充值余额。 这并非偶然发生的故障——付款根本无法通过，而且对于何时能解决这个问题也缺乏明确的说明。对于任何依赖短信验证服务进行测试、用户引导流程或质量保证的人来说，这种依赖性失效都具有出乎意料的破坏性。 这让我反思了一件我们常常低估的事情：类似“基础设施”的第三方服务可能有多么脆弱，尤其是在它们被广泛使用但抽象程度不高的情况下。 过去几个月，我一直在开发一个名为 SMS-Act 的小型替代方案，最初只是为了降低我自己的运营风险。目标不是在规模上竞争，而是专注于我个人关心的几个原则： * 明确的范围：仅限一次性、临时号码（而非长期租赁） * 透明的定价（如果验证失败，积分将自动退还） * 为只需要快速获取验证码的开发人员和测试人员提供更简单的用户体验 * 当出现问题时，减少“黑盒”行为 我原本没打算公开谈论它，但最近的停机让我意识到，这里很多人可能正面临同样的问题，并且默默地寻找替代方案。 我很好奇： * 您如何在您的技术栈中处理短信验证依赖关系？ * 您是构建内部备用方案，还是在出现问题时切换提供商？ * 您在使用此类服务时遇到的最大痛点是什么？ 如果有人感兴趣，我很乐意分享到目前为止构建 SMS-Act 的经验——或者仅仅是讨论更好的方法来降低围绕此类外部服务的风险。 （这里没有硬性推销——我真的更感兴趣其他人如何解决这个问题。）