将老旧的 Windows 9x/XP 时代电脑连接至现代安全的 Wi-Fi 网络难度极大，因为这些系统仅支持 WEP 等过时的安全标准。虽然使用以太网连接是可行的替代方案，但并非随时可用。
作者提出了一种简单有效的权宜之计：使用安卓手机作为桥接器。通过 USB-C 转以太网适配器将安卓手机连接到老式电脑，并在手机设置中开启“以太网共享”功能，电脑便可通过手机的 Wi-Fi 连接访问互联网。只要电脑设置为通过 DHCP 获取 IP 地址，手机就会自动完成桥接。这种方法既能避免降低网络安全性，又适用于任何带有以太网接口的电脑。尽管在物理连接上稍显繁琐，但这对于复古电脑爱好者来说是一个极具实用性的解决方案。
每日HackerNews RSS
这篇 Hacker News 帖子讨论了将旧式计算机连接到互联网的方法，起因是一篇关于使用 Android 以太网共享网络（Ethernet tethering）的文章。
讨论的主要内容包括：
* **连接替代方案：** 用户提出了网络共享之外的替代方案，例如使用专用的 WiFi 转以太网桥接器、USB WiFi 适配器（前提是旧系统支持），或者使用树莓派（Raspberry Pi）或迷你电脑搭建 WiFi 网桥。
* **硬件现代化：** 对于老式笔记本电脑（如经典款 ThinkPad），评论者建议通过修补 BIOS 来安装现代 WiFi 网卡。其他人则强调了现代 Auto MDI-X 支持的益处，这免去了以往需要特制交叉网线的麻烦。
* **旧硬件的再利用：** 参与者分享了赋予旧硬件新生命的成功案例。例如，在十年前的机器上安装轻量级的现代 Linux 发行版（如 Debian），将其作为高性能家用服务器或专用工作站。
* **对技术标准的思考：** 帖子中还包含了一些关于网络和接口标准演变的怀旧讨论，将现代 USB-C 和 Auto MDI-X 的便捷性与过去在 USB 插拔方向和手动配置网线时所经历的挫败感进行了对比。
科学家破解了烟草如何产生尼古丁这一两百年来的谜题。 Scientists solve 200-year-old puzzle of how tobacco plants make nicotine
1 小时前
请启用 JavaScript 和 Cookie 以继续。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
科学家解开 200 年谜题：烟草植物如何制造尼古丁 (york.ac.uk)
19 点，由 sohkamyung 发布于 3 小时前 | 隐藏 | 过往 | 收藏 | 2 条评论 | 帮助
x______________ 27 分钟前 | 下一条 [–]
你可能会更喜欢原始论文[0]，这篇简化后的文章实在是……太简单了。[0] https://www.nature.com/articles/s41467-026-72705-0
回复
hyrix 27 分钟前 | 上一条 [–]
与 https://phys.org/news/2026-04-tobacco-psychedelics-psilocybi... 搭配阅读效果更佳！
回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 加入 YC | 联系
搜索：
80 多年来，航空工程一直依赖于一种前提：光滑的表面对于维持层流以最大限度地减少空气动力阻力至关重要。然而，日本东北大学的研究人员通过证明特定的微小表面不规则结构实际上可以延迟向湍流的过渡，挑战了这一教条。 在副教授矢野爱子的带领下，该团队利用磁悬浮平衡系统（MSBS）悬浮测试模型，消除了由传统支撑杆引起的空气流干扰。这种精确度使他们发现，“分布式微粗糙度”（DMR）——即肉眼无法察觉的不规则结构——可以将空气动力阻力降低高达 43.6%。 与使用结构化凹槽来控制湍流的“鲨鱼皮”方法不同，DMR 的作用机制是主动延迟从层流到湍流的过渡。这一突破代表了空气动力学设计的根本性转变，表明违反直觉的表面纹理可以显著提高高速车辆和飞机的能源效率。
《连线》（Wired）杂志近期刊登的一篇文章声称推翻了航空工程的一项基本原理，在 Hacker News 上引发了热议。讨论的核心围绕“分布式微粗糙度”（DMR）技术展开，该技术利用微观表面不规则结构（38–53 μm）将空气阻力降低了高达 43.6%。
评论者们就这是否真正挑战了现有物理学展开了辩论。尽管有人将该效应比作高尔夫球凹槽或仿生鲨鱼皮“细流”图案所带来的众所周知的减阻特性，但该研究的支持者澄清称，DMR 的运作原理截然不同。与对齐涡流的沟槽结构（riblets）不同，DMR 似乎能延迟从层流到湍流的转变。
尽管人们对该文耸人听闻的标题仍存怀疑，但这项研究强调，这些亚毫米级的不规则结构在流体力学中从技术上被归类为“光滑”表面，却能带来显著的性能提升。普遍共识认为，即便这一发现并未真正“推翻”物理定律，它依然是一项重大的工程进步。
请提供您想要翻译的内容。
**Audiomass** 是一款全新的免费开源网页版多轨音频编辑器。该项目近期在 Hacker News 上分享后，因其简洁且扎实的设计风格受到赞誉，令人联想到 Audacity。
开发者 *pantelisk* 强调致力于保持工具的轻量化，目前其 JS 文件仅 98kb，CSS 文件仅 10kb。尽管用户提出了诸如 XM 格式支持和分轨导入等功能需求，但开发者对文件臃肿问题仍持谨慎态度。
目前，用户可以通过侧边栏界面添加无限数量的轨道。虽然该工具现阶段依赖基于 DOM 的波形渲染，但随着轨道数量的增加，开发者正在考虑未来转向 WebGPU 以提升性能。该项目已获得社区的良好反响，讨论甚至涉及了开发类似 Renoise 的网页版音频追踪器的潜力。
AlphaPixel 恢复了“LAN-LOK”，这是一款 1991 年的罕见 DOS 游戏，由南极帕尔默站的研究人员 Mark Chappell 和 Shane Maloney 开发。该游戏开发于该站首次部署点对点网络期间，是一部以“绞刑架幽默”风格讽刺早期系统管理的幽默作品。
游戏玩法是一种竞争性的“破坏与修复”循环：玩家扮演一名试图破坏网络节点的破坏者，而一个以现实生活中的 IT 员工 Al Oxton 为原型的 AI 角色则会竞相修复损坏。在机制上，它反映了那个时代的挫败感，例如打印机卡纸和意外命令行错误带来的噩梦。
该游戏三十年来一直鲜为人知，仅在帕尔默站和麦克默多站之间的“运动鞋网络”（SneakerNet，指通过物理介质传输数据）中传播。AlphaPixel 的创始人最近重新发现了该可执行文件，并与原始创作者及游戏反派的现实原型核实了其历史。现在，通过 DOSBox 即可运行该游戏，它已成为南极生活的一件独特数字文物。AlphaPixel 计划利用这个副项目探索现代人工智能辅助的反编译和现代化技术，以展示他们为客户处理复杂、真实的遗留代码恢复工作时所运用的技术能力。
抱歉。
本文探讨了一个大胆的观点：我们的物理现实并非一个客观、独立的“舞台”，而是一个由大脑呈现的生物界面——本质上就像一场多人游戏。 作者结合认知科学、量子力学和哲学，提出以下论点： 1. **感知即翻译：** 大脑看到的并非“真相”，而是创建了一个实用的用户界面。就像电脑图标一样，我们的感官输入将原始数据转化为有助于生存的格式，而非反映现实的本来面目。 2. **共识与同步：** 我们之所以能感知到一个稳定的世界，是因为我们拥有相同的“硬件”（人类生物学）和集体共识（共享的虚构），这使环境趋于稳定。现实之所以在我们不观察时依然保持一致，是因为它由量子退相干和观察者组成的集体网络所维持。 3. **共同创造：** 虽然我们没有打破物理定律的“管理员权限”，但我们可以影响自己的轨迹。通过将明确的意图与高频情绪结合，我们可以重塑网状激活系统（RAS），从而筛选出新的机遇。 总之，我们并非固定世界中的被动旁观者，而是可塑共享现实中的积极参与者；这表明宇宙远比我们传统认为的更具参与性，也更赋予人力量。
提供的 Hacker News 讨论帖探讨了一篇题为《为什么物理现实是一种集体建构》的文章。社区对此反应极其负面，认为该文是伪科学，论证拙劣且存在哲学缺陷。
评论者指出，作者混淆了由光子和原子构成的客观物理现实与人类对该现实的主观感知。多位用户质疑文章的核心论点，即“大脑是翻译而非感知世界”，并批评这种说法是陈旧且低水平的臆测。另一些用户认为，该文只是试图将辩证唯物主义或经典的哲学争论“重新包装”，却未提供任何独到见解。此外，网站设计的不友好也进一步削弱了文章的可信度。总体而言，参与者的共识是该文缺乏科学严谨性，未能区分生物感官处理过程与独立物质世界的存在。
为了防止未经授权的用户在安全密钥上发现凭据，开发人员可以使用 **CTAP 2.1 `credentialProtectionPolicy` 扩展**。 标准的 WebAuthn 凭据通常可以通过物理持有安全密钥来发现。此扩展允许依赖方（Relying Parties）在创建凭据时强制执行更高的安全要求： * **`userVerificationOptional`**：默认设置；允许在无需验证的情况下发现凭据。 * **`userVerificationOptionalWithCredentialIDList`**：除非提供特定的凭据 ID，否则在发现凭据时需要进行用户验证。 * **`userVerificationRequired`**：强制要求在发现和使用凭据时均进行用户验证。 `enforceCredentialProtectionPolicy` 标志可确保如果验证器不支持这些策略，操作将失败；不过，这通常应仅限于漫游验证器（roaming authenticators）。 各浏览器的支持情况有所不同；Chrome 和 Firefox 支持这些扩展，而 Safari 会忽略它们。值得注意的是，Chrome 可能会根据 `residentKey` 和 `userVerification` 设置静默应用默认策略。依赖方必须保持警惕，因为该扩展仅控制验证器端的发现功能，服务器仍需独立验证返回的断言是否确实包含了所需的用户验证。
```Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
理解 WebAuthn 凭据保护策略 (pilcrowonpaper.com)
4 点积分，由 mooreds 发布于 2 小时前 | 隐藏 | 过往 | 收藏 | 讨论 | 帮助
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：```
为大型功能特性维护干净的提交历史（即每个提交都是逻辑清晰、便于审阅的步骤）往往令人精疲力竭。像 `jj absorb` 或 `jj squash -i` 这样的传统工具容易出错，或者在边界复杂时导致合并冲突。 作者提出了一种替代工作流：“衣物分类法”（Laundry Sorting）。在开发过程中，与其费力维护完美的提交，不如先让初始提交变成一堆混乱的混合更改。待功能完成后，你先创建一个由空提交组成的链条，按逻辑顺序排列，代表你理想中的历史记录。接着，将所有“混乱”的提交合并为一个“全量”提交，再以交互方式将特定的代码块迁移到对应的逻辑提交中。 这种方法避免了“拆分与合并”的循环，简化了整理过程，并通过一次性分发更改避免了冲突地狱。虽然这有时会产生无法编译的中间提交（牺牲了完美的 `git bisect` 历史），但它显著减轻了版本控制带来的认知负担，将审阅者的可读性和开发者的顺畅度置于严格的增量提交规范之上。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
用 Jujutsu 克服 Git 操作疲劳 (ikesau.co)
9 分 | ikesau | 2 小时前 | 隐藏 | 过往 | 收藏 | 讨论 | 帮助
社区准则 | 常见问题 | 列表 | API | 安全 | 法律 | 加入 YC | 联系
搜索：
拒绝访问。您没有权限访问此服务器上的“http://www.cbp.gov/document/directives/cbp-directive-no-3340-049b-border-search-electronic-devices”。引用编号 #18.ad62c17.1779656521.a899f674 https://errors.edgesuite.net/18.ad62c17.1779656521.a899f674
```Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
CBP 指令 3340-049B：电子设备边境搜查 (cbp.gov)
17 点 由 Ember_Wipe 1 小时前发布 | 隐藏 | 过往 | 收藏 | 2 条评论 | 帮助
itstotallykyle 8 分钟前 [–]
这太疯狂了，我长期在国际间工作，去某些国家时的准则就是带一部一次性设备。去中国基本上意味着设备回国后就得彻底格式化，现在往返美国也有同样的感觉了。
回复
Caarticles 3 分钟前 | 父评论 [–]
需要使用一次性手机的国家名单可能会越来越长。加拿大、澳大利亚、英国、一些发展中国家等等……
回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：```
对于后端团队而言，从 Go 迁移到 Rust 不仅仅是为了提升运行速度，更是为了获得正确性保障和架构控制力。虽然 Go 是一门高效且“内置电池”的语言，但它依赖于惯例和运行时检查来管理内存、错误和并发——这往往使团队容易受到生产环境中空指针异常和数据竞争的影响。
Rust 通过将安全检查前置到编译器中解决了这些问题。Option 和 Result 类型、内存所有权以及基于特质（Trait）的泛型等特性，从根本上消除了许多类别的运行时错误。尽管这意味着更陡峭的学习曲线和更严苛的借用检查器，但其回报是更可预测的延迟、更低的内存占用，以及大幅减少的“救火”式事故。
作者建议避免“大爆炸式”的重写。相反，应采取战术性策略：将核心热点路径、后台任务或关键基础设施迁移至 Rust，同时在简单的胶水层服务中继续使用 Go。这一转型需要将“运行时检查”的思维模式转变为将编译器视为合作伙伴。归根结底，混合多语言的后端通常是最务实的策略，利用 Rust 来稳固那些可靠性和性能投资回报率最高的核心服务。
这段 Hacker News 的讨论探讨了从 Go 迁移到 Rust 的实际考量。
讨论主要聚焦于两个观点：
* **性能与 AI 辅助编程：** 一位用户称赞了 Rust 在批处理任务中的高效，并指出当前的大语言模型（LLM）在编写高质量 Rust 代码方面表现惊人。他们认为 Rust 和 Go 之间的性能差距足以促使开发者进行迁移，特别是在资源密集型任务中。
* **依赖管理的顾虑：** 另一位参与者则批评了 Rust 生态系统中的“依赖膨胀”问题。通过对比其同时维护的 Go 和 Rust 项目，他们观察到，尽管 Go 高度依赖于健壮的标准库，但即使是简单的 Rust 项目，通过 Cargo 引入的依赖项也会轻松达到数百个。该用户表示，Rust 社区的包管理方式正逐渐趋向于 npm 生态中常见的过度依赖现象，这令其感到沮丧。
总的来说，尽管开发者们认可 Rust 在函数式数据处理和性能表现上的优势，但管理庞大依赖树的复杂性，依然是实现全面生产环境迁移的主要障碍。