每日HackerNews RSS

在成功将 Linux 移植到 Atari Jaguar 后,作者出于对“板卡启动”(即让芯片运行自定义代码的挑战性过程)的热情,将目光转向了 Sega 32X。 Sega 32X 是 16 位 Sega Genesis 的 32 位扩展配件,其面临的重大障碍包括极其有限的内存和复杂的双 CPU 架构(两个 Hitachi SH2 和一个 Motorola 68000)。作者通过使用现代基于 FPGA 的烧录卡将 ROM 映射为 RAM,解决了硬件限制,从而为 Linux 内核和 initramfs 提供了必要的空间。 关键技术里程碑包括: * **内核移植:** 解决了交叉编译器的内部错误,并修复了 SH2 架构中的寄存器破坏问题。 * **驱动开发:** 创建了 UART 和定时器驱动程序,以实现基本的系统通信。 * **SMP(对称多处理)实现:** 通过实现 Peterson 算法进行同步,利用 68000 作为中断路由器,并克服了缓存一致性问题,实现了多处理器支持。 尽管性能极差且存在严重的总线竞争,该项目最终成功启动了 Linux 系统。作者指出,这次经历是一次极具价值的底层工程实践和持久实验。

一位开发者成功将 Linux 移植到了 Sega 32X 上,该项目建立在之前 Sega Jaguar 移植工作的基础上。尽管该硬件缺乏标准的同步原语,但该项目展示了在双 Hitachi SH-2 处理器上运行的对称多处理(SMP)Linux 实现。 开发者讨论中的要点包括: * **技术障碍:** 由于 32X 卡带接口在总线仲裁和内存访问方面的硬件限制,该移植目前主要在软件环境中运行。开发者指出,鉴于 Sega Saturn 拥有更优越的内存总线和现有的扩展能力,它可能是一个更切实际的后续目标。 * **架构:** 该项目使用了一个自定义通信通道,通过 Genesis 的 M68K 处理器转发 UART 数据来处理终端 I/O。 * **社区反响:** 该项目被拿来与“在 X 上运行 DOOM”相提并论,这是一种将操作系统移植到受限或非常规硬件上的经典极客尝试。 * **后续步骤:** 虽然目前的设置因总线争用而面临性能瓶颈,但创作者正在探索优化内存使用的方法,并可能将其扩展到其他复古硬件架构上。

AI 模型的定价往往具有误导性,因为广告中所宣称的“每百万 Token 价格”忽略了底层的成本驱动因素:**分词器(Tokenizer)**。 Token 并非固定的文本单位;不同的模型会将同一文件“切分”成不同数量的片段。在构建 AI 智能体(尤其是用于编程的智能体)时,这种差异会导致两种“隐性”成本: 1. **隐形涨价:** 供应商经常发布定价相同但更新了分词器的新模型,导致相同内容对应的 Token 数量增加。例如,从 Claude Opus 4.6 升级到 4.8 后,处理相同代码时 Token 数量增加了约 30%——这是一种变相涨价。 2. **跨供应商差异:** 不同模型处理语言和文件类型的方式各不相同。虽然英文散文在不同模型间的 Token 数量差异约为 1.4 倍,但在 AI 智能体主要处理的编程语言(如 TypeScript)中,差距最高可达 1.73 倍。 为了准确比较成本,开发者必须跳过标价。真实的成本应为:**(针对特定工作负载生成的 Token 数量)×(每 Token 价格)**。在选择模型时,开发者应当使用各自的代表性代码样本通过供应商的分词器进行测试,以计算每项任务的实际成本,而不是依赖误导性的标价。

抱歉。

你无需为了构建和发布 Mac 或 iOS 应用而苦苦纠结于 Xcode 的图形界面。通过利用 `xcodebuild`、`notarytool`、`stapler` 和 `devicectl` 等命令行工具,你可以实现完全无头(headless)的“代码直觉”工作流。 **工作流程:** 1. **准备工作:** 安装 Xcode 并通过 `xcode-select` 将其设置为默认工具链。 2. **项目管理:** 使用 **XcodeGen** 通过 `project.yml` 文件管理项目,这样你就可以在 Git 中忽略繁琐的 `.xcodeproj` 文件夹。 3. **一次性设置:** 手动执行必要的图形界面操作:登录 Apple ID、创建开发者 ID 证书,并将公证凭据存储在钥匙串中。 4. **自动化:** 创建一个 `release.sh` 脚本来处理归档、签名、公证、装订和部署。 5. **智能体集成:** 在代码库中创建一个 `CLAUDE.md` 或 `AGENTS.md` 文件。这相当于你为大模型提供的操作手册,使其能够自主执行完整的构建和部署流程。 虽然初始设置需要手动配置,但其回报是完全自动化的无头开发循环。一旦配置完成,你就可以将整个构建和分发过程交给 AI 智能体,将复杂的 Xcode 开发体验简化为一条指令即可完成的流程。

这次 Hacker News 的讨论探讨了通过 AI 驱动的命令行界面(CLI)开发和发布 macOS 及 iOS 应用这一日益增长的趋势,这种方式很大程度上绕过了 Xcode 图形用户界面。 支持者认为 Xcode 臃肿、容易崩溃,且往往会阻碍生产力。许多开发者成功利用 `xcodebuild`、`fastlane` 或自定义的 CLI 封装工具来处理构建、签名和公证。这些用户认为,像 Claude Code 这样的 AI 编程助手能够有效管理从代码生成到应用商店提交的整个生命周期,其速度往往快于在复杂的 Xcode 菜单中操作。 批评者和怀疑论者则指出了重大的权衡: * **安全风险:** 运行拥有广泛系统权限的 AI 代理存在泄露敏感数据(包括 SSH 密钥和环境变量)的风险。讨论强调了使用沙盒、独立用户账户或 Secure Enclave 等工具的必要性。 * **复杂性:** 构建一个可靠的非交互式流水线非常困难,特别是在涉及小组件、watchOS 目标或高级调试等复杂项目时。 * **苹果的限制:** 苹果生态从根本上要求使用 Mac 和经过苹果签名的凭证,这使得一些人认为“无 Xcode”工作流是不切实际的,或者与标准的 CI/CD 实践相比,这属于一种“定制化”的过度工程。 归根结底,虽然 CLI 方法提供了更多的控制权并减少了“臃肿”,但它需要大量的配置和对安全性的严谨态度。

*Ludus Coriovalli* 是一款古罗马策略游戏,在失传 1800 年后,通过 2025 年的一项突破性研究被重新发现。研究人员通过在荷兰海尔伦(前罗马城镇科里奥瓦卢姆)发现的一块石灰岩板确认了该游戏。专家们结合微观磨损分析与人工智能模拟(特别是 Ludii 通用游戏系统),成功从石头上留下的物理痕迹中重建了原始规则。 该游戏是一种在 19 个节点的棋盘上进行的非对称挑战。四只“猎犬”试图包围并阻截两只“野兔”,而野兔的目标是在 150 回合内生存下来或实现三次重复局面。猎犬依靠数量优势,而野兔则必须利用敏捷性进行逃脱。 该项目现已通过易于访问的网页平台,让玩家能够亲身体验这款游戏。用户可以在三个难度等级下与人工智能对手竞争,或进行本地双人对战,从而架起了历史考古与现代数字游戏之间的桥梁。这项研究发表于《古代》(*Antiquity*)期刊,证实了其游戏机制,标志着利用技术重建古代历史的一次重大成功。

研究人员通过结合人工智能驱动的模拟技术与对考古文物物理磨损痕迹的取证分析,重建了一款失传的古罗马棋盘游戏。这项发表在《古物》(Antiquity)杂志上的研究利用 Ludii 通用游戏系统模拟了数千种潜在的规则组合。通过应用 Alpha-Beta 搜索算法,研究人员确定了九种游戏配置,其模拟的游戏模式与在罗马棋盘上发现的物理证据相吻合。其中最可能的模型是一款采用四对二非对称设置的“阻挡”类游戏。 该项目可在 ludus-coriovalli.web.app 试玩,并在学术界和游戏界引发了争论。尽管一些用户赞赏这种复原失传历史的努力,但其他人则表示怀疑,指出该重建方案在很大程度上依赖于人工智能的假设,可能无法捕捉到古代玩法的细微差别。批评者认为,此类研究应被视为人工智能辅助的探索,而非定论性的历史事实;而支持者则强调了跨学科方法在考古学中的价值。这项重建工作增加了人们对复兴古代消遣活动的浓厚兴趣,此前类似的努力还包括对“乌尔王族局戏”(Royal Game of Ur)和“六博”(Liubo)的复原。

OpenClaw Machines 是一个开源、自托管的平台,旨在通过安全的硬件隔离沙箱运行 AI 智能体。与基于容器的解决方案不同,它使用 **Firecracker 微型虚拟机(microVM)**——每个微型虚拟机都有独立的客户内核和 KVM 边界——从而能够在您自己的基础设施上安全地执行不受信任或由智能体生成的代码。 **主要功能包括:** * **基础设施主权:** 在您自己的裸机服务器或云主机上运行控制平面和工作节点。通过利用自有硬件和本地 GPU 运行的模型,相比按 Token 或按智能体计费的托管服务,可显著提高成本效率。 * **稳健的架构:** 系统使用由 Cloudflare 支持的数据平面进行安全路由,隧道直接终止于微型虚拟机内部,确保不暴露任何宿主机端口。 * **集成生态系统:** 该平台内置支持浏览器自动化(Chromium 虚拟机)、实时终端、原生 MCP 工作空间集成(GitHub、Google 等)以及可观测性工具。 * **可扩展性:** 单台裸机服务器可在资源允许的范围内托管任意数量的隔离智能体,为 AI 开发提供一种固定成本的“微型云”。 OpenClaw Machines 采用 **Apache-2.0 许可证**发布,非常适合寻求专业级隔离、安全性和多智能体工作流成本控制的用户。

此网站的访问受到限制。 如果您认为这是错误, 请联系支持团队。 GitHub 状态 — @githubstatus

请提供您想要翻译的内容。

在 Hacker News 上疯传的网页游戏《Super Dario》已成为对当前人工智能行业的元评论。这款平台跳跃游戏由用户 `thepasch` 利用 GLM-5.2 和 Claude Opus 等 AI 模型开发,其设计初衷就是为了“营造氛围”且无法通关。 游戏中融入了讽刺元素,例如“代币最大化”(tokenmaxxing)道具和不断延后的截止日期,旨在嘲弄现代 AI 公司无休止的炒作周期和融资轮次。尽管一些用户批评该游戏物理机制存在漏洞且碰撞判定糟糕,但也有人称赞它是一部精彩的讽刺作品,捕捉到了当下科技圈的荒诞感。 开发者欣然接受了批评,并指出游戏没有结局——玩家只能重置或关闭标签页——这正是目前 AI 泡沫最真实的模拟。Hacker News 上的讨论聚焦于 AI 生成代码的局限性、利用 AI 工具批判行业的“诗意”,以及关于这些模型究竟是具备独立软件工程能力,还是仅仅精通“基于氛围”的模仿这一持续争议。该游戏目前已可在桌面和移动端游玩。

许多网络运营商目前仍在维护双栈基础设施,这迫使他们不仅要管理复杂且低效的 IPv4 子网和容易引发运维风险的 ARP 协议,还要同时维护现代化的纯 IPv6 网络架构。 IETF 拟议的草案 *draft-vanmook-intarea-ipv6-resolved-gateway* 提供了一种解决方案:将 IPv4 视为纯 IPv6 传输层上的一种服务,而无需进行翻译或隧道封装。通过引入一个“哨兵”IPv4 地址(192.0.0.11),该机制允许主机通过现有的 IPv6 邻居发现协议(Neighbour Discovery)来解析网关的 MAC 地址,从而取代了 ARP。 这种方法具有以下几个主要优势: * **消除 ARP:** 消除了广播风暴、缓存中毒和表项耗尽等问题。 * **简化运维:** 用高效的 /32 主机寻址和通用网关地址取代了传统的子网划分。 * **平滑过渡:** 该设计具有向后兼容性;未经修改的主机仍可使用传统的 ARP,而更新后的系统则能获得这种更安全的新功能。 目前,该提案正在 IETF IntArea 工作组讨论中,旨在将各大主机服务商目前使用的临时解决方案标准化。我们鼓励运营商支持该草案的采纳,以便彻底摆脱传统 IPv4 网络架构带来的运维负担。

到 2000 年代初,诺基亚已是全球无可争议的移动通信领袖,凭借 3310 和 1100 等标志性且耐用的设备定义了一个时代。尽管诺基亚取得了巨大的成功,并且内部也意识到了行业变革(包括多点触控技术的潜力),但在智能手机革命到来时,公司却难以实现转型。 2007 年 iPhone 的问世让诺基亚措手不及,随后试图与之竞争的努力又因开发缓慢和操作系统陈旧而受阻。虽然诺基亚在低端市场一度保持了统治地位,但安卓系统的崛起最终也侵蚀了这一堡垒。内部官僚主义以及未能将尖端研发成果商业化,导致该公司无法跨越从传统手机到现代智能手机时代的鸿沟。 2014 年,诺基亚以远低于其巅峰时期的价格将手机业务部门出售给了微软。虽然手机业务走向衰落,但公司通过将重心转向电信基础设施,成功实现了自我重塑。如今,诺基亚依然是 5G 技术的全球领导者,为曾经未能掌握的现代智能手机提供了网络主干支持。

关于诺基亚手机业务衰落的讨论,核心在于其转向 Windows Phone 系统究竟是致命的错误,还是身处危机之中的必然选择。 许多观点认为,诺基亚衰落的根源在于错失了触屏手机的革命浪潮,且无法适应“平台化”的经济模式。尽管搭载 MeeGo 系统的诺基亚 N9 常被称赞为超前且精致的高品质设备,但质疑者指出,它缺乏与迅速崛起的 iOS 和 Android 双寡头竞争所必需的强大应用生态系统。 与之相反,也有人认为转向 Windows Phone 是其“丧钟”,这不仅疏远了粉丝,还因微软不稳定的应用支持和糟糕的管理而归于失败。另一些观点则主张,诺基亚作为一家硬件导向型公司本已陷入困境,而微软的收购为其作为网络通信公司生存提供了必要的资金。总而言之,舆论普遍认为,尽管诺基亚的技术产出常属世界一流,但该公司深受内部决策摇摆、软件策略碎片化以及未能意识到从专有硬件向应用驱动型平台生态转变的影响。

简介 在 Java 中测量对象的大小并非易事。该平台鼓励开发者关注引用和抽象,而非原始内存占用。尽管如此,了解对象在内存中的实际分布仍能带来显著收益,尤其对于高性能、低延迟的系统而言。随着时间推移,JVM 引入了诸如压缩普通对象指针(Compressed Oops)以及最近的紧凑对象头(Compact Object Headers)等优化技术。这些因素都会影响对象的大小。理解这些因素有助于您更具体地推断内存使用情况。 测量对象大小 原则上,您可以通过创建实例并观察 JVM 空闲内存的变化来估算对象大小。然而,为了获得一致的结果,必须排除某些干扰因素。例如,关闭 TLAB 分配(-XX:-UseTLAB)可以使内存使用情况更直接地被观察到。通过重复测量并计算中位数,可以减少……

抱歉。

更多

联系我们 contact @ memedata.com