告别YouTube短视频:uBlock插件一键屏蔽Shorts,还你 | Hacker News 摘要 (2026-02-16)

1.告别YouTube短视频：uBlock插件一键屏蔽Shorts，还你清爽观影体验 (uBlock filter list to hide all YouTube Shorts)

一个由独立开发者维护的开源项目近期推出了一份uBlock Origin过滤器列表，旨在帮助用户彻底隐藏YouTube平台上的所有Shorts短视频内容。该列表最初由gijsdev创建，现已由i5heu接手并持续更新与维护。用户可以通过简单的步骤将该过滤器列表导入到其uBlock Origin浏览器扩展中，具体操作为访问uBlock Origin仪表板的“过滤器列表”部分，在“导入”选项下粘贴提供给定的链接即可启用此功能。除了隐藏Shorts，该项目还额外提供了一份独立的过滤器列表，允许用户选择性地隐藏YouTube视频下方的评论区，以进一步优化观看体验。该项目明确声明，其作为一项独立的开源倡议，与Alphabet公司、Google或YouTube平台没有任何形式的关联、认可、赞助或合作关系，完全基于社区力量运行，致力于为用户提供更纯粹、个性化的YouTube浏览环境。

原文链接：https://github.com/i5heu/ublock-hide-yt-shorts/

论坛讨论链接：https://news.ycombinator.com/item?id=47016443

社区成员们热烈讨论如何屏蔽YouTube Shorts，以改善观看体验。一种方法是利用uBlock Origin的重定向规则，将 Shorts 的 URL 转换为经典视频播放器的 URL，例如将 /shorts/XYWZ 重定向到 /watch?v=XYWZ 或 /v/XYWZ。一位用户建议，通过“添加到播放列表”功能也能在经典播放器中观看 Shorts，且不受 Shorts 界面干扰。

也有用户选择使用第三方应用如 Revanced 或 FreeTube 来完全禁用 Shorts，认为 YouTube 本身在浏览器上的体验已变得糟糕。另一位用户则采取了最简单的方式——“从不点击 Shorts”，但有人指出，Shorts 经常穿插在搜索结果中，难以避免误触。

为了更灵活地控制，一些人推荐使用 Redirector 浏览器扩展，它可以实现更复杂的 URL 重定向。还有用户分享了用于 Firefox 的特定 Shorts 屏蔽插件以及一个可以取消 Shorts 格式的 bookmarklet。不过，有用户提到某些方法可能会导致页面刷新，影响浏览历史的连续性。

2.告别Visual Studio依赖：Windows原生开发痛点终结者 (I fixed Windows native development)

在Windows原生项目开发中，将Visual Studio列为构建依赖已成为一个普遍而令人头痛的问题。开发者发现自己不仅要维护代码，还要充当微软Visual Studio安装程序的“非付费技术支持”。不同于Linux上通过包管理器轻松获取工具链，Visual Studio是一个庞大的集成开发环境，包含数千个组件，其安装过程复杂冗长。用户需在复杂的图形界面安装器中手动选择特定的“工作负载”、构建工具和软件开发工具包，任何错误选择都可能导致数小时的安装浪费或后续的神秘构建失败，例如因缺少特定版本的Windows软件开发工具包或Spectre漏洞缓解库而报错。这种做法模糊了代码编辑器、编译器和软件开发工具包之间的界限，形成一个纠缠不清的整体。

原文链接：https://marler8997.github.io/blog/fixed-windows/

论坛讨论链接：https://news.ycombinator.com/item?id=47022891

社区上关于“我修复了Windows原生开发”的讨论，主要围绕着Visual Studio构建工具及其LTSC（长期服务通道）版本展开。

一位评论者指出，原生开发无需复杂化，只需安装LTSC Visual Studio构建工具，配合命令行和VIM即可。他强调LTSC和稳定版的存在，但鲜为人知，对企业协作至关重要。另一位用户则补充道，LTSC通道通常需要Visual Studio Professional或更高版本许可，导致业余开发者和学生对此不甚了解，但在公司环境中则广为人知。

关于许可问题，有用户声称LTSC工具链本身可无许可安装，但IDE不行。然而，此说法很快被纠正，明确指出即使是构建工具也需要相应的Visual Studio许可（业余爱好者和初创企业用社区版，大公司则需专业版），并提到微软对许可执行的严格程度是另一个问题。还有人补充说，构建工具可通过winget安装，但用于商业用途仍需专业版以上许可。

讨论还触及了Visual Studio LTSC的发布周期。当有用户询问Visual Studio 2026的LTSC发布计划时，得到解释称微软已彻底调整发布策略。2026 LTSC将在2026初始版发布一年后（与VS 2027同期）推出，并额外支持一年。这意味着用户需适应IDE的滚动更新，而C++工具链则采用独立计划，允许多版本并存。对此，有用户质疑在新微软世界中，“长期”支持的定义是否已缩短为一到两年。

3.亚马逊Ring“寻犬”：美国监控国家的“温情”陷阱 (Amazon’s Ring and Google’s Nest reveal the severity of U.S. surveillance state)

近期，美国公众对隐私泄露的担忧因两起事件而再度升温。首先，在超级碗比赛期间，亚马逊为其Ring智能门铃摄像头播放了一则广告，宣传其名为“寻犬启事”的新功能。该功能允许用户上传丢失宠物的照片，然后利用邻近的Ring摄像头网络和人工智能技术扫描并识别宠物。虽然广告以感人的家庭团聚场景打动观众，但其展示的技术能力却引发了广泛的震惊和警觉。许多用户此前认为Ring摄像头仅用于家庭安防，却未曾料到它能与成千上万的摄像头连接，形成一个覆盖社区甚至城市的监控网络。尽管亚马逊强调此功能需要用户“选择加入”，但隐私倡导组织电子前线基金会（EFF）对此表示强烈谴责，认为这预示着一个“生物识别身份识别技术可以从消费设备中释放，用于识别、追踪和定位任何事物——人类、宠物或其他”的未来。大量用户因担忧隐私问题而拆除或销毁了他们的Ring摄像头。

原文链接：https://greenwald.substack.com/p/amazons-ring-and-googles-nest-unwittingly

论坛讨论链接：https://news.ycombinator.com/item?id=47023238

社区关于美国监控现状的讨论，主要围绕个人隐私与国家安全之间的权衡展开。有评论者引用了帕特里克·亨利的名言“不自由，毋宁死”，强调美国建国理念中对自由的重视，认为即使放弃部分公民自由能带来便利，也并非值得的交易。

另有评论者指出，安全与自由的权衡往往是虚假的承诺，可能会在失去自由的同时一无所获。更有观点引用本杰明·富兰克林的话，强调“暂时安全”的短暂性，认为为了微小的、临时的安全而放弃的自由是巨大且永久的损失。

然而，也有评论者对富兰克林引言的原始语境提出质疑，认为其并非如普遍理解的那样，而是为维护立法机构的治理权，反对富人家族通过贿赂来逃避税收。这一观点认为，引言的本意是立法者不应放弃对强大势力征税的自由，以换取暂时的军事安全。

此外，讨论中也提及《爱国者法案》被视为一个例子，即为了“暂时的安全”而付出了代价，但并未带来预期的效果。整体而言，社区成员对国家过度监控的担忧，以及对自由与安全之间平衡的深刻反思贯穿其中。

4.Instagram“黑洞”曝光：数千恶意链接筑起反诈防火墙 (Instagram’s URL Blackhole)

一位研究员在分析越狱版iPhone上的Instagram应用程序数据时，意外发现了一个名为“url_blackhole”的内部数据库。该数据库包含了多达4629个被Instagram系统识别为恶意或可疑的统一资源定位符（URL）片段。这些URL主要被归类为四种违规类型，其中绝大多数（4370个）与网络安全钓鱼（尤其是可能由外国行为者发起）有关，另有239个涉及灰色软件或间谍软件。这一发现表明Instagram积极维护着一个庞大的恶意链接黑名单，以保护用户。当用户在Instagram应用内尝试访问这些URL时，应用会主动弹出多重警告信息，有效阻止进一步访问。对这些恶意URL的域名分析显示，最常被利用的顶级域名是推特（现为X）的URL缩短服务t.co，其后是tinyurl.com、is.gd等常见的URL缩短或重定向服务，这表明攻击者倾向于使用缩短链接来掩盖真实目的地。

原文链接：https://medium.com/@shredlife/instagrams-url-blackhole-c1733e081664

论坛讨论链接：https://news.ycombinator.com/item?id=47004689

社区对一篇关于“Instagram的URL黑洞”的文章展开了讨论。多位评论者赞扬了文章的简洁和新颖，摆脱了常见冗长论述的疲劳感，甚至对文章的突然结束也感到耳目一新。然而，也有人提到Medium平台的付费墙和SEO垃圾信息问题，导致一些用户选择屏蔽该网站。

在技术层面，有评论者指出Instagram使用“storage.googleapis.com”可能因为这是一个“权威”域名，应用难以轻易禁用。这种方法可以托管带有客户端重定向的静态网站，使应用几乎不可能实时禁止某项推广活动。另有用户补充说，俄罗斯被封锁的VPN和新闻网站也利用此技术来镜像内容或重定向。

关于文章中提到的“CYBERSECURITYPHISHINGFOA”，一位评论者推测“FOA”更可能指Meta旗下的“应用家族”（Family of Apps），而非“外国来源行为者”。

讨论中还出现关于苹果App Store允许“手机杀毒”应用存在的争议。有人认为这很讽刺，并猜测苹果之所以允许，是因为这些应用通过内购为苹果带来巨额收入。这种观点被反驳，认为苹果更看重声誉，认为恶意软件造成的损害远超其可能带来的微薄收入，并推测此类应用是审查疏漏所致。也有评论指出，App Store让用户误以为所有下载内容都安全，但实际上苹果的审查流程存在缺陷，用户需更加谨慎。

5.古埃及“钻木取火”工具：改写工具史的5300年前发现 (5,300-year-old ‘bow drill’ rewrites story of ancient Egyptian tools)

英国纽卡斯尔大学和维也纳美术学院的研究人员重新审视了一件一个世纪前在埃及上巴达里墓地出土的铜合金小物件，并最终认定，这件可追溯至前王朝时期（公元前4千年末期）、早于首批法老统治之前的文物，是迄今发现的古埃及最早的旋转金属钻。该物件（剑桥大学考古与人类学博物馆编号1924.948 A）发现于3932号墓穴，长仅63毫米，重约1.5克。1920年代首次发表时，它被简要描述为“一柄缠有皮革带的铜制小锥子”，此后数十年未受重视。然而，通过放大观察，研究人员发现该工具展现出与钻孔活动相符的独特磨损痕迹：细微的划痕、圆润的边缘以及工作端的轻微弧度，所有这些特征都指向旋转运动而非简单的穿刺。研究还描述了六圈极其脆弱的皮革带，研究人员认为这是用于驱动弓钻的弓弦残骸，弓钻是一种古老的手钻，通过弓弦反复拉动缠绕在钻杆上的绳索，使钻头快速旋转。

原文链接：https://www.ncl.ac.uk/press/articles/latest/2026/02/ancientegyptiandrillbit/

论坛讨论链接：https://news.ycombinator.com/item?id=46970733

社区的讨论围绕一项5300年前“弓钻”的发现展开，重新审视了古埃及工具的故事。

一位评论者指出，考古学需要多学科方法，不应只关注历史和语言，而应融入工程学、化学和实用技术。他认为，公众常将祖先视为“原始人”，正是因为我们忽视了他们许多已失传或未完全理解的技术。另一位评论者对此表示赞同，强调过去的人们拥有与现代人完全相同的心智和能力，绝非劣等或“原始”，这种偏见源于历史理解中的“时代偏见”。

有评论者推荐了Clickspring的YouTube频道，其中展示了类似工具的复原过程，用于制作安提基特拉机械。另一位补充道，尽管Clickspring的方法并非“已证明”，但在当时技术条件下非常可信。他指出，考古学中的许多推断步骤虽然看似明显，但要获得物理证据来证明却异常困难。

此外，一位评论者描述了印度木匠和制作酥油时使用的类似钻孔技术：一人通过前后拉动缠绕在大型主轴上的绳索来旋转钻头，另一人则固定钻头。这一描述引发了对“总是”这一时间限定词的质疑，但该评论者随后澄清他指的是他所熟悉的通用机械旋转技术，而非特定历史时期。

6.Oat：小身材，大能量——零依赖语义化UI库，极速构建你的Web应用 (Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library)

追求极简开发的开发者们迎来了福音：全新超轻量级 UI 库 Oat 正式发布。这款库以“语义化、极简、零依赖”为核心理念，总体积仅约 8KB（CSS 6KB，JS 2.2KB），却能提供构建现代 Web 应用所需的核心组件。

与市面上动辄陷入“依赖地狱”的重型框架不同，Oat 彻底摒弃了复杂的 Node.js 生态和构建流程。它直接对原生 HTML 标签进行样式封装，无需添加繁琐的 Class 类名，通过强制使用语义化标签和 ARIA 角色，在保证代码纯净的同时，天然支持无障碍访问。

开发者只需引入轻量的 CSS 和 JS 文件即可快速上手，并能通过 CSS 变量轻松定制主题，甚至内置了一键切换暗黑模式的功能。Oat 的诞生源于对过度工程化的反思，其视觉风格致敬了流行的 shadcn 审美，旨在为追求长期稳定、回归标准的科技爱好者提供一个“清爽如燕麦”的开发选择。

原文链接：https://oat.ink/

论坛讨论链接：https://news.ycombinator.com/item?id=47021980

社区成员对Oat UI库的讨论集中在其设计理念、性能表现以及与现有技术栈的对比。

一些评论者赞赏Oat在语义化HTML、无类CSS以及利用ARIA属性实现样式反馈方面的努力，认为这是一种鼓励开发者“先考虑ARIA”的良好实践。特别值得称赞的是其内置的侧边栏，这在许多UI库中是缺失的，且其实现方式简洁，符合语义化原则。

Oat的极速加载性能也给用户留下了深刻印象，有人表示几乎忘记了网页加载可以如此之快，甚至激发了他们学习前端开发的兴趣。有评论提到Astro也具备类似的快速加载特性，并解释了Astro的优势在于自动预渲染和不包含运行时，与React不同，后者会额外加载运行时。

另有评论者认为Oat提供了DaisyUI未能实现的简洁性，并认为将其与Datastar结合，能够构建依赖于原生Web标准而非特定“生态系统”的强大应用。

此外，Oat的配套博客文章也引发了讨论，有评论者认为该文章比框架本身更能激发有趣的思考，表达了对当前JavaScript生态系统中复杂性的认同，并指出该文章的内容依然具有时效性。

7.Zvec：闪电般的进程内向量数据库，应用即享 (Zvec: A lightweight, fast, in-process vector database)

Zvec是一款开源的、进程内向量数据库，以其轻量级、极速的特性，能够直接嵌入应用程序。该数据库基于阿里巴巴经过实战检验的向量搜索引擎Proxima构建，提供了生产级别的低延迟、可扩展的相似性搜索能力，且配置过程极为简便。Zvec的突出优势包括：搜索速度极快，能在毫秒级内处理数十亿向量；安装简单，即装即用，无需服务器配置，省去繁琐步骤；支持密集型和稀疏型向量，并原生支持单次调用进行多向量查询；能够结合结构化过滤器实现混合搜索，确保结果的精确性；作为进程内库，Zvec可运行于任何代码环境，包括笔记本、服务器、命令行工具甚至边缘设备。Zvec提供Python和Node.js的安装方式，支持Linux和macOS平台。该项目团队也欢迎社区贡献，并提供了详细的构建指南和使用示例。其卓越的性能使其成为高要求生产环境的理想选择。

原文链接：https://github.com/alibaba/zvec

论坛讨论链接：https://news.ycombinator.com/item?id=47000535

社区讨论围绕着一个名为 Zvec 的新型内存向量数据库展开。有评论者对其宣称的 7 倍于 Pinecone 的查询每秒（QPS）性能表示怀疑，并呼吁进行独立验证。另一位评论者则认为，在更大型的数据集和服务器上，100K QPS 并非难事，并指出通过利用 CPU 缓存和 SIMD 指令是提升性能的关键，同时提到他们自己使用的 SimSIMD 项目将支持更多定制内核。

Zvec 的作者对此回应，解释了在特定测试环境（1000 万条数据，768 维）下，他们实现的 8K QPS 已经超越了之前的领先者，并表示欢迎 USearch 参与第三方基准测试。作者还透露，Zvec 的性能提升得益于预取、SIMD 和一种新颖的批量距离计算方法，并承诺将在春节后发布详细的技术博客。他们也欢迎社区进行独立验证，并通过 GitHub 或 Discord 提供技术支持。

8.Flashpoint档案：20万网络游戏动画的数字方舟 (Flashpoint Archive – Over 200k web games and animations preserved)

Flashpoint Archive是一个由社区驱动的非营利项目，致力于保存网络游戏和动画，以应对互联网历史和文化因技术快速迭代而面临的流失风险。该项目认识到，当前普遍存在的网络内容可能在未来迅速过时，因此致力于尽可能多地保存这些平台上的体验，以防它们随时间消逝。自2017年12月启动以来，Flashpoint Archive已成功保存了超过20万款游戏和动画，涵盖了上百种浏览器插件和网络技术。除了这些保存工作，该项目还提供了一个高度灵活的软件包，用于可靠地导航和播放已保存的内容。支持Flashpoint的软件包括一个功能齐全的启动器，作为内容集的集成前端；一个代理服务器，能让游戏误以为仍在实时网络上运行；以及一个沙盒环境，用于安全播放依赖插件的内容，所有这些软件都是开源的。该项目最初由BlueMaxima发起，旨在赶在Flash技术消亡前抢救网络游戏。

原文链接：https://flashpointarchive.org

论坛讨论链接：https://news.ycombinator.com/item?id=47021354

社区讨论围绕Flashpoint Archive项目展开，该项目致力于保存超过20万款网络游戏和动画。

一位评论者对Ruffle项目表示赞赏，但指出其在支持AS3的NetConnection类方面存在不足，特别是.connect()调用。这使得许多依赖于多玩家功能或通过AMFPHP等方式传输数据的单人游戏难以重现。

Ruffle项目的维护者解释说，虽然浏览器环境无法直接支持套接字连接，但已在桌面版播放器中实现大部分NetConnection API。他们还通过WebSockets实现了浏览器端的套接字模拟，建议通过WebSockify代理服务器来解决连接问题，而无需修改游戏服务器代码。

原评论者进一步澄清，其遇到的问题并非源于套接字，而是NetConnection.connect()用于常规API调用，以HTTP方式传输AMF消息，而非直接套接字连接。他认为，若Ruffle能支持这种RESTful风格的NetConnection连接和调用，将有助于其旧游戏的运行。

另一位Ruffle开发者则指出，AMF序列化/反序列化在Ruffle中确实存在一些已知问题，这可能是导致上述游戏无法运行的原因，并提供了相关的GitHub问题链接供参考。

9.欧盟禁令：未售服装不得销毁，走向循环经济 (EU bans the destruction of unsold apparel, clothing, accessories and footwear)

欧盟委员会于2月9日通过了新的可持续产品生态设计法规，旨在禁止销毁未售出的服装、配饰和鞋类，以减少浪费、降低环境损害并为采纳可持续商业模式的企业创造公平竞争环境，从而促进循环经济。据估计，欧洲每年有4-9%的未售出纺织品在未被穿着的情况下被销毁，产生的二氧化碳排放量接近瑞典2021年总净排放量。为解决这一问题，该法规要求企业披露其丢弃的未售出消费品信息，并禁止销毁未售出的服装、配饰和鞋类。通过的授权和实施法案将通过明确销毁的例外情况（如出于安全原因或产品损坏）以及提供标准化的信息披露格式来帮助企业合规。企业被鼓励通过转售、再制造、捐赠或再利用等方式更有效地管理库存。禁止销毁未售出商品以及相关的例外规定将从2026年7月19日起适用于大型企业，中型企业预计将在2030年跟进。信息披露规则目前已适用于大型企业，并将于2030年扩展至中型企业。

原文链接：https://environment.ec.europa.eu/news/new-eu-rules-stop-destruction-unsold-clothes-and-shoes-2026-02-09_en

论坛讨论链接：https://news.ycombinator.com/item?id=47025378

社区对欧盟禁止销毁未售服装的禁令讨论热烈，观点多元。有评论员认为这是一项积极政策，指出现代生产技术能更精准预测需求并实现小批量生产，有助于解决微塑料污染、极端天气、粮食减产及物价上涨等严峻环境问题。

然而，另有评论者预测该法律将被规避。制造商或将未售衣物转售给非洲或亚洲等法治薄弱国家的“转售”公司，由其销毁并谎报已售出。此举不仅增加不必要的运输和碳排放，还可能通过复杂的文书和潜在腐败，阻碍小型企业与大型品牌竞争。

对此，有声音反驳称，制造商不会为处理废弃物付费，反而有强大经济动力避免过量生产或低价出售。但也有评论者指出，西方国家长期以来一直向他国支付费用处理“回收物”，直至近期中国出台限制，表明将废弃物转移国外并非新鲜事，且衣物可能比塑料垃圾更有价值。最终，一些评论者悲观地认为，欧盟的规定可能无法达到预期效果，甚至因增加运输环节和环境成本而适得其反，仅让制造商获得“帮助穷人”的公关利益。

10.ArchWiki：开源世界的明珠，致敬默默奉献的维护者 (I love the work of the ArchWiki maintainers)

在2026年“我爱自由软件日”之际，自由软件基金会欧洲分部（FSFE）主席马蒂亚斯·基施纳撰文，特别感谢ArchWiki的维护者们，并指出自由软件文档维护者们的贡献往往被低估。他强调，ArchWiki是一个宝贵资源，无论是针对Arch Linux还是其他自由软件发行版，他本人及身边许多人都会定期查阅。该维基帮助用户深入理解日常使用的工具如电子邮件程序、编辑器和各种窗口管理器，并发现难以在软件自带文档中找到的便捷功能和配置技巧。基施纳表示，每当他或亲友在设置GNU/Linux发行版时遇到问题，或者想更好地理解某款软件时，ArchWiki通常是首选的参考页面。他引用爱德华·斯诺登的话，称当前搜索结果质量普遍下降，而ArchWiki是少数能提供有用信息的“互联网明珠”之一。

原文链接：https://k7r.eu/i-love-the-work-of-the-archwiki-maintainers/

论坛讨论链接：https://news.ycombinator.com/item?id=47020191

在社区的讨论中，许多用户对Arch Wiki的维护者表达了赞赏，认为其信息丰富且极具实用性。有观点指出，Arch Wiki的内容因其紧跟上游项目而具有跨发行版的普适性，甚至被认为是早期Gentoo Wiki的继承者。

讨论者们回顾了Gentoo Wiki曾是早期Linux社区的知识宝库，但随着时间的推移，Arch Wiki逐渐崭露头角并超越了它。有人认为，Gentoo Wiki在一次安全事件后未能完全恢复，而Arch Wiki则在此期间吸收了大量知识并迅速发展。

此外，有用户提到Arch Wiki的详尽程度有时甚至超过了man pages，它能够解释开发者们认为理所当然但对新手而言晦涩的知识点。相较于man pages侧重于已知操作但忘记具体参数的场景，Arch Wiki更侧重于帮助用户理解工具的工作原理，对于有一定基础的用户来说，其信息量和易懂性更胜一筹。Arch Wiki的易于修改和即时发布特性，也使其能够更快地包含实际使用中的例子和解决方案，这与需要等待上游项目采纳的man pages形成对比。

近期，有人注意到NixOS Wiki也在逐渐补充Arch Wiki的内容，因为NixOS的特性经常会遇到新的软件边缘情况，需要深入研究并记录解决方案。