每日HackerNews RSS

预计于 2026 年底发布的 PostgreSQL 19 引入了多项重要的新功能与性能改进。核心亮点包括: * **属性图查询:** 实现了 SQL/PGQ,允许用户通过 `GRAPH_TABLE` 使用模式匹配,在现有表上定义并查询图数据。 * **时态特性:** 新增的 `FOR PORTION OF` 语法简化了对记录中特定时间范围的更新或删除操作。 * **性能与运维:** * **REPACK:** 将 `VACUUM FULL` 和 `CLUSTER` 合并为一个命令,并提供 `CONCURRENTLY` 选项,以避免长时间占用锁。 * **自动清理(Autovacuum):** 现在根据计算得出的分数而非任意顺序对表进行优先级排序。 * **预聚合(Eager Aggregation):** 查询优化器现在可以将部分聚合操作下推至连接(JOIN)之前,以减少数据处理量。 * **优化器建议(Planner Advice):** 新的 `pg_plan_advice` 模块允许用户对查询优化器施加约束,这在长期坚持的“无提示(no hints)”原则上做出了一定折中。 * **可观测性:** `EXPLAIN` 现在提供详细的异步 I/O 指标,并能更清晰地洞察 `Memoize` 节点。 * **易用性:** `COPY` 指令现已支持 JSON 输出、跳过表头以及错误处理选项。 **注意:** 开发者需查阅迁移说明,因为 JIT(即时编译)现已默认关闭,且若干旧有功能(如 RADIUS 身份验证)已被移除。

抱歉。

本网站正在使用安全服务以抵御网络攻击。您刚才的操作触发了安全防御机制。触发此拦截的原因可能有多种,包括提交了特定的词汇或短语、SQL 命令或格式错误的数据。

关于“C 语言并非低级语言”这一 Hacker News 讨论,其核心在于探讨在现代复杂处理器时代,C 语言是否仍属于“低级语言”。 文章认为,C 语言的设计初衷是对 PDP-11 架构的一种轻量级抽象。批评者指出,由于现代 CPU 采用了推测执行、分支预测和复杂的微代码——这些都无法通过标准 C 语言直接暴露或控制——因此该语言已不再真正“贴近硬件”。 评论者们对此观点分歧明显: * **怀疑派**:一些人认为 C 语言实际上只是一个“快速的 PDP-11 模拟器”。他们认为“低级”一词已失去意义,因为即使是汇编语言,在现代 CPU 硬件面前也已被抽象化。 * **务实派**:另一些人则认为“低级”是一个实用的专业术语。他们坚持认为 C 语言仍属于低级语言,因为它允许开发者轻松地使用机器级指令(通过内建函数或内联汇编)来显式控制硬件,从而提供高级语言所缺乏的可见性和手动优化能力。 归根结底,这场辩论凸显了视角的转变:曾经被视为“裸机”的东西,如今已成为另一层抽象。

为了实现 NEC V20 的周期精确仿真,作者着手对该芯片的内部微代码进行了逆向工程。由于意识到单纯“复制粘贴” 8088 的逻辑不足以实现真正的精确度,作者委托拍摄了夏普制造的 V20 芯片的高分辨率(5.6 吉像素)晶圆照片。 这一过程涉及多个技术难点: * **ROM 提取:** 作者编写了一个自定义 Python 脚本,将物理微代码 ROM 的比特转换为数千张小图。随后,他们利用 PyTorch 训练了一个简单的卷积神经网络(CNN)来将这些比特分类为 0 或 1,从而有效地实现了本应耗费巨大人力任务的自动化。 * **逻辑解码:** 通过分析芯片的可编程逻辑阵列(PLA),他们确定了指令操作码如何触发特定的微代码序列。 * **协同分析:** 作者在 Vintage Computer Federation 论坛寻求帮助,以破译剩余的功能字段,并纠正了历史文档中关于 V20 微代码字格式的不准确之处。 该项目揭示了 V20 和 V30 共享相同的微代码,两者唯一的区别在于晶圆上的一处金属层切割。目前解码工作仍在进行中,但已取得足够进展,足以在 MartyPC 模拟器中开始实现周期精确的 V20 内核。

本次讨论围绕一篇关于NEC V20微处理器微代码逆向工程的文章展开。NEC V20是20世纪80年代一款流行的Intel 8088“直接替换”升级芯片,以能为IBM PC带来立竿见影的速度提升而闻名。 讨论要点如下: * **技术特性:** 尽管V20在硬件上与8088兼容,但NEC使用了独特的助记符和寄存器名称(例如用“AW”代替“AX”),这使得底层的逻辑虽然相同,但在编程文档上却容易造成混淆。此外,该芯片还具备80年代特有的扩展功能,如位域操作和8080仿真。 * **历史背景:** 用户提到了该芯片著名的法律史,涉及关于微代码版权的里程碑式诉讼——“Intel诉NEC案”。 * **社区反响:** 评论者对此次逆向工程的深度表示赞赏。一些人分享了将其作为高性价比性能升级方案的怀旧回忆,同时也指出,尽管基准测试成绩亮眼,但在实际软件运行中,性能的提升往往并不显著。

特斯拉再次向企业推销购买并运营“Cybercab”自动驾驶出租车车队的商机,并承诺提供丰厚的被动收入。然而,这与2019年那项从未实现的失败承诺如出一辙,当时导致早期投资者及如MisterGreen等公司蒙受了巨额财务损失,甚至导致后者破产。 问题的核心在于逻辑上的不一致:如果Cybercab真的是能够每年产生巨额利润的“印钞机”,特斯拉大可将整个车队留给自己运营,而非将其出售给外部买家。通过将这些车辆转嫁给第三方,特斯拉成功地将高昂的资本成本和资产折旧风险转移到了买家身上,同时继续掌控软件、网络及服务费用。 在这种安排下,买家承担了整个项目的财务风险,而该项目却完全由特斯拉掌控。特斯拉随时拥有削减价格、优先调度自家车辆或更改收益分配比例的权力。归根结底,Cybercab的推销策略是一种“轻资产”手段,旨在通过转嫁风险来保护特斯拉的利润空间。这再次证明:如果一个商业机会看起来好得不切实际,那它很可能就是个陷阱。

在2003年1月的一封电子邮件中,比尔·盖茨表达了对微软用户体验的强烈不满,并详述了他下载Windows Movie Maker和Plus!软件包失败的经历。他形容微软官网“慢得可怜”且“无法使用”,并指出整个下载过程就像一个无法破解的谜题。盖茨批评了Windows更新过程中复杂的多步骤操作、“添加/删除程序”列表中充斥着测试文件的混乱状况,以及重复且易出错的数据录入表格。他总结道,公司对易用性的漠视简直“令人震惊”。 这封邮件引发了微软高管层内部的紧急应对,以解决这些系统性问题。随后的邮件往来揭示了一家在组织孤岛中挣扎的公司:领导层争论着究竟该由市场部门还是工程部门来“负责”用户体验。内部批评指出,更新流程过于僵化、令人困惑,并且在关键补丁的标注上使用了“令人恐惧”的用词。归根结底,这次交流凸显了公司在优先考虑统一、以用户为中心的下载与安装体验上的普遍缺失;开发者们也承认,当时的流程确实是一团“乱麻”,需要立即但缺乏协调的改进。

在这篇关于其具有深远影响的“数据流模型”(Dataflow Model)论文的回顾中,作者 Akidau 等人反思了流式分析领域的十年历程。虽然该论文准确地识别了向无界、乱序数据转变的趋势,并确立了事件时间和强一致性的重要性,但作者们也承认其中存在重大的概念性错误。 他们认为,自己过分强调了流处理的机制(特别是窗口和触发器),而牺牲了更简单、更稳健的数据库式抽象。作者们现在认识到,“流与表”的二分法是伪命题;流和表仅仅是同一数据的不同访问表现形式。业界向 SQL、增量视图维护和物化视图的转变证明,其目标本应是屏蔽流处理的复杂性,而非将其暴露出来。 最终,作者们得出结论:最成功的流处理范式是那些对用户配置要求最低的范式。他们认为,流处理的未来在于将这些原则整合到标准数据库模型中,不再将流处理视为一种独立的范式,而是将其作为一种保持数据新鲜度的专业化机制。

Hacker News 上关于“重访数据流模型”(The Dataflow Model Revisited)的讨论显示,行业资深人士达成了共识:专门的流式编程模型在很大程度上未能成为主流,因为大多数企业更青睐 SQL 和传统批处理系统所带来的熟悉感与高效性。 深耕流式处理领域的专家认为,尽管流式处理在低延迟、有状态任务方面技术强大,但它在运维上过于复杂,对多数公司而言并无必要。因此,行业已将“流式”视为数据库架构的一种实现细节,而非独立的编程范式。现代分析主要依赖于具有“新鲜度”保证的 SQL 物化视图,这有效地吸纳了数据流模型的优势,而无需开发者采用复杂的专业流式语言。 尽管一些参与者认为流式处理在大规模、高并发应用(如大型实时仿真)中仍具潜力,但主流观点认为,流式处理应当对最终用户透明。归根结底,业界已达成共识:由优化的后台数据流执行所增强的标准关系模型,才是满足当前数据需求的最实用解决方案。

我使用必应壁纸已经很多年了,一直很愉快。但今天我第一次发现壁纸的位置竟然出现了一个广告。这种变着法子收费的行为简直不可理喻。这用户体验太糟糕了,直接占据了整个屏幕,让我一度以为自己安装了什么流氓软件或恶意程序。

近日一则 Hacker News 帖子引发了用户对 Windows 壁纸出现《哈利·波特/神奇动物》广告的强烈不满。这再次点燃了舆论对微软将 Windows 操作系统“垃圾化”(enshittification)的广泛批评。 评论者对微软强推 OneDrive 和 Bing 等服务的做法感到疲惫,并指出广告现在已经渗透到开始菜单、锁屏界面、小组件以及资源管理器中。用户认为,尽管他们为操作系统支付了费用,却被当作产品而非客户来对待。许多人分享了 Windows 如何在处理工作或学术任务时,通过干扰性的、无关紧要的或博眼球的通知打断他们的经历。 尽管一些用户认为该广告“尚可接受”或可以避免,但普遍的共识是,微软正通过持续的、低价值的干扰和数据搜集来消磨客户的善意。许多参与者指出,这些常被形容为“类似恶意软件”的做法,正驱使用户转向 Linux 或 macOS。这次讨论反映出一种更广泛的情绪:现代科技变得日益敌对、具有侵略性,并以牺牲用户体验为代价专注于攫取收益。

一位开发者发布了一款免费的开源 Mac 应用,允许用户通过吹口哨来控制合成器。通过利用人工智能重构代码库,开发者成功将音频延迟从 80 毫秒降低至仅 5 毫秒,并消除了性能卡顿。 该应用包含多种新音色,包括“无八度”贝斯和拉杆风琴,这些都是通过与 AI 的反复协作开发出来的。开发者还增加了一个五度音程设置,以扩展口哨的音域。虽然开发者在使用 AI 设计长笛和电钢琴等复杂高音音色时遇到了一些挑战,但他们成功利用 AI 完成了 Mac App Store 的提交流程,包括图标设计和行政要求。 该项目证明了 AI 辅助开发的价值,使开发者能够升级并发布一个原本无法实现的热门项目。建议用户配合外接麦克风和有线耳机使用,以获得最佳体验。

在这篇文章中,作者挑战了将“小”与“简单”混为一谈的普遍观点。他指出,Unix 哲学虽然推崇小巧、模块化的工具,但这些工具往往高度耦合且逻辑复杂。作者以词频计算为例,说明了 Unix 管道(pipelines)由于强制将聚合与排序紧密交织在一起,反而迫使开发者采用了复杂的变通方案。 作者引用 Rich Hickey 对“简单”的定义(即“未交织”或解耦),强调真正的简单在于关注点的分离。尽管小程序在资源受限的环境中很有用,但它们往往缺乏大型、复杂系统所具备的灵活性。相比之下,那些具备良好解耦特性的系统——例如 Clojure 将类型检查与数据表示分离的方法,或是 SQL 的声明式本质——则更为优越。 作者总结道,虽然实现这种程度的解耦通常需要高难度的工程投入,但其回报是更易于维护和扩展的系统。归根结底,开发者应追求构建“简单”而非仅仅是“小”的程序,通过识别并消除不必要的隐性依赖,从而创建稳健、灵活且真正解耦的架构。

这个讨论帖探讨了软件设计中“简单(simple)”与“小巧(small)”之间的区别,并引用了 Rich Hickey 的《简单易用(Simple Made Easy)》以及经典文章《更糟就是更好(Rise of Worse is Better)》。 参与者争论了简单性究竟是指对用户的界面易用性,还是对开发者的实现简易性。一个常见的争议点是 Unix 管道:虽然它因其小巧且可组合的基元而备受赞誉,但批评者认为它可能变得“并不简单”,因为它缺乏数据类型、隐藏了错误,并迫使用户为非标准任务创建复杂的变通方案。 讨论强调,“简单”往往是一个主观且语义过载的术语。有些人将其定义为低代码量,有些人将其定义为易于重用,还有些人将其定义为认知负荷(即“评估/执行鸿沟”)。贡献者们指出,构建能够保持真正简单的大型系统极其困难,因为复杂性往往是复合增长的,而非线性增加。最终,共识倾向于认为“简单”并不等同于“容易”,而最有效的设计通常需要深思熟虑地选择抽象方式,在管理复杂性的同时不掩盖系统的底层逻辑。
bzip3 bzip3 2 天前

BZip3 是 BZip2 的高性能继任者,专为压缩文本和代码而优化。它采用了先进的架构,结合了上下文混合熵编码器、基于快速后缀数组的 Burrows-Wheeler 变换,以及混合 LZ77/PPM 式的压缩方法。 基准测试表明,BZip3 在实现更高压缩比的同时,还能保持快速的并行解压速度,其性能经常超越其前身以及 XZ 和 Zstandard 等竞争对手。如果结合 `lrzip` 等长距离去重工具,BZip3 可以达到出色的压缩效果。 该软件可通过标准构建流程或系统软件包管理器(如 Homebrew)获取。尽管 BZip3 已在各种架构上经过广泛测试,但作者仍针对数据完整性提供了标准免责声明,指出算法的复杂性使得无法 100% 排除罕见边界情况错误的可能性。BZip3 在 LGPLv3 许可下发布,并包含来自不同贡献者的模块化组件,其中包括用于 BWT 构建的 `libsais` 库。鼓励用户查阅随附文档,以获取完整的基准测试细节和针对特定架构的性能预期。

关于 **bzip3** 的 Hacker News 讨论主要集中在其压缩性能与行业标准 **zstd** 的对比上。虽然 bzip3 在某些场景下表现出令人印象深刻的压缩比,但社区成员认为所提供的基准测试具有选择性且存在误导。 主要结论包括: * **性能权衡:** 用户指出,尽管 bzip3 在特定数据集上可以实现更高的压缩比,但它通常需要更多的内存,且解压速度比 zstd 慢几个数量级。 * **对基准测试的质疑:** 批评者指出,这些基准测试未能统一窗口大小和压缩级别等因素。当 zstd 配置为 `--long` 窗口或更高的压缩级别时,它通常能优于或持平 bzip3,同时保持更好的速度和资源效率。 * **使用场景:** 参与者得出结论,bzip3 可能适用于以最大压缩率为首要需求的特定归档场景,但目前缺乏取代 zstd 或 lz4 等成熟格式所需的通用性、生态系统支持和速度。 * **开发情况:** 讨论还涉及缺乏正式的正确性证明、利用人工智能优化压缩参数的可能性,以及围绕“bzip3”命名规范和许可选择的争论。

更多

联系我们 contact @ memedata.com