## 待在家中的理由：为什么在线研究比旅行更能带来真正的理解 本文认为，令人惊讶的是，待在家中并通过在线方式研究一个地方，可能比实际前往旅行更能获得信息。作者认为，在维基百科等资源上花费的短时间，可以获得与长时间旅行一样多的“有趣”信息，而且往往具有更广泛的意义。 虽然承认旅行能提供独特的感官体验，但作者指出这些体验并不一定能带来*更好*的理解。现代技术——直播、360°照片和社交媒体——可以复制许多传统上与旅行相关的观察学习。 作者提醒人们警惕在“实地”获得的看似客观信息的错觉，并引用了联合果品公司操纵记者的历史例子。他们还强调了通过精心策划的旅行体验形成的主观偏见。虽然承认旅行可以培养情感联系——在紧张的地缘政治环境中可能很有价值——但作者最终认为，政府真正试图控制的是信息获取途径，而不是机票。 最终，本文认为旅游本身存在根本性的缺陷，它建立在对“未受破坏”体验的渴望之上，而这种体验本身是不具备可持续性的，甚至可能*降低*与一个地方及其人民的真正联系。
每日HackerNews RSS
## 旅行 vs. 教育：Hacker News 讨论
Hacker News 上一篇帖子引发了关于旅行是否是一种有价值的教育形式的争论。原文似乎认为旅行本身并不具有教育意义，从而引发了热烈的讨论。
许多评论者同意，仅仅*身处*某个地方是不够的。肤浅的旅游——专注于喝酒、Instagram 照片或只体验热门景点——几乎不会带来真正的理解。几个人指出短途旅行的局限性，例如去巴厘岛却没有体验更广阔的印度尼西亚背景。
然而，大多数人认为第一手经验提供了维基百科无法提供的东西：背景、视角和“低阶信息”——对文化和日常生活的微妙观察。直接体验一个地方可以挑战先入为主的观念，并带来更深入的学习，从而促使进一步的研究。
似乎达成共识是*如何*旅行很重要。将研究*与*沉浸式体验相结合是理想的。最终，旅行的价值不在于收集事实，而在于以一种在线资源无法复制的方式与某个地方建立联系。
## GitHub Actions 交互式 Web 终端：总结
该项目提供了一个免费且开源的解决方案，用于获取对失败的 GitHub Actions 运行的交互式 Web 终端访问权限。解决的核心问题是，为了修复在本地工作但构建失败的情况，不断推送猜测性的更改所带来的困扰。
该解决方案利用 WebRTC 在 Actions VM 和用户浏览器之间建立点对点连接，从而最大限度地降低服务器成本。一个使用 Go 构建并托管在 Railway.com 上的信令服务器（利用按使用量付费和“休眠”实例以提高成本效益）促进了初始连接交换。
安全性至关重要：身份验证使用 GitHub OAuth 用于浏览器，并使用来自 Actions 的 OIDC 令牌来验证用户和仓库身份。此外，还增加了可选的一次性密码 (OTP)，在浏览器和 VM 之间直接验证，即使信令服务器受到损害，也能防止恶意连接。
该系统通过 WebRTC 数据通道流式传输终端数据，在 Actions VM 上使用 `pty.Shell`，在浏览器中使用 Ghostty 库，以提供无缝的终端体验。该项目优先考虑最少的服务器参与，专注于安全的对等体介绍，并利用高效的云基础设施提供具有成本效益的公共可用服务。
您可以在 [https://actions-term.gripdev.xyz/](https://actions-term.gripdev.xyz/) 试用它，并在那里找到代码链接。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
在 GitHub Actions 中启动调试终端 (gripdev.xyz)
11 分，由 martinpeck 发表于 37 分钟前 | 隐藏 | 过去 | 收藏 | 讨论
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 使用原生 JavaScript 实现声明式 UI：总结 本文探讨了仅使用原生 JavaScript、Web API 和 `Proxy` 对象构建响应式、声明式 UI，从而绕过传统的 UI 框架。该实验侧重于一个实际场景：显示一个模态对话框，该对话框会定期轮询 API，直到满足特定条件。 核心原则是将 UI *应该做什么* 与 *如何实现* 分离开来。这通过一个用于元素创建的 **DOM 工具层**、一个用于跟踪更改而无需外部库的基于 **Proxy 的响应式状态** 系统，以及一个可重用的 **轮询逻辑** 抽象来实现。然后，**模态编排器** 将这些组件集成在一起。 示例展示了一个用于显示轮询对话框的简洁、声明式 API，其中消费者定义端点、成功标准、内容和回调函数——而不是底层实现细节。主要收获包括声明式方法的扩展性、原生 Web API 的强大功能以及可重用工具的优势。 该实验得出结论，虽然框架提供了便利性，但通过精心使用原生 JavaScript 可以实现声明式行为和响应式，强调无论使用何种工具，抽象的重要性。
一个 Hacker News 的讨论围绕着 jsdev.space 上一篇关于使用原生 JavaScript 构建响应式、声明式 UI 的文章。 许多评论者批评了文章的方法，认为其复杂性并不值得，最终仍然导致直接的 DOM 操作。
一个关键的争论点是 JavaScript 应该*在哪里*用于渲染 HTML。 一些人提倡服务器渲染 HTML，并使用最少的 JavaScript “点缀”（例如 HTMX、Hotwire/Turbo、LiveView）来构建更简单的、基于文档的应用程序。 另一些人则认为，复杂的高度交互式应用程序受益于完全客户端渲染的框架。
这场争论的中心是正在构建的应用程序类型，以及是否需要考虑禁用 JavaScript 的情况。 最后，人们对文章的质量提出了担忧，有多位用户怀疑它主要由 AI 生成。
## 化石 vs. Git：总结 化石和 Git 都是分布式版本控制系统，具有重叠的核心功能——存储更改、分支、合并等——并且可以通过转换工具实现互操作性。然而，它们在设计理念和用户体验上存在显著差异。 Git 是一系列工具的集合，*仅*专注于版本控制，需要单独的工具来进行问题跟踪、维基和 Web 界面。相反，化石将这些功能——包括维基、错误跟踪器、论坛和聊天——集成到一个独立的、自包含的可执行文件中，近似于“开箱即用的 GitHub”体验。 主要区别包括：化石使用 SQLite 数据库进行存储（允许强大的查询），而 Git 使用键/值存储。化石优先考虑整个更改历史和同步，鼓励一种连贯的开发风格，而 Git 专注于单个分支，支持一种更加分散的、集市式的开发方式。化石强调在提交*之前*进行测试，并优先记录开发中*实际发生的事情*，抵制历史重写。它还具有更小的占用空间和更简单的设置，尤其是在自托管方面。 最终，选择取决于项目需求：Git 适合大型、松散耦合的项目，而化石则擅长于小型、协作环境，优先考虑简单性和集成功能。
## 化石 vs. Git：Hacker News 讨论
最近 Hacker News 上进行了一场关于化石（Fossil）的讨论。化石是一种版本控制系统，集成了wiki、bug 跟踪和论坛等功能，而这些功能在使用 Git 时通常需要外部服务（如 GitHub）。
一些人欣赏化石的一体化方法，而另一些人则质疑这是否是“功能蔓延”，认为这些功能可以通过 Git 和简单的变通方法来复制。
然而，核心争论在于**网络效应**：Git 广泛的应用是它最大的优势，尽管它很复杂。Mercurial 被一些人认为是一种更优秀的 DVCS，但由于同样的原因未能获得发展。用户最终依赖于他们的团队/雇主使用的工具。
尽管不如 Git 流行，但化石被 SQLite 数据库使用，这表明它具有实际应用。最终，这场讨论突出了集成便利性（化石）与复杂但普遍使用的系统（Git）的统治地位之间的权衡。
我们使用 Cookie 来改善您的体验并分析使用情况。必要 Cookie 启用核心功能，而分析 Cookie 帮助我们了解您如何使用游戏。隐私问题？仅接受必要 Cookie 全部接受
## Uncrossy：一款文字解谜游戏总结
Uncrossy 是一款新的、引人入胜的文字解谜游戏，其吸引力与 Wordle 类似。玩家通过在屏幕上滑动单词来达成解决方案。然而，许多用户遇到无法解开的情况，需要进行大量的撤销操作，这令人沮丧。
普遍的反馈表明，应该实施一个警告系统，提醒玩家他们正在进入死胡同，或者在早期设计关卡以避免这些情况。一些用户还报告了浏览器兼容性问题（特别是 Firefox 和 uBlock Origin），与cookie管理有关。
尽管存在这些问题，玩家仍然称赞游戏的规则简单、视觉设计吸引人以及游戏玩法令人满意。许多评论员预测它具有更广泛成功的潜力，甚至建议它可以被改编成移动应用程序。一个独特的元素是，玩家会意识到仅仅让一个单词消失并不总是最佳策略，因为它会改变剩余的单词。
人工智能黑猩猩爱，因衰老和器官衰竭在日本去世，享年49岁。爱以其认知能力而闻名，自1977年起一直是京都大学人类行为进化起源研究中心“爱项目”的中心。 研究人员发现爱能够理解和运用数字和颜色，甚至掌握了高达六的数字命名，并且在五岁时可以使用电脑键盘界面识别300种不同物体的属性。除了学术成就外，爱还喜欢通过绘画来表达艺术，甚至还因与另一只黑猩猩一起大胆逃跑而闻名！ 爱也是黑猩猩绫人的母亲，绫人以其非凡的记忆力而著称。她的遗产在2017年被庆祝，一 条带有她艺术作品的围巾被赠送给灵长类动物学家简·古道尔。爱为深入了解黑猩猩的思维做出了重大贡献。
人工智能，一只以认知能力著称的日本黑猩猩——包括计数和绘画——已于49岁时去世。该消息在Hacker News上分享，引发了用户讨论。
Ai于1977年从野外捕获，并在京都大学灵长类研究所以（KUPRI）进行研究。用户指出他被捕获的历史背景，强调此类动物销售现在违反了CITES法规。
讨论还集中在Ai的艺术作品上，并提供了链接以查看他绘画的例子。 一条幽默的评论承认了“Ai”新闻出现在以人工智能讨论为主导的科技论坛上的讽刺意味，并澄清了这只“Ai”与人工智能截然不同。 这篇帖子引起了人们对这只非凡黑猩猩的兴趣和怀念。
## XMPP 与元数据：摘要
本次演讲最初在混沌通信大会上发表，探讨了 XMPP 消息协议中的元数据问题。虽然 XMPP 提供了可扩展性和联合，但即使使用端到端加密 (E2EE)，每条消息的发送都会向相关服务器泄露信息——发送者、接收者和时间。信任您的服务器至关重要，因为服务器被攻破会暴露所有元数据。
演讲概述了四种主要的元数据威胁：服务器被攻破、实时数据关联、利用静态服务器数据以及网络层面的观察。讨论了几种潜在的解决方案，包括无服务器消息传递 (XEP-0174)，它绕过了服务器但牺牲了加密，以及 XTLS，用于直接、加密的客户端到客户端连接。加密身份 (XEP-0416) 提供了另一种减少对服务器信任的途径。
将 XMPP 与其他协议进行了比较：Signal 虽然在密码学上很强大，但它是中心化的并收集元数据；Matrix 在服务器之间复制数据，加剧了元数据问题；SimpleX 优先考虑隐私，内置了密码学和洋葱路由。
最终，改进 XMPP 的元数据处理需要持续的努力，尽管资源有限。虽然采用可能缓慢，但增量改进可以加强协议和生态系统。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
XMPP 和元数据 (mathieui.net)
15 分，by todsacerdoti 2 小时前 | 隐藏 | 过去 | 收藏 | 讨论
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## Lightpanda 新的基于 Zig 的 DOM：zigdom
Lightpanda 发现 V8、Zig 和 LibDOM 之间存在摩擦，尤其是在事件、自定义元素和 ShadowDOM 方面，因此用自定义的基于 Zig 的解决方案 `zigdom` 替换了之前的 DOM 实现 (LibDOM)。 这个为期六个月的项目旨在创建一个更精简、更可控的代码库，简化未来的扩展和改进。
`zigdom` 使用基于指针的节点结构和大型分配来最大程度地减少内存开销，并采用延迟加载元素属性以进一步降低内存使用量。他们集成了基于 Rust 的 `html5ever` 解析器，用于强大的 HTML 处理，并实现了 V8 快照以显著缩短启动时间。
虽然性能提升个位数，但主要好处是统一的代码库，可以更好地控制内存管理和事件处理。 这个基础将促进多线程和改进的自定义元素/ShadowDOM 支持等功能。 开发过程得到了 AI 编码代理 (Claude) 的帮助，证明对于 DOM 实现这样定义明确的任务非常有效，但仍然需要彻底的代码审查。 `zigdom` 现在已集成到 Lightpanda 的主分支中。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Lightpanda 将 DOM 实现迁移到 Zig (lightpanda.io)
12 分，由 gearnode 46 分钟前发布 | 隐藏 | 过去 | 收藏 | 讨论
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 软件工程的演变趋势 (2026) 软件行业正处于转折点，受到人工智能编码进步和从“不惜一切代价增长”向“效率”转变的驱动。 这影响着该领域的招聘、技能和角色。 **初级开发人员的角色面临不确定性。** 人工智能自动化可能会减少入门级职位，但软件在各行业的应用扩展可能会创造新的机会——需要适应性强、精通人工智能的候选人。 传统的职业道路正在减弱，要求初级人员展示立竿见影的价值和多功能性。 **核心编码技能正在被重新定义。** 虽然人工智能处理常规任务，但对架构、系统设计以及批判性地评估人工智能生成的代码的专业知识变得至关重要。 开发人员必须平衡人工智能的速度与基础知识，以确保质量和安全。 **开发人员的角色正在演变。** 他们可能专注于审计人工智能输出，*或者*扩展到协调复杂的人工智能驱动系统，需要更广泛的战略和伦理责任。 **适应性是关键。** 过度专业化面临过时风险； 拥有深度专业知识*和*广泛知识的“T型”工程师将受到高度重视。 **教育正在经历颠覆。** 传统的计算机科学学位可能难以跟上行业变化，可能会让位于更快速的学习路径，如训练营、在线平台和雇主主导的培训。 最终，成功取决于持续学习、将人工智能视为工具以及专注于独特的human skills，例如解决问题、沟通和战略思维。 未来不是害怕自动化，而是积极塑造它。
## 软件工程的未来：摘要
这次Hacker News讨论围绕Addy Osmani的文章，关于软件工程未来两年的发展，引发了关于人工智能，特别是LLM对该领域的影响的争论。一个关键主题是技能组合的转变：减少对纯编码的强调，而更多地关注有效地提示AI、验证输出，以及具备强大的沟通和解决问题的能力。
许多评论者同意LLM *加速* 开发，充当强大的助手而非完全自动化工具。然而，人们对代码可维护性、潜在的低质量输出（“AI垃圾”）以及知识中心化的风险表示担忧。
对于传统计算机科学学位的价值存在分歧，一些人认为基础知识仍然至关重要，而另一些人则认为实际的AI熟练度现在至关重要，尤其是对于初级开发人员。一个反复出现的担忧是，管理层并不完全理解软件工程的复杂性，可能导致不切实际的期望和对熟练劳动力的贬值。最终，讨论表明，一个破坏和适应的时期即将来临，未来将青睐能够利用AI同时保留核心能力的可适应工程师。
Please provide the content you want me to translate. I need the text to be able to translate it to Chinese.
一张新的交互式地图 (kikkia.dev) 可视化了日本不同便利店连锁店的比例——这个话题被戏称为“便利店战争”。这张地图发布在Hacker News上，很快因其炫酷的界面和响应速度而获得积极反馈。
用户赞赏这种数据可视化方式，一位居住在日本的用户指出，由于地图的叠加层，难以确定特定街区，并建议添加GPS定位功能。另一些人表示有兴趣看到类似的分析应用于香港等其他市场（也分享了香港分析的链接）。有人提到数据叠加层的初始加载时间稍长。这张地图将便利店特许经营店之间的竞争戏称为“市场份额和黄金地点的战争”。