Mojang 正在将《我的世界：Java 版》的渲染从 OpenGL 过渡到 Vulkan，作为“鲜活视觉效果”更新的一部分，承诺带来视觉增强和性能提升。这一重大改变旨在利用现代特性，并保持与包括 macOS（通过翻译层）和 Linux 在内的 PC 操作系统兼容。
此次切换将要求模组制作者更新他们的作品，放弃 OpenGL，Mojang 鼓励提前准备并利用现有的渲染 API 以简化过渡。虽然缺乏 Vulkan 支持的旧硬件可能会变得不兼容，但 Vulkan 具有广泛的 GPU 支持。
玩家不会立即被强制切换；Mojang 计划今夏在开发快照中发布 Vulkan 和 OpenGL 并存的版本，允许在两者之间切换。最终，一旦 Vulkan 稳定且性能良好，OpenGL 将被移除。此次更新代表了《我的世界：Java 版》未来发展的重要一步。
每日HackerNews RSS
## HM 与双向类型系统：为你的语言提出的错误问题 关于 Hindley-Milner (HM) 和双向 (Bidir) 类型系统的争论，常常被框定为二选一的选择，但这是一种错误的二分法。核心问题不是 *选择哪个* 系统，而是 *你的语言是否需要泛型*。 泛型需要合一——推断和求解类型变量的过程（例如 Rust 中的 `Vec<T>`）。HM 本质上包含合一。然而，双向类型系统并不局限于缺乏合一；它 *支持* 合一，使其成为 HM 的超集。你可以实现一个带有或不带有合一的双向系统，提供灵活性。 如果没有泛型，一个更简单的依赖于类型注解的双向系统就足够了，尤其是在学习练习或领域特定语言 (DSL) 中，在这些情况下，最小化复杂性是关键。然而，对于通用语言，泛型越来越被认为是必不可少的，从而推动了对合一的需求。 最终，双向类型系统提供了一种更具适应性的方法。选择它并不会排除合一，并且允许你根据语言的特定需求定制系统——无论是一个功能齐全的泛型语言，还是一个精简的、注重注解的 DSL。
## Hacker News 讨论总结：类型推断方法
一个 Hacker News 帖子讨论了一篇比较 Hindley-Milner (HM) 和双向类型推断的博文。 讨论迅速扩展到初始主题之外，涉及类型系统和语言设计的复杂性。
关键点包括：
* **HM vs. 双向：** HM 依赖于合一解决全局类型约束，而双向类型推断遍历语法树，通过向上和向下流动信息来推断类型。 大多数实用语言最终使用双向方法来处理子类型等 HM 难以处理的特性。
* **合一 vs. 双向作为核心概念：** 有人认为核心区别在于 *如何* 解决类型（合一作为全局约束问题 vs. 双向流动），而不仅仅是 HM vs. 双向。
* **权衡：** 复杂的类型推断并不总是受益。 一些人提倡要求显式类型声明以提高清晰度和更好的错误消息，或者采用渐进式类型以获得灵活性。
* **实用性与历史：** 许多流行的语言由于从早期的设计选择演变并试图适应现有的代码库而具有“混乱”的类型系统。
* **个人经验：** 几位评论员分享了关于学习类型理论、早期编程探索的乐趣以及后来生活中保持个人项目专注的挑战的轶事。
最终，讨论强调选择类型系统涉及平衡力量、简单性、错误报告和实际考虑因素。 没有一种万能的解决方案。
## 486.713通往罗马的路线：摘要
“486.713通往罗马的路线”是一个数据可视化项目，通过大规模的移动模式来研究“殊途同归”的说法。该项目利用路由算法和OpenStreetMap数据与GraphHopper，绘制了从各个地点到罗马的大量可能路线。
结果以大尺寸lambda打印（120厘米 x 80厘米）和交互式网络地图的形式呈现，提供详细信息和“探索”应用程序。这些可视化展示了道路基础设施如何反映地理、政治和区域背景。 除了罗马，该项目还扩展到分析东京、柏林和旧金山等城市的城市流动“指纹”和“街道DNA”，从而深入了解独特的城市结构。 最终，它将数据艺术和信息可视化巧妙地结合在一起。
一个黑客新闻的讨论强调了2015年的项目“通往罗马之路”（benedikt-gross.de），该项目以视觉方式绘制从罗马辐射的路线，展示了道路基础设施如何反映地理和政治。该项目显著提高了GraphHopper路由引擎的知名度。
评论者分享了相关资源，包括一个详细介绍古罗马道路的网站([https://itiner-e.org/](https://itiner-e.org/))，并指出moovel/FreeNow等相关公司的演变（现在被Lyft收购）。
讨论还涉及了该项目的研究方法，一些人质疑强调严格遵循政治边界的路线是否显得人为，指出现实世界的交通通常优先考虑效率而非意识形态（例如使用非申根路线或渡轮）。对话也幽默地推测了未来交通技术，如传送，可能会如何进一步扰乱此类可视化效果。
CMake 对 Swift 6.0 的完整支持目前受到 Swift 编译器 (swiftc) 和 Ninja 构建系统的一些兼容性问题阻碍。具体来说，Swift + Ninja 会忽略 `CMAKE_OSX_DEPLOYMENT_TARGET`，导致版本不匹配和警告。一个临时解决方法是手动设置 Swift 编译器的目标。 另一个问题与 CMake 策略 CMP0157 相关，swiftc 无法正确处理安装名称，需要一个构建后命令来调整库 ID。对此的修复已于 2024 年 8 月 2 日合并，并将回移植到 CMake 3.29 和 3.30 版本。 最后，swiftc 无法识别在导入目标依赖项中定义的某些编译和链接选项，因此需要一个解决方法来修改这些标志在导入之后。这些问题正在积极解决，以在 CMake 中实现稳定、非实验性的 Swift 6.0 体验。
都一样吗？
All Look Same?
2 天前
请记住，食物文化不断地相互引进和输出。这不是测试食物的起源地。答案基于图片拍摄地点。例如，面条起源于中国，但韩国和日本都以不同的方式进行了改良。
## 一次性软件的兴起与API的力量
成为新手父母激发了他对睡眠追踪的需求，现有的Fitbit无法满足。现有的用户体验并非为新生儿父母的零碎睡眠而设计，因此这位工程师利用AI编码工具快速构建了一个自定义界面，以可视化他的数据并解答关于他疲惫程度的关键问题。
虽然有用，但他意识到这并非一个可行的产品——它缺乏基本功能，并且完全依赖于Fitbit的核心功能。这突显了“一次性软件”的出现，这种软件可以利用AI轻松创建，以满足高度特定且临时的需求。
关键在于**API**的持久价值。Fitbit现有的API实现了这种个性化，展示了暴露核心产品能力如何培养客户忠诚度，*而无需*企业构建所有可能的功能。
展望未来，AI代理正在进一步扩展“界面表面”，可能会完全绕过应用程序。那些在*服务层面*（如订阅）进行盈利的企业将处于最佳的蓬勃发展地位，因为他们控制着潜在的价值。未来在于拥抱开放的API，认识到在界面廉价的世界里，持久的产品本身就是服务——核心能力，而不是它的呈现方式。
## 一次性接口与向服务器端计算的转变
一则Hacker News讨论集中在软件接口日益普及和可能回归服务器端计算模型上。核心观点呼应威廉·吉布森的“街头会为事物找到自己的用途”，即软件的个体价值正在下降，凸显了对连接这些短暂工具的强大、可重用系统的需求。
评论者认为API对于产品相关性至关重要，WebMCP提供了一种将用户体验与API控制相结合的强大方式。一个关键点是与“维修权”运动的相似之处——访问API能够实现定制化。
此外，一种普遍情绪表明，正在从个人计算和微电子投资转向大规模数据中心和私有高速互联网接入。这意味着未来信息访问将日益集中和隔离，处理能力将回归服务器。最后，一位评论员指出，接口可以降低用户身份的重要性，而用户身份是许多盈利策略的关键组成部分。
使用带有连字功能的字体来显示十三世纪僧侣数字。
Making a font with ligatures to display thirteenth-century monk numerals
2 天前
冲洗并重复数千行。 “sub”序列贪婪地匹配字符，这就是为什么此列表从4位数字开始；如果从1到9开始，我们只会得到一堆个位数替换。 这也意味着对于5位或更多位数的数字，例如123456，字体将一次匹配4位数字并生成“1234”的字形，然后是“56”。 字形外观本身是使用Chris Heilmann的Cistercian数字生成器的SVG路径定义的。 感谢Chris！有关我用于生成Cistercian字体的完整代码，请参见GitHub仓库：bobbiec/cistercian-font。 请注意，代码大部分是由AI生成的——尽管我对其进行了审查，但我也没有专业知识来发现如果存在严重错误。 我在玩转演示时注意到，象限的顺序非常不寻常。 如果从最低有效数字（个位）到最高有效数字（千位）计数，你会得到这种反Z形：
这个Hacker News讨论围绕着一种新创建的字体，旨在显示13世纪西斯特会僧侣使用的数字，如[digitalseams.com](https://digitalseams.com)所示。该字体使用连字——组合的字形——来表示这些数字。
用户讨论了在Unicode中表示历史数字系统的挑战，指出纳入需要正式请求和持续支持。为了尽量减少所需的码点数量，提出了零宽连接符（ZWJ）和组合字符等替代方案，并争论了数字的笔画是否应被视为一个独立的元素。
一些评论员指出了现有的方法，包括一种组合字体([https://github.com/ctrlcctrlv/FRBCistercian](https://github.com/ctrlcctrlv/FRBCistercian))和MusGlyph，一种专注于连字的音乐符号字体。讨论还涉及使用这些数字进行加法的视觉效果，指出它只有在特定情况下才容易显现。总的来说，该帖子突出了数字排版和历史数字表示的复杂性。
本文讨论了作者提供开放性问题作为额外学分的方式。一个关键的争论点在于透明度：学生应该知道这些问题是未解决的吗？作者认为应该，因为真正困难的问题不太可能由单个学生解决，但承认存在将难题误认为易题的情况（例如乔治·丹齐格）。 作者区分了真正意义上的“开放性问题!!!”和他们自己无法解决的问题，明确告诉学生后者可能在他们的能力范围内。一位朋友警告说，如果学生成功解决，这可能会损害作者的信誉，但作者认为热情地承认解决方案可以避免这种情况。 最后，作者坚信额外学分不应计入学生的成绩，而是提供推荐信作为奖励——保持这项工作的“额外”性质。
您的请求已被阻止，原因是网络策略。请登录或在此处创建帐户以恢复浏览。如果您正在运行脚本或应用程序，请在此处注册或使用您的开发者凭据登录。此外，请确保您的User-Agent不为空，并且是独特且具有描述性的，然后重试。如果您正在提供替代的User-Agent字符串，请尝试改回默认设置，因为这有时会导致阻止。您可以在此处阅读Reddit的服务条款。如果您认为我们错误地阻止了您，或者想要讨论更轻松地获取所需数据的方式，请在此处提交工单。联系我们时，请提供您的Reddit帐户以及以下代码：019c72e2-7558-7a2c-aabe-88e7867854cd。
## 20 年前的苹果 iBook 仍在 2024 年连接
Reddit 上的一篇帖子引发了 Hacker News 上的讨论，内容是关于 20 年前的苹果 iBook 令人惊讶地能够连接 Wi-Fi 并下载官方更新。虽然最初的帖子被认为具有误导性（许多旧 iBook *无法* 连接到现代 Wi-Fi），但它凸显了苹果硬件和软件支持的持久性。
用户分享了复活旧 Mac 的经历，经常遇到不兼容的网络协议（WPA3）、过时的 SSL 证书以及难以找到可下载的操作系统安装程序等障碍。一些人找到了解决方法，例如使用旧网络或通过 USB 传输文件。
对话涉及了苹果随着时间的推移的设计选择，对旧版 macOS 的美感感到怀旧，并批评了最近的“液态玻璃”UI 更改。许多人哀叹科技领域日益增长的计划报废趋势，并将其与苹果对旧系统持续（但有时不安全）的支持进行对比。最终，该帖子展示了社区对保持旧硬件活力的赞赏，即使这需要付出巨大的努力。