(Empty input provided. There is nothing to translate.)
每日HackerNews RSS
一位名为Codegres的用户在Hacker News上分享了一个Trello克隆项目的链接，并提供了源代码。代码通过codebuy.org和lemonsqueezy.com出售。然而，评论者很快注意到链接存在问题——codebuy.org域名似乎存在DNS问题，导致链接无法访问。
多位用户表达了怀疑，指出源代码链接已损坏，并质疑提交者的历史记录。一位评论员认为该项目视觉效果不错，但缺乏实际功能，形容其为“氛围代码”，许多按钮无法工作。总的来说，该帖子引发了更多关于链接有效性和项目完整性的讨论，而对Trello克隆本身的兴趣并不大。
## Wozz Kubernetes 审计：查找并减少云端浪费
Wozz 是一个脚本，用于识别 Kubernetes 集群中过度配置的资源，帮助您降低云成本。它分析 Pod 配置，找出请求资源（CPU、内存）和实际使用情况之间的差异，并估算潜在的节省，通常集群的节省率在 30-60%。
该脚本通过 `curl -sL wozz.io/audit.sh | bash` 在本地运行，提供按类别（内存、CPU、负载均衡器、卷）划分的浪费情况细分，并突出显示浪费最多的 Pod。它使用 `kubectl top` 获取准确的使用数据（需要 metrics-server），如果不可用，则回退到请求/限制比较。
**主要特点：**
* **无需注册/代理：** 完全在本地运行。
* **只读：** 不修改集群。
* **可选仪表盘：** 推送结果以进行历史趋势和告警。
* **开源：** 可检查代码。
* **成本估算：** 基于平均云定价。
Wozz 识别出常见的过度请求内存/CPU 和孤立资源等问题，提供每月每个 Pod 节省 $5-$50 的潜力。它需要 `kubectl` 访问权限，并可选地使用 `jq` 进行详细分析。
迪克·范·戴克年满100岁，是好莱坞中一个非凡的异例——一位活着的传奇人物，似乎战胜了时间。从早年为部队演出，到在《迪克·范·戴克秀》、《玛丽·波ppins》和《奇蒂奇蒂뱅뱅》等标志性角色中表演，范·戴克几代人都被他的魅力所吸引。他在《玛丽·波ppins》中那句著名的“蹩脚”的伦敦腔口音，现在被认为是这部电影持久吸引力的一部分。 范·戴克的职业生涯跨越了几十年，他活过了同事甚至电影公司，并且仍然出人意料地活跃，最近出现在《蒙面歌手》节目中，并支持伯尼·桑德斯的总统竞选活动。他融合了滑稽喜剧和真诚的温暖，经常扮演“全能好男孩”的角色，尽管他过去曾与酗酒作斗争。 范·戴克不仅仅是一位艺人，他还是一个活生生的历史，连接着表演艺术的不同时代。他将长寿归功于良好的基因、友谊和积极的心态，称自己的人生是一场“美妙的放纵”。他仍然是一位备受喜爱的人物，证明了一点魔法和大量的能量确实可以使世界变得更快乐。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
迪克·范·戴克迎来百岁生日 (theguardian.com)
118 分，thunderbong 发表于 1 天前 | 隐藏 | 过去 | 收藏 | 2 条评论
js2 发表于 1 天前 [–]
相关讨论 (196 分，ggm 发表于 11 小时前 | 50 条评论): https://news.ycombinator.com/item?id=46252993 回复
dang 发表于 1 天前 | 父评论 [–]
评论已移至此处。谢谢！
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## LLM 的 SSE：为何不足 尽管服务器发送事件 (SSE) 简单且兼容现有网络基础设施，但它并不适合传递 LLM 的 token。核心问题在于可靠性：LLM 推理成本高昂，而 SSE 容易受到连接中断的影响，导致需要重新生成响应，从而产生高昂的成本。连接中断（例如，由于用户进入隧道或切换网络）意味着需要重新启动整个过程。 虽然可以通过跟踪 token 并允许重新连接来使 SSE 具有恢复能力，但这需要大量的服务器端状态管理（本质上是将每个 token 写入数据库）。WebSockets 也无法解决这个核心问题。 发布/订阅模型提供了一个更好的解决方案，允许客户端重新订阅并在断开连接后接收剩余的 token。但是，这会增加发布/订阅提供商的成本，可能超过 LLM 推理本身的成本。最终，作者认为，考虑到推理成本与传输成本不成比例，构建强大的传输层的成本可能不如接受 SSE 较差的用户体验更令人满意。
## SSE 与 LLM Token 流：关于可恢复性的讨论
一篇最近的文章认为，由于难以恢复中断的连接，服务器发送事件 (SSE) 不太适合流式传输 LLM token。然而，许多评论者不同意，认为问题不在于 SSE 本身，而在于其*通常*的实现方式。
核心问题是在生成过程中断开连接导致流丢失。作者建议使用 Pub/Sub 作为解决方案，但许多人指出 SSE 可以通过序列号和缓存来支持恢复，这已在协议规范中定义。 几位用户强调现有的框架（如 Google 的 ADK）可以自动处理这种“记录”。
一个关键的争论点在于是否缓存 token（考虑到每个 token 的成本，这很昂贵）还是重新生成它们。一些人提出了诸如幂等提示或持久化流（一种用于可恢复流的开源规范）之类的解决方案，以避免重新生成。 另一些人则建议使用简单的数据库缓存。
最终，共识倾向于认为问题是应用层面的问题，而不是 SSE 的根本缺陷，并且需要更好的抽象和构建块来构建强大的代理系统。
## 中年觉醒：重拾真我 中年时期可能会带来意想不到的转变：取悦他人的能力和意愿下降。这种“不再迎合”并非负面变化，而是一种神经结构的重组。几十年以来，我们的大脑，尤其是女性的大脑，由于社会教养，一直将社会和谐放在优先位置，不断地用前额叶皮层进行监控和情感劳动，导致精疲力竭。 随着年龄增长，大脑会修剪掉不必要的通路，通常从那些用于过度取悦他人的通路开始。激素变化进一步降低了将他人的舒适度置于自身真相之上的动力。这导致了清晰的认知，拒绝压抑自我，以及优先考虑真实性。 虽然这种转变具有解放意义，但也可能遇到阻力。依赖我们表现的系统会失灵，我们可能会被贴上“难相处”的标签，或者经历人际关系的转变。然而，这种不适感揭示了剥削性的关系动态。这并非关于*变成*一个消极的人，而是*展现*真实的自我——拥有界限、观点和需求。 最终，对“不在乎”的练习是为了充分地生活，优先考虑真诚的连接，并认识到我们内在的价值，独立于外部认可。这是迈向自由和自我接纳的勇敢一步。
一个黑客新闻的讨论围绕着一篇最近分享的文章，探讨了优先事项的转变以及“取悦他人”行为的下降，尤其是在经历围绝经期的女性中。许多评论者对文章的框架表示沮丧，特别是它将这种变化主要归因于激素变化。
几位用户认为文章缺乏科学依据，并且忽略了生活经验和对年龄增长带来的可能性减少的现实评估。一位男性评论者分享了类似的经历，认为这种转变源于认识到维持表面的徒劳，并将有限的时间和精力集中在真正重要的事情上。
核心批评在于，文章试图*解释*一种不在乎他人意见的心态——根本上错失了拥抱这种自由的意义。几位用户直言将文章称为“AI垃圾”，暗示这是一篇写得糟糕、泛泛而谈的文章，很可能是由人工智能生成的。
## Java 中的 SwissTable：性能深度剖析
本文详细介绍了作者实现 Google 的 SwissTable Java 版本的过程，这是一种高性能哈希表设计。SwissTable 将键/值存储与用于快速探测的紧凑“控制字节”分离，从而避免了大多数情况下昂贵的键比较。它通过将哈希分成两部分来实现这一点——一部分用于初始组选择，另一部分作为组内快速过滤的指纹。
受到其在 Rust 和 Go 中的采用（在这些语言中带来了显著的速度提升）的启发，作者利用孵化中的 Vector API 来高效批量比较控制字节，从而在 Java 中迎接这一挑战。关键在于围绕 Vector API 进行设计，以最大限度地利用 SIMD，重点关注缓存友好的控制字节扫描作为热路径。
由此产生的“SwissMap”优先考虑最小化键访问次数，并利用诸如前哨填充、高负载因子（87.5%）和墓碑重用等技术来实现高效的删除和调整大小。基准测试表明，SwissMap 保持了具有竞争力的吞吐量，尤其是在高负载因子下，并且与标准的 Java 哈希映射相比，展示了更低的内存使用量。该项目名为 HashSmith，是开源的，可供实验。
最近 Hacker News 上出现了一场讨论，围绕着一篇详细介绍了 Java 中高效哈希表实现的博客文章（[https://bluuewhale.github.io/](https://bluuewhale.github.io/)）。作者实现了一种利用“SWAR”（寄存器内 SIMD）的技术，出人意料地性能优于 Java 的 Vector API（旨在用于 SIMD 操作）。
作者认为，关键原因并非 Vector API *没有* 使用 SIMD，而是将向量掩码转换为标量位掩码的成本很高。SWAR 通过直接在通用寄存器上使用按位运算来避免这种转换，从而提供简单性和可预测性。
评论者指出，文章可以从更清晰地解释核心概念中受益——本质上是一种用作第一阶段检索步骤的布隆过滤器——作者承认了这一点并计划解决。 还有人好奇 fastutil，另一个 Java 库，是如何实现其哈希表的。作者计划发布后续文章，深入探讨 Vector API 编译成机器码的过程。
## 可调度太阳能现已具有全球竞争力
Ember 的最新报告强调，电池储能系统 (BESS) 的成本正在迅速下降，使得可调度太阳能——即与储能配套的按需电力太阳能——成为全球范围内与传统电力来源具有竞争力的选择。
仅 2024 年，核心 BESS 设备成本就下降了 40%（达到 165 美元/千瓦时），电池性能也得到了改善（寿命更长、效率更高），储能的平准化成本已降至 65 美元/兆瓦时。这使可调度太阳能的总成本降至 76 美元/兆瓦时，低于新建燃气发电厂，尤其是在依赖液化天然气进口的地区。
该报告基于国际拍卖数据和专家访谈，显示全球项目成本约为 125 美元/千瓦时，而采购自中国的设备可以显著降低成本。尽管由于关税和国内内容要求，美国成本较高，但美国仍然是一个主要且快速增长的 BESS 市场，2024 年新增了 10 吉瓦的公用事业规模电池。
Ember 总结认为，太阳能与储能相结合，不再局限于白天发电，可以可靠地满足全球能源需求的重要部分。
日间颜色： 夜间颜色： 由 Marko Denic 制作。源代码在 GitHub 上。灵感来自 Pong Wars。
一款名为“动态乒乓大战”(markodenic.tech) 的网页游戏正在 Hacker News 上引发讨论。这款游戏具有简单的迷人视觉效果，展示了两个玩家用“乒乓”进行战斗——本质上是动态演化的 Pong 游戏。
用户对游戏的催眠般品质印象深刻，将其比作围棋或熔岩灯。一些评论员指出游戏可能会“卡住”，乒乓在中心碰撞，建议增加卡顿检测和随时间绘制分数的功能。
其他人受到启发，创建了拥有更多玩家的版本(pong.u11g.com)。改进想法包括可视化游戏的时间周期，以及分析分数变化的“波函数”，可能揭示类似于黏菌生长的模式。该游戏被描述为一种零和竞争，让人联想到纸牌游戏“战争”。
## Gleam 与 2023 年 Advent of Code：积极体验
作者连续第七年完成了 Advent of Code 的所有挑战，这次使用了 Gleam 编程语言。尽管活动缩短至仅 12 天（24 个部分），而不是通常的 25 天，但谜题仍然引人入胜，并且常常出乎意料地困难。
Gleam 非常适合 AoC 的风格——解析、转换数据和折叠——这得益于其简洁的语法、有用的编译器和强大的管道运算符。该语言对函数式编程的强调及其强大的列表函数（如 `transpose` 和 `combination_pairs`）尤其有益。像 `fold_until` 和 `echo` 调试工具这样的特性显著简化了开发。
虽然总体上是积极的，但出现了一些摩擦点，包括文件 I/O 和正则表达式需要外部依赖，列表模式匹配的限制以及显式比较。针对 JavaScript 也需要使用大整数，因为其数字存在限制。尽管如此，作者发现 Gleam 的选项/结果处理和备忘录功能特别强大，从而产生了优雅的解决方案，尤其是在基于网格的谜题中。总而言之，这次体验非常令人满意，并激发了对未来项目中使用 Gleam 的兴趣。
## Gleam 与编程语言的未来 (Hacker News 总结)
一个 Hacker News 的讨论围绕 Gleam 编程语言及其在 LLM 时代的前景。作者尝试用 Gleam 参加 Advent of Code，发现其性能令人惊讶，并且语言服务器非常出色。
一个关键主题是 LLM 是否会因其对大型训练数据集的依赖而扼杀新语言的创新。一些人担心缺乏大量代码库的语言将被抛在后面，而另一些人则认为 LLM 将适应设计良好、更简单的语言，例如 Gleam。
讨论还涉及 Gleam 的设计选择，特别是它缺乏接口（尽管它*有*泛型），以及它侧重于显式代码而非简洁性。 许多评论员强调 Gleam 的强类型和与 Erlang VM (BEAM) 的集成是优势。
最终，对话反映了对 LLM 对编程格局的影响以及它们是否会偏爱成熟语言而非更新、可能更具创新性的语言的更广泛担忧。 一种观点是，如果设计良好的语言，即使是小众语言，也能提供独特的优势和清晰、一致的风格，从而使 LLM 能够轻松学习，那么它们就能蓬勃发展。
## z8086：为FPGA设计的忠实8086内核
z8086是一个用SystemVerilog实现的新的8086/8088 CPU内核，旨在忠实复制原始Intel微架构。它不采用手工编码指令，而是利用从ROM运行的恢复的Intel微代码，重现原始芯片的行为。
这个紧凑的内核——大约2000行代码，在60MHz的Gowin GW5A FPGA上利用约2500个LUT——通过了ISA测试，可以启动小型程序，并控制外设。该项目的目标是具有教育意义、FPGA友好型，并准确反映8086的独特特性，如分段寻址和通过预取队列实现早期流水线。
开发过程中的关键发现包括纠正原始专利文档中的不准确之处，并忠实地重现了一个已知的中断错误。虽然目前尚未达到周期精确或能够运行DOS，但z8086展示了对8086内部运作的深刻理解，并为CPU考古和FPGA项目提供了一个宝贵的资源。未来的工作包括更广泛的测试、DOS启动，以及潜在的WebAssembly可视化。该项目是开源的，并且可在GitHub上获取。
## 黑客新闻讨论：重建8086与架构比较
一篇关于从微代码重建8086处理器的文章引发了黑客新闻的讨论，并迅速演变成与摩托罗拉68000的比较。虽然原文侧重于8086，但评论者指出68000 *也* 使用了微代码（甚至“纳米代码”），尽管它是一个32位架构，而8086是16位设计。
对话深入探讨了性能差异，普遍认为286比8086和68000都更快。68000复杂的寻址模式与286更简单、受RISC影响的方法形成了对比。关于68000的内部架构的细节浮出水面——利用多个算术逻辑单元实现更快的处理——以及它的灵活性，甚至允许IBM委托定制芯片运行S/370代码。
评论者还回忆了编程经验，强调了Z80等处理器上字符串指令的实用性，并分享了过去微处理器设计书籍中的轶事。