系统与基础设施nongnu.org
认为 xz 格式不适合长期归档（2016）
Xz format considered inadequate for long-term archiving (2016)
2016 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 lzip 官网上一篇批评 xz 压缩格式的文章。作者认为 xz 的格式设计（如多层头部、填充、实现可选子集等）使其不适合需要数百年可靠读取的长期归档，并主张 lzip 更合适。文章自 2016 年起多次引发争论：反对者认为归档韧性应靠哈希和纠错码，而非更换压缩格式，也有人指出 lzip 自身对数据损坏并不稳健。
为什么经久不衰：它集中呈现了长期数字归档中“压缩格式该多复杂、容错该由谁负责”的核心争论，并随着 xz 在打包和发行版中的普及反复被重提，今天仍值得读。
HN 评论精选
dpkg 弃 lzma 转 xz 后，xz 的随机访问优势被 tar 抵消，文件还变大。
dpkg 主动弃用对 lzma 格式归档的支持（我觉得他们永远不该这么做），全面转向 xz，真令人失望。现在解压器需要文章提到的那种烦人的灵活性，而该格式唯一的优势——能对文件随机访问——几乎被 dpkg 用 xz 压缩 tar 文件所抵消：tar 即使不压缩也几乎不支持加速访问，最好也就是尝试跳过文件头，只有归档内文件足够大才有用；更糟的是，文件因额外头部都略微变大。
saurik查看英文原文
It was really disappointing when dpkg actively deprecated support (which I feel they should never do) for lzma format archives and went all-in on xz. The decompressor now needs the annoying flexibility mentioned in this article and the only benefit of the format--the ability to do random access on the file--is almost entirely defeated by dpkg using it to compress a tar file (which barely supports any form of accelerated access even when uncompressed; like the best you can do is kind of attempt to skip through file headers, which only helps if the files in the archive are large enough) and, to add insult to injury, the files are now all slightly larger to account for the extra headers :/. Regardless, this is a pretty old article and if you search for it you will find a number of discussions that have already happened about it that all have a bunch of comments. https://news.ycombinator.com/item?id=20103255 https://news.ycombinator.com/item?id=16884832 https://news.ycombinator.com/item?id=12768425
归档韧性应靠哈希和前向纠错，而不是换压缩格式。
我不同意文章的前提。所有归档格式对长期韧性都不够，而让它们够用会违反“做一件事并做好”的原则。要支持韧性，你不需要 xz 的替代品，你需要哈希和前向纠错。具体来说：用 xz 以高压缩比压缩文件，可选加密，然后取 SHA-256 用于检测错误，再用 PAR 或 zfec 生成奇偶校验文件用于纠错。
jl6查看英文原文
I disagree with the premise of the article. Archive formats are all inadequate for long-term resilience and making them adequate would be a violation of the “do one thing and do it right” principle. To support resilience, you don’t need an alternative to xz, you need hashes and forward error correction. Specifically, compress your file using xz for high compression ratio, optionally encrypt it, then take a SHA-256 hash to be used for detecting errors, then generate parity files using PAR[1] or zfec[2] to be used for correcting errors. [1] https://wiki.archlinux.org/title/Parchive [2] https://github.com/tahoe-lafs/zfec
批评文章有偏见；xz 的复杂与填充不是缺陷，实现碎片化是社交问题。
这篇文章又来了？我认为它有偏见，潜台词是作者在说他的 lzip 格式更优越，但 xz 并非文章所称的“盲目”选择。大多数说法都可商榷：三层头部不等于“不安全的复杂性”，间接层是设计的基础；填充也并非无用，tar 就大量使用填充，并借此扩展支持更大文件，几十年没有灾难性后果。xz 的决策背后有思考。说“xz 实现可选择支持格式子集，甚至不做完整性检查，安全互操作无保证”是纯 FUD——任何软件都能被说成“有人可能做出烂实现”；格式碎片化本质上是社会问题，不是技术问题。
moltensyntax查看英文原文
This article again? In my opinion, this article is biased. The subtext here is that the author is claiming that his "lzip" format is superior. But xz was not chosen "blindly" as the article claims. To me, most of the claims are arguable. To say 3 levels of headers is "unsafe complexity"... I don't agree. Indirection is fundamental to design. To say padding is "useless"... I don't understand why padding and byte-alignment that is given so much vitriol. Look at how much padding the tar format has. And tar is a good example of how "useless padding" was used to extend the format to support larger files. So this supposed "flaw" has been in tar for dozens of years, with no disastrous effects at all. The xz decision was not made "blindly". There was thought behind the decision. And it's pure FUD to say "Xz implementations may choose what subset of the format they support. They may even choose to not support integrity checking at all. Safe interoperability among xz implementations is not guaranteed". You could say this about any software - "oh no, someone might make a bad implementation!" Format fragmentation is essentially a social problem more than a technical problem. I'll leave it at this for now, but there's more I could write.
lzip 的尾部数据特性导致单 bit 损坏可静默截断，反而不稳健。
上次这个话题出现在 HN 时我做了些研究，发现 lzip 面对数据损坏相当不稳健：在正确位置翻转一个 bit，就可能让解压器静默截断解压数据而不报错。这一漏洞正是文章用来宣称 lzip 优于 xz 的特性之一的直接后果——即可以在 lzip 归档后附加任意“尾部数据”而不使其失效。lzip 文件是一串拼接的压缩块，每块以魔数开头，没有整体文件头，也没有标记最后一块；这允许直接拼接两个 lzip 文件。但解压器读完一块发现还有输入时，无法可靠区分“另一块 lzip 数据”和“应被静默忽略的尾部随机数据”，于是可能把损坏当成尾部数据而静默截断。
comex查看英文原文
Last time this came up on HN, I did some research, and discovered that lzip was quite non-robust in the face of data corruption: a single bit flip in the right place in an lzip archive could cause the decompressor to silently truncate the decompressed data, without reporting an error. Not only that, this vulnerability was a direct consequence of one of the features used to claim superiority to XZ: namely, the ability to append arbitrary “trailing data” to an lzip archive without invalidating it. Like some other compressed formats, an lzip file is just a series of compressed blocks concatenated together, each block starting with a magic number and containing a certain amount of compressed data. There’s no overall file header, nor any marker that a particular block is the last one. This structure has the advantage that you can simply concatenate two lzip files, and the result is a valid lzip file that decompresses to the concatenation of what the inputs decompress to. Thus, when the decompressor has finished reading a block and sees there’s more input data left in the file, there are two possibilities for what that data could contain. It could be another lzip block corresponding to additional compressed data. Or it could be any other random binary data, if the user is taking advantage of the “trailing data” feature, in which case the rest of the file should be silently ignored. How do you tell the difference? Simply enough, by checking if the data starts with the 4-byte lzip magic number. If the magic number itself is corrupted in any way? Then the entire rest of the file is treated as “trailing data” and ignored. I hope the user notices their data is missing before they delete the compressed original… It might be possible to identify an lzip block that has its magic number corrupted, e.g. by checking whether the trailing CRC is valid. However, at least at the time I discovered this, lzip’s decompressor made no attempt to do so. It’s possible the behavior has improved in later releases; I haven’t checked. But at least at the time this article was written: pot, meet kettle.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选