在 IBM PC 问世之前，小型计算机运行的是 CP/M 操作系统，其所使用的处理器架构与 PC 不同。os8088 现已模拟了该处理器，因此你可以在此运行 CP/M 软件：包括提示符下的 1979 年命令行处理器、Microsoft BASIC、汇编程序和编辑器，且运行在一个可随意拖动的窗口中。该程序用 4,679 行 C 代码模拟了一颗 Zilog Z80 处理器，运行频率为 4.77 MHz 的 8088。
每日HackerNews RSS
**os8088** 是一款创新的业余操作系统，采用 16 位 x86 汇编语言编写，旨在从原始的 8088 CPU 到现代处理器等各类硬件上运行。该项目支持 CGA/VGA 显卡、Sound Blaster 声卡和 NE2000 网卡等传统硬件。其显著功能包括 CP/M 2.2 模拟器、MS Word 1.1a 等经典应用程序的移植版本，以及一个功能齐全的网页浏览器。
该项目在 Hacker News 上引发了关于人工智能在软件开发中作用的广泛讨论。虽然开发者 jggonz 利用人工智能来加速编码和文档编写，但一些批评者认为这会产生“AI 垃圾内容”或降低对底层技术的深入理解。然而，支持者强调，人工智能使个人开发者能够完成原本需要数月时间才能实现的复杂复古计算项目。
讨论帖中的技术探讨强调了在老式机器上实现现代网络功能的极大挑战，例如在内存有限且运行速度为 4.77 MHz 的 CPU 上进行 TLS 握手，以及“主权计算”的潜力——即通过低成本、可信的硬件，为现代监控严重的系统提供一种注重隐私的替代方案。该操作系统的在线演示可在 [os8088.com](https://os8088.com) 查看。
我们写下的每一个字，目前都在被人工智能实验室采集、转化为数据，并加工成驱动大型语言模型的数学权重。作者反思道，虽然自己的文字如雪崩中的一片雪花般微不足道，却已成为未来人工智能发展中永久且不可或缺的一部分。无论这项技术是被用于重大的数学发现，还是被用于恶意的黑客攻击，作者都意识到自己已被“统计学式地抹平”并融入了这些模型的基石之中。这种认知改变了作者对内容创作的看法；既然深知自己的文字本质上是未来人工智能的基石，作者认为自己应当以更明确的目标和更高的质量进行创作。
抱歉。
**Xwayland 26.0.99.901 发布（发布候选版）** Olivier Fourdan 宣布了即将推出的 Xwayland 26.1.0 的首个发布候选版（rc1），标志着自 Xwayland 24.1 以来的重大更新。 **主要改进包括：** * **剪贴板集成：** Rootful 模式的 Xwayland 现已支持剪贴板和主要选择（primary selection）桥接（通过 `-clipboard` 启用），可与 Wayland 桌面实现无缝复制粘贴。 * **多席位（Multi-seat）支持：** Wayland 的席位（seat）和设备现已映射至 XInput 2 层级结构中。 * **兼容性增强：** 包含对 `wl_fixes`（destroy_global/ack_global_remove）和 `xdg-system-bell` 协议的支持。 * **RandR 与显示改进：** RandR 仿真现在优先使用原生分辨率并考虑屏幕旋转；Rootful 全屏模式默认使用实际输出分辨率，而非进行缩放。 * **清理工作：** 移除了对 EGLStream 的支持。 此版本凝聚了超过两年的开发成果，包括大规模的代码清理、大量的安全修复以及现代化的构建流程。鼓励用户和维护者测试此候选版本，并将任何问题报告至 X.Org GitLab 问题追踪系统。 源码压缩包及签名可在 [X.Org 存档](https://xorg.freedesktop.org/archive/individual/xserver/xwayland-26.0.99.901.tar.xz) 获取。
Xwayland 24.1.0 rc1 版本的发布移除了对 EGLStream 的支持，这在 Hacker News 上引发了关于 Linux 桌面现状的激烈辩论。
Wayland 的支持者认为这是一场必要的演进，并列举了 HDR、VRR（可变刷新率）和分数缩放等功能——这些功能在老旧的 X11 协议上很难甚至无法妥善实现。他们主张，尽管 Wayland 的实现较为碎片化（每个合成器都必须处理自己的协议）且显得杂乱，但它为现代硬件提供了更优越的基础。
相反，许多用户表达了强烈的不满，特别是在屏幕共享、稳定性和 Wayland 的“重策略”特性与 X11 的“机制优于策略”理念的对比上。批评者指出，即使经过了 15 年，在不同的合成器之间实现一致的屏幕共享和可靠的窗口管理等基本任务依然存在问题。一些用户因为 X11“开箱即用”而回归，另一些用户则在审慎地关注着像 Xlibre 这样旨在复兴 X11 的项目。
归根结底，这场讨论凸显了深刻的分歧：一方优先考虑现代显示标准和面向未来的能力，而另一方则优先考虑可靠性、灵活性以及遗留 X11 生态系统的简洁性。
在毕生致力于制造盖革计数器后，作者打造出了一款终极的、高灵敏度且节能的便携式模拟盖革计数器。该装置专为测量低水平辐射而设计，配备了一根大型 J306β 探测管，无需复杂的数字平均运算即可实现稳定的模拟读数。
该电路效率极高，仅靠一节 AA 电池即可运行超过 2000 小时。它利用定制的脉冲频率调制反激式转换器为探测管提供所需的 400V 电压，并辅以一个简单的 5V 升压转换器。设计侧重于简洁与实地应用，配备了一个双量程模拟表头用于实时扫描，并配有声音提示反馈。
该设备采用定制蚀刻 PCB 板制造，封装在紧凑的外壳中，盖革管安装在外部以实现最佳的辐射捕获效果。虽然作者承认该设备是针对相对测量而非实验室级绝对精度进行校准的，但它在检测花园肥料中钾-40 的天然辐射方面表现出色。该项目是一个实用的“开箱即用”工程解决方案，证明了在某些便携式应用中，专业的模拟电路仍优于数字替代方案。
抱歉。
Inco AI 发布了 **DFlash 2**，这是投机采样（speculative decoding）技术的一次重大演进，旨在解决“智能体时代”的推理瓶颈。传统的自回归解码速度较慢，而 DFlash 2 通过并行草稿机制同时预测多个 token 块，显著提升了吞吐量。 基于初代 DFlash 的成功（该版本下载量已超过 350 万次，并被 NVIDIA 和 Meta 等行业巨头采用），DFlash 2 推出了两项关键创新： 1. **轻量级路径选择器：** DFlash 2 不再仅依赖单一的最佳候选 token，而是保留每个位置的前 16 个候选项，并通过对相邻对进行评分，确保整个草稿块的逻辑连贯性。 2. **动态短卷积：** 该技术取代了以往为修复“后缀衰减”（即块末尾准确率下降）而添加高计算成本 Transformer 层的方法，能以极低的延迟开销有效地模拟局部依赖关系。 这些功能结合使用，使接受长度（acceptance length）提升了 16%–25%，吞吐量达到标准自回归解码的 2.7–4.6 倍。DFlash 2 现已集成于 SGLang、vLLM 和 llama.cpp 等主流引擎中，为高需求的智能体工作流提供了一种高效且可扩展的解决方案。
关于 **DFlash 2**（由 inco.ai 开发）的 Hacker News 讨论主要集中在其技术性能以及投机采样（speculative decoding）中潜在的缺陷上。
讨论的一个核心争议点是演示视频中 DFlash 2 在调用工具时生成了无效的 Python 语法。一些用户认为 DFlash 2 应当是“无损”的，即输出结果应与目标模型完全一致；而另一些用户则解释称，非贪婪采样可能导致生成路径出现偏差。尽管投机采样的数学原理旨在保留概率分布，但参与者指出，伪随机数生成（PRNG）和草稿生成过程中的差异可能导致输出结果与标准推理有所不同，这或许可以解释视频中出现的语法错误。
在实际应用方面，用户分享了性能指标，部分用户报告称在 DGX 硬件上使用 vLLM 和 Qwen 模型时，速度可达每秒 27 个 token。技术人员还讨论了实施过程中的挑战，特别是为了支持优化的 FP8 `lm_head` 配置所需的补丁。该讨论帖还包含了将 DFlash 2 集成到 vLLM 和 llama.cpp 等主流推理引擎的正在进行中的拉取请求（pull request）链接，凸显了社区对采用该技术以实现更高效低内存带宽模型使用率的兴趣。
访客：上方地图显示了我们数据库中 3300 多台机器中的 2000 台。如果您想搜索某个区域，请使用搜索框。© Penny Presses 保留所有权利。设计：HTML5 UP
抱歉。
铜是全球绿色转型中至关重要且不可替代的支柱。其高导电性和耐用性使其成为电动汽车、可再生能源基础设施和电网现代化不可或缺的材料。然而，受需求激增、供应停滞、矿山开发周期长以及地缘政治不稳定性等因素驱动，一场即将来临的“铜荒”正威胁着脱碳进程，并可能推高成本。 分析人士警告称，如果产量无法提升，由此导致的短缺可能通过项目延误、通胀压力和消费者价格上涨影响全球经济。由于开发新矿山需要 10 至 15 年，采取行动的时间窗口非常有限。 为降低这一风险，需要采取多管齐下的方针： * **负责任的生产：** 简化可持续采矿的审批流程，并扩大冶炼产能。 * **循环经济：** 扩大城市采矿和回收计划，以回收现有的铜库存。 * **创新：** 通过更智能的设计提高材料利用效率，并在技术可行的情况下进行选择性替代。 * **政策与战略：** 政府和企业必须将金属供应安全纳入气候模型，建立长期承购协议，并实现供应链多元化。 铜危机是一个结构性挑战，而非暂时性的问题。主动投资和战略规划对于确保材料限制不会阻碍我们的气候目标至关重要。
抱歉。
`WINSTART.BAT` 最初于 Windows 3.1 中引入，并在 Windows 95 中得到应用，它是一种专门用于在 Windows 环境下加载“内存驻留”（TSR）程序的机制。 `AUTOEXEC.BAT` 在 MS-DOS 初始启动时运行，会将 TSR 程序全局加载到所有虚拟机中；而 `WINSTART.BAT` 的执行时间较晚——即在虚拟机管理器初始化“系统虚拟机”之后，但在 Windows 用户模式内核启动之前。 由于 `WINSTART.BAT` 在系统虚拟机中运行，通过此方式加载的 TSR 程序仅对 Windows 程序可见，而对后续单独启动的 MS-DOS 命令提示符虚拟机则是隐藏的。这种架构允许用户通过避免全局安装驱动程序来为 MS-DOS 程序节省常规内存，或者加载与多虚拟机环境不兼容的驱动程序。简而言之，它提供了一种将特定 TSR 程序隔离在 Windows 会话中的方法。
这篇 Hacker News 帖子围绕着一篇关于晦涩难懂的 `winstart.bat` 文件的文章，讨论了基于 DOS 的 Windows（3.x/9x）系统“考古”般的复杂性。
参与者就早期 Windows 与“成熟”的 NT 架构背后的工程理念展开了辩论。一些用户将基于 DOS 的 Windows 视为资源受限环境下的工程奇迹，指出它就像一个轻量级的虚拟机监控程序，通过虚拟机来管理 DOS 应用程序。而另一些人则反驳称，这种“拼凑”出的遗留产物本质上是一种局限，并将其与 NT 在内存保护、内核/用户空间分离以及安全性方面的规范化设计进行了对比。
讨论的一个重点是微软在弥合传统 DOS 兼容性与现代 32 位计算之间差距的策略。许多评论者对那个时代表达了怀旧之情，将其视为“经济性与局限性”的杰作。尽管承认基于 DOS 的系统系列存在不稳定性，但贡献者们认为，在向现代图形用户界面过渡的同时，维持如此高水平的向后兼容性所需的工程能力是一项深刻的成就，它使用户能够循序渐进地迁移，而非被迫转换。这篇帖子最终向在严苛技术限制下支持早期 PC 用户所需的独创性致敬。
在发现一台滚轮损坏并被废弃的 Cricut Maker 后，作者决定尝试进行维修，尽管他知道该机器很可能已被制造商“停用”。
在更换滚轮并确认硬件功能正常后，作者绕过了被软件锁定的序列号。由于直接修改 EEPROM 和拦截网络数据较为困难，作者利用树莓派 RP2040 作为 USB 代理。通过在硬件层面拦截并重写机器与计算机之间的序列号数据包，作者成功欺骗了 Cricut 软件，使其将该设备识别为一台全新的激活设备。
虽然作者承认可能存在更简单的软件破解方法，但这种硬件代理方案成功使机器恢复了全部功能。出于对版权法潜在法律风险的考虑，作者选择不公开具体代码，但指出该方案是基于标准的 USB 通信库实现的。该项目有效地将电子垃圾变成了一台功能齐全的工具。
这篇 Hacker News 的讨论聚焦于“被锁定”或“变砖”硬件所带来的挫败感，特别是针对 Cricut 机器及其限制性的云依赖生态系统。
参与者批评那些将禁用可用硬件作为商业模式一部分的公司，并指出 Cricut 的软件强迫用户进入一种狭窄且重度依赖订阅的工作流程，这往往会抑制创作自由。许多用户分享了为完成基本任务而与软件“斗争”的经历，导致一些人建议这些机器更适合喜欢折腾的爱好者，而另一些人则完全劝阻购买。
替代方案是讨论的主要议题，许多人推荐 Silhouette 或 Graphtec 切割机，因为它们能更好地与 Inkscape 和 Inkcut 等开源工具集成。技术交流探讨了对这些设备进行逆向工程的可行性，一些用户建议用 GRBL 或 FluidNC 等开源方案替换内部控制器，以使硬件摆脱专有限制。最终，共识是用户应优先选择不依赖限制性远程服务器的硬件，因为即使“破解”一台被锁定的机器是可能的，但与选择更开放的竞争对手相比，所付出的努力往往得不偿失。
要使用 Mastodon 网络应用，请启用 JavaScript。或者，尝试为您所在的平台选择一款 Mastodon 原生应用。
谷歌已大幅限制对 Pixel 设备源代码的访问，将原本自动化的 Git 标签更新转变为一种繁琐的手动流程：用户必须填写表格并等待 Google Drive 链接。
GrapheneOS 团队指出，谷歌已不再将 Pixel 设备视为 AOSP 参考设备，并已停止向公共代码库推送内核和驱动更新。尽管谷歌坚称这种“手动”系统在技术上符合 GPL 协议的条文，但 GrapheneOS 反驳称，这种蓄意拖延数周的做法以及移除 Android 标准构建系统所必需的元数据，违反了该协议的“精神”。
GrapheneOS 认为，此举旨在增加人为阻碍，专门针对该项目为用户提供安全保障的能力。由于谷歌拒绝采用本可轻松实现自动化的分发方式，这种持续的低效与落后迫使 GrapheneOS 将工作重心转向与摩托罗拉等其他厂商的合作。社区中许多人认为，这是谷歌旨在加强中心化控制、扼杀第三方 ROM 开发，并迫使用户进入更封闭、专有生态系统的一项广泛举措。