系统与基础设施magcius.github.io编辑精选
Xplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
2013 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。作者当时全职开发 GNOME 窗口管理器，系列试图中立地呈现 X11 的设计取舍；他后来转向 Wayland，系列也随之停更。文章自 2013 年起多次登上 Hacker News 首页，是理解 X11 的经典入门材料。
为什么经久不衰：它用可交互的浏览器演示把晦涩的 X11 绘图模型变得直观，是理解 X11 设计取舍——以及后来 X11 与 Wayland 之争——的经典入门；即使 X11 渐被取代，这些权衡仍值得读。
HN 评论精选
作者自述用浏览器重建 X11 绘图模型来学习，并借此撰写长文；他本想保持中立，却常被读者断章取义。
作者本人。我几年前停止更新这个系列，现在正好做一次冗长、未经编辑的回顾。开始做这个时，我全职开发 GNOME 的窗口管理器，想深入理解 X11 的绘图模型如何运作，于是用几周时间在酒店房间里用浏览器重建了 X11 绘图模型的大部分，边修瑕疵边推进，直到觉得自己真正掌握了它。最初的测试场景是带任务栏的传统桌面和 xeyes，两者至今仍在代码库里但未测试。后来我决定用其中的片段构建一篇长文。我学到了很多关于写作、教学法，以及「100% 技术正确」与「为了让行文流畅讲点小谎」之间那条模糊界线的东西。白天的工作大多转向 Wayland，这里学到的东西帮我设计更好的协议和系统。系列的目标是尽量中立；我原本的设计是给「作者观点区」加上巨大的警告标志，讨论某些设计特性在实践中并不成立。但 HN、Phoronix、Reddit 上的人似乎只是略读文章，摘取片段就开喷……
Jasper_查看英文原文
Author here. I stopped working on this a few years ago, so now's as good a time as any for an overly-long, rambly, unedited retrospective. When I started this, I was working on GNOME's window manager full-time, and wanted to learn intricately how X11's drawing model worked, so over the course of a few weeks in a hotel room, I recreated large parts of X11's drawing model in a web browser, fixing artifacts as I went along, until I feel I had a really good grasp of it. My initial test scene was a traditional desktop-like approach with a taskbar and xeyes, both of which are still in the codebase today, but untested [0]. I didn't know what I wanted to do with it, until I settled upon using snippets of it to build a long-form article. I learned a lot about the difficulty of writing, of pedagogy, of that blurred line between being technically correct 100% of the time vs. telling a few small lies here and there to keep the flow consistent and help people see the broader picture. At my day job, I had mostly moved onto Wayland, where some of the bits I picked up here really helped me design better protocols and systems. My goal with the series was to try to be as neutral as possible, and my original design was to have a giant caution sign around "Author Opinion Zones" where I would talk about how certain design features haven't held up well in practice. But quickly, people on Hacker News or Phoronix or Reddit seemed to skim the article, pick up a piece here or there, and go on straight to bashing Wayland, gleefully unaware that I was one of the people making it. So, the end result was that I basically stopped working on Xplain basically after the second article. The COMPOSITE article was one I made after a colleague was having trouble understanding COMPOSITE, and I figured it was easier to write with my framework than explain in a chatroom, and maybe some others would appreciate it. I have a deep passion for sharing my knowledge, and Xplain was the format I first really used to do it widely, so I tried to keep it exciting for me by changing it from "Xplain" to "Explanations", and opening up the topics from X11 to just about anything, but at some point I was just unhappy working on it. The last thing I was working on was a continuation of my Basic 2D rasterization article, where I had a fun code editor you could use to make your own graphics [1] [2], but as fun as the technology was, I couldn't find a satisfying flow to the article, so I stopped it. Parts of it were later recycled for an article on the histories of 2D and 3D graphics. [3] Around mid-2016, I had stopped working on Linux and open-source graphics entirely, and by 2017 I had exited the open-source industry completely and jumped ship to professional game development. I still have a deep love for graphics and a passion to explain things. I just released a new side project a few days ago for it, even. Here's some stuff I'm working on these days. It's much cooler than X11/Wayland flamewars, in my opinion. https://noclip.website/ https://blog.mecheye.net/2018/03/deconstructing-the-water-effect-in-super-mario-sunshine/ https://www.youtube.com/watch?v=8rCRsOLiO7k -- [0] https://github.com/magcius/xplain/blob/gh-pages/src/clients/xeyes.js [1] https://u.teknik.io/XdSbC.webm [2] Sort of up here at https://magcius.github.io/xplain/article/rast2.html [3] https://blog.mecheye.net/2019/05/why-is-2d-graphics-is-harder-than-3d-graphics/
X11 和 Wayland 都是各自时代的产物；今天需要针对硬件叠加层、内存带宽和低延迟重新设计显示架构，而现有系统（包括 Windows）多是启发式 hack。
看这些内容让我有些不安。X 是 35 年前问题的绝妙解法，那时内存勉强够一帧缓冲，图形模型也很原始（没有抗锯齿和透明）。据我所见，Wayland 是大约 15 年前模型的良好解法，代价是接受合成器路径带来的一帧半延迟。我的问题是：有没有人在为今天的硬件做解法？如今有硬件叠加层，GPU 吞吐量比合成桌面所需高几个数量级，但我们仍在意内存带宽（分辨率、位深、帧率都在上升），并且希望以高定时精度调度每个呈现的像素。我熟悉 Windows，但觉得它是一堆 hack：它会把窗口提升为叠加层，但全靠启发式，过渡时延迟很可能会卡顿；新的 flip-model 还让平滑调整窗口大小退步。我甚至不确定 macOS 在降低延迟，也没见他们提硬件叠加层。现在注意力多在 VR/AR，那里延迟很重要且没有历史包袱，但我希望……
raphlinus查看英文原文
Looking over this stuff, I get an uneasy feeling. X was a brilliant solution to problems 35 years ago, where you barely had enough memory for a full frame buffer and the graphics model was primitive (no antialiasing or transparency). From what I've seen, Wayland is a good solution for the model maybe 15 years ago, where you're willing to accept the frame-and-a-half latency hit from having a compositor in the path. Basically, my question is whether anybody is working on a solution for the hardware we have today, where there are hardware overlays, the GPU throughput is orders of magnitude higher than what's needed to composite a desktop, but we still care about memory bandwidth, largely because all of resolution, bit depth, and frame rate is still going up. And you really want to be able to schedule every pixel that gets presented with a high degree of timing accuracy. I've become familiar with Windows, but feel like it's a bunch of hacks. They will promote a window to an overlay, but it's all a heuristic, and I'm pretty sure latency will stutter while it does the transition in and out. And the new flip-model stuff actually regresses the ability to do smooth window resizing. I'm not even sure macOS is working on lowering latency. I haven't seen any mention from them of hardware overlays. Most of the attention these days seems to be in the VR/AR space, where latency is obviously important, and there's more of a green field with respect to legacy compatibility, but I'd love to see this problem space actually solved on the desktop. Doing this right is not easy - it probably requires some form of soft real time discipline across the graphics stack (including GPU scheduling) so you can race the beam.
赞赏 X11 不预设应用形态的开放设计，认为 Wayland 缺乏设计哲学，抛弃 X11 的庞大生态是错误。
「金句」：『所以，X11 的大量设计是给客户端和应用一整套工具去设计和实现自己的应用，而不对应用该怎么做持有真正有主见的设计。X 客户端可以用这个工具或那个工具来权衡这种或那种取舍，两者本质上都不是错误的选择。』这一点在 Wayland 上完全不能这么说。除了「每一帧都完美」的口号，Wayland 根本没有设计哲学。用这个来引入新协议也是弱论据。现代驱动下 X11 很少出现撕裂，有时禁用 vsync 反而合理（比如竞技游戏）。引入 Wayland 是个错误，因为 X11 有庞大的生态系统、大量小程序和广泛的用户群，几乎所有 Unix 操作系统都支持过 X11。Intel 仍把 i386 指令集塞进处理器，Windows 仍能运行 1995 年的程序，IBM 仍靠高价大型机赚钱——成功系统往往会留存并积累 cruft。放弃 X11 对 FOSS 社区将是沉重打击（也许这正是本意）。
sprash查看英文原文
Money Quote: > So, a lot of the design of X11 is giving clients and apps a large set of tools to design and implement their app, without any real opinionated design about how an app should be made. An X client can use this tool or that tool to battle this tradeoff or that tradeoffs, and neither is fundamentally a wrong choice. That is something that can not be said about Wayland. Besides the "every frame is perfect" mantra Wayland has no design philosophy at all. It is also a weak argument to introduce a new protocol. With modern drivers it is rare to experience tearing on X11 and on some occasions it even makes sense to disable vsync (e.g. competitive gaming). The introduction of Wayland was a mistake because X11 has a huge ecosystem with lot of little programs and a large diverse users base. Almost every Unix OS supported X11 at some point. There is a reason why Intel still stuffs the i368 instruction set in their processors, Microsoft Windows still can execute programs from 1995 and IBM is still able to make money with vastly overpriced mainframes. Successful systems have the tendency to stay and accumulate cruft as a result. The abandonment of X11 will be a heavy blow to the FOSS community (and maybe that is exactly the intend).
对文中历史归因的纠正：暴露重绘和 regions 最早见于 Apple Lisa 的 Bill Atkinson 工作，而非 X11 或 Windows。
作者似乎把 repaint-on-expose（暴露时重绘）归功于 X Window System 或 Microsoft Windows。据我所知，这最早是由 Bill Atkinson 为 Apple Lisa 实现的（连同 regions），原因是他记错了在 PARC 看到的东西；当时 PARC 系统的重叠窗口并不会自动高效地只重绘受影响区域。
eschaton查看英文原文
The author appears to credit the X Window System or Microsoft Windows with repaint-on-expose. To my knowledge that was first implemented (along with regions) by Bill Atkinson for the Apple Lisa, because he misremembered what he saw on the visit to PARC; overlapped windows in the PARC systems at the time didn't automatically and efficiently repaint only the affected area.
历次讨论
同类还值得读
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.org旋风教程：为 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编辑精选给分布式系统新人的笔记（2013）
Notes on Distributed Systems for Young Bloods (2013)
一篇面向分布式系统新手的经验笔记，作者以格言式的短条总结了多年实战中踩过的坑，涵盖一致性、延迟、背压、监控、CAP 定理等主题。
系统与基础设施上首页 5 次 · 2013–2024somethingsimilar.com编辑精选