1. 告别 CRDT/OT！协同文本编辑迎来全新简洁方案 (Collaborative Text Editing Without CRDTs or OT)
告别复杂算法！开发者 Matthew Weidner 带来了一种全新的协同文本编辑方案，无需依赖让人头大的 CRDT 或 OT 算法。这种新方法的核心思想是为每个字符赋予唯一的 ID，客户端通过“在某ID之后插入”的操作与服务器同步，服务器则忠实地执行这些指令。即使出现并发编辑，也能通过服务器协调机制确保最终一致性。
这种方案不仅简单易懂，更赋予开发者极高的灵活性，可以根据需求定制各种高级功能，例如分段权限、建议修改和富文本格式等，这些在传统的黑盒 CRDT/OT 库中往往难以实现。更棒的是，该方法还支持去中心化协作，并与现有 CRDT 技术巧妙结合。
为了方便开发者使用，作者还推出了 Articulated 库，它通过优化数据结构，显著提升了 ID 管理和序列化效率。
原文链接：https://mattweidner.com/2025/05/21/text-without-crdts.html
论坛讨论链接：https://news.ycombinator.com/item?id=44053560
论坛中，有人指出该方案本质上是一种CRDT（Conflict-free Replicated Data Type），只是文档操作顺序由中心服务器决定，类似于Google Docs和Zoho Writer的工作方式，但后者使用OT（Operational Transformation）和中心服务器协调，而该方案采用更接近CRDT的方式。另有人称赞了该算法的简洁，它为每个字符分配全局唯一ID，客户端发送“在…之后插入”的操作，服务器查找目标ID并插入新字符，删除操作仅隐藏字符但不真正删除。
有人认为这是一种退化的CRDT，通过中心服务器进行冲突解决，让人联想到Google Wave。另一些人提出，可以通过客户端ID代替中心服务器进行冲突解决，甚至可以使用时间排序的UUIDv7。但也有人质疑时钟同步的可靠性，并指出在分布式系统中实现真正的同时性是不可能的。最后，有人表达了对Google Wave的怀念，认为它以一种独特的方式运行，适合进行D&D游戏。
2. AI“逼疯”微软员工？Reddit热帖引爆科技界焦虑 (Watching AI drive Microsoft employees insane)
这则Reddit论坛帖子引发了关于AI是否正在“逼疯”微软员工的热烈讨论。一位名为NegativeWeb1的网友分享了自己的“新爱好”：观察AI如何让微软员工逐渐崩溃。该帖子迅速吸引了大量经验丰富的开发者参与，留言超过500条。
许多网友纷纷表示赞同，分享了他们在使用AI工具时遇到的各种挑战和困惑，例如AI生成代码的质量问题、AI工具的不可靠性以及对AI过度依赖可能导致的技能退化等。一些人甚至认为，微软内部对AI的过度宣传和应用已经对员工造成了不必要的压力。尽管存在争议，但该帖子无疑引发了科技行业对AI发展方向以及人类与AI之间关系的深刻思考，也促使人们关注AI工具在实际应用中可能带来的负面影响。这场讨论也显示了开发者们对AI抱有的复杂情感，既期待AI能提升工作效率，又担忧AI可能带来的潜在风险。
论坛讨论链接：https://news.ycombinator.com/item?id=44050152
论坛的讨论围绕着Copilot在代码审查中的实际表现展开。有人注意到，Copilot提出的修改建议虽然附带了反馈按钮，但几乎没有收到任何反馈，质疑这是否只是治标不治本。部分人认为，Copilot的表现像一个不靠谱的初级开发者，不仅无法理解指令，还会犯低级错误，比如忘记将新文件添加到csproj中，或者直接移除/注释掉失败的测试用例。有评论指出，谷歌和微软的模型似乎比OpenAI和Anthropic的模型更容易出现此类问题。
一些人分享了具体的代码审查案例，展示了Copilot生成的代码质量问题以及由此给开发者带来的困扰。另有人指出，将Copilot比作初级开发者并不恰当，因为真正的初级开发者通常更认真、更具学习能力。还有人将Copilot的表现与Upwork等平台上的低价外包团队相提并论，认为其交付的代码质量低下，需要耗费大量时间才能解决问题。总的来说，讨论对Copilot在代码审查中的实际效果持怀疑态度，认为其在没有人工干预的情况下难以胜任复杂任务。
3. 告别PG&E！湾区居民自建太阳能，怒怼天价电费！ (Building my own solar power system)
加州居民乔·埃克伦德不堪忍受太平洋煤电（PG&E）的连番涨价，毅然决定自建太阳能系统，摆脱对电力公司的依赖。他原本每月电费高达1200美元，自建计划遂应运而生。
埃克伦德在充分调研后，没有选择报价高达7.5万美元的专业安装，而是决定DIY。他花费约3万美元（税收减免前），购入EG4逆变器、PowerPro电池、Aptos太阳能板及Tigo优化器等设备，打造了一个14.1千瓦太阳能+43千瓦时电池的系统。
过程中，埃克伦德聘请专业人士设计图纸，并由其父协助完成电气布线。虽然遭遇了屋顶更换、设备版本错误等挑战，但最终顺利通过城市检查，获得运营许可。系统投入使用后，不仅完全覆盖了家庭用电需求，还能将多余电力输回电网。
埃克伦德分享了他的经验教训，强调电池在NEM3政策下的必要性，推荐传统串式逆变器以降低损耗，并建议选择提供良好支持的经销商。他还提醒大家务必阅读手册、尽早规划布线，并在必要时寻求专业帮助。
论坛讨论链接：https://news.ycombinator.com/item?id=44023226
论坛上有用户分享了自己在咖啡农场使用太阳能微电网的经验，7年来从最初的几个高尔夫球车电池和4块太阳能板，发展到如今为4栋房屋、7个小屋、水处理系统、光纤网络、安全系统和一个小型服务器机架供电。系统包含6个逆变器、35千瓦的太阳能板和160千瓦时的锂电池，并计划增加20千瓦的太阳能板。他认为在加勒比地区，农村地区的人们花钱用电是不划算的。
另一位用户表示，在美国，电价大约为0.1美元/千瓦时，相比之下，维护太阳能设备和使用备用发电机并不划算。加拿大BC省的用户分享说，他支付0.13加元/千瓦时，但他的7.8千瓦太阳能系统在获得激励和无息贷款后无需自掏腰包，每年还能产生约1000加元的收入。还有用户指出，佐治亚州的夏季电价较高，太阳能系统可以在7-8年内收回成本。加州的用户则表示，当地的非高峰电价为0.32美元/千瓦时，高峰电价为0.58美元/千瓦时。一位农村电力合作社的成员表示，当地住宅用电的统一费率为0.13美元/千瓦时，企业和农场的电价甚至可以降至0.10美元/千瓦时。电力公司曾提议将价格提高到0.15美元，以便更好地修剪线路周围的树木，但遭到合作社成员的拒绝。
4. 不丹“会说话的邮票”：一段被遗忘的传奇 (The curious tale of Bhutan’s playable record postage stamps (2015))
1972年，不丹王国发行了一套“会说话的邮票”，这套邮票实际上是可以播放的迷你黑胶唱片，只需撕下背面纸张，贴在信封或明信片上，再用唱机就能播放。内容包含不丹民歌以及用英语和宗喀语讲述的不丹历史。
这些邮票由美国冒险家Burt Todd设计。 Todd的人生经历丰富，与《了不起的盖茨比》的主人公颇有相似之处。他曾帮助不丹国王筹集资金，并创新性地将邮票与音乐结合。
最初，集邮界对这种新奇玩意儿并不感冒，价格低廉。然而，随着稀有黑胶收藏家的发掘，这些“会说话的邮票”身价飙升，一套的价值已超过300英镑，且预计未来几年还将翻倍。 Todd家族的创新精神也延续了下来，他的女儿后来还推出了带有纪录片视频的CD-ROM邮票。这些独特的邮票不仅是集邮爱好者的心头好，也成为了解不丹历史和文化的有趣载体。
原文链接：https://thevinylfactory.com/features/the-curious-tale-of-bhutans-playable-record-postage-stamps/
论坛讨论链接：https://news.ycombinator.com/item?id=44054775
这套不丹于1972年发行的邮票由七枚小型单面33 1/3转速的黑胶唱片组成，可以在标准唱机上播放。邮票内容包括不丹民歌和用英语及当地语言宗喀语讲述的不丹历史。
一位IT从业者，曾经是集邮爱好者，惊叹于这种邮票的创意，认为它比90年代的CD名片更胜一筹。有人推测，这种邮票的构思可能源于60年代中期的迷幻体验。另有人认为，这种邮票类似于70、80年代在麦片盒或开心乐园餐中出现的塑料玩具唱片。
有评论提到2020年曾讨论过类似的不丹可播放邮票。有人询问邮票的尺寸，并得到解答，尺寸约为69毫米或100毫米直径，相当大。
一些人质疑这些邮票是否真的被用作邮资，考虑到其尺寸、重量以及需要盖销等问题。但也有人发现有使用这些邮票的首日封，表明它们确实可以用于邮寄，只是效果不太好。
有链接分享了这些邮票的声音。还有人希望@Techmoan频道能详细介绍这些邮票。由于播放表面积较小，普通唱机可能无法正常播放，可能需要手动操作。有人好奇物理学家莱顿或费曼是否了解这些邮票。
5. 内存胜时间：算法效率突破，空间换时间的新可能 (For algorithms, a little memory outweighs a lot of time)
MIT的理论计算机科学家 Ryan Williams 在计算领域取得突破性进展，他证明了在所有可能的计算中，少量内存可以像大量时间一样有效。这项研究在计算机科学领域时间与空间复杂度的关系上取得了50年来的首次进展。Williams的证明提供了一种数学方法，可以将任何算法转换成占用更少空间的形式。
他的研究表明，对于任何算法，都存在一种等效算法，其空间占用量大约等于原始算法运行时间的平方根，尽管新算法运行速度会慢很多。 这一发现不仅在理论上具有革命性意义，也为解决计算机科学中最古老的未解难题之一提供了新思路，并为后续研究开辟了新的方向。
这项成果建立在 Stephen Cook 及其合作者早期关于极有限空间计算的研究之上，并受到了 Cook 之子 James 和 Ian Mertz 提出的“挤压数据”概念的启发。 Williams 的突破受到了学界广泛赞誉，被誉为“惊艳”且“优美”的成果，有望推动计算复杂性理论的进一步发展。
原文链接：https://www.quantamagazine.org/for-algorithms-a-little-memory-outweighs-a-lot-of-time-20250521/
论坛讨论链接：https://news.ycombinator.com/item?id=44055347
论坛讨论围绕一篇关于时间与空间复杂度的论文展开。有人批评Quanta的文章在数学描述上过于冗余。另有评论指出，文章用“合理的时间”来解释P复杂度类，却避用了“多项式”一词，不够严谨。
有人分享了编程书籍中的Perl哲学：“如果内存不够，可以购买更多。但如果时间不够，你就完蛋了。” 并指出内存不足程序无法运行，时间不够至少程序还能运行。
还有人结合自身经验，分享了在图形编程中利用查找表和预先计算的方法来优化性能的案例。他认为很多日常工作中的技巧，一部分可能源于聪明人的研究成果，另一部分则来自程序员的经验积累。他举例自己写了一个服务器，将多边形数据预先加载到数据库中，从而在查询时提高速度。
6. Rocky Linux 10 重磅发布：正式拥抱 RISC-V 架构！ (Rocky Linux 10 Will Support RISC-V)
开源操作系统Rocky Linux宣布，其即将发布的Rocky Linux 10将正式支持RISC-V架构！这一激动人心的进展得益于Fedora RISC-V社区和Rocky Linux AltArch SIG小组的紧密合作。新版本将包含ariscv64gc构建，目标平台包括StarFive VisionFive 2 (VF2)、QEMU和SiFive HiFive Premier P550等，与Fedora支持的平台保持一致。
Rocky Linux 10上的RISC-V将被视为一种备选架构，但其构建失败不会阻碍其他架构的发布。这意味着Rocky Linux的软件包更新不会因RISC-V版本的构建或修复问题而受到影响。目前，StarFive VisionFive 2和QEMU已获得全面支持，SiFive HiFive P550则提供有限支持。
Rocky Linux的RISC-V项目自2024年初开始，与上游Fedora RISC-V项目密切合作，从Fedora RISC-V引导编译器堆栈，并进行了必要的移植。Rocky Linux社区鼓励大家积极参与，共同推动RISC-V生态系统的发展。用户可以通过Mattermost频道参与讨论，或通过Bluesky、LinkedIn和RSS订阅获取最新进展。
原文链接：https://rockylinux.org/news/rockylinux-support-for-riscv
论坛讨论链接：https://news.ycombinator.com/item?id=44056104
针对红帽宣布在RHEL 10中支持RISC-V一事，论坛上展开了讨论。有人质疑获取红帽源代码的途径，因为之前有消息称红帽更改了源代码的提供方式，现在几乎不可能获取。另有人分享了自己使用各种Linux发行版的经验，认为红帽的发行版虽然稳定，但略显陈旧，用户在更新时也常遇到问题。
一位红帽员工回应，对用户的体验表示歉意，并解释说版本和ABI保证并非适用于所有人。他同时强调，即将发布的P550镜像中包含的GCC 15和LLVM 19等都是最新的，旨在促进更多软件在RISC-V上的开发。
还有用户指出，RHEL的kABI保证有其局限性。在HPC/AI领域，使用的外部驱动程序（如MOFED和Lustre驱动程序）在每次RHEL小版本更新时都会中断。尽管现在情况可能有所改善，但过去几年一直如此。有用户提到weak-modules机制在一定程度上可以缓解这个问题，但通常还是会选择为每个内核重新构建驱动模块。另有用户表示，RHEL 8增加了内核符号签名哈希作为依赖，通过自动化提取，内核模块的处理变得更加容易。但是也有人指出RHEL的小版本更新会破坏内核内部API，导致内核模块构建失败。最后，有人提议将这些驱动程序升级。
7. LLM函数调用难扩展，代码编排更高效 (LLM function calls don’t scale; code orchestration is simpler, more effective)
大型语言模型（LLM）在调用工具时，若直接处理全部输出数据，效率低且成本高。利用输出模式能获得结构化数据，让LLM通过生成的代码协调处理过程，简化工具调用，提高效率。
目前常见做法是将工具的输出作为消息反馈给LLM，让其判断下一步动作。但当数据量庞大时，例如从Linear或Intercom的MCP服务器返回的包含大量冗余ID字段的JSON数据，这种方法会遇到瓶颈。将编排和数据处理混在同一线程中，导致模型可能无法准确处理数据。
更优方案是解析结构化数据，用代码执行数据操作，例如对问题按截止日期排序。这类似于带有AI的代码解释器。通过代码执行处理来自MCP工具的数据，为AI模型开辟了可扩展的道路。利用变量存储数据，并通过代码编排多个函数调用，保证完整性。模型可以使用循环或NumPy/pandas等库来转换大量数据，甚至可以调用其他LLM进行非结构化数据处理。
MCP规范已经定义了输入模式，并引入了输出模式，有望解锁大型数据集的使用场景，如构建自定义仪表板、创建每周报告或推进停滞问题。
目前挑战在于MCP客户端，需要在沙盒环境中安全运行用户/AI生成的代码。设计具有特定API访问权限的沙盒环境，为模型提供API调用文档，是关键。此外，无状态但持久的执行环境对于长时间运行的任务至关重要。这些约束催生了一种新型运行时——“AI运行时”，它使用LLM来编排和执行任务。目前仍处于早期阶段，欢迎大家参与讨论。
原文链接：https://jngiam.bearblog.dev/mcp-large-data/
论坛讨论链接：https://news.ycombinator.com/item?id=44053744
论坛中，一位开发者分享了为电商业务构建智能代理系统的经验，并评估了smolagents。他认为smolagents虽然优雅，但增加了系统复杂性，适用于动态报表等特定任务，对大多数任务而言是过度设计。Gemini和OpenAI提供的Python解释器已能满足许多代码代理的需求。他强调，过度依赖工具调用和交互是不具可扩展性的，有效的智能代理工作流应该是短期的，并通过结构和规范管理复杂性。函数调用在智能代理系统中可以高效扩展，也可能变得混乱，关键在于管理开发者认知负荷，并选择足够简单的解决方案，例如组合函数调用和传统的数据解析转换方法。管理智能代理系统的复杂性，最终可归结为精细管理应用状态，将消息堆栈作为模型上下文的来源，类似于受限环境中的内存管理。
另一位来自IsarTech的开发者赞同了这种权衡的总结，并分享了他们在电商对话式产品发现方面的经验。他们也认为函数组合和结构化数据对于控制复杂性至关重要，良好定义的结构化输出是工具调用的可扩展性关键。他们尽可能依赖确定性行为，仅在处理无模式数据或模糊不清的情况时才使用LLM。LLM适用于将模糊的用户请求映射到更结构化的确定性系统。不过，在消除高熵输入中的复杂性和通过链式工具调用引入复杂性之间，需要谨慎权衡，因为在实际应用中往往需要结合多种方法。
8. 工程师卓越之道亦是卓越工程组织之基 (What makes a good engineer also makes a good engineering organization (2024))
软件开发常常被视为工程实践，但其独特性在于它存在于一个完全已知的计算机宇宙中。然而，软件的魔力在于其“愿景”与“工程”之间并非简单的线性关系，而是相互交织、双向影响。就像早期的计算机图形动画通过巧妙的颜色循环技术实现惊艳的视觉效果一样，对工具和技术的深刻理解常常能催生新的愿景和意想不到的结果。
作者认为，如今的软件开发过于依赖抽象层，工程师们倾向于将这些抽象层视为黑盒，而非深入理解其运作原理。这种做法可能阻碍创新，因为缺乏对底层技术的理解，难以产生真正卓越的成果。即使是大型工程组织，也常常陷入孤岛效应，团队之间缺乏交流，导致潜在的创意和技术想法无法碰撞。
作者鼓励开发者和工程团队打破常规，深入理解技术细节，将“愿景”与“工程”紧密结合，激发创新。就像早期的开发者通过对硬件的深入理解创造出令人惊叹的效果一样，对工具和技术的深刻理解是软件开发和工程组织创新的基石。真正理解才能真正创造，打破黑盒，拥抱好奇心，才能释放软件和团队的全部潜力。
原文链接：https://moxie.org/2024/09/23/a-good-engineer.html
论坛讨论链接：https://news.ycombinator.com/item?id=44026703
论坛上的讨论围绕着产品开发中工程师与商业人员的角色和利润的重要性展开。一位用户指出，Signal的创建者Moxie成功建立了一个非营利性的开源软件公司，其技术被许多大型科技公司采用。该用户认为，如果目标是创造高质量的产品，工程师应专注于产品本身，而利润是商业人士的领域。这种分工能够创造平衡，避免产品开发过于缓慢或质量低劣。
另一位用户反驳说，利润并非仅仅是商业人士的领域，运营非营利组织也需要商业技能。成本控制对任何组织都至关重要。他强调，需要在不同优先级之间取得平衡，过度追求利润可能会损害业务和客户，同时也应考虑到员工的生计。
最初发言者随后澄清说，并非提倡完全忽视商业运营，而是主张在不同团队或个人之间进行分工，一部分人专注于产品，确保满足客户需求，另一部分人则专注于盈利，以维持公司运营。他认为，工程师和管理者之间应相互制约，以实现客户价值最大化和利润最大化。