“漫长停顿”之谜——波利尼西亚先民在长达1700年的时间里停止向东太平洋扩张——长期以来一直令历史学家感到困惑。虽然迪士尼电影《海洋奇缘》歌颂了这一航海传统，但近期的考古研究为这些航海家为何在公元900年至1100年间突然重启迁徙提供了科学解释。 通过分析古湖泊和沼泽沉积物中的氢同位素，研究人员发现，西南热带太平洋在那个时期经历了2000年来最严重的干旱。这种气候变化是由南太平洋辐合带（SPCZ）的长期变动引起的，该变动改变了降雨模式。 随着汤加和萨摩亚人口的增长，这种持续的“干旱冲击”可能导致岛屿无法再支撑其生存，迫使他们寻求新的土地。这种环境压力，加上人口增长和先进的双体独木舟技术，引发了历史上最勇敢的探索时期之一。最终，东太平洋的迅速定居不仅是一项航海壮举，更是人类在面对气候驱动的资源匮乏时，展现出韧性与智慧的非凡应对。
每日HackerNews RSS
1994年，顽皮狗（Naughty Dog）创始人安迪·加文（Andy Gavin）和杰森·鲁宾（Jason Rubin）寻求通过开发一款3D角色平台游戏来推动他们小工作室的发展。在从波士顿驱车前往洛杉矶的途中，他们构思了这个项目，并戏称其为“索尼克的屁股”（Sonic’s Ass），旨在解决创建一个玩家大部分时间都在盯着角色后背看的3D平台游戏所带来的挑战。
由于索尼PlayStation拥有优于土星（Saturn）和3DO等竞争对手的硬件，团队选择了它。当时团队规模扩大，加入了戴夫·巴格特（Dave Baggett）和环球影业副总裁马克·塞尔尼（Mark Cerny），他们的目标是填补市场空白。当时任天堂和世嘉都已经拥有了自己的标志性吉祥物，顽皮狗从中看到了机会，希望在当时缺乏旗舰角色游戏的平台上建立一个新的品牌。
为了克服3D视角固有的设计缺陷，他们尝试了多种摄像机角度，包括2D片段以及角色朝向屏幕奔跑的标志性“追逐”关卡。这一宏大的努力由两位年仅24岁且行业经验有限的年轻人主导，最终为传奇的《古惑狼》（Crash Bandicoot）系列奠定了基础。
这场 Hacker News 讨论聚焦于 17 世纪瑞典战舰“瓦萨号”（Vasa）。该舰在下水后不久便沉没，如今已成为软件工程和项目管理中一个著名的警示案例。
评论者指出，“瓦萨号”之所以能成为杰出的考古遗址，是因为波罗的海的半咸水使其残骸得以近乎完美地保存下来。虽然许多人将该舰的失败（通常归因于后期设计变更以及无法质疑权威）比作组织机能障碍的隐喻，但也有人提醒，大众叙事可能会过度简化复杂的历史事件。
参与者强烈建议参观斯德哥尔摩的瓦萨沉船博物馆，并指出它是全球最独特的航海展览之一。该讨论串还涉及一些有趣的轶事，例如芬兰学生在沉船打捞前曾恶作剧式地在船身上放置了一尊跑步运动员帕沃·努尔米（Paavo Nurmi）的雕像；此外，该舰还频繁出现在技术管理文献中，甚至包括 C++ 标准化的讨论。归根结底，“瓦萨号”既是一座引人注目的历史丰碑，也是对过度工程化且缺乏约束的项目需求所带来风险的持续警示。
一位安全研究员在 Motorola MR2600 路由器中发现了一个未经身份验证的远程代码执行（RCE）漏洞。该漏洞的利用主要依赖于两个缺陷：固件上传流程的绕过以及固件验证 API 中的身份验证失败。
首先，研究员发现固件上传端点对多部分（multipart）数据的处理不当，允许攻击者在未经身份验证的情况下上传恶意文件。其次，用于验证和刷写固件的 API 存在安全检查缺陷；它错误地使用了针对黑名单的精确字符串匹配，攻击者只需在请求 URI 后追加一个白名单字符串即可绕过该限制。
由于固件未经过加密签名，攻击者可以上传一个恶意镜像文件，路由器会在重启后自动安装并执行。局域网内的任何用户，或在开启远程管理功能的情况下，公网上的攻击者均可利用此漏洞。
研究员曾尝试向摩托罗拉报告这一发现，但 Motorola Mobility 和 Motorola Solutions 均表示对该产品不负责，目前该产品已停止服务。由于厂商不再提供支持，且更新基础设施已被废弃，研究员已将该漏洞公开披露。
《理解 Odin 编程语言》是程序员掌握底层概念的必备指南。该书由游戏开发者兼教育家 Karl Zylinski 撰写，内容涵盖从基础语法到手动内存管理、参数化多态和面向数据设计等高级主题。
Zylinski 不仅仅是在教授代码，更深入阐述了 Odin 设计背后的“缘由”，帮助读者成长为更精湛的开发者。该书凭借清晰的教学方式，在 Odin 社区（包括该语言的创始人 Bill "gingerBill" Hall）中备受推崇，是那些从垃圾回收语言转向底层开发的人员的理想资源。
该书目前已更新至 1.10 版本，并保持持续维护，定期根据语言变化和社区反馈进行更新。它提供易于阅读的便携式 HTML 格式，并可通过 store.zylinski.se 和 Itch.io 获取捆绑的电子书版本。无论你是初学者还是经验丰富的开发者，这本书都能为你提供一条结构化且易于理解的路径，助你精通 Odin 编程语言。
这份 Hacker News 讨论聚焦于日益受到关注的 **Odin 编程语言**。相比于 C++ 的复杂性或 Rust 的内存管理开销，开发者们更倾向于 Odin 所提供的类 C 语言的简洁性及手动内存控制。
主要内容包括：
* **系统编程的吸引力：** Odin 的拥护者赞赏其“低开销”设计，该设计摒弃了 C++ 风格的 RAII（资源获取即初始化），转而采用区域分配（arena allocation）等技术。这种方法深受优先考虑精细化内存管理的游戏开发者和系统工程师的青睐。
* **与 C 语言的互操作性：** Odin 被采用的一个主要驱动因素是其与 C 语言的无缝集成；许多人认为这比 Rust 的 FFI（外部函数接口）限制更为优越。
* **“手工打造”哲学：** 大部分讨论反映了一场由 Jon Blow 和 Casey Muratori 等人物引领的运动，他们主张追求性能、面向数据的设计以及可预测的执行，摒弃复杂的、重抽象的范式。
* **对 Rust 的批评：** 尽管 Rust 依然流行，但一些用户认为，其严格的所有权模型以及可插拔分配器等功能的缓慢稳定过程，使其在某些底层高性能任务中不如更“极简”的替代方案合适。
作者提倡一种“极简计算”的文献管理方式，即绕过 Zotero 等传统软件，直接管理 BibTeX 文件。 虽然大多数学者仅将 BibTeX 视为中间导出格式，但作者认为直接以纯文本形式对其进行操作更具优势。通过利用 BibTeX 的原生字段（特别是利用“关键词”进行分类，以及利用“备注”进行总结），用户可以使用 grep 等标准命令行工具高效地管理大型文献库。 这种方法符合“UNIX 哲学”，允许用户进行灵活且可叠加的操作，而不受专用管理软件功能局限的约束。此外，由于 BibTeX 是纯文本格式，它具有极高的可移植性，易于进行版本控制，且能避免专用数据库常见的迁移问题。尽管相较于图形用户界面，这种方法的学习曲线更为陡峭，但作者认为，基于文本的系统所带来的生产力提升、可移植性以及长期稳定性，使其成为学术生涯中更具可持续性和价值的选择。
登录以查看您的图表或创建新账户
新图表
图标库
AWS 上的无服务器架构
AWS 上的分布式负载测试
物理数据中心架构
开始引导教程
视角笔记
描述
chevron_left
chevron_right
touch_app
搜索
highlight_alt
编辑
退格
查看所有图表资源
此图表没有描述。点击此处添加。
chevron_right
chevron_left
正在查看此图表的旧版本。点击此处查看最新版本。
关闭
您的团队工作区许可证即将过期。点击此处以确保持续访问。
关闭
您的团队工作区许可证已过期。点击此处立即恢复访问。（忽略）
错误
发现致命错误。请修复以查看更新。
错误
图表不可用。请联系您的 Ilograph 管理员以恢复访问。
关闭
请将您遇到的所有错误提交至 [email protected]。您也可以在 Twitter 上通过 @ilographs 联系我。请包含图表名称、错误描述以及您使用的浏览器。
抱歉。
本次比较评估了三款 Emacs 终端模拟器：**Ghostel**（基于 `libghostty-vt`）、**vterm** 和 **eat**。 **Ghostel** 是最先进的选择，它利用高性能的 Zig/C 原生引擎，支持 Kitty 图形协议、键盘协议、自动 Shell 集成以及智能密码提示检测等现代特性。其运行速度显著优于其他两者。 **vterm** 是一款稳定且经过原生编译的方案。虽然其性能优于纯 Elisp 实现，但缺乏对现代图形（如 Sixel 或 Kitty 协议）的支持，且鼠标处理较为受限，更侧重于 Emacs 集成而非终端交互。 **Eat** 的特点在于它是纯 Emacs Lisp 实现，因此具有最好的可移植性和最简便的安装方式。但代价是性能显著降低，且不支持高级协议。 综上所述，**Ghostel** 通过利用现代原生技术，提供了最出色的功能集与性能；**vterm** 依然是一个成熟、均衡的原生选择；而对于需要纯 Emacs 原生环境、且不希望有外部依赖或编译需求的用户来说，**eat** 是最容易上手的选择。
**Ghostel** 是一款基于 `libghostty-vt` 开发的全新高性能 Emacs 终端模拟器。它旨在取代 `vterm` 和 `eat` 等现有解决方案，将终端输出直接集成到 Emacs 缓冲区中。这让用户能够在终端会话中充分利用 Emacs 的原生功能，例如高级导航、文本处理以及键盘驱动的工作流。
**Hacker News 讨论中的主要亮点：**
* **性能：** 用户反馈称，与旧的软件包相比，该工具在处理大量输出或复杂的终端界面（TUI）应用程序时，速度有显著提升。
* **工作流集成：** 由于将终端内容视为 Emacs 缓冲区，用户可以对回滚文本应用熟悉的命令，尽管有些人认为它缺乏 `eshell` 那种深度的集成。
* **技术挑战：** 维护者指出，为了在保持高效的同时将终端状态同步到 Emacs 缓冲区，他们使用了 `libghostty-vt` 来追踪“脏”行，从而优化重绘过程。
* **安装：** 该软件包需要一个原生模块（首次使用时编译或下载），一些用户对此提出了潜在的安全顾虑，但这在追求性能的 Emacs 扩展中属于常规做法。
尽管一些用户在早期版本中遇到过小 bug 或乱码，但许多人已将 Ghostel 作为在 Emacs 中进行终端工作的日常主力工具。
一位游戏开发者分享了他们的心血之作：将自研的 C++20“Mirage”引擎移植到初代 Xbox 上。作者明确表示，这是一个与他们在 Xbox 部门的专业工作无关的个人爱好项目，并详细阐述了将现代引擎（基于 Vulkan/C++20 设计）与 2000 年代初期遗留开发需求相结合所面临的巨大技术挑战。
为了使引擎兼容初代 Xbox SDK，开发者不得不回归到 C++98、Visual Studio 2003 以及古老的 CMake 版本。一个主要的障碍是数据优化；由于初代 Xbox 内存有限，作者必须通过复杂的流程，将现代 3D 模型（如虚幻引擎 6 的“Quinn”角色）通过 Blender 2.3 和 Maya 6.5 等过时软件进行转换，以生成 Xbox 原生的 `.x` 和 `.xbg` 文件。
该项目需要深入研究原始硬件文档，并手动编写基于汇编的顶点着色器。通过采用该平台原生且古老的工具链，而非使用现代自制方案，开发者成功实现了一套可行的工作流。该项目不仅是一次怀旧之旅，更是对游戏开发环境演变过程的一次严谨技术探索。