在 2022 年 Hackaday 超级大会上展示了自制二极管真空管后，作者为《Make:》杂志详细记录了整个制作过程。本摘要概述了在家中制造功能性真空管所涉及的技术挑战与方法。
最关键的步骤是使用“压封法”（pinch method）制作管座。通过清洁钨针并加热使其与硼硅酸盐玻璃熔合，作者实现了真空密封。管座准备就绪后，将钨丝灯丝和镍板等内部元件点焊到位，并加入一种钡基“吸气剂”来吸附残留的氧气。
随后，将组件密封在玻璃壳中，并连接到真空系统上。在将真空管抽至 10⁻⁵ mbar 并通过加热对内部元件进行除气后，作者执行了“封离”（tip-off）工序以永久密封真空管。最后，通过感应加热器激活吸气剂，形成一面反应镜以维持真空状态。尽管作者最终将该真空管测试至损坏，但这一成功的制作过程证明，只要掌握正确的方法并持之以恒，业余爱好者也能制造出高质量、功能完备的真空电子元件。
每日HackerNews RSS
惠普推出了 **ZGX Fury AI 工作站**，这是一款基于 NVIDIA GB300 Grace Blackwell Ultra 超级芯片构建的企业级推理强机。该设备拥有 748GB 统一内存和高达 20 petaFLOPS 的 FP4 计算能力，专为部门级和边缘计算环境设计，可作为无需传统数据中心的“本地 AI 工厂”。
硬件亮点包括液冷散热、400Gbps 网络连接，以及既可作为塔式工作站也可作为 5U 机架式设备使用的灵活设计。该系统预装 Ubuntu 系统及惠普专有的 AI 管理工具（Z Runtime 和 Z Toolkit），而其最重要的进展是与红帽（Red Hat）及 NVIDIA 的合作。此次协作旨在将“Red Hat AI Factory with NVIDIA”部署在 ZGX Fury 上，提供企业级的编排、安全性和工作负载隔离功能，以简化本地 AI 部署。
作为一种先进的边缘基础设施解决方案，ZGX Fury 允许团队实现工作流从原型设计到生产环境的无缝衔接。尽管目前尚未公布价格，但该系统现已开放订购，惠普正借此在高性能本地 AI 工作站市场与微星（MSI）和 AMD 等新兴竞争对手展开角逐。
抱歉。
作者赞扬了 NetBSD 的高移植性软件包管理器 **pkgsrc**，称其通过将已安装软件与基础操作系统分离，从而保持系统的整洁。与通常会弄乱 `/bin` 或 `/lib` 等系统目录的标准软件包管理器不同，pkgsrc 将软件安装在独立的子目录中（例如 `/usr/pkg` 或用户的主目录）。
除了在各种类 Unix 系统（Linux、macOS、Solaris）上的高移植性外，作者还强调了从源代码构建软件包的优势。Pkgsrc 本质上是一系列 Makefile 的集合，它从去中心化的位置获取源代码（“distfiles”），有效地将软件包管理与单一中央服务器解耦。
对作者而言，其最大的吸引力在于“非特权模式”，该模式允许构建一个无需 root 权限的自定义本地用户环境。此外，作者还强调了该项目的韧性，并指出由于 pkgsrc 使用去中心化的源并支持镜像重定向，因此完全可以在离线状态下构建软件。这使得 pkgsrc 成为那些重视自主性、系统整洁度以及构建自托管、独立软件环境能力的用户的理想工具。
最近的一场 Hacker News 讨论凸显了 **pkgsrc** 的持久魅力，这是一个源自 NetBSD 社区、基于源代码的通用软件包管理系统。
用户称赞 pkgsrc 的可移植性，使其不仅能在 NetBSD 上，还能在多种操作系统中实现一致的软件管理。其以非特权模式（安装到用户主目录）运行的能力被视为保持基础系统整洁的一大优势。支持者认为，它的长处在于管理复杂的依赖链，并提供了一种应用必要补丁的标准化方法，这远比手动从源码构建软件包高效。
讨论帖还将 pkgsrc 与 **Spack** 和 **Easybuild** 等现代构建工具进行了对比。这些工具在高性能计算（HPC）领域很受欢迎，且正逐渐被普通用户所使用。批评者和爱好者们探讨了此类系统的利弊：一些人认为“ports”风格的管理方式优雅、稳健，非常适合离线或定制环境；而另一些人则觉得它缺乏预编译二进制管理器所具备的快速和便捷。归根结底，这场讨论突显了一种遗憾，即像 pkgsrc 这样统一的跨平台软件包管理器，最终没能成为 Linux 行业的标准。
“压缩即预测”这一观点在数学上是成立的，但并不完整。虽然这两个概念相互关联——概率模型的累积对数损失对应于编码比特流的理想长度——但这种等价性只有在确定了几个关键参数后才成立。 在进行预测之前，编码器和解码器必须就以下内容达成一致： 1. **对象族**：明确被压缩的对象是什么，以及什么样的重建结果才算无损。 2. **信息边界**：区分哪些知识是预先共享的，哪些是必须传输的（例如模型的参数）。 3. **操作约定**：如随机访问或部分解码等需求，这些需求可能会导致必须引入增加总比特长度的结构。 虽然柯尔莫哥洛夫复杂性和计数界限在不假设概率模型的情况下定义了描述的极限，但实际的压缩通常使用序列模型来缩短比特流。然而，一个在训练数据上实现对数损失最小化的模型，在处理未来数据时表现可能不佳，或者在计入存储模型的成本后，会导致文件变得更大。 总之，这一口号只有在编码问题被完整定义之后才成立。它描述了给定模型下的理想负载长度，却忽略了决定压缩方案是否真正实用的基本结构和上下文前提。
这则 Hacker News 评论探讨了一篇关于压缩与预测之间联系的文章。评论者将该文与香农的“赶时髦”（Bandwagon）论文联系起来，指出虽然计算神经科学领域存在各种宏大的规范性理论，但诸如信道容量定理之类的概念，很少能转化为具有实际解释力或技术价值的成果。
该评论进一步将此与纳夫塔利·提什比（Naftali Tishby）关于深度学习训练动态的信息瓶颈理论进行了类比。最终，用户质疑这些信息论方法是否正被积极用作大语言模型的训练目标，还是仅仅停留在哲学辩论的理论探讨层面。
所有 3,915 条轨道在地图上各有一席之地。外观相似的轨道彼此相邻，形成一个个“岛屿”，每个系列都有专属页面。从远景看地图如同一片星系，近看每条轨道都在实时运行；点击任何一条轨道即可进入独立页面，以单周期方式播放，还可以对其进行微调、评分以及在对战中进行排名。动画和地图功能需要 JavaScript 支持，本页面的其余内容均已在此呈现。
OpenArch – 现代大语言模型架构的 PyTorch 实现 OpenArch – PyTorch implementations of modern LLM architectures
36 天前
该代码仓库提供了一系列具有教育意义的手写 PyTorch 实现，涵盖了现代大语言模型（LLM）架构。本项目灵感源自 Sebastian Raschka 的 LLM 架构画廊（LLM Architecture Gallery），与 `transformers` 等生产级库中的性能优化代码不同，本项目优先考虑代码的可读性和结构清晰度。 每个模型都包含在各自的目录中，能够直观地展示架构细节，例如注意力机制（MHA、GQA、MLA）、归一化策略以及 MoE 路由等——这些细节在经过高度优化和分布式处理的代码库中往往难以察觉。目前，该项目已包含 Llama 3、DeepSeek R1 和 Qwen 3 等主流模型的可用实现，并计划覆盖画廊中的全部 72 种架构。 作为一个学习资源，该仓库为那些希望从零开始理解现代大语言模型构建方式的学习者提供了理想的参考。作者欢迎社区贡献，包括新的模型实现、文档编写和测试，前提是这些贡献需秉持本项目清晰易懂的教育宗旨。所有代码均在 Apache License 2.0 许可下发布。
XCancel 服务已暂停。遗憾的是，由于正在进行的法律诉讼出现了新情况，我们被要求再次暂停此项服务，直至另行通知。我们无法提供更多细节。您可以在原始网站上找到您要查找的内容：继续访问 X。感谢您的理解，以及您对 XCancel 项目的信任。
作者通过以下三点反思，探讨了舞蹈的机制与哲学： **1. 足部即平面：** 稳定性始于足部。由于缺乏使用，足部往往会退化，从一个稳定的平面变成一条窄线或一个单一的接触点。重获动作能力需要通过耐心且刻意的训练，使足部重新发挥支撑基础的作用。 **2. 本体感觉的能动性：** 作者质疑了为何有些学生难以复刻动作。他们摒弃了“学习风格”这一迷思，推测所谓的“笨拙”可能源于发育过程中或创伤导致的与自身身体的脱节。一些舞者在自己的身体里仿佛“外来者”，难以跨越认知意图与身体执行之间的鸿沟。 **3. 连接的物理学：** 作者对“连接”一词模糊且玄学的用法提出了挑战，主张采取一种物理学、颗粒化的研究方法。通过放慢舞伴互动中的动作机制，可以识别出具体的失误环节。尽管情感上的开放不可否认，但作者认为，舞者应追求更高的自我觉察，通过分析自身的生理与心理状态，从而更好地理解舞蹈成功或失败的原因。
抱歉。
LIVE地图显示了过去52周的鸟类观测数据，其中99%的条目每天更新。然而，由于部分在线门户网站报告数据的间隔较长或不规律，某些地区在最近几周可能会显示为空白。 用户在解读这些地图时应保持谨慎： * **数据不完整：** 最近一周的数据可能尚未统计完毕；请查看地图页脚以获取所包含的具体天数。 * **准确性：** 由于更新具有近乎实时的特性，在自动化验证协议修正之前，一些错误记录可能会暂时出现。 * **延迟：** 各门户网站的更新频率不同。虽然许多来源的数据在1-2天内即为最新，但其他来源的数据可能已是几周甚至几个月前的。 请务必查阅所提供的门户网站列表，以核实特定地区数据的时效性。
抱歉。
**FRANK** (frank.rh1.tech) 是一款专为树莓派 Pico 2 (RP2350) 设计的高性能 i386 PC 模拟器。它基于何春晖（Chunhui He）的 *Tiny386* 开发，使 RP2350 开发板能够运行 DOS、Windows 3.x、Windows 95 以及 Linux 系统。
**主要功能：**
* **硬件模拟：** 完整的 i386/i486/i586 CPU 模拟，可选 x87 FPU，支持最高 8MB PSRAM。
* **外设支持：** 支持 VGA/HDMI 输出、用于磁盘镜像（软盘/硬盘/ISO）的 SD 卡存储、PS/2 或 USB 键盘/鼠标，以及 NES 手柄支持。
* **音频：** 包含模拟的 AdLib (OPL2)、Sound Blaster 16、PC Speaker、Tandy、Covox 和 Disney Sound Source。
* **用户界面：** 提供运行时磁盘管理器（Win+F12）用于热插拔镜像，以及设置菜单（Win+F11）以便即时调整硬件配置。
**技术要求：**
该固件支持多种 RP2350 开发板（M1、M2、Olimex PC、Waveshare Z2），并要求 SD 卡中配置 `bios.bin`、`vgabios.bin` 和 `config.ini` 文件。构建选项允许对 CPU（最高 504MHz）和 PSRAM 进行超频，并针对 USB-HID 和视频输出提供了特定的标记。该项目基于 MIT 许可证开源，集成了包括 SeaBIOS 和 FatFs 在内的多个成熟模拟库。
一个在 Hacker News 上展示的项目通过树莓派 RP2350 微控制器模拟了 386 电脑。社区对此反响热烈，并称赞这款售价 1 美元的单片机能够模拟 VGA 和 SoundBlaster 等传统硬件，令人印象深刻。
讨论主要集中在以下几个核心议题：
* **性能与架构：** 尽管 RP2350 的 PIO（可编程 I/O）模块及其灵活性广受好评，但一些用户对其与 ESP32 等其他单片机的性能对比提出了质疑。讨论还涉及了内存访问延迟与 16 位 x86 软件对时序敏感性之间可能引发的瓶颈问题。
* **复古计算情怀：** 该帖引发了用户对往昔的回忆，大家纷纷谈起在 386 系统上运行 Windows 95 的艰辛、通过软盘安装 Slackware 的繁琐过程，以及关于 EMACS（戏称为“8MB 内存且不断交换”）的著名梗。
* **未来潜力：** 一些评论者探讨了使用 LPC 等现代协议来连接旧硬件，或是打造模块化“现代 ISA”卡的可能性。
总体而言，尽管仍有人对其实际应用于工业旧设备持怀疑态度，但社区普遍认为该项目是现代单片机应用领域的一项卓越成就。