最新

大家好， 我正在做一项研究，有个问题想请教一下。当语音 AI 助手的流量激增时，你们会怎么处理？据我所知，Kubernetes 的原生自动伸缩器（HPA）通常无法及时响应这种突发流量，导致延迟过高。如果方便的话，我很乐意了解一下你们的经验。 谢谢！

大家好，我是 Ben，来自 K-Scale Labs (<a href="https://kscale.dev">https://kscale.dev</a>)。我们正在构建开源人形机器人。 硬件视频：<a href="https://www.youtube.com/watch?v=qhZi9rtdEKg" rel="nofollow">https://www.youtube.com/watch?v=qhZi9rtdEKg</a> 软件视频：<a href="https://www.youtube.com/watch?v=hXi3b3xXJFw" rel="nofollow">https://www.youtube.com/watch?v=hXi3b3xXJFw</a> 文档：<a href="https://docs.kscale.dev">https://docs.kscale.dev</a> Github：<a href="https://github.com/kscalelabs">https://github.com/kscalelabs</a> 五月份的 HN 帖子：<a href="https://news.ycombinator.com/item?id=44023680">https://news.ycombinator.com/item?id=44023680</a> 我创办 K-Scale 的原因是我真的很想捣鼓一个人形机器人，所以我知道如果我造一个，至少会有一个客户。在 Unitree G1 推出之前，当时最便宜的选择也要 5 万多美元，但我认为我可以用 COTS（商用现货）组件以大约 1 万美元的价格造一个，这对独立黑客和开发者来说会是一个更好的价格点。 我们使用一些 3D 打印机和从亚马逊和阿里巴巴购买的零件制造了第一个版本。它并不出色，但它让我们构建了完整的流程，从设计和制造硬件到在模拟中训练控制策略。我们实际上在两个月内完成了大部分工作，并在 YC Demo Day 之前就有一个可以站立和挥手的机器人（尽管它没啥其他用处！）。 从那时起，我们的重点就放在了如何将一个爱好级机器人变成消费级机器人，同时不增加我们的 BOM（物料清单，即所有零件的成本）或不得不建立我们自己的工厂。这出乎意料地困难。目前，许多机器人组件的供应链都经过中国，但关税使得依赖中国供应商的组件变得困难。此外，即使是 1 万美元的价格点，对于大多数客户来说，对于一个功能相当有限的人形机器人来说，也相当昂贵。 我们的解决方案是开源我们的硬件和软件。这使我们更容易应对关税和制造挑战。通过公开我们的参考设计，我们的供应商更容易找到为我们提供有竞争力的解决方案的方法，而我们的制造合作伙伴也能够更容易地调整我们的设计以适应他们的生产流程。 在需求方面，人形机器人的基本问题是它们目前基本无用，而且要让它们变得有用，这可能是一个漫长且相当耗费资金的旅程。我的期望是，像我这样对捣鼓人形机器人感兴趣的人群中存在着大量的潜在兴趣，而且这个客户群体是比更传统的以业务为中心的机器人应用更好的客户群体。作为这个客户群体中的一员，我认为开源软件和硬件将是一个强大的价值主张，特别是对于探索将人形机器人引入自己业务领域的开发者来说。 更具哲学意味的是，我认为拥有一个好的、开源的人形机器人很重要。我认为这项技术很可能比许多人目前预期的发展得更快，而由某个公司拥有的成群结队的人形机器人四处走动是很反乌托邦的。 目前，我们以 8999 美元的价格出售我们的基础人形机器人 K-Bot。我们现在出售它的主要原因，而不是等待做更多的研发，是因为我们试图在进行最终的 DfM（面向制造的设计）之前，与我们的供应商协商批量价格。例如，我们能够为执行器和末端执行器协商比普通独立开发者为小批量订单所能获得更好的批量定价。 然而，今天许多想购买人形机器人的人这样做是因为他们想要一个完全自主的机器人来做所有的家务，这是一个非常困难（尽管令人兴奋）的事情。为了解决这个问题，我们提供“完全自主”选项——它与机器人硬件相同，但我们将提供免费的硬件和软件升级，直到我们能够使机器人完全自主。通过这种方式，我们可以预先获得一些额外的现金来启动开发，并开始建立一个核心团队，他们致力于帮助我们提高机器人在各种环境中的能力。从我们客户的角度来看，这是一种降低从一家年轻的硬件公司购买第一代产品的风险的方式，并对技术的发展产生更大的影响。 构建开源软件和硬件最好的部分是被比我们更聪明的人“肢解”，所以我们很乐意听取您的反馈！

证书透明度系统可以保护您免受恶意 HTTPS 证书的侵害。当 CT 日志拥有可预测的私钥时，整个 Web PKI 安全模型就会崩溃。 这将危及该日志签署的每一个证书——过去、现在和未来。 我报告了 Google Chrome 信任的证书透明度基础设施中的安全漏洞。他们将其驳回为“不是漏洞”，未经同意就公开了我的私人报告，然后在几个小时后默默地实施了我的修复方案。 发现： 在基准测试过程中，我使用了 echo " " > seed.bin (32 个空格)。Sunlight 接受了这一点，并为 CT 日志生成了有效但可预测的私钥。没有警告，没有错误。 为什么这很重要： 1. 操作员正确运行：cat /dev/urandom > seed.bin 2. 文件系统损坏，用空值/空格填充种子（发生在生产环境中） 3. Sunlight 从损坏的种子中默默地生成可预测的密钥 4. CT 日志“正常”运行——有效的签名，没有错误 5. 任何知道损坏的人都可以重新创建私钥 如果没有校验和，即使是完美的操作员也会被默默地攻破。这是保护 HTTPS 证书的 PKI 基础设施。 这并非假设——文件系统损坏在生产系统中很常见。断电、内核崩溃和存储故障经常会导致部分写入和空字节。 谷歌的回应： - “不是漏洞”：https://groups.google.com/a/chromium.org/g/ct-policy/c/qboz9s8b9j8/m/B6JXa2q1BAAJ - 未经同意就发布了我的私人安全报告 - 几个小时后实施了我的确切修复方案 - https://github.com/FiloSottile/sunlight/commit/f62f9084016c4c377d3855471720d7d0cdea3663 - https://github.com/FiloSottile/sunlight/commit/32cc3ea2524e89f93febb967683c6467753f484d - 禁止我指出矛盾：https://groups.google.com/g/certificate-transparency/c/u8SsXgSFbz4/m/14ePyeCrBAAJ 额外漏洞： 他们使用 User-Agent 字符串进行身份验证。任何人都可以伪造这些标头来绕过速率限制并压垮服务： - https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L176 - https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L148 这是生产代码，今天被 Google Chrome 信任 (https://www.gstatic.com/ct/log_list/v3/all_logs_list.json) 请参阅“sunlight”日志。 导致我被禁的电子邮件就在这里 https://groups.google.com/g/certificate-transparency/c/u8SsXgSFbz4/m/14ePyeCrBAAJ - 请您自己判断它是否违反了任何合理的行为准则。 还有其他人因为负责任的安全披露而遭到报复吗？我们如何修复一个报告漏洞会被禁止而问题却被悄悄修补的系统？

今天有个供应商要求我们提供 Kubernetes 集群的日志。除了 DataDog，我们没有运行任何日志聚合工具（没有 fluentd/fluentbit），所以我需要从三个命名空间中的 30 多个部署中获取日志。 与其手动为每个部署运行 kubectl logs，我构建了这个 Python CLI，它可以一次性从命名空间中收集所有部署的日志。它按日期和命名空间组织日志，并行运行收集，并处理常见的 k8s 边缘情况（每个部署有多个 Pod、Pod 失败等）。 用法很简单：klogger collect -n production 没什么了不起的，但它为我节省了数小时的手动工作，并且可能对遇到类似情况的其他人有所帮助。它基本上是一个 kubectl 包装器，擅长一件事——在您需要时批量收集日志。 GitHub: <a href="https://github.com/christensen143/klogger">https://github.com/christensen143/klogger</a>

我开发了 RingtoneSmartKit——一个开源的 Kotlin 库，用于以简单可靠的方式管理 Android 铃声。<p>它支持： - 设置系统铃声：闹钟、通知和来电 - 为联系人分配自定义铃声 - 直接处理来自 assets 或内容 URI 的音频 - 无需 Context 或 Activity——使集成在应用程序的任何地方都更容易<p>目标是提供一个干净、可重用的铃声处理解决方案，而不依赖于混乱的平台代码。<p>欢迎反馈、测试和建议！