我将 Linux 移植到 PS5 并将其改造成了 Steam Machine。运行带有光线追踪的增强版 GTA 5。🤯 2026年3月6日 · 晚上8:02 UTC 443 1,617 17,485 2,005,204
每日HackerNews RSS
我将Linux移植到PS5，并把它变成了一台Steam Machine。
I ported Linux to the PS5 and turned it into a Steam Machine
2 天前
## WigglyPaint：病毒式传播及其阴暗面
WigglyPaint 是一款于 2023 年 12 月创建并在 Itch.io 上发布的绘画程序，意外地在亚洲社交媒体上走红。该程序的核心功能是自动“线条抖动”——一种通过操纵多个图像缓冲区和随机绘图工具实现的生动动画效果。与 Photoshop 等复杂程序不同，WigglyPaint 优先考虑简洁性，具有有限的调色板、单个撤销按钮以及一种独特的“标记”绘制在线条图下方的操作流程。
WigglyPaint 构建在开源 Decker 环境中，其灵活性使其易于定制，并且其有意的设计选择受到欢迎，帮助艺术家克服了创作瓶颈。然而，这种成功却被广泛的盗窃行为所掩盖。许多网站涌现出来，提供修改过的、通常虚假宣传的 WigglyPaint 版本（特别是 v1.3）——有时甚至声称与原始创建者有关联并募集捐款。这些网站借助 LLM 构建，经常包含错误信息和被盗艺术品。移动“移植”版本进一步限制了程序的自定义功能。
该创建者对这种剥削感到沮丧，强调了作者身份的重要性以及围绕 LLM 生成内容所产生的伦理问题。尽管存在侵权行为，WigglyPaint 仍然是免费且开源的，是献给创意社区的一份礼物。
## WigglyPaint 与在线复制问题
一篇关于在 Decker 中构建的创意工具 WigglyPaint 的文章，在 Hacker News 上引发了关于创作者面临的在线模仿和版权挑战的讨论。作者哀叹了克隆软件的泛滥，这在 LLM 的兴起下更加严重，但承认这个问题早于它们——以 Wordle 狂潮和类似的游戏复制品为例。
许多评论者分享了他们的作品被复制的经历，并指出对抗这种情况的困难。建议包括注册域名、主动向 Google 提交版权声明，以及联系托管侵权网站的托管提供商/平台。一些人指出转向客户端-服务器架构作为版权保护，但承认其缺点。
一个关键点是，创造一些东西却很容易被复制的沮丧感，尤其是在简单的概念上。其他人强调了人工智能*故意*为那些抓取项目的代码创建错误的潜力，以及对齐人工智能的需求，优先考虑人类福祉而非利润。最终，这场对话强调了创作者在容易被模仿的数字环境中保护其作品的持续斗争。
## Eyot：无缝GPU卸载 Eyot是一种新的编程语言，旨在简化GPU加速，目标是使利用GPU像使用CPU上的后台线程一样容易。它通过允许代码透明地编译为CPU和GPU版本来实现这一点，运行时管理它们之间的通信——消除了GPU编程中传统上所需的、手动内存管理、内核编译和调度的复杂性。 Eyot面向游戏开发、数值分析和人工智能等领域，允许开发者使用简单的关键字（`cpu`或`gpu`）指定函数在CPU或GPU上执行。该语言处理底层的复杂性，从而提供统一的编码体验。 目前Eyot处于早期开发阶段，优先考虑CPU/GPU交互等核心功能。未来的计划包括通过Vulkan添加渲染支持，扩展语法（目前保持最简以确保兼容性），以及改进GPU内存管理。目标不是*取代*现有的GPGPU库，而是提供一种更方便、更易于访问的方法，即使这意味着为了易用性而接受轻微的性能折衷。Eyot可通过playground和安装方式进行实验，开发者欢迎反馈。
## Eyot：将GPU视为线程 - Hacker News 总结
一种名为Eyot的新编程语言正在Hacker News上引发讨论，其特点是将GPU视为另一组线程。这种方法旨在简化GPU编程，允许开发者使用一种混合C风格块和Python风格行分隔（通过类似Go的无声分号插入实现）的语法来利用GPU的强大功能。
然而，评论者提出了关于GPU计算复杂性的重要观点。具体来说，与CPU线程相比，不同的延迟和成本模型，尤其是在像LLM推理中具有可变请求大小的场景下，可能会带来挑战。
讨论还涉及现有的Rust替代方案，如Candle和rust-gpu，以及类似的项目，如CubeCL和wgpu。一些人认为，这种功能可以在现有的语言（如C++）中复制，质疑是否有必要创建一种新语言。总的来说，Eyot引发了关于可访问和高效GPU编程的最佳方法的争论。
观察人士认为，这归因于良好的骑行天气、经济实力雄厚的父母——最受欢迎品牌中最便宜的型号零售价至少为3000澳元（2110美元，1579英镑）——以及缺乏可靠的公共交通。
## 悉尼胖车扰乱秩序及更广泛的担忧
一篇BBC文章报道了悉尼富裕海滩郊区中具有破坏性的“胖车”活动，引发了黑客新闻论坛对该问题及相关安全隐患的讨论。虽然文章重点关注鲁莽行为——超速、无视交通法规和缺乏安全装备——但评论员很快将讨论范围扩大了。
许多人指出澳大利亚在自行车基础设施方面的投资不足（仅占交通预算的0.2%）是导致所有骑自行车者危险状况的一个因素。 另一些人则争论风险，一些人回忆起类似的年轻冒险行为，而另一些人则对由于自行车速度和重量增加而导致事故严重程度加剧表示担忧。
一个反复出现的主题是需要寻找替代方案来解决这种行为背后的潜在动机，这可能源于近期对青少年的社交媒体限制。 几位评论员强调了其他地区与电动滑板车类似的问题，并出现了一种观点，即问题不在于自行车本身，而在于对安全和规则的漠视。 讨论还涉及达尔文选择的可能性以及对更好监管的需求，但解决方案仍然难以捉摸。
奥德赛背后的集体雄心：一款改变游戏规则的科幻LARP
The Collective Ambition Behind Odysseus, a Game-Changing Sci-Fi Larp
2 天前
## 奧德賽：突破沉浸式边界的里程碑LARP
奧德賽是一款广受好评的科幻LARP，灵感源自《太空堡垒卡拉狄加》，在2019年首次成功后，最近又复活并连续举办了三场售罄的活动。超过200名玩家在持续50小时内居住在一个庞大的宇宙飞船环境中——由200多名志愿者以19万欧元的成本建造，拥有精细的布景，并由定制软件驱动，用于战斗、工程和通信。
这款LARP以其“钟表式”游戏玩法而闻名，要求玩家在严格的时间压力下完成相互依赖的任务，从而反映了电视剧《33》的紧迫感。除了复杂的游戏机制外，奧德賽还以其探索悲伤、决心甚至种族灭绝等主题的复杂叙事而著称——这与更乐观的沉浸式体验形成了鲜明对比。
虽然门票（每张550欧元）几乎无法覆盖制作成本，但该项目的成功引发了关于创建一个财务上可持续、专业运营的LARP的讨论。目前，奧德賽在芬兰游戏博物馆举办的主要展览中展出，正在突破沉浸式艺术的边界，挑战对LARP的传统观念，吸引了潜在投资者的关注，并巩固了其在该领域作为开创性成就的地位。
一个名为奥德赛的引人入胜的科幻LARP（真人角色扮演游戏）在Hacker News上受到关注。由一支敬业的志愿者团队创建，奥德赛旨在在一个细节丰富的世界中提供沉浸式和情感参与的体验。
该项目目前通过Indiegogo众筹85万欧元，以建立一个永久性场地。玩家和观察者都称赞了游戏的科技成就——特别是复杂的电子设备和IT基础设施——以及引人入胜的玩家体验。
链接到该帖子的讨论线程也提出了关于奇幻核心的有趣观点，引用了托尔金的观点，即*世界*本身是主要焦点，这个概念似乎是奥德赛LARP设计的核心。 也有一些展示游戏和志愿者努力的视频被分享。
## 龙虾：一种简洁而强大的编程语言
龙虾是一种开源、静态类型编程语言，专为速度和易用性而设计，尤其适用于游戏开发和图形处理。它旨在结合静态类型和编译时内存管理的优势，同时采用轻量级、简洁的语法，最大限度地减少样板代码。
主要特性包括：基于流的类型推断、编译时引用计数/借用检查，以及轻量级的块/匿名函数。龙虾支持向量运算、统一的重载和动态分发，以及用于零开销性能的不可变内联结构体。它拥有无GIL、无竞争的多线程模型。
实现提供了一个JIT编译器用于快速迭代，以及编译到C++以获得优化的速度。包含了一个完全图形化的调试器和动态代码加载功能。龙虾相对较快——比Python和Lua更快——并且内存使用经济。
该语言具有可移植性，可在Windows、Linux、macOS、iOS、Android和WebAssembly上运行，并提供对OpenGL的高级接口，包括2D/3D图元、着色器和精确的文本渲染。它还提供了一个简单的声音系统和ImGui支持，以及A*寻路等实用库。
更多信息、文档和源代码可以在[GitHub](https://github.com/lobster-lang/lobster)上找到。
## Lobster编程语言：概要
Lobster编程语言由Cube/Sauerbraten和Treesheets的开发者创建，正在Hacker News上引发讨论。它具有流程敏感类型推断和静态类型检查——这种组合因其在编译语言中的低调优势而受到赞扬，并具有简洁的语法和独特的规则，例如函数本地的`return`语句。
评论者强调了诸如沙盒代码执行、数据解析、内置图形/声音/VR/物理支持以及与ImGui和Steamworks的集成等功能。一个关键的设计元素是在静态生命周期分析失败时自动引用计数，这提供了一种可能优于Rust手动内存管理的方法。
讨论还涉及了LLM时代编程语言的未来。有些人认为LLM可能会降低对*新*语言的需求，而另一些人则认为，专门针对AI交互进行优化的语言——优先考虑机器验证而非人类简洁性——将仍然至关重要。 还有一种观点认为LLM可能会*创造*新的语言。最终，对于形式化、构建化的语言在抽象、规范和可靠通信方面的需求依然强烈。
## Sem：语义版本控制与差异分析
Sem 是一款工具，它通过**语义差异**增强 Git 的功能，超越了基于行的更改，从而识别出*哪些*代码被更改——例如，添加或修改了一个函数——而不是*哪里*。它为 13 种编程语言（TypeScript、Python、Go、Rust、Java 等）以及结构化数据格式（JSON、YAML、TOML）提供实体级别的差异。
**主要特性：**
* **实体识别：** 检测函数、类和其他代码实体的添加、修改和删除。
* **重命名/移动检测：** 使用结构化哈希和模糊相似性识别重命名或移动的实体。
* **影响分析：** 确定实体更改可能造成的破坏。
* **多功能用法：** 直接在 Git 仓库中使用，支持暂存的更改、特定的提交，甚至 stdin 输入。
* **JSON 输出：** 支持与 AI 代理和 CI 管道集成。
Sem 提供 CLI 版本（可通过 Rust 或预构建的二进制文件安装）和 Rust 库版本，以便集成到其他工具中，例如 weave 和 inspect。它利用 tree-sitter 进行解析，并使用 git2 进行 Git 操作。
## Sem：语义版本控制 - Hacker News 讨论
一个名为“Sem”的新项目（之前名为“graft”和“got”）旨在在Git之上提供语义版本控制，利用实体级别差异。Hacker News上的讨论集中在“语义差异”与“语法感知差异”的实用性和定义上——一些人质疑这种区别是否有意义，因为编译器会在简单的AST比较之外优化代码。
用户分享了使用现有语义差异工具的经验，这些工具适用于较简单的语言，如YAML和JSON，并赞赏它们忽略无关差异（如数组顺序）的能力。 许多评论员强调需要关注*变化了什么*（函数、特性）而不是*在哪里*（行号）的差异，尤其是在AI驱动代码提交日益普及的情况下。
其他人指出“difftastic”和“Beagle”等项目是相关的努力，Beagle采取了一种独特的方法，即直接在数据库中存储AST树。 讨论还涉及当前方法的局限性以及未来AI驱动的差异的潜力，这些差异可以在更高的层次上抽象变化。
## Rust & Wasm 与 `wasm-bindgen`: 实用模式 使用 Rust 和 WebAssembly (Wasm) 通过 `wasm-bindgen` 进行开发可能具有挑战性，但采用特定模式可以显著改善体验。 本摘要概述了更流畅开发的 key 策略。 **核心原则:** 主要通过引用 (`&`) 传递数据跨越 Wasm 边界，利用 `Rc<RefCell<T>>` 或 `Arc<Mutex<T>>` 实现可变访问和共享所有权。 避免在导出类型上派生 `Copy`，以防止意外复制 Wasm 资源。 使用 `wasm_refgen` 处理包含需要跨越边界的类型（如 `Vec`）的集合。 **命名约定:** 在 Rust 导出的类型前加上 `Wasm*` 前缀（例如 `WasmFoo`），并使用 `js_name` 以未加前缀的名称暴露给 JavaScript。 相反，在 JS 导入的类型前加上 `Js*` 前缀。 **错误处理:** 使用 `js_sys::Error` 为 `JsValue` 实现 `From<YourError>`，以便在 JavaScript 端提供详细的错误信息。 **关键考虑因素:** `wasm-bindgen` 管理 JavaScript 的垃圾回收环境与 Rust 的所有权模型之间的通信。 使用 `js_sys` 进行手动绑定是一种选择，但依赖 `bindgen` 的胶水代码可以提供更好的编译时反馈。 **构建过程:** 使用 `build.rs` 脚本在 Wasm 构建中包含 Git 哈希和构建状态，以帮助调试和版本跟踪。 这些模式可以促进在 Wasm 中桥接 Rust 和 JavaScript 时提高清晰度、安全性和可维护性。
## Rust 与 WebAssembly：挑战与未来方向
一则 Hacker News 讨论围绕着 WebAssembly (Wasm) 开发的现状，特别是使用 Rust 时的情况。虽然 Wasm 正在改进，但其 C 风格的接口限制需要像 `wasm-bindgen` 这样的工具来实现更高级别的交互。
一个关键的争论点是提议的 WASM 组件模型，旨在直接将 Web API 暴露给 Wasm。一些人认为这是朝着更好的开发者体验和性能迈出的积极一步，尤其是在字符串编组等任务上。另一些人则担心增加的复杂性，并质疑收益是否大于成本，尤其是在访问 WebGPU 时可能出现的性能瓶颈。
人们对依赖 JavaScript “胶水代码”以及希望 Wasm 直接与浏览器交互表示担忧。 讨论强调了性能、安全性和易用性之间的权衡，以及将复杂性从浏览器转移到工具链的持续努力。 最终，对话强调了 Wasm 虽然强大，但仍然存在挑战，并非万能药，需要仔细考虑其局限性和具体用例。
作者认为，即使通过像LLM这样的工具实现*完美*的信息检索（想象成一个无懈可击的“我感觉幸运”谷歌按钮），最终也会*阻碍*智力发展。虽然提供了答案，但它会剥夺研究过程中至关重要的*经验*——接触不同的观点，应对矛盾，以及培养批判性思维能力。 然而，LLM甚至并非完美有效。它们擅长模仿在*我们*缺乏专业知识的领域的理解（盖尔-曼失忆症），常常自信地呈现看似合理但可能存在缺陷的信息。这种“流畅性”掩盖了潜在的不确定性，阻碍了培养关键的“认识论嗅觉”——直觉地检测不准确的能力。 真正的智慧并非建立在获得正确答案之上，而是建立在理解*为什么*某事可能是错误的，以及驾驭知识的复杂性之上。因此，仅仅依赖高效的LLM会带来“智力腐烂”的风险，因为它优先考虑结果，而非成为的关键过程。
## 黑客新闻讨论：LLM 与独立思考
一个黑客新闻帖子讨论了一篇最近的文章，质疑使用大型语言模型（LLM）的价值。核心论点在于LLM是否会助长智力上的懒惰，提供答案却不培养真正的理解——优先考虑“到达”而非“成为”。
许多评论者分享了细致的观点。一些人同意作者的观点，担心LLM会扼杀独立思考和批判性分析。另一些人则认为LLM作为探索、产生想法和克服技术障碍（如调试代码）的工具很有价值。 许多人强调了*如何*使用LLM的重要性；将它们视为研究助手而非神谕至关重要。
一个反复出现的主题是LLM增强而非取代人类智能。 将其与计算器和搜索引擎等工具进行比较，这些工具也同样改变了我们解决问题的方式。 人们提出了对偏见和错误信息的担忧，但有人认为这些问题也存在于传统信息来源中。 最终，讨论表明关键在于负责任地适应这项新技术，利用其优势，同时牢记其局限性。