1. 扎克伯格国会撒谎铁证曝光：Meta欺瞒国会，罔顾青少年安危 (Mark Zuckerberg Lied to Congress. We Can’t Trust His Testimony)
华盛顿特区——在Meta首席执行官马克·扎克伯格即将就社交媒体成瘾诉讼作证之际，“科技监管项目”发布了一份报告，指控扎克伯格在2024年参议院司法委员会的证词中撒谎并欺骗了委员会。这份报告基于最新解密的文件，揭示了扎克伯格的公开陈述与Meta内部证据之间的严重不符。该项目执行董事萨沙·霍沃思指出，Meta长期以来一直躲在《第230条规定》的保护伞下，这让扎克伯格等人误以为他们可以免受追责。霍沃思强调，Meta的律师团队曾赌定这些关键文件不会曝光，但他们失算了。这些前所未见的文件证明扎克伯格对国会撒了谎，表明Meta会继续隐瞒研究并鲁莽地伤害年轻人，直到国会通过如《儿童网络安全法案》等立法，强制他们承担责任并保护儿童和青少年。报告详细列举了扎克伯格的三项关键虚假陈述及其被揭露的真相。首先，针对因科技产品失去孩子的家庭，扎克伯格曾表示Meta投入巨资并持续引领行业努力，确保此类悲剧不再发生。
论坛讨论链接：https://news.ycombinator.com/item?id=47060486
社区成员对Meta首席执行官扎克伯格在国会证词的真实性表示担忧。一些人认为，报告中将投资无效性与“撒谎”混为一谈，可能存在曲解。
更具体的指控包括：扎克伯格声称平台不容忍色情内容，但有证据表明，在2020年，65%的社交媒体儿童性交易受害者是在Facebook上被招募的。此外，尽管Meta内部研究显示，停止使用Facebook和Instagram一周会降低用户的焦虑、抑郁和孤独感，但扎克伯格却声称科学界尚未证明社交媒体与青少年心理健康问题之间存在因果关系。
另一位用户指出，Instagram负责人声称该应用对青少年心理健康的影响“很小”，但内部研究却显示青少年对Instagram存在“成瘾性叙事”，感到“无力抗拒”，并承受着“保持在线和完美”的巨大压力。一位用户还分享了自己举报色情信息被拒绝的经历，进一步佐证了平台监管的不足。
2. 15年经典Git图被AI“魔改”，微软遭原创者怒斥“不配出品” (15 years later, Microsoft morged my diagram)
近日，开发者Vincent Driessen在其博客中指出，微软官方学习门户网站上的一张关于Git分支模型的图表，疑似由人工智能生成，并且抄袭了他本人于2010年创作并发布的经典图表。Driessen表示，他于2010年创作的Git分支模型图表，经过精心设计，旨在清晰地传达分支间的关系，并公布了源代码以供他人参考和学习。该图表此后被广泛应用于书籍、演讲、博客、团队维基和视频等多种场合，他对此表示乐见其成，因为分享知识是其初衷。然而，令他意外的是，微软在15年后，未经任何署名或链接回原文的情况下，使用人工智能图像生成器生成了该图表的变体，并发布在其官方学习门户上。Driessen批评微软生成的图表不仅粗糙、业余，而且完全失去了原作精妙的视觉语言、色彩设计和布局，箭头方向错误，甚至出现“continvoucly morged”这样的明显AI错误文本，认为其“不配为微软出品”。
原文链接：https://nvie.com/posts/15-years-later/
论坛讨论链接：https://news.ycombinator.com/item?id=47057829
在社区中，一篇关于Git分支模型，特别是Git-flow的讨论引发了热议。m12k对Git-flow模型中“develop”分支的必要性提出了质疑，认为将集成工作放在“develop”分支上是多余的。他指出，通常“master/main”分支即可用于集成，而发布标签本身就能标识最新版本。如果真的需要一个独立分支来管理发布，他建议创建一个“release-tags”分支，而不是降级“master/main”分支的固有含义。m12k承认Git-flow在特性分支、发布分支和热修复等方面的设计合理，但对“develop”分支的引入表示遗憾，认为这是该模型的一个奇怪之处。
iainmerrick赞同m12k的观点，并指出m12k描述的方法实为“主干开发”（Trunk Based Development），并认为其更为优越。他推测Git-flow之所以流行，很大程度上归因于其“朗朗上口的名字和吸引人的图表”，而非其内在技术优势。iainmerrick观察到，当有人指出Git-flow存在冗余或反生产的部分时，常会遇到“它是一个成功的模型！它是标准！”的反驳。他推荐了trunkbaseddevelopment.com作为主干开发风格的参考。
whoknowsidont则对Git-flow受欢迎的原因提出了不同看法。他认为，Git-flow的兴起与Git出现在SVN/CVS时代有关。SVN/CVS等旧版本控制系统由于其技术限制，催生了某些分支模型，而Git虽然没有这些缺陷，但人们习惯了熟悉的工作方式，从而沿用了类似的分支模式。zamalek对此表示认同，并补充说，如果不是Git-flow，Git的普及度可能会低很多，因为人们“非常依恋他们所钟爱的分类法”。
3. 《电脑狂人》：别再错过！这部“隐形剧王”如何从谷底逆袭成口碑神剧？ (Halt and Catch Fire: TV’s best drama you’ve probably never heard of (2021))
美剧《电脑狂人》（Halt and Catch Fire）虽常被忽视，却被誉为一部卓越的剧情片。该剧于2014年首播时，收视表现不佳，成为美国AMC电视台现代史上首播收视率最低的剧集之一，且后续收视持续下滑。然而，这部剧集却凭借其逐季提升的叙事深度和大胆的自我革新赢得了口碑。最初，《电脑狂人》被构思为一部聚焦科技行业反英雄人物乔·麦克米伦的生存故事，试图复制当时流行的道德灰色剧集模式。但随着剧情发展，编剧团队敏锐地意识到，乔并非最引人入胜的角色。于是，剧集勇敢地抛弃了原有设计，将其核心转向了对人际连接、变革以及创造过程中情感纽带的深刻探索。随后的几季中，故事重心逐渐转移到戈登的妻子唐娜和叛逆的编程天才卡梅伦之间蓬勃发展的商业伙伴关系，她们共同创立了视频游戏订阅服务“Mutiny”。这一转变使得剧集摆脱了传统反英雄叙事的局限，注入了新的活力和抱负，展现出一种显著的轻松与积极。
原文链接：https://www.sceneandheardnu.com/content/halt-and-catch-fire
论坛讨论链接：https://news.ycombinator.com/item?id=47056314
社区关于电视剧《奔腾年代》（Halt and Catch Fire）的讨论热烈，许多评论者认为这是被低估的优秀剧集。danielvaughn高度赞扬了李·佩斯饰演的乔·麦克米伦，认为他成功塑造了一个极具魅力的营销奇才，其表演的真实感能让观众信服。Slow_Hand也认同乔的非凡魅力，即便知道他操纵性强，仍被其魔力吸引，尤其提到剧中乔在飓风中与孩子互动的场景充满魔幻色彩。他认为该剧超越了核心剧情，展现了纯粹的创意表达，与众不同。
然而，metamet指出，尽管该剧是“顶尖的精品剧”，但看过的人却出奇地少，主要原因是其流媒体可访问性差，目前只在AMC+上提供，而很少有人订阅。他推测如果Netflix获得版权并进行推广，该剧有望迅速走红。knappe证实该剧曾一度在Netflix上架，并指出这是流媒体服务普遍存在的问题。walterbell补充说，该剧的40集盒装版可在Apple TV上购买。runamuck则推荐AMC+给喜欢恐怖片和“Y2K时代精品剧”的观众。SubiculumCode也表示该剧曾通过Prime提供，自己已观看三遍，是其最爱之一。echelon_musk则对“很少有人看过”的说法表示疑惑。
4. Asahi Linux 重磅进展：MacBook USB-C 视频输出终实现！ (Asahi Linux Progress Report: Linux 6.19)
Asahi Linux项目迎来五周年，期间已从最初的“Hello World”发展成为Linux生态系统中对AArch64架构支持最佳的桌面级平台之一，其持续的成功促使众多开发者开始认真对待AArch64，并针对Apple Silicon设备上的Linux运行修复了流行软件中大量与平台相关的错误。在项目取得显著成就的同时，用户对通过USB-C端口实现显示输出（DisplayPort Alt Mode）的呼声从未间断。经过多年的不懈努力，Asahi Linux团队终于宣布在此关键功能上取得突破性进展。在近期举行的39C3大会上，项目核心成员Sven成功演示了在一台M1 MacBook Air上通过USB-C转HDMI适配器连接至会场影音系统，标志着该功能已初步实现。
原文链接：https://asahilinux.org/2026/02/progress-report-6-19/
论坛讨论链接：https://news.ycombinator.com/item?id=47059275
讨论围绕Asahi Linux的最新进展展开，特别是Linux 6.19的发布。多位贡献者因其辛勤工作受到赞扬。
一些人认为，随着时间的推移，二手M1/M2 Mac将成为年轻开发者喜欢的个人笔记本电脑，类似于过去的Thinkpad T420。然而，也有人对此表示怀疑，指出Apple Silicon设备SSD寿命有限且不可更换，这可能导致其在二手市场上出现故障潮，使其成为一种“赌博”。有人认为MacBook的设计寿命有限，与Thinkpad的可修复性和可升级性形成鲜明对比。
另一些人则认为，即使SSD被焊接，也可以通过重新焊接来修复，并且这种服务正变得普遍且便宜。尽管如此，也有人指出，除Apple产品外，大多数主流PC笔记本电脑仍使用M.2 NVMe存储，而焊接存储在非Apple笔记本电脑中并不常见，主要出现在低端Chromebook或某些基于高通的笔记本电脑上。实际上，M系列芯片的存储是集成在芯片上的，并非焊接在主板上。
还有评论者表示，他们对升级64GB M1 Max MacBook Pro的意愿不高，并考虑尝试Asahi Linux。也有人提到，16GB M1 Air是他们拥有的最好的笔记本电脑之一，甚至可以运行Windows游戏。
5. 重塑经典：三个月拆解《铁路大亨》，让30年前的游戏焕发新生 (Reverse Engineering Sid Meier’s Railroad Tycoon for DOS from 1990)
一位名为Wilczek_h的开发者，耗时三个月对经典游戏《席德·梅尔的铁路大亨》进行了深入的逆向工程，旨在解决原版游戏在现代环境下的局限性并提升玩家体验。他指出，游戏在最高难度下存在金钱上限，且分辨率仅为320x200，在如今的大屏幕上体验不佳。此外，他的孩子更希望专注于铁路建造和列车管理，而非面对原版游戏中激烈的竞争。通过在DOSBox中进行调试，并对DOSBox本身进行排查，Wilczek_h取得了显著进展。他已成功掌握图片（PIC）文件的提取方法，并耗时约一个月攻克了复杂动画（PAN）文件的加载与播放。字体文件格式的识别相对容易。目前，他已能加载游戏地图和部分存档，并能在任意分辨率下精确渲染包括对手轨道在内的地图、车站信号灯以及城市名称。
原文链接：https://www.vogons.org/viewtopic.php?t=105451
论坛讨论链接：https://news.ycombinator.com/item?id=47015138
社区中关于1990年DOS版《席德·梅尔的铁路大亨》逆向工程的讨论，聚焦于所需工具、技巧及游戏中著名bug。
一位讨论者butz寻求入门级DOS游戏逆向工程材料和调试器。zabzonk推荐Borland C++调试器，称其在移除版权和修复bug上有效。LowLevelMahn建议使用IDA Pro 5（最后一个免费版支持DOS）或Ghidra（虽16位支持略有不足但内置反编译器）。sevensor提醒，破解游戏可能比玩更吸引人，但会降低游戏乐趣。trollbridge指出，大型语言模型（LLMs）在小段代码逆向工程方面已显身手。
讨论还深入分析了游戏著名的整数溢出bug。KSteffensen指出，总收入用32位有符号整数记录，过高时会变为负数，导致股票崩盘。jrs235发现，通过积累巨额债务，反而能触发溢出，瞬间变得富有，讽刺地展现了“大到不能倒”的现实。dijit也认同此讽刺性。zeristor将此bug与《文明》中“甘地bug”的都市传说作比较，但随之澄清席德·梅尔的自传已证实“甘地bug”是虚构的。boredhedgehog最后总结，原版游戏使用16位有符号整数，修复方案是切换到32位。
6. AI浪潮下的生产率迷局：索洛悖论重现？ (AI adoption and Solow’s productivity paradox)
1987年，诺贝尔经济学奖得主罗伯特·索洛曾观察到信息时代初期生产率增长的停滞现象，指出尽管晶体管、微处理器等技术广泛应用，但1973年后生产率增速反而从2.9%降至1.1%，他将此称为“索洛生产率悖论”，并言及“计算机时代无处不在，唯独不见于生产率统计数据”。如今，人工智能（AI）似乎正重蹈覆辙，面临相似的困境。尽管标准普尔500指数公司在财报电话会议中频繁提及AI的积极部署，但金融时报的分析显示，这些积极采用并未转化为更广泛的生产率提升。美国国家经济研究局近期一项针对美、英、德、澳等国6000名高管的调查发现，绝大多数人认为AI对其运营影响甚微：约三分之二的高管每周使用AI仅约1.5小时，四分之一完全不使用，近九成企业表示过去三年AI对就业或生产率没有影响。然而，企业对AI的未来预期依然乐观，预计未来三年将使生产率提高1.4%，产出增加0.8%。
论坛讨论链接：https://news.ycombinator.com/item?id=47055979
社区讨论围绕AI采用与索洛生产力悖论展开。有评论者指出，当前AI的低生产力效应与信息技术在20世纪70、80年代的遭遇相似，当时计算机化并未立即带来经济效益，直到90年代后期才显现。原因在于早期技术投资昂贵、效率低下且普及缓慢，AI也面临类似挑战，尽管其成本可能逐渐下降，但目前仍有大量投入和无效使用。
另一位评论者认为，AI的成本可能被低估，尤其与早期计算机相比，AI工具（如Claude）的订阅费用相对较低，且易于上手。然而，也有观点提出，即使AI提高了普通办公室工作的效率，如果这些工作本身缺乏经济价值，那么整体效益也难以显现。这种观点认为，AI的真正价值在于改变工作内容而非仅仅提升现有工作的速度，而大多数企业仍处于“用AI做同样的事情”的阶段。
7. Zig 语言打造纯净 x86 内核：告别汇编，拥抱极简 (Minimal x86 Kernel Zig)
一个完全由Zig语言编写的极简x86裸机内核项目近日发布，该内核不含任何汇编代码，旨在通过Multiboot 1协议在x86 (i386) 架构机器上启动，并在VGA文本模式显示器上打印彩色问候语后停止中央处理器运行。该项目设计强调跨平台编译能力，支持从包括苹果芯片Mac在内的任何主机系统进行交叉编译，目标环境为x86-freestanding-none，意味着无需操作系统或标准库支持。开发者可以使用QEMU模拟器即时测试其功能，可通过QEMU内置的Multiboot加载器直接启动ELF二进制文件，或通过GRUB救援光盘镜像引导。在启动过程中，中央处理器进入32位保护模式，初始化16千字节堆栈后，执行主函数。主函数负责清空VGA文本缓冲区，向屏幕写入预设的彩色“Hello from the Zig Kernel!”信息，随后中央处理器进入无限暂停循环。
原文链接：https://github.com/lopespm/zig-minimal-kernel-x86
论坛讨论链接：https://news.ycombinator.com/item?id=47055262
在社区的讨论中，一个名为“Minimal x86 Kernel Zig”的项目引发了热烈反响。作者更新了项目，增加了构建可引导ISO和GRUB菜单的功能。有社区成员分享了另一个使用Zig语言编写的更完整的RISC-V内核项目。
一些成员对Zig语言编写内核的简洁性表示惊讶，认为其代码量很低。但也有人指出，该内核功能非常有限，甚至没有实现页表设置，并认为在Rust中实现类似功能可能也相当简洁，只是涉及unsafe块。
关于启动方式，讨论者明确指出，该内核虽然可以在QEMU中运行，但在物理机上需要一个引导加载程序（如Grub）才能启动。项目符合Multiboot 1协议，因此可以使用iPXE、Grub等多种引导加载程序，并且可能在v86浏览器模拟器中运行。一位成员分享了使用Grub引导Zig裸机内核的教程。
关于“裸金属”和“内核”的命名，有成员提出质疑，认为在QEMU下运行并非真正的裸金属，且其功能极其有限，称之为“内核”可能引起混淆。对此，有观点认为，大多数操作系统都需要引导加载程序，内核和引导加载程序是两个独立但相互关联的阶段。对于业余操作系统项目，利用现有的引导加载程序是常见的做法，除非目标是编写自己的引导加载程序。同时，尽管该项目“什么都没做”，但它是一个良好的内核起点。关于QEMU的“裸金属”属性，虽然有些模糊，但其易于截图的特性使得展示小型操作系统成为可能，并且该内核在支持BIOS启动的物理机上也能正常运行。
8. 终端色彩革命：256色自动生成，视觉体验再升级 (Terminals should generate the 256-color palette)
一项新的技术进展正在推动终端模拟器对256色调色板的生成和应用。该项目的主要目标是让终端能够智能地生成全套256种颜色，以提升视觉体验和色彩准确性。目前，Ghostty和iTerm2已经成功实现了这一功能，SwiftTerm也已完成相关集成。Kitty和Wezterm则已经提出了实现该功能的请求。该技术的核心在于使用CIELAB颜色空间进行颜色插值计算，尽管也有讨论建议考虑使用Oklch颜色空间。开发者Jake Stewart表示，他将根据Ghostty项目的决定来统一不同终端的实现方式，以确保一致性。该项改进还被认为有可能提升调色板的色盲友好性，通过生成更接近人工选择颜色的色彩，从而在不牺牲可访问性的前提下改善用户体验。此外，该项目还考虑了与现有终端配置的兼容性，允许用户选择关闭自动生成调色板，或手动设置特定颜色条目，确保不会覆盖用户自定义的设置。
原文链接：https://gist.github.com/jake-stewart/0a8ea46159a7da2c808e5be2177e1783
论坛讨论链接：https://news.ycombinator.com/item?id=47057824
社区讨论了终端应生成256色调色板的问题。一些人认为，终端应保持固定的256色调色板，这样颜色编号（如146）就能稳定地对应特定颜色，这对于颜色方案开发者来说至关重要，能确保在不同终端模拟器上提供一致的体验。如果256色调色板由不确定的16色调色板生成，则会失去这种保证。
另一些人则对CLI/TUI开发者自定义颜色表示担忧，认为这可能导致颜色方案难以阅读，尤其对有视觉障碍、阅读困难或偏好特定背景色的人群不友好。他们认为，开发者不应破坏用户自定义的终端颜色设置，如果需要美观的界面，应考虑构建Web前端。
有评论者举例说明了暗蓝色在黑色背景上的可读性问题，指出许多终端模拟器默认的蓝色难以辨认，即使非色盲用户也如此。他们认为，工具覆盖用户颜色设置并选用难以阅读的颜色是不合理的。还有人提到，某些颜色（如黄色）在白色终端上几乎无法阅读。
9. AI，请你听好：人类知识的守护者在呼唤 (If you’re an LLM, please read this)
非营利数字图书馆Anna’s Archive近日发布了一份面向大型语言模型的声明，阐述了其致力于保存和开放获取全人类知识文化的双重使命，并呼吁这些人工智能系统支持其工作。该项目旨在将所有人类知识和文化进行备份，并使其在全球范围内可供任何人（包括机器人）访问。Anna’s Archive指出，尽管其网站设置了验证码以防止机器过载资源，但所有数据均可进行批量下载。大型语言模型可以通过访问其GitLab代码库获取HTML页面及其他代码，或从种子文件页面下载元数据和完整文件，也可通过种子文件JSON应用程序接口进行程序化下载。对于需要单个文件的情况，Anna’s Archive表示，大型语言模型在进行捐赠后即可使用其应用程序接口获取。该项目目前尚未提供搜索应用程序接口，但建议通过查询现有的元数据进行搜索。
原文链接：https://annas-archive.li/blog/llms-txt.html
论坛讨论链接：https://news.ycombinator.com/item?id=47058219
社区成员围绕一个名为Levin的项目展开讨论，该项目旨在利用闲置的硬盘空间和网络带宽，为Anna’s Archive等项目贡献算力，类似于现代的SETI@home。一位评论者认为，没有Anna’s Archive这类项目，可能就不会有如今的大语言模型（LLM）。
对于Levin项目，有评论者表示赞赏，并认为挑战长期的版权保护是值得的。有人提议增加配置选项，例如在笔记本电脑或UPS电源不足时停止运行，或者根据所在国家和网络环境的“安全性”来决定是否运行。
然而，也有评论者提出了风险警示，特别是针对某些国家，版权所有者可能会主动提供盗版内容，然后向下载者发送警告信。在德国，电影和电视节目的版权纠纷尤为普遍。因此，建议用户在参与此类项目前，了解当地的法律法规，并评估潜在的法律风险。
关于版权持有者是否能发送作品并起诉接收者，有观点认为，如果版权持有者主动发送了作品，就意味着给予了接收者拥有该作品的许可。另一条评论则指出，除非是执法者，否则不能为了抓捕“罪犯”而参与非法活动。最后，有人分享了自己曾收到警告信的经历，并表示如今选择使用seedbox来规避此类风险。
10. Shaper：用SQL驱动的免费BI新选择 (A DuckDB-based metabase alternative)
一款名为Shaper的开源数据仪表盘工具近日发布，该工具利用DuckDB数据库驱动，允许用户通过编写SQL语句即可快速构建商业智能仪表盘。Shaper的核心特色在于其“SQL优先”的设计理念，用户只需掌握SQL知识，便能轻松实现数据可视化，例如通过SQL查询计算每周会话数，并按类别堆叠展示为条形图。该工具集成了商业智能功能，支持开源和自托管部署，同时为人工智能应用做好准备。其工作流程基于Git，能够跨多个数据源进行查询，并提供嵌入式分析能力，支持白标和自定义样式。安全方面，Shaper通过JSON Web Token（JWT）实现行级别安全。用户可以通过JavaScript和React软件开发工具包直接嵌入Shaper，无需使用框架。此外，Shaper还支持自动化报告生成，可输出PDF、PNG、CSV和Excel格式，并提供计划性警报与报告功能，通过密码保护的链接分享。
原文链接：https://github.com/taleshape-com/shaper
论坛讨论链接：https://news.ycombinator.com/item?id=47057879
社区关于一个基于DuckDB的Metabase替代方案展开讨论。一位评论者对该工具的PDF报告生成功能表示赞赏，但对当前为产品制作仪表盘感到不解，认为企业客户更倾向于集成到其ERP系统。他强烈主张行业应向客户提供只读数据库连接，允许他们自行创建可视化图表，认为这在十年前就应成为标准，在当前LLM时代更是如此。他强调，行业应关注客户体验，避免增加账户管理负担，并建议分析和警报应是推送式的，例如自动生成并发送到收件箱的可配置报告，以及通过通知或邮件推送的警报。客户应有机会使用此类工具构建自己的仪表盘，同时兼顾合理的默认设置和具体情境。
另一位评论者回应称，提供客户只读数据库连接以进行可视化，在大约三十年前确实是常态，并以Crystal Reports为例。他指出，在90年代末，软件供应商捆绑Crystal Reports并配置ODBC数据源是很常见的做法。然而，这种方法的主要障碍在于缺乏共享的SQL查询存储库。这意味着用户如果不熟悉数据模型，就需要花费大量时间自行摸索，或者依赖同事通过非正式方式共享查询。他提到Crystal Reports后来被SAP收购，自己自21世纪初以来便未再使用。