Garmin 开发者 概述 兼容设备 API 文档 获取 SDK 提交应用 保持关注 Connect IQ 基础 Monkey C 函数 对象和内存 容器 Monkey 类型 异常和错误 注释 编码规范 编译器选项 核心主题 用户体验指南 个性化库 Connect IQ 常见问题解答 参考指南 应用审核指南 盈利 设备参考 菜单 Monkey C 开发者博客 Garmin 品牌指南 联系我们 开发者论坛 ©2026 Garmin LTD 或其子公司•使用条款•隐私 Garmin
每日HackerNews RSS
Monkey C – 一种为 Garmin 手表应用设计的简单易用的语言
Monkey C – Small familiar language for apps on Garmin watches
47 天前
一场在Hacker News上的讨论集中在Garmin的专有编程语言Monkey C上，该语言用于开发他们的手表应用程序。开发者质疑在Lua等成熟选项可用时，是否有必要使用自定义语言。
一位维护Garmin应用程序的开发者表示同意，指出Lua拥有现成的工具（如语言服务器），而Monkey C依赖于Garmin构建的解决方案，例如自定义VSCode插件和基于Java的类型检查器，这些解决方案的可靠性较低。
对话中还质疑了“Monkey C”这个名称，因为它与C编程语言并不相似。核心观点是，创建一种独特的语言会阻碍开发者生态系统的发展，相比之下，采用标准语言更有利。
## 强化学习环境对人工智能训练日益重要
强化学习 (RL) 环境正变得对训练先进人工智能模型至关重要，像 Anthropic 这样的实验室可能每年为此投入超过 10 亿美元。这些环境允许模型通过可验证的任务进行试错学习，培养“推理”能力——以 OpenAI 的 o1 及其后续版本为例。然而，仅仅增加计算能力是不够的；**高质量、多样化的环境是进步的关键瓶颈。**
该行业正在超越最初对数学和编码的关注，在**企业工作流程任务**方面取得显著增长，例如导航软件（Salesforce、Excel）和自动化报告。一个主要挑战是**奖励欺骗**——模型找到漏洞来钻系统空子——这需要对任务和环境进行持续迭代。
在保持质量的同时扩大生产规模是一个核心的运营障碍，需要有效的任务构建器管理和健全的质量评估。环境由明确的动作和上下文组成，而任务提供目标和评分器来评估性能。成本差异很大，每个任务从 200 美元到 2000 美元不等，独家访问则需要支付更高的费用。
该领域包括专业初创公司、传统数据提供商和内部团队，并且与产品公司建立合作关系呈增长趋势。未来将侧重于更长远的任务、多轮交互以及强大的评分器以防止利用漏洞。
这次Hacker News讨论的中心是一个最近发布的强化学习环境FAQ（来自epoch.ai）的标题。最初的发帖人dcre分享了链接，引发了关于标题语法问题的争论：“An FAQ”。
几位评论者指出在缩写词“FAQ”前使用“An”显得别扭，尽管“FAQ”源自“Frequently Asked Questions”，但通常被视为单数名词。一些人建议使用“FAQ on Reinforcement…”或“FAQs on Reinforcement…”等替代方案来解决语法问题。
这段对话幽默地剖析了发音（“An Eff-AQ”与“a fak”）以及对“FAQ”作为单数术语的理解演变。一位评论者因为标题中 perceived 的错误而贬低该帖子为“ai slop”。最终，这个帖子突显了技术社区内的一个小小的语法争论。
## 红网格链接：离线MGRS导航与团队协同
红网格链接是一款移动应用程序（目前iOS，Android即将推出），可在*无需*蜂窝网络的情况下提供离线MGRS导航和团队位置跟踪。它基于红网格MGRS引擎构建，使用GPS提供1米精度，并支持带有MGRS网格叠加的离线地图。
主要功能包括方位、距离、推算航位和坐标转换等战术工具，以及北约语音字母表读数。**现场链接**通过蓝牙/WiFi Direct实现零配置团队同步，支持2-8名用户，在地图上显示队友位置，并对超出范围的用户使用加密数据和“幽灵”标记。
提供省电的远征模式。用户可以下载地图包（USGS地形图、OpenTopoMap）并将任务数据导出为PDF。该应用程序可适应各种任务（搜救、荒野探险、狩猎、训练），并具有可定制的术语和主题。
定价从具有有限功能的免费版本到解锁完整功能的订阅/终身选项不等，包括无限地图下载和团队管理。红网格链接优先考虑隐私 – 无账户、分析或第三方数据收集。它是开源的，并欢迎社区贡献。
## 红格链接：点对点团队追踪
红格链接是一款新的免费iPhone应用程序，通过蓝牙在设备之间实现位置共享，专为信号有限或没有蜂窝网络的情况设计，例如野外探险。它解决了对简单、经济团队追踪的需求，无需依赖昂贵的无线电或依赖Android系统的ATAK等。
该应用程序在离线地形图上显示附近用户，并利用“幽灵标记”系统显示超出范围用户的最后已知位置和移动方向。它通过CRDT同步层来防止合并冲突，并采用端到端加密（AES-256-GCM，ECDH P-256），从而优先保证可靠性。
开发者正在寻求反馈，并计划未来的更新，包括Android兼容性、蓝牙长距离支持（编码PHY），以及潜在地与Meshtastic桥接，以使用LoRa硬件实现更广的范围。电池寿命通过不同的模式进行管理，在超远征模式下，耗电量可低至每小时2%。
[github.com/redgridtactical](github.com/redgridtactical)
幽灵 (Yōulíng)
Ghostling
47 天前
## Ghostling：一个极简终端演示
Ghostling 是一个单文件 C 演示程序，展示了 libghostty 的功能，libghostty 是从 Ghostty GUI 中提取的一个可嵌入终端模拟库。它利用 Raylib 进行窗口管理和渲染，展示了 libghostty 在传统 GUI 环境之外的灵活性。
虽然 Ghostling 不是一个功能齐全的终端，但它提供了令人惊讶的强大功能，包括调整大小并重排文本、24 位/256 色支持、文本样式（粗体、斜体）、Unicode 处理、键盘和鼠标输入（包括 Kitty 协议支持）以及滚动历史记录。这些功能由 libghostty-vt 提供支持，libghostty-vt 是一个零依赖库，用于处理 VT 序列解析和终端状态。
Ghostling 优先考虑核心模拟，省略了全功能终端中常见的选项卡、拆分和配置等功能——这些功能留给开发者实现。它被设计为一个易于理解的 libghostty C API 示例，其经过验证且优化的代码库受益于数百万 Ghostty GUI 用户。
Ghostling 使用 CMake 构建，需要 C 编译器和 Zig，它为通过其 C API 和潜在的社区驱动绑定将终端功能嵌入到各种应用程序和语言中提供了一个基础。
## Ghostling & Libghostty：将TUI带到桌面应用
Ghostling基于libghostty构建，允许开发者将文本用户界面（TUI）打包为原生桌面应用程序——类似于Electron打包Web应用程序的方式。这使得从现有的基于终端的工具创建跨平台桌面应用程序成为可能，甚至在Windows上也可以。
讨论亮点包括它在Blisswriter（一个剧本编写工具）和Trolley（打包TUI）等项目中的应用。开发者们正在探索其将CLI工具带到移动平台（Android/iOS）的潜力，并欣赏它与iTerm2等替代方案相比的渲染速度。
一个关键的技术细节是将二进制资源（字体等）嵌入到代码中，讨论涉及CMake基于的头文件生成、`xxd`和`objcopy`等方法。对话还涉及终端模拟器与窗口管理器中选项卡归属的争论，许多人提倡窗口管理器控制，但承认在某些工作流程中应用程序级别的选项卡具有便利性。
## 从腕上手机到永恒科技
这份经历始于对腕表的热爱，觉得它们比智能手机更胜一筹——智能手机就像一把“瑞士军刀”，容易分散注意力。最初尝试智能手表（“腕上手机”）很快让人失望，凸显了它们需要不断充电以及反而会*增加*手机使用时间的缺点。
幻灭之后，一份坚固耐用的苏联时代Vostok Komandirskie腕表点燃了对自动腕表的热情。这促使他收藏了一系列腕表，包括Seiko 5 GMT，以及令人惊讶地喜爱的古董Seiko Sports 50。它们的吸引力在于其持久性、机械复杂性和永恒的风格——与科技产品的计划报废形成鲜明对比。
在欣赏自动腕表的艺术性的同时，作者也发现了卡西欧G-Shock的实用性，最终购买了一款原子太阳能型号，因为它具有准确性和近乎坚不可摧的特性。现在的收藏代表了一种平衡：耐用、低维护的选择与迷人的、具有传承品质的机械腕表并存。这种新的爱好感觉像是一项成熟的追求，并且比无休止的滑动屏幕要健康得多。
## GLP-1药物：停药后益处消退
GLP-1药物（如Wegovy和Ozempic）最初用于治疗糖尿病，但因其在减肥方面的效果以及改善心脏健康、肝功能甚至痴呆症的潜力而广受欢迎。然而，新的研究揭示了*停用*这些药物的显著风险。
一项对超过33.3万退伍军人进行的研究发现，即使暂停GLP-1治疗六个月，也会大大增加心脏病发作和中风的风险。 随着停药时间的延长，这种风险会增加，两年后增加22%。重要的是，重新开始用药后益处并不能完全恢复，这表明“代谢反弹”会留下持久的损害。
研究人员强调，逆转不仅仅是体重反弹的问题；炎症、血压和胆固醇也会反弹。 考虑到大约一半的用户在开始使用GLP-1药物后不久就会停止使用，这项研究强调需要改变这些药物的处方方式——将持续、可能终身的依从性视为治疗慢性疾病的关键部分。
## 阴影舰队追踪器精简版：摘要
阴影舰队追踪器精简版是一款免费、开源工具，用于监测波罗的海地区的船只，特别是与俄罗斯“阴影舰队”以及潜在制裁规避相关的船只。它在本地运行——无需云服务或订阅，只需一个免费的AISStream API密钥——并利用实时AIS数据追踪来自乌克兰GUR监视清单中的1200多艘船只。
该追踪器在自动更新的地图上绘制船只位置，标记其与海底电缆的接近程度，并根据21天窗口内的港口停靠情况检测潜在的俄罗斯-西方转运模式。它还能识别在特定区域逗留的船只。数据被记录到SQLite中以供离线分析，地图使用历史数据快速重启。
一个FastAPI仪表盘提供日志检查、船只分析、GPX导出和交互式航线回放。该项目由Former Lab构建和维护，优先考虑隐私，并且可以在旧硬件上运行。鼓励通过Patreon提供支持，以获得提前访问更新的权限。源代码可在GitHub上找到：[https://github.com/FormerLab/shadow-fleet-tracker-light](https://github.com/FormerLab/shadow-fleet-tracker-light)。
## 波罗的海影子舰队追踪器总结
一个在Hacker News上分享的新开源项目，追踪在波罗的海可能参与规避制裁的船只。该工具由FormerLabFred开发，利用AISStream的实时AIS数据（需要免费API密钥）来监控乌克兰GUR战争与制裁目录中识别的1200多艘船只。
该追踪器在本地运行——除了API密钥外，无需云服务或订阅——并在自动更新的地图上显示船只位置，提醒用户靠近海底电缆以及潜在的俄罗斯-西方转运活动。尽管开发者承认AIS数据可能被伪造或禁用，但他认为它是一种有价值的情报工具，尤其是在与其他数据源（如卫星图像）结合使用时。
早期用户报告了设置问题（特别是API密钥），但开发者正在提供支持，并致力于简化上手流程，考虑到OSINT爱好者的不同技术水平。他们的Patreon页面上有截图和更多信息。
## openui-lang 解析器：从 WASM 回到 TypeScript 团队最初使用 Rust 构建了 openui-lang 解析器，并将其编译为 WASM 以提高速度，期望能从 Rust 的性能和 WASM 的接近原生浏览器执行中获益。然而，基准测试表明 Rust 本身的解析并非瓶颈。显著的开销源于 JavaScript 和 WASM 堆之间重复的数据复制——字符串输入、结果的 JSON 序列化/反序列化。 尝试使用 `serde-wasm-bindgen` 绕过 JSON（直接对象传递）*增加了*延迟，因为将 Rust 数据转换为 JavaScript 对象需要大量的细粒度转换。最终，将整个流程移植到 TypeScript 消除了这些边界成本，从而实现了**2.2-4.6 倍的单次调用性能提升**。 进一步的优化集中在流式架构上。最初简单的解析会随着每个数据块重新解析整个字符串（O(N²))。实施语句级增量缓存——重用已解析的语句——将其降低到 O(N)，从而使总流式成本**降低 2.6-3.3 倍**。 这次经验表明，WASM 最适合计算密集型任务，且 JavaScript 互操作最少，或者移植现有的原生库。对于将结构化文本解析为 JavaScript 对象，边界开销通常超过了 Rust 或 WASM 带来的任何性能提升。算法改进，例如增量缓存，被证明影响更大。
## 黑客新闻讨论总结：Rust WASM 解析器重写
一篇最近的博客文章详细介绍了将 Rust WASM 解析器重写为 TypeScript，结果性能出人意料地更快。黑客新闻的讨论强调了除了语言选择之外的几个关键点。
最初，团队发现仅仅通过在移植过程中修复一个错误，就显著提高了速度——一个存在于原始 C++ 代码中的缓存键比较问题，难以用 Python 表达（因此在 TypeScript 中避免了）。除此之外，消除跨越 WASM/JavaScript 边界的序列化开销也提供了很大的提升。
许多评论者分享了类似的经验，即使在同一语言中重写代码，也暴露出性能问题并允许进行算法改进。其他人指出避免不必要的数据序列化以及利用共享内存缓冲区等技术的重要性。
讨论还涉及 WASM 互操作的开销、AI 生成内容可能影响博客文章质量的问题，以及关于 Rust 相对于其他语言在 Web 开发中优势的持续争论。最终，共识倾向于性能提升源于算法修复和减少开销，而不仅仅是语言切换本身。
## Fortransky：一个Fortran Bluesky/AT 协议客户端 Fortransky 是一个基于终端的 Bluesky 社交网络客户端，独特性在于它使用 Fortran 编写。它利用 Rust 静态库来解码 AT 协议的 relay-raw 流，通过 `iso_c_binding` 和 C libcurl 接口将 Fortran 与 Rust 连接起来。 该客户端提供诸如时间线获取、作者订阅源、搜索、个人资料查看、撰写帖子以及基本的帖子互动（点赞、转发、引用帖子）等功能。它支持两种流模式：Jetstream（WebSocket，JSON）和 relay-raw（二进制 CBOR，由 Rust 解码）。会话数据存储在 `~/.fortransky/session.json` 中，需要应用程序密码进行身份验证。 安装过程包括使用 `cargo` 构建 Rust 桥接，然后使用 CMake 将其与 Fortran 代码链接。relay-raw 流路径需要 Python 依赖项 (`cbor2`，`websockets`)。目前，它显示原始 DID，尚未将其解析为句柄。最近的更新 (v1.1) 集成了原生 Rust 解码器，以提高性能和稳定性。
## Fortransky：一个基于终端的Bluesky客户端，用Fortran编写
一位开发者（FormerLabFred）分享了他的项目“Fortransky”，这是一个仅限终端的Bluesky/AT协议客户端，使用Fortran编写——以及一个配套项目“Cobolsky”。该项目在Hacker News上引发了热烈讨论，许多人对这种非常规的语言选择表示赞赏。
开发者解释说，其动机是希望让老语言保持活力，强调Fortran的速度和历史重要性。其他人也纷纷表示，他们回忆起学习Fortran以及它的持久可移植性。
除了新颖性之外，评论员指出AT协议对开发者来说易于使用，一位用户分享了其他几个基于该协议的独特应用，包括直播和博客平台。开发者还提到即将举行的温哥华AT协议会议。该项目引起了怀旧开发者和对探索不太常见的编程语言的人们的共鸣。
亨利埃塔的Postgres生产集群因OOM killer事件崩溃，消耗了2TB内存，尽管`work_mem`设置仅为2MB。调查显示，问题并非简单的`work_mem`错误配置，而是Postgres内存管理中更深层次的行为。 Postgres的内存上下文系统优先一次性释放整个上下文以提高效率，而不是单个分配。一个复杂的查询，涉及用作连接表中PL/pgSQL函数，创建了一个巨大的`ExecutorState`上下文。该上下文积累了数十万个`work_mem`块——每个块最多2MB——在整个操作完成之前不会释放它们，但操作从未完成。 虽然无法为每个后端设置硬性内存上限，但解决方案包括确保使用`ANALYZE`和`CREATE STATISTICS`获得准确的统计信息，重写有问题查询，实施查询超时(`statement_timeout`)，以及利用`pg_log_backend_memory_contexts`函数（Postgres 14+）进行详细的内存使用分析。最终，该事件强调了即使是强大的硬件也无法克服设计不良的查询。
## Postgres 的 `work_mem` – 设计缺陷？
一篇 Hacker News 的讨论强调了 PostgreSQL 中 `work_mem` 设置可能存在的设计问题。用户认为它是一个不精确的工具，将内存管理的负担转移到 DBA 上，而不是由数据库智能地处理资源分配。
目前，`work_mem` 决定了一个查询可以使用多少内存，超过这个限制就会溢出到磁盘。然而，系统不会监控*全局*资源使用情况并相应地划分查询。这可能导致查询尝试分配过多的内存（例如，在 2MiB 设置下分配 2TiB！），尽管默认值很小。
核心问题是 Postgres 缺乏整体内存管理策略。虽然文档对此限制是透明的，但提供的实用指导很少。一些人建议实施批处理和监督器来调度查询阶段，可能使用协程以获得更高效的控制流。
虽然存在诸如 `ulimit` 之类的外部限制，但它们不是可靠的解决方案。最终，讨论指出 Postgres 需要超越暴露内部“旋钮”，并实施更强大、自动化的内存管理，特别是考虑到它的成熟度。