此档案包含来自 SAIL-DARTS 项目的软件，具体来说是 1975 年 1 月在 PDP-10 机器（SUMEX、KI-10）上使用 Interlisp 语言开发的程序代码。代码源自 Bruce Baumgart 的收藏，并在相关的博士论文（ADA155378.pdf）中有详细说明。 核心文件 – LT、TA、TB 和 CON6 – 旨在按顺序加载，其中 CON6 是较新的补充。该系统利用 256k 核心内存，Interlisp 本身占用 140k，但提供额外的“阴影空间”用于编译后的代码。 由于其 ARPA 资助，并且论文明确鼓励使用、修改和分发，因此认为该软件属于公共领域。更多文档和相关文件可以在 SAILDART 档案中找到（[https://www.saildart.org/[AM,DBL]/](https://www.saildart.org/[AM,DBL]/)），有关 DBL 区域的信息可在 EURISKO 项目 wiki 上找到。Discord 服务器（[https://discord.gg/vhsmVCwgvK](https://discord.gg/vhsmVCwgvK)）可用于讨论。
每日HackerNews RSS
一篇 Hacker News 帖子介绍了道格拉斯·莱纳特（Douglas Lenat）的“自动数学家”的源代码，该项目是 1970 年代具有历史意义的早期人工智能项目。这个符号人工智能系统是 Cyc 和 Eurisko 等项目的先驱，旨在利用规则和符号来发现和证明数学定理。
尽管在当前性能上已被大型语言模型（LLM）超越，但评论员指出它作为人工智能先驱的重要性，展示了任务之间的早期知识迁移——例如将芯片设计中的策略应用于游戏。该系统甚至在 1980 年代通过 Eurisko 激发了超人游戏能力。
讨论承认符号人工智能在取得突破之前经历了停滞期（“人工智能寒冬”），这与神经网络发展的类似模式相呼应。这次发布提供了一窥现代深度学习之前的早期人工智能工作，其灵感来自雄心勃勃的 Cyc 项目的同一思想。 附加链接分享了相关的 SAIL（斯坦福人工智能实验室）材料，包括一部电影甚至一个 D&D 角色表。
## webminal.org：一个持续15年的Linux学习平台 webminal.org是一个非常坚固的在线平台，自2011年以来一直在浏览器中提供真实的Linux终端，运行在一个单独的8GB CentOS服务器上——没有云服务、微服务或自动扩展。该网站由一位自学Linux的开发者创建，旨在为练习命令和系统管理技能提供一个无风险的环境。 最近，webminal.org经过重新设计，采用了现代、轻量级的前端，现在提供“Root Labs”，利用用户模式Linux实现完全root权限和使用`fdisk`和`systemctl`等工具进行真实练习。一个实时命令滴答器显示匿名化的实时用户活动，由eBPF提供支持。 该平台使用一种故意过时的（但功能完善！）技术栈构建——Python 2.7、Flask 0.12.5和令人惊讶的强大的Shellinabox，已经服务了超过50万用户。完全由创始人的个人储蓄资助，webminal.org仍然是免费的，优先考虑学生的可访问性，并继续运行，只要它能帮助哪怕一个学习者。该项目正在寻求赞助，以升级服务器资源并扩展对其流行的Root Labs的访问权限。
## Webminal：在极简资源下坚持15年
Webminal (webminal.org) 仅用一台服务器、8GB内存，却令人瞩目地运行了15年，目前已服务50万用户。该项目源于资金有限的必要性，优先考虑巧妙的优化而非横向扩展。
其成功的关键在于用户模式Linux (UML)，以及SELinux、XFS等技术，以及细致的资源管理（如MySQL配额）。创始人最初在家中托管服务器，依靠Linux社区的信任，之后迁移到云提供商，利用可用额度。
该服务提供基于浏览器的终端，因其易用性和零配置而备受推崇，尤其吸引初学者。尽管由于服务器位置（新加坡）存在延迟，但该项目仍在蓬勃发展，证明了一个“足够好”的解决方案，加上一个专注的社区，可以胜过资源密集型的替代方案。它证明了足智多谋的工程技术，并提醒人们互联网的 simpler 时代。该项目目前由Github Sponsors支持。
## 演示场景中技艺的演变
演示场景，一种专注于在有限硬件上创作令人印象深刻的视听演示的亚文化，与复制和原创性有着复杂的关系。早期的艺术家经常“借用”图形——特别是来自像鲍里斯·瓦列霍这样的知名创作者的奇幻和科幻艺术——并非为了创新，而是为了展示他们一丝不苟地逐像素重现的*技巧*。扫描仪昂贵，因此手工像素化、抖动和抗锯齿等技艺至关重要，通常甚至比原创想法更重要。
这种最初被接受的做法逐渐演变。随着工具的改进（扫描仪、Photoshop）和普及，直接扫描并将作品冒充原创的行为出现，被认为是一种低地位的“作弊”。大约在2000年左右，人们开始重视原创性，尽管复制仍然存在。
今天，随着生成式人工智能的兴起，这场争论仍在继续。虽然有些人认为人工智能只是另一种工具，但演示场景中的许多人更看重*过程*以及通过专注的技艺赋予的独特“灵魂”。演示场景仍然是一个主要由自我管理的社区，重视技术技能、艺术表达以及对商业压力的抵制——这使得人工智能辅助创作成为一个备受争议的问题，通常被使用者所隐藏。最终，这个场景的蓬勃发展依赖于突破限制，并庆祝纯粹为了创作的乐趣。
## Eclipse GlassFish：现代化平台
多年来，GlassFish一直饱受缓慢、缺乏支持且仅适用于开发的声誉。然而，自2022年以来，在Eclipse基金会的管理下，并得益于OmniFish的重大贡献，GlassFish已经发生了重大转变。现代Eclipse GlassFish（版本7.0及更高版本，最新版本为8.0）现在是一个强大、企业级的应用服务器。
主要改进包括来自OmniFish的积极商业支持和长期维护、频繁发布，以及对现代Java版本（高达25）和Jakarta EE 11的支持。与旧的Oracle GlassFish版本不同，它具有更快的性能、增强的安全功能，并且具有云就绪能力，提供Docker镜像和轻量级微服务分发版。
此外，Embedded GlassFish已经发展成为一个生产就绪的运行时环境，非常适合微服务。该平台现在积极支持MicroProfile API，提供健康检查和配置管理等功能。Eclipse GlassFish不再是一个过时的平台，而是满足当今企业Java需求的面向未来的解决方案。
## Eclipse GlassFish：Java生态系统的复兴
foojay.io上的一篇文章强调了Eclipse GlassFish的复兴，它是一个Java应用服务器。 历史上，GlassFish在JBoss早期粗糙版本和Sun的Java应用服务器之后，成为一个强大的竞争者。 它作为Java EE（现在是Jakarta EE）的参考平台以及一个生产就绪的服务器而声名鹊起，提供用户友好的体验和通过OSGI对模块化应用的支持。
尽管在Oracle远离JEE之后面临挑战，但该项目在Eclipse基金会和OmniFish的支持下得到了复兴。 目前的重点是稳定性和性能，旨在解决过去对GlassFish过时的看法。
讨论线程显示出复杂的观点。 一些人回忆起在生产中使用GlassFish的积极经验，称赞其兼容性和稳定性。 另一些人承认其负面声誉源于过去被放弃，并被Spring Boot的崛起所掩盖。 然而，人们对Spring的替代方案越来越感兴趣，一些开发者更喜欢Micronaut和Quarkus等框架，或者寻求回归GlassFish提供的基于标准的解决方案，如Jakarta EE。
## 复制研究揭示关键创新聚集研究中的问题
一篇最近被《美国经济评论》接受的评论详细指出了Moretti (2021) 的十个重大问题，该论文是一篇被高度引用的研究，探讨了技术集群规模与创新（专利产出）之间的联系。作者的复制研究对该论文的核心主张，即*因果*关系，提出了质疑，认为观察到的相关性可能并非因果关系。
批评的核心集中在Moretti尝试解决选择偏差（使用事件研究）和遗漏变量偏差（使用工具变量）中的缺陷。复制研究揭示了两种分析中的编码错误，更正后导致结果为零。其他问题包括由于数据合并错误导致的结果无法复现，不正确的统计计算影响了专利质量估计（显示质量随着集群规模的扩大而*下降*，与原始发现相反），以及对统计模型的误读。
作者最初受委托为住房政策资金扩展Moretti的研究，发现了许多编码和概念错误。这些错误范围从简单的数据处理错误到模型规范中的重大错误，显著改变了结论。研究结果表明，聚集的益处可能被夸大，并强调了在有影响力的研究中回应复制尝试的重要性。
黑客新闻 新的 | 过去 | 评论 | 提问 | 展示 | 工作 | 提交 登录 Moretti 复制发表在 AER (michaelwiebe.com) 10 分，luu 2 天前 | 隐藏 | 过去 | 收藏 | 1 条评论 帮助
pacbard 1 天前 [–]
这似乎是 Stata 代码的问题。令人失望但并不令人惊讶。Stata 并不是一种容易调试的语言，这样的问题经常发生。我想知道原始作者做了多少编码，以及有多少是由研究助理编码的。我认为，一些遗漏变量的最大问题可以通过使用“新的”Stata 交互语法（“新”是指它在 Stata 10 版本中已经可用）而不是自己编写产品并忘记包含主效应来解决。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 硬件纹理压缩：一个新时代
硬件图像格式的创新历来缓慢，受到广泛硬件支持需求阻碍。然而，新的实时和硬件压缩技术正在改变这一局面。实时压缩允许更快地引入格式，因为它绕过了对现有内容的依赖。
目前，三种主要的硬件压缩格式正在出现：苹果的无损压缩（A15/M2芯片）、ARM的AFRC（Mali-G715/G615）和ImgTec的PVRIC4（Pixel 10）。苹果的格式易于实现，提供1:2压缩，质量良好，可与现有编解码器相媲美。ARM的AFRC以其灵活的压缩比和卓越的质量脱颖而出，甚至超过了实时ASTC编码。ImgTec的PVRIC4目前默认使用1:2压缩，测试表明质量较低。
性能测试表明，硬件压缩可以饱和内存带宽，通常与软件解决方案（如Spark）的速度相匹配或超过，尤其是在带宽受限的设备上。虽然AFRC目前在质量和性能方面领先，但硬件压缩仍然仅限于较新的设备。
最终，硬件压缩提供了一种引人注目的替代方案，但跨厂商的一致质量仍然是一个挑战，这使得像Spark这样的解决方案对于可预测的结果和潜在的未来WebGPU集成具有价值。
## 硬件图像压缩：一个充满问题的领域
最近在Hacker News上的讨论强调了硬件图像压缩的挑战，尤其对于那些*最需要*它的旧款、带宽受限设备。虽然ARM AFRC和PVRIC4等技术提供了潜力，但它们主要限于现代旗舰设备，在这些设备上内存带宽不是一个显著的瓶颈，这使得开发工作的价值令人质疑。
一个关键问题是不可靠的驱动程序行为——即使硬件*看起来*支持压缩，实现通常会默认使用最小的压缩比，且缺乏透明度。这造成了一种“纹理压缩地狱”，难以保证在不同厂商之间获得一致的结果。
对*GPU端*压缩的需求正在增长，特别是对于运行时生成的纹理（程序化生成、环境贴图），因为CPU压缩速度太慢。然而，当前的GPU API缺乏有效利用压缩数据的方法，通常需要CPU往返处理。
最终，硬件压缩仍然是一种“锦上添花”而非可靠的解决方案，在生产环境中至关重要的是回退策略。内存限制和功耗效率推动了需求，但实际实施面临着重大障碍。
## VHDL 与 Verilog：确定性的关键
本文重点介绍了 VHDL 和 Verilog 之间的一个关键区别：**确定性**。VHDL 通过其“delta 循环”算法实现可预测的结果。该系统将信号更新和过程评估分为不同的阶段。信号更新首先发生，触发过程，然后过程更新信号——但这些更新被安排在*未来*的 delta 循环中。这确保了过程始终看到信号值的稳定快照，无论每个阶段内的执行顺序如何，从而保证了确定性的结果。
Verilog 缺乏这种分离。信号更新和过程评估可以交错进行，这意味着过程可能会根据执行顺序观察到不同的值，从而导致非确定性行为。虽然 Verilog 的非阻塞赋值*延迟*更新，但它们并未强制执行 VHDL 的分阶段方法。
作者认为 VHDL 的 delta 循环是其最强大的特性，以最小的开销提供内置的确定性。虽然 Verilog 可以通过使用非阻塞赋值在特定的同步设计中实现确定性，但这并非普遍保证。VHDL 依赖于信号进行过程间通信，而信号本质上利用了 delta 循环，这有助于其一致的行为，与 Verilog 依赖 `reg` 类型以及阻塞赋值与非阻塞赋值的复杂性形成了鲜明对比。
## VHDL 与 Verilog：仿真确定性争论
一则 Hacker News 讨论集中在 VHDL 和 Verilog 在硬件描述方面的优劣。一个关键论点是，VHDL 的“delta 周期”逻辑提供了仿真中固有的确定性，将值变化与过程响应分离——这一概念类似于函数式响应式编程。这与 Verilog 形成对比，尽管编码约定试图缓解，但 Verilog 的仿真容易出现竞争条件。
虽然承认 Verilog 由于编写速度快和广泛的工具支持而在行业中占主导地位，但 VHDL 的支持者认为其仿真模型能够带来更强大的设计。然而，其他人反驳说，在遵循编码标准的情况下，实际经验很少会揭示 Verilog 中的确定性问题，并且复杂的芯片*确实*可以使用它可靠地构建。
这场争论扩展到工具链的实用性、语言的冗长性以及更广泛的工程生态系统。最终，讨论强调了理论优雅性（VHDL）与务实效率（Verilog）之间的权衡，选择通常取决于团队熟悉度、就业市场需求和业务考虑因素。有人认为，较新的 HDL 正在努力实现更高层次的抽象。
## Windows 98SE/ME 高清音频驱动 – 概要 该项目旨在为 Windows 98SE 和 ME 系统带来高清 (HD) 音频支持，特别是针对 Intel 915 及更新芯片组，*没有* AC97 音频的系统。 目前这是一个处于 Alpha 阶段的驱动程序，可在虚拟机 (VMware, VirtualBox) 以及部分 Intel/VIA 芯片组系统（使用瑞昱编解码器）上运行。 **重要限制：** 它仅*官方*支持 98SE/ME，Windows 98 第一版已知存在问题。 Windows 2000/XP 具有原生支持，不需要此驱动程序。 预计可能存在不稳定情况 – 音频失真、冻结或静音是常见问题。 **对于关键应用，强烈建议使用 USB 音频扩展坞。** 该驱动程序仅支持播放（不支持录音），限制为 22-48kHz 16 位音频，并且具有明显的延迟 (~40ms)。 它依赖于 BIOS 设置，并且缺乏对错误配置的覆盖。 开发正在进行中，重点是提高硬件兼容性（目前 Nvidia/AMD 和某些编解码器支持较差）。 调试信息和构建说明可在项目的 Github 页面上找到。
对不起。
一位团队成员调用Copilot为我的PR中的一个错别字进行修正，结果Copilot编辑了我的PR描述，添加了关于它自己和Raycast的广告。这太可怕了。我知道这种事情迟早会发生，但我没想到会这么快。平台衰败的方式是这样的：首先，它们对用户很好；然后，它们为了商业客户的利益而滥用用户；最后，它们为了自己攫取所有价值而滥用这些商业客户。然后，它们就衰败了。科里·道克托罗
关于 新闻 版权 联系我们 创作者 广告 开发者 条款 隐私政策和安全 YouTube 工作原理 测试新功能 © 2026 Google LLC
对不起。