## GLP-1药物：停药后益处消退
GLP-1药物（如Wegovy和Ozempic）最初用于治疗糖尿病，但因其在减肥方面的效果以及改善心脏健康、肝功能甚至痴呆症的潜力而广受欢迎。然而，新的研究揭示了*停用*这些药物的显著风险。
一项对超过33.3万退伍军人进行的研究发现，即使暂停GLP-1治疗六个月，也会大大增加心脏病发作和中风的风险。 随着停药时间的延长，这种风险会增加，两年后增加22%。重要的是，重新开始用药后益处并不能完全恢复，这表明“代谢反弹”会留下持久的损害。
研究人员强调，逆转不仅仅是体重反弹的问题；炎症、血压和胆固醇也会反弹。 考虑到大约一半的用户在开始使用GLP-1药物后不久就会停止使用，这项研究强调需要改变这些药物的处方方式——将持续、可能终身的依从性视为治疗慢性疾病的关键部分。
每日HackerNews RSS
## 阴影舰队追踪器精简版：摘要
阴影舰队追踪器精简版是一款免费、开源工具，用于监测波罗的海地区的船只，特别是与俄罗斯“阴影舰队”以及潜在制裁规避相关的船只。它在本地运行——无需云服务或订阅，只需一个免费的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 需要超越暴露内部“旋钮”，并实施更强大、自动化的内存管理，特别是考虑到它的成熟度。
Hacker News新帖 | 过去 | 评论 | 提问 | 展示 | 工作 | 提交登录
模因建筑 (misfitsarchitecture.com)
37 分，speckx 发表于 1 天前 | 隐藏 | 过去 | 收藏 | 3 条评论 帮助
jonah 发表于 1 天前 | 下一个 [–]
我首先想到的建筑是加州威尼斯的比目鱼建筑。最初由弗兰克·盖里为 Chiat/Day 设计，它不属于谷歌园区。
https://en.wikipedia.org/wiki/Binoculars_Building回复
m_p 发表于 8 小时前 | 上一个 | 下一个 [–]
https://ronnysalerno.com/queencitydiscovery/2022/10/the-worl...回复
zoklet-enjoyer 发表于 1 天前 | 上一个 [–]
我最喜欢的建筑是鲍勃的 Java Jive
https://www.bobsjavajive.com/about回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 定制软件“革命”——一种怀疑的观点 尽管围绕人工智能使每个人都能构建定制软件的炒作不断，但作者认为这场“革命”在很大程度上被夸大了。虽然定制软件*存在*——而且常常质量不高——但这并不是大多数人真正*想要*的。 这种兴奋主要来自那些*构建*软件的人，而不是那些需要解决方案的人。大多数用户只是容忍计算机，并渴望简化的结果，而不是系统维护或设计的负担。一家繁忙的会计师事务所希望消除纸质工作，而不是一个新的项目；一家物流公司希望优化路线，而不是一个定制系统来管理。 人工智能无疑会被*使用*，但期望广泛采用定制软件构建是不现实的。它吸引的是现有的“业余爱好者”，但给那些专注于核心业务的人增加了另一层责任。就像获得工具并不意味着每个人都是承包商一样，软件构建工具也不会让每个人都变成开发人员——大多数人只是希望问题得到解决，而不是过程。
## NumKong：苹果芯片混合精度内核
一个名为NumKong的新项目提供了2000个混合精度内核，旨在加速苹果芯片上的计算。开发者ashvardanian指出，README最初是由人工编写，但经过AI模型的辅助改进——接受小幅度的修改。
Hacker News用户的初步反馈表明，他们希望对项目的目的有更简洁、更少“炒作”的解释。讨论还引发了关于潜在应用的问题，有建议称NumKong可能对利用苹果的Silicon Metal Engine (SME)进行音频处理有益。目前，开发者不清楚是否存在使用SME的音频处理实现。
此演示针对桌面屏幕（1000像素以上）优化。
申请抢先体验
为新一代打造的现代工作邮件 | 定义