您的请求已被阻止，原因是网络策略。请登录或在此处创建帐户以恢复浏览。如果您正在运行脚本或应用程序，请在此处注册或使用您的开发者凭据登录。此外，请确保您的User-Agent不为空，并且是独特且具有描述性的，然后重试。如果您正在提供替代的User-Agent字符串，请尝试改回默认设置，因为这有时会导致阻止。您可以在此处阅读Reddit的服务条款。如果您认为我们错误地阻止了您，或者想讨论更轻松地获取所需数据的方式，请在此处提交工单。联系我们时，请提供您的Reddit帐户以及以下代码：019c7464-ce30-74cd-bfc8-5d1f5b32034f
每日HackerNews RSS
## 乌克兰韧性：通过LoRa使用Home Assistant
一位乌克兰居民正在使用LoRa无线电控制他们的Home Assistant设置，即使在战争造成的停电期间也能确保功能正常。这一创新解决方案突显了在充满挑战的环境中足智多谋的解决问题的能力。
Hacker News上的讨论显示，Meshtastic（一种低功耗、长距离网状网络）在乌克兰被广泛使用，甚至用于转发空袭预警。用户分享了使用各种LoRa设备（如RAK4631和T-Echo）的经验，并指出Meshtastic令人印象深刻的范围（在较高海拔地区已实现331公里的链路）以及任何人都可以为网络覆盖做出贡献的能力。
一位用户成功地通过MQTT将Meshtastic与Home Assistant集成，优化了数据传输，因为LoRa的带宽有限。其他人正在探索进一步的连接选项，例如卫星收发器。该帖子赞扬了这种“黑客精神”以及在冲突中维持基本系统的实用、赛博朋克式的做法。
``` npm install @openfuseio/sdk import { OpenfuseCloud } from '@openfuseio/sdk'; const openfuse = new OpenfuseCloud(...); const customer = await openfuse.breaker('stripe').protect( () => stripe.customers.retrieve(customerId) // 正常调用 Stripe ); // 一个断路器。所有服务器同步。 这就是你所需的所有代码。 阈值、恢复和同步由仪表盘管理。 ```
## Openfuse：微服务的集中式熔断器
分布式系统工程师Rodrigo发布了Openfuse (openfuse.io)，旨在解决传统熔断器的一个常见问题：独立的、按实例决策。他注意到，在微服务集群中，一些实例会继续冲击故障依赖，而另一些实例已经触发了熔断，导致级联故障和难以调试的问题。
Openfuse提供了一个集中控制平面，汇总所有服务实例的故障指标，并基于整个*集群*的整体健康状况做出熔断决策。这确保了行为的一致性和对中断的立即、协调响应。它与Opossum、Resilience4j和Polly等现有库集成，但增加了全局感知和控制层。
主要功能包括一个简单的SDK、一个用于实时熔断器状态可视化的仪表盘，以及在不重新部署的情况下手动打开/关闭熔断器的能力。定价从免费版本开始，扩展到每月99美元，适用于大多数团队，每月399美元适用于更高吞吐量。SDK是开源的，并且计划提供自托管选项。讨论中强调了延迟和对集群内部调用的适用性问题，但Rodrigo强调Openfuse的目标是共享外部依赖，并提供Fail-Open设计，以防止Openfuse中断期间的阻塞。
Electrobun 是一个使用 TypeScript 构建的新桌面应用框架，旨在解决作者在使用 Electron 和 Tauri 等现有解决方案时遇到的问题。在多年构建 Web 规模应用之后，创建者希望回归桌面应用开发的“黄金时代”，发现当前工具对于持续交付和更新来说过于繁琐。 Electrobun 专注于速度、小型打包尺寸和跨平台兼容性（macOS、Windows、Ubuntu）。它自动化安装包创建、自动更新（使用 Zig 优化的差异补丁系统），并利用 Bun 的 FFI 以提高效率。 该框架提供全面的功能——窗口控制、菜单、webview 以及强大的工具——旨在提供卓越的“进程外 iframe”（OOPIF）体验。作者已经使用 Electrobun 重写了他们的项目 co(lab)，现在专注于发展社区并支持开发者构建雄心勃勃的桌面应用程序。
## Electrobun v1：更快的桌面应用框架
Electrobun 是一个使用 TypeScript 和 Bun 构建快速、小型且跨平台桌面应用程序的新框架。一位开发者报告称，与使用 Tauri 相比，使用 Electrobun 构建相同的 macOS 应用所需时间减少了 70%，并认为 Bun 的开发者体验和内置打包器是关键优势。
Electrobun 简化了窗口管理、RPC 通信、构建、代码签名和公证等任务。它提供平台原生通知和高效的更新机制（使用 bsdiff，更新包小至几 KB）。
用户强调了它在游戏开发方面的潜力，并赞赏其完整的 TypeScript 堆栈，避免了与 Tauri 等替代方案通常相关的 Rust 复杂性。Electrobun 默认使用系统 webview，但也支持捆绑 Chromium (CEF) 以实现跨平台一致性。创建者确认正在进行开发，并欢迎通过 GitHub issue 提交反馈，并展示了一个使用 Electrobun 构建的名为 Colab 的演示应用程序。
## 欧洲的人工智能挑战：生产力提升与不均衡分配 欧洲在全球人工智能竞赛中面临十字路口。虽然在人工智能研究和工业能力方面具有优势，但在技术发展上落后于美国和中国。最近的研究既带来了乐观——潜在的生产力提升——也提出了关于技能差距和不平等加剧的警告。 对超过12,000家欧洲企业的新研究表明，采用人工智能后，平均劳动生产力提高了4%，*没有*立即出现工作岗位流失——表明人工智能目前是*增强*而非取代工人。然而，这些收益并非平均分配。大型企业比小型企业受益更多，并且至关重要的是，对软件、数据基础设施和*特别是*员工培训的配套投资对于释放人工智能的全部潜力至关重要。 该研究强调了一个悖论：欧洲的人工智能采用率与美国总体水平相当，但在金融发达（例如瑞典、荷兰）和欠发达（例如罗马尼亚、保加利亚）欧盟国家之间存在显著差异。政策制定者必须专注于促进金融市场以支持小型企业，激励配套投资，并优先发展“融合技能”培训，以确保包容性增长并防止人工智能加剧现有的经济差距。持续监测人工智能对劳动力市场的影响至关重要。
## 步骤 3.5 Flash：快速且易于访问的语言模型
步骤 3.5 Flash 是一种 1960 亿参数的语言模型，专为速度和高效推理而设计，每个 token 仅激活 110 亿参数。它通过 **稀疏混合专家 (MoE)** 架构和 **混合注意力机制** 实现这一点，该机制结合了滑动窗口注意力 (SWA) 和全注意力，并针对 **推测解码** 进行了优化——并行预测和验证多个 token。
主要创新包括增加 SWA 层中的查询头数量，以增强表示而无需增加成本，以及 **头部门控注意力** 以实现数值稳定性。这在 NVIDIA Hopper GPU 上可实现高达每秒 350 个 token 的解码吞吐量。
重要的是，步骤 3.5 Flash 专为 **本地部署** 而设计，可在 Apple M4 Max 和 NVIDIA DGX Spark 等硬件上运行。它提供 INT4/INT8 量化格式，即使在边缘设备上也能实现 256K 上下文窗口。
一种新颖的 **强化学习 (RL) 框架**，利用 **Metropolis Independence Sampling Filtered Policy Optimization (MIS-PO)**，确保了推理能力的稳定且可扩展的训练，解决了训练-推理不匹配和脱离策略漂移的问题。这使得在数学、编码和工具使用等领域实现持续自我改进成为可能。
## 3.5 Flash：一款有前景的开源大语言模型
3.5 Flash是由中国公司StepFun发布的一款新的开源基础模型，因其性能和效率而备受关注。用户报告称，它在性能上超越了其他可本地运行的大语言模型，如Minimax 2.5和GLM-4.7，尤其擅长代理式编码任务。
其主要特点包括强大的上下文处理能力（在128GB机器上可处理高达256k tokens）和快速的速度——在M1 Ultra Mac上可达到高达每秒36个tokens。虽然前景可期，但它也存在一些缺点，例如冗长的推理链和偶尔的无限循环（据报道，新的版本将修复此问题）。
这款模型的创建者同时也是ACEStep音乐生成模型的开发者，他们采用了一种混合专家（MoE）架构，每个token只激活其196B参数的一部分。讨论的重点在于它作为Claude和Codex等付费模型的经济高效替代品的潜力，以及与Qwen3和GPT-OSS等其他开放权重模型的比较。它正在pi.dev等社区中因其代理能力而受到欢迎。
Anthropic 正式禁止使用订阅授权用于第三方用途。
Anthropic officially bans using subscription auth for third party use
2 天前
## Claude Code：法律与合规摘要
本文档概述了使用Claude Code的法律和合规方面。您的使用受**商业条款**（团队、企业、Claude API）或**消费者服务条款**（免费、Pro、Max）管辖，具体取决于您的计划。现有的商业协议适用于Claude Code的使用，除非另有约定。
**合规性：** 对于已激活业务伙伴协议（BAA）和零数据保留（ZDR）的客户，BAA扩展到Claude Code的使用。所有使用还受Anthropic **使用政策**约束。
**身份验证至关重要：** 免费、Pro和Max计划仅对Claude Code和Claude.ai使用OAuth – 在其他地方使用这些令牌是被禁止的。使用Agent SDK或通过API构建的开发者*必须*使用API密钥。第三方开发者不能通过这些计划提供Claude.ai登录。
**安全性：** Anthropic优先考虑信任和安全，Trust Center & Transparency Hub中提供相关资源。应通过HackerOne报告安全漏洞。
## Respectlytics：注重隐私的移动分析
Respectlytics 是一款自托管的移动分析服务器，其核心设计原则是隐私保护——通过最小化数据收集来优先考虑*规避回报* (ROA)。它仅存储每个事件的 5 个必要字段：`event_name`、轮换的 `session_id`（仅在 RAM 中，每 2 小时刷新一次）、`timestamp`、`platform` 和近似 `country`（从 IP 推断得出，并立即丢弃）。**不保留任何个人数据、用户 ID、设备 ID 或精确的位置数据。**
该服务器易于使用 Docker 或 Python/PostgreSQL 环境部署。提供快速入门指南，以及全面的 API（包含事件摄取、摘要和漏斗分析端点）和 SDK。
主要功能包括基于会话的分析、严格的数据限制以及可选的 GeoIP 集成（使用 MaxMind）。数据保留时间可通过 `purge_old_events` 命令进行配置。
Respectlytics 采用 AGPL-3.0 许可，鼓励开放贡献。对于不兼容的使用场景，提供商业许可。还提供完全托管的云版本。**请咨询法律顾问，以确保符合相关的隐私法规。**
## Respectlytics：注重隐私的移动分析
Respectlytics 是一款新的开源移动分析解决方案，其核心原则是保护隐私。创建者 cesncn 对现有 SDK 的数据收集行为以及缺乏真正的隐私合规性感到沮丧。
与竞争对手不同，Respectlytics 采用“规避回报”方法——通过*不*收集不必要的信息来最小化数据收集。它每个事件仅存储五个字段：事件名称、会话 ID、时间戳、平台和国家/地区。IP 地址仅在确定位置时短暂使用，然后被丢弃。
该项目包含适用于 Swift、Flutter、React Native 和 Kotlin 的 SDK（MIT 许可），以及一个可自我托管的分析服务器（Django + PostgreSQL，AGPL-3.0）。 托管 SaaS 选项也可提供。开发者欢迎反馈，特别是关于他们主动拒绝额外数据字段的决定。
该项目已经引起了类似领域开发者的兴趣，例如 OpenAttribution 的创建者，并且正在寻找示例应用程序来展示其用法。
十五年来，英伟达一直有策略地限制消费级GPU的双精度（FP64）性能，使其与企业级GPU相比存在明显市场划分。虽然消费级显卡的FP32性能大幅提升（从2010年到2025年增长了77.63倍），但FP64仅提升了9.65倍，性能差距持续扩大——目前RTX 5090上为64:1。
这种差异并非技术限制，而是一种刻意的商业策略，因为FP64对于高性能计算至关重要，但对于游戏等典型的消费者任务来说并不必要。然而，人工智能的兴起正在打破这种模式。人工智能训练通常*更喜欢*较低的精度（FP16、BF16），这使得消费级GPU在计算工作负载方面出乎意料地强大。
现在，英伟达正在转变重点。随着FP64仿真技术（使用FP32甚至FP8张量核心）变得可行，并且人工智能推动了对低精度计算的需求，该公司最新的企业级GPU（如B300）正在*减少*专用的FP64硬件，转而采用更高效的人工智能核心。这代表着一种逆转——企业级硬件采用了以前与消费级显卡相关的限制——并预示着FP64将越来越多地通过仿真实现，潜在地模糊了消费级和企业级芯片之间的界限，低精度浮点数将成为新的分界因素。
Mojang 正在将《我的世界：Java 版》的渲染从 OpenGL 过渡到 Vulkan，作为“鲜活视觉效果”更新的一部分，承诺带来视觉增强和性能提升。这一重大改变旨在利用现代特性，并保持与包括 macOS（通过翻译层）和 Linux 在内的 PC 操作系统兼容。
此次切换将要求模组制作者更新他们的作品，放弃 OpenGL，Mojang 鼓励提前准备并利用现有的渲染 API 以简化过渡。虽然缺乏 Vulkan 支持的旧硬件可能会变得不兼容，但 Vulkan 具有广泛的 GPU 支持。
玩家不会立即被强制切换；Mojang 计划今夏在开发快照中发布 Vulkan 和 OpenGL 并存的版本，允许在两者之间切换。最终，一旦 Vulkan 稳定且性能良好，OpenGL 将被移除。此次更新代表了《我的世界：Java 版》未来发展的重要一步。
## HM 与双向类型系统：为你的语言提出的错误问题 关于 Hindley-Milner (HM) 和双向 (Bidir) 类型系统的争论，常常被框定为二选一的选择，但这是一种错误的二分法。核心问题不是 *选择哪个* 系统，而是 *你的语言是否需要泛型*。 泛型需要合一——推断和求解类型变量的过程（例如 Rust 中的 `Vec<T>`）。HM 本质上包含合一。然而，双向类型系统并不局限于缺乏合一；它 *支持* 合一，使其成为 HM 的超集。你可以实现一个带有或不带有合一的双向系统，提供灵活性。 如果没有泛型，一个更简单的依赖于类型注解的双向系统就足够了，尤其是在学习练习或领域特定语言 (DSL) 中，在这些情况下，最小化复杂性是关键。然而，对于通用语言，泛型越来越被认为是必不可少的，从而推动了对合一的需求。 最终，双向类型系统提供了一种更具适应性的方法。选择它并不会排除合一，并且允许你根据语言的特定需求定制系统——无论是一个功能齐全的泛型语言，还是一个精简的、注重注解的 DSL。
## Hacker News 讨论总结：类型推断方法
一个 Hacker News 帖子讨论了一篇比较 Hindley-Milner (HM) 和双向类型推断的博文。 讨论迅速扩展到初始主题之外，涉及类型系统和语言设计的复杂性。
关键点包括：
* **HM vs. 双向：** HM 依赖于合一解决全局类型约束，而双向类型推断遍历语法树，通过向上和向下流动信息来推断类型。 大多数实用语言最终使用双向方法来处理子类型等 HM 难以处理的特性。
* **合一 vs. 双向作为核心概念：** 有人认为核心区别在于 *如何* 解决类型（合一作为全局约束问题 vs. 双向流动），而不仅仅是 HM vs. 双向。
* **权衡：** 复杂的类型推断并不总是受益。 一些人提倡要求显式类型声明以提高清晰度和更好的错误消息，或者采用渐进式类型以获得灵活性。
* **实用性与历史：** 许多流行的语言由于从早期的设计选择演变并试图适应现有的代码库而具有“混乱”的类型系统。
* **个人经验：** 几位评论员分享了关于学习类型理论、早期编程探索的乐趣以及后来生活中保持个人项目专注的挑战的轶事。
最终，讨论强调选择类型系统涉及平衡力量、简单性、错误报告和实际考虑因素。 没有一种万能的解决方案。