## TestFlight Beta 测试总结 TestFlight 允许开发者分发其应用程序的测试版，用于在 iOS、iPadOS、macOS、tvOS 和 visionOS 上进行测试。测试者通过电子邮件或公共链接接收邀请，并可在最多 30 台设备上安装测试版应用程序。 测试版构建可用 90 天，之后将无法使用，需要下载 App Store 版本。在测试期间，应用内购买是免费的，但不会转移到已发布的应用中。可以启用自动更新，以无缝安装新的构建版本。 测试者可以直接在 TestFlight 中访问之前的构建版本和构建组。开发者会收到公共链接测试者的匿名使用数据（会话、崩溃、安装日期、版本）。Beta 测试期间，订阅续订率加快，以便更快地迭代。安装过程因平台而略有不同，但通常包括接受邀请并通过 TestFlight 安装。 确保您的设备满足最低操作系统要求，以支持自动下载应用内资源等功能。
每日HackerNews RSS
## 微波炉：Bluesky/AT协议上的类似TikTok的应用
一名开发者发布了“微波炉”，这是一个原生iOS应用（可通过TestFlight获取：[https://testflight.apple.com/join/cVxV1W3g](https://testflight.apple.com/join/cVxV1W3g)），旨在利用去中心化AT协议（Bluesky）复制TikTok的体验。
该应用旨在展示一种可行的、轻量级客户端方法来实现短视频分享，完全依赖现有的ATproto基础设施——这意味着没有自定义后端。开发者正在寻求用户对用户体验、纯客户端实现（如排序和审核）的挑战以及潜在协议限制的反馈。
早期测试者报告说，该应用具有流畅的滚动体验，但指出存在加载指示器缺失、UI小故障以及内容多样性不足（目前偏向美国政治）等问题。用户建议鼓励创作者将内容交叉发布到Bluesky，或构建缓存解决方案从TikTok和Instagram等平台拉取内容。
vLLM已完全过渡到其V1引擎，在大型语言模型（LLM）推理方面实现了显著的性能提升，并已通过Meta和Hugging Face等公司的基准测试和实际应用验证。 近期的优化，得益于近2000名贡献者组成的社区，现在在多节点部署中可提供**每块H200 GPU 2.2k tokens/秒** – 相比之前的成果有了大幅提升。
关键进展包括**双批次重叠（DBO）**以提高GPU利用率，**专家并行负载均衡（EPLB）**以解决混合专家（MoE）模型中不平衡的工作负载，以及针对DeepSeek架构优化的内核。 **Wide-EP**部署可最大限度地提高DeepSeek-V3等模型的KV缓存效率，并且**分离式服务**进一步提升性能，尤其是在MoE模型中。
vLLM与**llm-d、Dynamo和Ray Serve LLM**等服务框架无缝集成，提供灵活的部署选项。 持续的开发重点是弹性专家并行性、长上下文支持以及对DeepSeek-R1等模型和即将推出的GB200硬件的进一步优化。
## DeepSeek 2.2k Tokens/秒：成本分解
最近的基准测试显示，DeepSeek，一个670亿参数的模型，在使用vLLM时，在NVIDIA H200 GPU上实现了每秒2.2k tokens。 这意味着在16xH200系统上，每年可能生成630亿 tokens（估计成本：75万美元）。
最初的计算表明成本约为每百万tokens 4美元，但修正后指出，考虑到每GPU的性能，更现实的成本是**每百万tokens 0.25美元**。 电费估计每年在1万至7.4万美元之间，具体取决于位置，每百万tokens增加约0.02至0.07美元。 这使总成本约为**每百万tokens 0.30美元**，远低于OpenAI的GPT-5.2 Pro（21/168美元/百万）。
讨论强调了优化的重要性——包括量化（可能低至4位）和高效引擎如vLLM——在降低成本方面的作用。 虽然当前定价可能受到风险投资的补贴，但这些基准测试为了解可持续的LLM推理定价的潜力提供了见解，随着硬件和软件的不断改进。 讨论还涉及瓶颈从推理速度转移到工具调用延迟，以及对更好AMD GPU支持的需求。
## Sei：DevOps工程师 概要 Sei 是一家快速发展的、具有代理能力的金融服务AI平台，服务于全球大型企业，并获得Y Combinator和PayPal等知名投资者的支持。由经验丰富的金融科技领导者创立，Sei 正在寻找一位**资深DevOps工程师**来扩展其平台以适应持续扩张。 该职位专注于在AWS（Kubernetes、Terraform）上构建强大且成本优化的基础设施，同时管理监控、安全和核心AI组件（WebRTC、LLM等）。 Sei 优先考虑高度协作、行动导向的文化，具有持续反馈和强大的产品所有权。他们重视**主动性、同理心和“实干”精神**——期望所有团队成员，包括领导层，都能跨职能贡献。 理想的候选人应具备构建和扩展系统（从0到1或从1到10）的经验，对AWS/Kubernetes/Terraform有深入的了解，并具有AI/ML技术的实践经验。实际能力和与Sei核心价值观的契合度比正式资格更重要。该职位要求每周至少四天在古尔冈或钦奈办公室办公。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Sei (YC W22) 正在招聘 DevOps 工程师 (印度/现场办公/钦奈/古尔冈) (ycombinator.com)
1天前 | 隐藏
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
作者设想过一份镀金的RCX积木作为纪念礼物，但真正的镀金成本过高。初步估算12克拉镀金的费用高达每块200美元，并且可能遮盖乐高品牌标识。 随后，他们探索了金属拉丝工艺，但由于RCX/NXT表面相对较大，可能存在涂层不均匀的问题。他们通过内部关系，经由Bo Kristiansen促成该工艺，并承诺作为回报送蛋糕。 为了让礼物更具个性化，作者与Ebbe的工作室——一个原型“特种部队”部门——合作，将RCX/NXT单元嵌入雕刻的亚克力板中，使其能够独立站立。这些单元是从研发测试室的“寻宝”行动中获得的，使用了退回的零件，并且显示屏上贴有定制贴纸以保持外观。
## 黑客新闻讨论：乐高Mindstorms的遗产
一篇关于“黄金乐高RCX和NXT”的文章在黑客新闻上引发了一场怀旧讨论，强调了这些机器人套件对一代程序员和工程师的深刻影响。
许多评论者分享了通过RIS 2.0套装发现编程的个人经历，并经常将其视为他们职业道路的催化剂。用户们 fondly 回忆了充满活力的自制社区，学习像Java（通过LeJOS）和C（通过brickOS）这样的语言来克服基于块的编程的限制。
讨论还涉及RCX起源于麻省理工学院媒体实验室的“可编程积木”项目，以及一些人通过学校试点项目获得的早期接触。几位用户表达了对一款能够重现相同水平的开放可编程性和易用性的现代乐高产品的渴望。一位用户甚至正在为他们的孩子构建定制电子积木，旨在将原理图设计与物理乐高搭建结合起来。总的来说，该帖子展示了乐高Mindstorms作为一种强大的教育工具和灵感来源的持久遗产。
数据是明智决策的基础，但理解其不同类型至关重要。数据大致分为**定性**（描述性属性，如颜色或满意度）和**定量**（数值，可测量数量）两大类。定量数据进一步分为**离散**（可计数，整数）和**连续**（可测量，带小数）两种。定性数据包括**名义**（无序标签，如水果类型）和**顺序**（排序类别，如调查回复）。
除此之外，数据还按结构分类：**结构化**数据高度组织在数据库中，**非结构化**数据无组织（电子邮件、视频），**半结构化**数据具有一定组织性，但格式不严格（如JSON文件）。
现代数据科学经常处理“大数据”——其特征是高**容量**、**多样性**和**速度**——包括事务、机器、社交和文本数据。最终，原始数据在经过处理、分析和情境化后才能成为有意义的信息，从而实现洞察、预测和更好的决策。认识这些区别对于任何从事数据驱动洞察工作的人都至关重要。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
理解数据中的数据类型 (syracuse.edu)
11 分，来自 mahirsaid 1 天前 | 隐藏 | 过去 | 收藏 | 讨论
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## Terra：现代软件包生态系统 Terra是一个新的软件包生态系统，建立在强大的安达曼工具链（基于Rust）之上，旨在实现可扩展性和易用性。其关键特性包括**自动软件包更新**——甚至为早期采用者提供每日构建版本——以及通过严格审查对**软件包质量**的强烈关注。 Terra优先考虑**透明度**，所有软件包源代码采用单一代码仓库，并在GitHub Actions上公开可见构建过程，从而简化调试。它被设计为**开发者友好**，直接与项目合作以确保无缝集成。 最后，**安全性**至关重要；软件包在Fyra Labs维护的安全环境中构建，通过现代工具和严格审查最大限度地减少潜在问题。Terra旨在提供可靠、最新且安全的软件包体验。
## Terra：Fedora滚动更新仓库 - 摘要
Terra是一个由社区驱动的Fedora滚动更新仓库，类似于RPMFusion，提供官方Fedora仓库中未包含的软件。它适用于稳定的Fedora版本和开发分支Rawhide（两者并非直接可比）。
用户讨论Terra可能是解决Fedora升级期间RPMFusion软件包延迟问题的一种方案，特别是关于依赖问题。虽然有些人建议发布后等待几周以获得稳定性，但也有人报告即使安装了大量RPMFusion软件包，升级过程也很顺利。通常不建议在升级前使用COPR仓库，因为可能存在不稳定性。
Terra旨在提供更流畅的体验，早期用户尚未报告其软件包存在重大升级问题。该项目还提供Ultramarine Linux分支，并拥有自己的仓库，供那些希望减少对外部组织依赖的用户使用。
在为 Greptile（一款 AI 代码审查工具）构建功能时，作者遇到了 GitHub API 的一个问题：PR 评论的可点击链接需要 GraphQL 节点 ID 或旧的数据库 ID，而 Greptile 使用的是前者。完全的数据库迁移似乎令人望而却步，直到出现了一种模式。 节点 ID 虽然全局唯一，但其结构中包含数据库 ID。通过解码节点 ID 的 base64 部分并应用位掩码，作者可以可靠地提取所需的数据库 ID，*而无需* 迁移。 进一步调查发现 GitHub 维护着*两种* ID 系统——一种是较新的 MessagePack 编码格式，另一种是为较旧仓库保留的旧格式。较新的格式编码了仓库和对象 ID，对象的数据库 ID 是 MessagePack 数组中的最后一个元素。旧格式则简单地组合了对象类型、名称和数据库 ID。 这个复杂系统源于 GitHub 的演进，即使在较旧的仓库中，较新的对象有时也会收到新的 ID。虽然 GitHub 建议将节点 ID 视为不透明字符串，但作者成功地逆向工程了其结构，为最初的问题提供了一个巧妙的解决方案，并深入了解了 GitHub 的内部运作。
## GitHub Node ID：深入解析与警示故事
最近的 Hacker News 讨论深入探讨了 GitHub 全局节点 ID 的内部结构。这些 ID 虽然本意是作为不透明字符串，但却暴露出潜在的模式——一个类型前缀，后跟一个包含版本和数据库 ID 的 base64 编码有效载荷。虽然技术上可以解码这些 ID，但评论员强烈建议*不要*依赖这种实现。
核心要点是，GitHub 随时可能更改 ID 格式，从而破坏依赖于它的代码。GraphQL API 提供了对 `databaseId` 和 URL 的直接访问，这是官方支持的互操作方法。
讨论强调了“海陆姆定律”——任何可观察的行为*都会*被依赖，即使没有文档记录。这强调了健壮的 API 设计的重要性，以及逆向工程内部细节的风险。一些人认为应该使用加密来防止依赖内部结构，而另一些人则认为简单的混淆就足够了，还有一些人强调通过文档化的 API 提供必要的数据的重要性。最终，共识是避免依赖未文档化的 ID 结构，并使用 GitHub 官方支持的方法。
本文认为，公司应被法律要求在产品达到使用寿命终结 (EOL) 时开源其软件。作者以一款硬件功能完好但因应用停用而无法使用的“智能”体重秤为例进行说明。 目前，当公司停止软件支持时，消费者只能面对电子垃圾，作者认为这种做法令人沮丧且不可持续。虽然承认完全发布代码库不切实际，但该建议侧重于要求公司在GitHub等平台上发布基本的硬件规格和连接协议。 这将使社区甚至普通用户——借助如vibe-coding之类的工具——能够创建替代软件并延长产品寿命。作者认为这不仅是一个环境问题，也是消费者权益和负责任的产品设计问题，将Bose等少数积极案例与Spotify Car Thing等常见失败案例进行对比。
## 开源报废硬件：黑客新闻讨论总结
核心讨论围绕着公司在产品达到寿命终结（EOL）时，应该开源软件和硬件规格的想法。许多评论者同意这一原则，认为这可以防止电子垃圾，并赋予用户维护他们购买的设备的能力。然而，实际挑战和不同的观点也很突出。
一个关键论点是**从一开始就开源**比承诺稍后开源更好。多位用户提倡**消费者行动**：支持具有开源基础的产品，并在购买前要求开放性。另一些人认为**监管**是必要的，但承认对其执行的难度，尤其是在强大的公司面前。
提出的担忧包括由于授权的第三方知识产权而开源的复杂性、潜在的安全漏洞以及公司放弃控制权的缺乏动力。一些人建议专注于**开放API**，而不是完全发布源代码。
一个反复出现的主题是**消费者教育**的需求，关于数据所有权以及依赖云端设备的局限性。最终，讨论强调了对技术更大的控制权以及对计划报废的反击，但也承认实现广泛变革的重大障碍。
线条类型：直线 正交（横→竖） 正交（竖→横） 正交（横→竖→横） 正交（竖→横→竖） 样式：单线（浅） 双线 粗线 ASCII (+|-) 起点：无 箭头 三角形 菱形 圆形 | (一个) 终点：无 箭头 三角形 菱形 圆形 | (一个) 标签：混合
## AsciiSketch：一款新型浏览器ASCII艺术编辑器
最近在Hacker News上分享了一款名为AsciiSketch（littlebird.com.au）的新型、免费的浏览器ASCII艺术和图表编辑器。该工具使用JavaScript和手动调整创建，是开源的，并鼓励用户“尽情发挥”，查看源代码并进行拆解。
AsciiSketch受Monodraw启发，允许用户使用ASCII字符创建图表。用户已经建议添加诸如随对象移动的连接线、分组功能以及标准的复制/粘贴操作等功能。
一位用户指出圆圈内的反斜杠存在轻微的视觉问题，而另一位用户则认为它是一个方便的基于Web的Monodraw替代品。一个类似的项目，一个“基于ASCII的Figma类编辑器”也被链接，AsciiSketch的创建者赞扬了它的质量。
## 日本的机器人建筑革命——以及它为何衰落
尽管全球都在努力应对低生产率问题，但建筑业并未像汽车制造业等行业那样取得同样的进步。日本在20世纪70年代后期大力投资建筑机器人，旨在实现整个摩天大楼的*现场*自动化建造——本质上是在创造建筑工厂。
受到高劳动力成本和熟练劳动力短缺的驱动，清水建设和大林组等公司开发了自动化材料输送、机器人工作站（用于焊接、喷漆等）以及逐层建造的攀爬机制等系统。这些“空中工厂”需要为机器人组装而设计的建筑，优先考虑标准化组件和简化的连接。
虽然这些系统——如SMART、赤月和ABCS——显示出劳动力减少（20-70%）和大型项目建设速度加快，但它们面临着重大障碍。高昂的前期成本、漫长的设置时间和对广泛前期规划的需求限制了它们的实用性。投资回报期很长，阻碍了进一步的投资。
最终，尽管在90年代至少有60座建筑积极使用这些自动化工厂，但到21世纪初，它们大多已消失。清水建设继续进行机器人研究，但完全自动化的建筑工地的最初愿景仍未实现，受到高成本、缓慢的迭代周期和有限的可扩展性的阻碍。
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 工作 | 提交 登录
日本的摩天大楼工厂 (2021) (construction-physics.com)
65 分，由 Pikamander2 1 天前 | 隐藏 | 过去的 | 收藏 | 1 条评论
Analemma_ 1 天前 [–]
我想知道这是否是过去出现像 X-Seed 这样遥远概念的原因之一：[0]。那个想法一直很奇幻，但也许如果认为建筑自动化即将解决，并且有一天实际建造它只是意味着收集材料、按下开始并让它完成，那么它可能就没那么不切实际了。[0]: https://en.wikipedia.org/wiki/X-Seed_4000 回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：