1. 安卓秒变电脑？谷歌自研“DeX”桌面模式曝光！ (Google is building its own DeX: First look at Android’s Desktop Mode)
安卓用户们有福啦！一直以来，三星DeX的桌面模式让Galaxy手机连接显示器后秒变电脑，体验超赞。现在，Google终于要推出官方版的“DeX”了！Android的桌面模式初探已经在Pixel手机上曝光，虽然还是早期版本，但已经让人眼前一亮。
新的桌面模式拥有任务栏，可以固定常用应用，还能显示最近使用的应用，多任务处理更方便。最酷的是，多个应用可以像在电脑上一样，以自由窗口的形式同时运行，随意调整大小和位置。这简直就是把平板电脑上的窗口模式搬到了外接显示器上，效率瞬间提升！
虽然这个功能很可能不会在Android 16中立即推出，可能要等到后续的季度更新或者Android 17才能正式亮相，但已经足够让人期待了。
原文链接：https://www.androidauthority.com/android-desktop-mode-leak-3550321/
论坛讨论链接：https://news.ycombinator.com/item?id=43973395
论坛上讨论了Android系统的桌面模式潜力与现有问题。有人对微软退出手机市场感到惋惜，认为Windows手机的“一机多用”理念很吸引人，但Android系统在商业领域的普及面临挑战，而苹果则倾向于用户购买多个设备。
另一些人认为桌面模式的关键在于与Google Linux Terminal应用的集成，这将极大地方便开发者。有人指出Chrome OS早就可以实现Linux和Android应用并排运行，但同时也存在一些问题，例如部分应用的GUI不适合触摸操作。
还有人认为Chrome OS在某些方面比Android更有优势，但Android拥有庞大的生态系统，用户和应用数量远超Chrome OS，因此谷歌选择集中发展Android是明智之举。
不少人提到在笔记本电脑上使用Android的体验不佳，类似在iPad上进行主要计算任务，希望谷歌能改进Android在桌面环境下的使用体验。有人提到Android TV在使用键盘和鼠标时的体验也很糟糕，三星的Dex模式虽然有潜力，但距离真正好用还有差距。
2. FastVLM：视觉语言模型效率飞跃，移动端部署提速！ (FastVLM: Efficient vision encoding for vision language models)
备受瞩目的CVPR 2025大会即将到来，一款名为FastVLM的创新视觉语言模型正蓄势待发！这款模型的核心优势在于其高效的视觉编码能力，能显著提升视觉语言模型的运行效率。开发者们现在就可以通过官方代码库，利用LLaVA框架训练和微调FastVLM的各种变体。
项目团队贴心地提供了详细的推理指南，包括在普通PyTorch环境以及Apple Silicon上的运行方法。针对苹果设备，还专门提供了三种预先转换好的模型，方便开发者在iPhone、iPad和Mac等设备上进行部署和测试。为了方便大家上手，官方还提供了脚本一键下载所有预训练模型。
FastVLM的出现，无疑将加速视觉语言模型在移动设备上的普及，为未来的智能应用开启更多可能性。该项目基于多个开源贡献构建，开发者在使用前请务必查阅相关许可协议。团队也热情邀请大家引用他们的论文，共同推动视觉语言领域的发展。
原文链接：https://github.com/apple/ml-fastvlm
论坛讨论链接：https://news.ycombinator.com/item?id=43968897
论坛的讨论围绕苹果可能在操作系统层面预加载小模型并提供SDK供应用调用展开。有人认为开放权重和操作系统标准的基础模型潜力巨大，特别是如果API允许开发者在运行时将自定义LoRa微调加载到这些模型上，可以兼顾应用体积和性能。
有评论指出LoRa主要用于扩散图像生成模型，在LLM上的应用不如前者。虽然可以通过f16甚至int8量化来缩小模型体积，但用户依然不希望为应用下载数百MB的模型。
随后，话题转向了应用体积过大的问题，以Uber为例，即使不包含LLM模型，其iOS版本也达到了500MB。造成这种现象的原因包括大量地理位置相关的场景编译到应用中，以及集成了各种区域支付SDK。有前Uber工程师解释了这个问题，并指出应用包含了大量第三方代码，例如各种本地支付方式的SDK。虽然可以通过OTA更新应用，但无法仅下载应用的一部分或懒加载用户可能不使用的功能。
3. Firefox 火狐浏览器官方代码库登陆 GitHub！ (Mozilla Firefox – Official GitHub repo)
Mozilla Firefox浏览器爱好者们有福啦！这款备受喜爱的开源浏览器的官方代码仓库已在GitHub上开放。拥有5.6k的star和155个fork，这个项目绝对是开源社区的焦点。
该代码库不仅包含了Firefox浏览器的完整源代码，还提供了构建和贡献代码的详细指南。无论你是想深入了解Firefox的内部结构，还是希望为其开发贡献一份力量，这里都将是你理想的起点。 Mozilla 团队还贴心地提供了包括构建说明和贡献指南的详细文档，帮助开发者快速上手。
值得一提的是，Mozilla鼓励开发者参与到Firefox的开发中来，并提供了多种沟通渠道，例如Matrix聊天频道，方便开发者们交流想法、解决问题。对于喜欢尝鲜的朋友，还可以下载Nightly版本，抢先体验最新的功能和改进。不过要注意，Nightly版本可能存在一些bug，适合有一定技术基础的用户。
项目使用多种编程语言，包括JavaScript (28.6%), C++ (28.1%)和HTML (22.0%)，以及C, Python, Kotlin 和其他语言。
原文链接：https://github.com/mozilla-firefox/firefox
论坛讨论链接：https://news.ycombinator.com/item?id=43969827
一位Mozilla员工透露，Firefox代码已从Mercurial迁移到GitHub，但Bugzilla、Phabricator和Taskcluster等工具保持不变。目前Mercurial服务器仍在同步，方便系统逐步过渡到Git。迁移的主要原因是减少Mozilla在VCS基础设施上的投入。
评论中，有人认为Mozilla不应迁移到微软拥有的闭源平台GitHub，但也有人指出Git的去中心化特性降低了这种风险，因为Mozilla仍然可以使用自己的issue tracker和项目管理软件，避免被GitHub锁定。另有评论提到Phabricator已经停止维护，询问是否有替代方案，并提到了Phorge，并指出两个fork都在互相pull修复。最后有人补充询问了关于规模上的挑战问题。
4. 英特尔CPU再曝Spectre级漏洞：分支权限注入绕过硬件防御，泄露敏感信息 (Branch Privilege Injection: Exploiting branch predictor race conditions)
安全研究人员发现了一个名为“分支权限注入”（Branch Privilege Injection，CVE-2024-45332）的新漏洞，它让针对英特尔CPU的分支目标注入攻击（Spectre-BTI）重现威力。该漏洞利用了英特尔处理器中分支预测器的竞争条件，绕过了英特尔为防御Spectre-BTI攻击而设计的eIBRS和IBPB等硬件缓解措施。研究表明，在特权切换或IBPB操作期间，分支预测器的更新可能与指令流不同步，导致预测与错误的特权模式相关联，从而泄露敏感信息。
研究人员成功利用此漏洞在开启所有默认缓解措施的Ubuntu 24.04系统上以5.6KB/s的速度泄露任意内存，并在第13代英特尔Raptor Lake处理器上进行了演示。该漏洞影响自第9代Coffee Lake Refresh以来的所有英特尔处理器，甚至可能影响到第7代Kaby Lake处理器。
英特尔已经针对受影响的处理器开发了微代码更新，经验证可以有效阻止漏洞利用。该更新在Alder Lake处理器上的性能开销约为2.7%。研究人员也评估了其他软件缓解方案，开销在1.6%到8.3%之间。相关研究论文将在USENIX Security 2025上发表，并在Black Hat USA 2025上进行演讲。攻击源代码和实验数据已在GitHub上公开。建议用户尽快安装最新的操作系统和BIOS更新，以防范此漏洞。
原文链接：https://comsec.ethz.ch/research/microarch/branch-privilege-injection/
论坛讨论链接：https://news.ycombinator.com/item?id=43974891
论坛上，大家纷纷表达了对James Mickens文章的喜爱，并引用了其中的一些经典段落，如关于处理器发展困境的比喻、Mossad获取数据的方式等。一位评论者指出，Mickens的文章可能启发了人们对寻呼机和对讲机等技术的思考。另有人则从阴谋论的角度出发，认为文章揭示了一个历时多年的巨大阴谋，并以此反驳了阴谋论中“参与人数过多，行动过于复杂”的观点。还有人提到，人们往往因为寿命有限而目光短浅，容易忘记过去发生的事情，例如冷战时期那些复杂精妙的间谍活动。一位评论者分享了文章中关于“Zubotov Gambit”的段落，并指出虽然2013年文章中的某些观点是正确的，但如今世界已经发生了变化，暗示着技术发展日新月异，人们使用计算机的方式也与过去不同。
5. 搜索引擎迎来PDF索引能力：破解文字提取难题 (PDF to Text, a challenging problem)
搜索引擎迎来重大升级！未来几个月内，它将具备索引PDF文件的强大能力。要知道，从PDF中提取文字并非易事，因为PDF本质上是一种图形格式，文字信息以“字形”和坐标映射的形式存在，排列方式复杂，缺乏语义信息。
为了让搜索引擎更好地理解PDF内容，工程师们没有采用成本高昂的GPU机器学习方案，而是在现有PDFBox的PDFTextStripper基础上进行了优化。 优化主要集中在标题和段落的识别上。通过分析字体大小的统计数据，特别是页面内字体大小的分布，能够更准确地识别标题，即便标题字体不加粗也能识别。 此外，工程师们还改进了段落识别算法，不再使用固定的行距断点，而是通过统计页面内的行距，自适应地判断段落分隔，即使在行距不规则的学术文档中也能准确识别。
虽然从PDF中完美提取文本依然具有挑战，但这些改进让搜索引擎能够更有效地提取关键信息，如标题和摘要，从而更准确地理解和索引PDF文档的内容。
原文链接：https://www.marginalia.nu/log/a_119_pdf/
论坛讨论链接：https://news.ycombinator.com/item?id=43973721
论坛上，有用户回忆起多年前曾精通PDF和OCR技术，甚至忘记了自己曾用tesseract做过很酷的项目。另一位用户分享了2006年左右，为了在iRex阅读器上复制多栏科学论文的文本，修改了poppler库，利用tesseract作者的算法推断多栏文档的阅读顺序。这个修改最终被kpdf采用，实现了多栏选择功能。
另有用户提到，当时为了在梦幻橄榄球联盟中获得优势，花费大量时间从NFL历史数据PDF中提取可用数据。很多人感叹PDF格式浪费了大量时间，并讨论了理想的替代方案应具备的特点，包括存储为单个文件、支持表格和图像、避免动画和外部链接，以及无需JavaScript。有人指出，现在的PDF已经支持动画、3D内容，甚至需要JavaScript，这与最初的设想背道而驰。还有人补充说，理想的格式应该是矢量格式，在任何操作系统上都能完美呈现，并支持所有排版需求。
6. GNU Screen惊曝多重安全漏洞，Arch Linux与NetBSD用户需紧急修复 (Multiple security issues in GNU Screen)
开源终端复用工具GNU Screen近期被发现存在多重安全漏洞，影响其最新5.0.0版本及部分4.9.1版本，尤其在配置为setuid-root的系统（如Arch Linux和NetBSD）上风险更高。2024年7月，开发团队请求安全专家审查代码，意外发现包括本地提权漏洞（CVE-2025-23395）在内的多个问题，可能允许攻击者以root权限创建或修改文件，甚至劫持终端会话窃取敏感数据。此外，新的默认伪终端权限设置（CVE-2025-46803）让任何用户可写入Screen终端，增加数据注入风险。
这些漏洞部分源于5.0.0版本的代码重构，破坏了原有安全机制。专家已发布补丁修复问题，并建议用户避免以setuid-root运行Screen，或限制多用户模式使用。披露过程因开发团队资源不足而波折，凸显开源项目维护挑战。此次事件提醒科技爱好者关注软件安全更新，及时修复漏洞以保护系统安全，展现开源社区协作的重要性。
原文链接：https://www.openwall.com/lists/oss-security/2025/05/12/1
论坛讨论链接：https://news.ycombinator.com/item?id=43971716
论坛中围绕screen的多用户模式及其安全风险展开了讨论。有人指出，screen为了实现多用户连接，采用了setuid-root配置，导致程序以root权限运行，显著增加了攻击面。这种做法源于历史原因，screen的代码库复杂且年代久远，维护者难以完全理解，使用setuid-root成为最简单的实现方式。
与tmux不同，tmux使用unix域套接字，避免了类似的安全风险。screen的设计可以追溯到1987年，那时setuid在Unix系统中很常见。现在的开发者面临更多操作系统历史和可移植性问题，以及伪终端在不同平台上的差异。此外，screen还保留了许多1980年代的理念，例如动态生成TERMCAP环境变量。总而言之，screen的安全问题是历史因素、代码复杂性和安全观念演变共同作用的结果。将类似代码移植到OpenBSD之类的系统会面临更多挑战。
7. Snobol奇遇记：用古老语言重塑Forth，吟唱啤酒之歌 (I learned Snobol and then wrote a toy Forth)
一位名叫Dave的程序员最近沉迷于古老的编程语言Snobol4，并分享了他的探索之旅。Snobol4以其独特的模式匹配功能著称，每一行代码都包含标签、主体、模式、替换和跳转五个部分，全部可选，简洁而强大。为了深入理解Snobol4，Dave决定用它来实现一个玩具版的Forth解释器，名为Snobol4th。
这个迷你Forth解释器的目标是运行一个能打印“99 Bottles of Beer”歌词的程序。最终，Dave用不到500行Snobol代码完成了这个项目，并将代码发布在代码仓库中，仓库里的解释器源码可读性良好。Dave认为，对于想要学习新语言的开发者来说，设定一个明确的目标程序是个不错的方法。这个项目是在一台MNT Pocket Reform电脑上，利用Krita绘制了可爱的老鼠和雪球图案。
原文链接：https://ratfactor.com/snobol/
论坛讨论链接：https://news.ycombinator.com/item?id=43951885
论坛的讨论围绕SNOBOL编程语言展开，一位用户回忆了SNOBOL在其计算机科学学习中的重要地位，并赞赏其优雅独特的语法、强大的模式匹配和垃圾回收机制，还提到了影响深远的《SNOBOL4》书籍以及使用SNOBOL4编写硕士论文的经历。
另有用户推荐了Griswold在SNOBOL之后设计的语言Icon，认为它平滑了SNOBOL的一些想法，并表示Icon对Python的生成器产生了启发。虽然Icon经常被提及，但有评论者认为，这低估了Icon本身的独特性和趣味性，它在基本的控制流结构上仍然有创新之处。
此外，讨论中还分享了多个与SNOBOL相关的链接，包括用SNOBOL4编写的Eliza、SPITBOL的实现、以及关于SNOBOL各个方面的讨论。有人指出SNOBOL是一种高级字符串处理语言，其模式比正则表达式更强大，但模式匹配可能需要指数级的时间，因为它是在递归空间中进行深度优先搜索。
8. 空中管制：从烽火台到雷达屏的百年演变 (Air Traffic Control)
美国空管系统长期投资不足、国防工业综合体效率低下以及管理不善等问题日益凸显，引发人们对空管系统发展历程的关注。早期航空业对空管需求不高，依赖旗帜和信号灯引导飞机着陆。一战推动了航空无线电技术的发展，军方开始利用无线电协调侦察机的航线，奠定了地勤人员跟踪飞机并提供信息的基础。
20世纪20年代，商业航空公司开始使用无线电进行调度协调，并逐步形成了天气简报、飞行计划等现代惯例。美国邮政署运营着当时全球最大的航空业务——航空邮件，为航空业发展提供了资金和动力。航空邮件航线比客运航线更具挑战性，促进了导航技术的发展。邮政署建立了航空邮件无线电台，提供飞行员信息和天气报告，是美国国家空域系统的前身。
1926年，商业部航空局成立，负责维护航空邮件航线，航空邮件无线电台也随之更名为飞行服务站，为飞行员提供政府服务。1935年，首个航路空管中心在纽瓦克成立，利用无线电通信和文件跟踪飞机。二战期间，雷达技术的出现彻底改变了空防，英国发明的雷达技术被应用于地面控制拦截系统，显著提升了空防能力。二战后，民航迅速发展，空管中心开始采用地面控制拦截技术，并安装了空中监视雷达。然而，随着航班数量的增加，空管系统面临巨大挑战。1956年，两起重大空难事故促使美国成立联邦航空管理局（FAA），统一管理军用和民用航空，并加大对空域系统的投资。冷战时期，美国空军研发了半自动地面环境系统（SAGE），但未被用于空管。FAA随后启动了自己的自动化项目，购买了基于SAGE的新系统，以应对日益增长的空管需求。如今，美国空管系统仍在不断发展，以适应现代航空业的需求。
原文链接：https://computer.rip/2025-05-11-air-traffic-control.html
论坛讨论链接：https://news.ycombinator.com/item?id=43958562
论坛的讨论围绕国际空中交通管制如何运作展开。一位用户好奇不同国家空中交通管制的演变以及国际航班系统如何在国家之间交接，尤其是在欧洲和加勒比地区。
有用户解释，飞行员提交飞行计划，途经的每个国家都会知晓。飞行员根据飞行规则和高度与飞行情报服务部门或区域管制中心通信，并在接近国界时进行交接，告知身份和目的地，对方可允许按计划飞行或更改航线。也有人提到飞行计划通常通过航空固定电信网络（AFTN）传输。
关于前互联网时代的飞行计划备案，用户提到当时填写标准表格，通过传真发送给相关方。
另有用户指出，一战后，凡尔赛条约促成了国际空中航行委员会（ICAN）的成立，建立了首个航空交通监管框架。欧洲空中航行安全组织（Eurocontrol）是欧洲国家间管制员合作的成功案例，管理比利时、卢森堡、荷兰和德国西北部上空空域。国际民用航空组织（ICAO）也为此存在。
还有用户分享了二战时期利用无线电进行空中支援的例子，地面部队通过无线电提供坐标，台风战斗机对目标实施攻击。前进空中管制会从步兵那里获得目标的地图网格或其他描述，然后派遣飞机前往目标。