Linux 漫谈(一) - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
kuanat
V2EX    Linux

Linux 漫谈(一)

  kuanat 13 小时 6 分钟前 2747 次点击

Linux 漫谈

虽然标题是 Linux 相关,这篇文章和之后的续篇都会将三个主流的系统一起做对比,特别是设计图形界面和桌面的部分。其实鸿蒙系统也非常值得拿来一起对比,但我考虑到这个系列的切入视角是近三十年的发展史,所以就刻意回避了。

选择发布在 Linux 板块,主要还是为了避免无意义的口水仗。以我这些年的经历来看,Linux 用户的典型画像一方面是沉默的少数派,另一方面又往往是用爱发电的主力。所以互联网上的资料常常处于两种极端,要么很专业但要求读者有足够的认知门槛,要么就是语焉不详,甚至可能充斥着错误或者误导性的信息。

我写这篇文章的目的只是简单的想要回答一些为什么类型的问题,尽可能消除一些常见的技术误解。很早之前我就有写这个系列的构思,当时感觉如果要做完整清晰的论述,篇幅会非常长同时依赖大量的基础内容做铺垫。现在有了 AI 的辅助,我就将文章定位为 AI 的提示词,梳理好大纲脉络即可。

另一个目的算是我的私心,这篇文章也是阐述“为什么开发者应当学习 Linux”这样一个观点。我并不急于回答这个问题,而且我相信读过文章的你一定会有自己的理解。至于我把我的理解分享出来这个行为的动机也很简单,我从 Linux 上学到了很多,这些知识经验很大程度上影响了我的职业经历,某种程度上也影响了我的价值观,所以我愿意将这些精神财富再次分享出来。

0x00 前言

我先拿一个可能是误解最深的话题作为引子:“Wayland 协议加剧了 Linux 桌面的碎片化”。很多人会认为 Wayland 协议应当像 Windows/macOS 那样有个统一的标准,而不是现在松散、混乱的实现状态。

如果我告诉你这恰好就是 Wayland 追求的设计目标呢?你可能觉得我或者 Wayland 至少有一个疯了。如果我告诉你“提供机制而非策略( Mechanism vs Policy )”恰恰是 X 提出的,而 Wayland 继承了相同的精神内核,估计 X 的支持者也坐不住了吧?

详细阐述问题需要比较多的铺垫,之后的篇幅会做相应的解释。

如果你看过我之前发的文章、帖子,你可能会注意到我经常会用一个词“哲学”。所谓哲学就是回答为什么,如果再直白一点就是“小孩子才做选择,成年人当然是我全都要”的反面,技术领域中很多时候谈论好与坏,本质上是在谈论取舍。哲学的意义再具象化一点可以表述成“设计理念”,它往往有着具体的应用场景和时代背景,以借鉴总结为目的对错、好坏讨论是有意义的,为了宣泄情绪争个输赢属实没有必要。

当然也不是说就没有统一且普适的评判标准了,我之所以喜欢谈哲学就是因为,设计理念及其对应的实现手段是能体现出设计者智慧的。可以这样理解,人类历史上出现过的科学技术到今天可能都被新技术替代了,但是类似数学抽象、以及对物理世界的认知,一起构成了如今的科学技术框架。思想智慧的光芒是不会因为历史进步而被掩盖,反而会更加闪耀。

日常中我们也很少拿如此严苛的标准来评判一般事物,毕竟时间才是最强的检验手段,经得起时间考验的才是大智慧。

如果以图形系统作为后现代操作系统的分界线,目前 Linux/Windows/macOS 差不多都经历了二三十年的发展。关于操作系统好坏的争论一直没有停过,且很少有人讨论好在哪里或者坏在哪里。又或者是没人回答这类问题:那么多开发者竟然解决不了某某问题、为什么某某系统就做不到等等。

与其说我要系统性回答各种疑问或者解析各个误解的原因,不如说是我要回答“为什么某某操作系统会是现在这个样子”,或者“它为什么要这样设计”。三个系统演化成今天的形式,简单说和它们最初的设计思路是分不开的,最初的框架定型之后,想要再改就很困难了,谁都离不开一层层打补丁,这个打补丁的过程又重新巩固了原有的设计。

我相信以今天的视角来看,我们是能够给出比较客观的评判的。

0x10 现代操作系统的基础

为什么需要操作系统?

这个问题似乎简单到不需要思考,那我为什么要把它单独拿出来?因为在我看来,这个问题的答案就如同逻辑三段论中的大前提,后续一切讨论都建立在这个大前提之上。

在操作系统出现之前,可以认为计算机是“单任务”的,即单一程序直接在硬件上运行,通过人工外部手段切换应用程序。随着硬件技术的进步,彼时的开发者迫切需要某种能够让多个应用程序以纯软件的方式共享硬件资源的机制。

这个机制并不完全等同于现代意义上的“多任务”,但在逻辑层面上,二者都是基于“时分复用”这个思想的,甚至人工“单任务”也可以理解为时间片尺度非常大的复用系统。

回到计算机硬件上,核心计算单元 CPU 只是机械地按照程序计数器( PC )以及栈指针、寄存器中的数据来执行相应的指令,如果要实现在多个应用程序之间进行切换,实际上只需要实现这个环境保存及恢复机制即可。

这就是对于操作系统最原始的需求。

0x11 内核

如果说图形操作系统的分界线是图形界面,那么现代操作系统的分界线就是内核。所以现在的问题是内核又是怎么来的,要解决什么需求。

现在操作系统的雏形源自 Unix ,估计绝大多数人并不知道它的原始含义。有个戏谑的说法是它代表 uniplexed 也就是单路非复用的意思,与它相对的是 multiplexed 今天一般叫做多路复用,而 Unix 取这个名字就是为了与当时名为 Multics 操作系统的设计做区分。

尽管 Multics 在商业和软硬件技术上都很失败,但它的理念是超越时代的,所有 Unix 之后的现代操作系统都是建立在它的设计思路之上。

内核或者更准确地说保护环( Protection Rings )这个概念是 Fernando Corbato (图灵奖得主)在六十年代提出的,在当时的背景下,它旨在解决原始操作系统面临的安全性问题。Multics 的设想是,将庞大昂贵的计算机安全、方便地共享给多人使用,所以提出了环这个概念。同时 Multics 和通用 GE-645 的合作,增加了硬件环支持也是第一次软件需求影响硬件设计的例子,后面这样软硬件相互影响进化的例子就非常普遍了。

为了避免某个应用影响到其他程序,或者影响到操作系统本身,就让操作系统运行在 Ring0 最高权限,而应用程序运行在 Ring3 权限。同时为了解决内存昂贵且管理复杂的问题,Multics 还提出了虚拟内存的概念,包括动态链接技术在内的很多设计都是源自 Multics 操作系统。(还包括 ACL 访问控制列表概念,以及 / 代表的树状目录结构,这里就不展开了)

虽然 Multics 的理念很先进,但受限于当时的技术水平,实现层面却比较失败。后来 Ken Thompson 和 Dennis Ritchie 离开项目,发展出了 Unix 项目。对于环的模型也简化成了 Kernel/User 空间的划分,操作系统就演变成了内核和用户空间辅助程序的组合。

为了准确表述起见,后面提到操作系统的时候都会以其内核的名字来称呼,Linux 自身就是内核名字,Windows 目前的内核依旧称作 NT ,而 macOS 内核的正式名称为 XNU(X is NOT Unix)。

0x12 设计哲学

是的,我又要谈哲学了。

从 Unix/Multics 的对比可以发现,即便理念相同,在具体实现上也会存在巨大的分歧。而从 XNU 这个名字,以及后续 Linux 这个名字,也能看出操作系统发展的脉络。对于不同的设计者而言,他们追求的理想目标不同,在满足操作系统这个基础需求时的解决思路也不同,这便是哲学上的分歧。在后面我们能看到不同的哲学对于操作系统发展带来的巨大影响。

由于 Unix 不在这个系列主要的讨论范围内,这里就总结一下 Unix 影响后世的几个重要哲学观念:

  • Do one thing and do it well. 和 KISS(keep it simple and stupid) 基本是一个意思,这个理念与 Multics 大而全的理念恰恰相反,影响了 awk/sed/grep 等等一系列软件的发展。

  • Worse is better. 这个理念的影响主要是 C/Lisp 的语言,前者是追求工程简单,后者追求形式正确。我更愿意称之为工程派和学院派,为什么 XNU 要强调自己不是 Unix ?因为它诞生于学院派,和 Lisp 一样都追求形式上的正确和美。

  • Everything is a file. Linux Torvalds 称这是 Ken Thompson 最优雅的设计,伟大无需多言。

我觉得到这里已经很明显了,哲学观点属于润物细无声的存在,影响的是对同样事物的不同看法,进而影响做同样事情的不同选择。还是那句话,好和坏都是相对的,对错不重要,为什么更重要。

0x13 对比

铺垫了这么久,终于可以开始对比了。如果说继承 Unix 衣钵的 Linux 算作工程派,XNU 出身学院派(卡内基梅隆大学 Richard Rashid ),那么 NT 应当算作激进的先锋派。

顺便一提,NT 内核的核心设计是 Dave Cutler ,他主导设计了 VMS(Virtual Memory System),后来成为了 NT 虚拟内存的核心。他最出名的一句话是 Unix is a junk OS designed by a committee of PhDs。鄙视链真是无处不在啊……

在 Unix 诞生之后,操作系统内核的基本框架就确定了。现代内核无论是 Linux 还是 NT/XNU ,最基本的功能模块都包括任务调度和虚拟内存,只是实现层面存在差异。然而不管是哪一派,都不约而同将文件系统、网络栈和硬件驱动放到了内核中。

从技术上讲,Linux 是纯粹的宏内核( Monolithic )设计,而且 Linus Torvalds 对此和 Andrew Tanenbaum (微内核之父)有过一场辩论,Linus 认为在九十年代微型内核的性能开销是不可接受的。这种设计下所有的内核功能模块都运行在同一个地址空间。(一般现在说的纯微内核( MicroKernel )指的是 Minix/L4 这种,因为性能问题基本没有桌面应用,也就不展开了。)

至于 NT 和 XNU ,学术层面一般的说法是混合内核( hybrid ),因为它俩都是设计上的微内核,但也都在实现上采用宏内核的方案。

NT 内核的设计者 Dave Cutler 受微内核思想影响,将 NT 内核设计成了很多的子系统,比如 OS/2 和 POSIX 子系统,甚至后来 WSL(windows subsystem for linux) 和 WSA(windows subsystem for android) 都得益于这个设计,后来连 GDI 和 http 服务器也都塞进了内核。XNU 则基本上是把 BSD 的网络栈、文件系统实现直接链接进了内核。当然本质上,NT/XNU 还是和 Linux 一样只有一个地址空间的,只是它们不推荐像 Linux 一样自由访问。

真正的区别在于以下两个问题:

  • 是否将 IPC 放到内核里。 准确的说法应该是:内核各个部分之间依赖直接函数调用进行交互,还是依赖特定协议的 IPC 消息进行交互。

  • 是否将图形系统放到内核里。

在这两个问题上的不同抉择才是真正影响几个操作系统如今不同形式的根本原因,IPC 和图形系统恰恰也是对桌面体验影响最大的两个部分,如果要谈论桌面系统的话题,归根结底都会回到这两个系统的设计上。

说到底,这几个内核的追求都是一样的,既要保证安全,还要追求性能,但在这两个关键问题上走出了不同的路线。


PS 感谢各位没有让 AI 总结而是人工阅读。这会是一个比较长的系列,分开发布一方面是因为确实太长了,另一方面也是想根据反馈来调整后续内容的结构顺序和内容侧重。

20 条回复    2025-12-24 18:50:56 +08:00
levelworm
    1
levelworm  
   13 小时 1 分钟前
我之前阅读了很多遍 Showstoppers,这是一本讲 Windows NT 开发过程的书。我感觉 David Cutler 功不可没。他和 Linus 一样是对代码质量追求极致的人。他的名言之一:if you break the build, your ass is grass and I'm the lawn mower.
kuanat
    2
kuanat  
OP
   12 小时 56 分钟前   1
@levelworm #1

是的,我认为他和 Linus 一样都是能兼具工程管理和技术开发能力的人,而且在几十年前就对未来的技术发展有非常深刻的洞察。NT 有很多优秀的设计都是出自他本人。
levelworm
    3
levelworm  
   12 小时 32 分钟前
@kuanat #2
的确是个牛人,可惜他的代码开源的太少了。我在泄漏的 NT 3.5 代码里看过他的代码,当然完全看不懂,但是像他这种 Architect,还能坚持写操作系统内核最难的代码,就难能可贵了。
hronro
    4
hronro  
   12 小时 19 分钟前
好文。这个系列的文章是就发在 V2EX 上,还是有专门的博客地址?
craftsmanship
    5
craftsmanship  
   10 小时 51 分钟前 via Android
好文 来个博客地址啊 贴子的形式不可持续
kuanat
    6
kuanat  
OP
   10 小时 34 分钟前 via Android   3
@hronro
@craftsmanship

就只发在 V2EX 上,我认为文章内容的价值是一方面,这里的讨论同样重要。对我自己来说这些内容更多是总结整理,放在这里比放在个人博客更有生命力。(我确实没有写博客的习惯)
xtreme1
    7
xtreme1  
   9 小时 52 分钟前   1
现代 Windows 的图形也不在内核里, 只是仍然保留旧图形系统的兼容(win32k.sys), 并且看不到放弃的可能
我觉得可以说走到今天, 三大家的图形系统大差不差.
levelworm
    8
levelworm  
   9 小时 47 分钟前 via iPhone
@xtreme1 #7
我记得早先为了性能把图形驱动放内核里,后来在 4.0 的时候放弃了。看来是很难保证质量。
fkdtz
    9
fkdtz  
   8 小时 29 分钟前
哥们太强了,早早就特别关注了
每篇回复都有理有据,逻辑严谨,面面俱到
先赞后看
BlackDoge
    10
BlackDoge  
   8 小时 24 分钟前
支持,期待更新
yyzq007
    11
yyzq007  
   7 小时 26 分钟前
写的很好, 期待后续更新
freedomSky
    12
freedomSky  
   7 小时 21 分钟前
有深度的内容
n0bin0bita
    13
n0bin0bita  
   6 小时 58 分钟前
持续关注
archxm
    14
archxm  
   5 小时 40 分钟前 via Android
现在电脑硬件,说停滞都不为过。
软件也是。
基本处于堆规模了
GavinXSF
    15
GavinXSF  
   5 小时 7 分钟前
好文,期待续集。
同样推荐有兴趣了解 NT 内核开发历程的朋友去读一读《 Showstopper 观止》。
Bronya
    16
Bronya  
   4 小时 53 分钟前
关注楼主了,期待后续
zzxx3322
    17
zzxx3322  
   4 小时 40 分钟前
刚好我有幸在工作上有参与对 wayland 的研究,我一直在寻找可靠的论文来探索一下 Linux 下图像的发展脉络,但是貌似不管 X 还是 Wayland 这些都是偏工程化的实践,好像并没有学术上的讨论。当然也有可能是我英语水平太烂,借助了 AI 也没有检索到好的信息,想请教一下博主有图形栈这方面的论文书书籍推荐吗?我想要鱼,哈哈哈。
mrzx
    18
mrzx  
   3 小时 9 分钟前
@kuanat 明显是的,V2EX 这里讨论技术的氛围,我觉得再国内中文技术社区来说,V2EX 排第二,没人敢称第一。。
mrzx
    19
mrzx  
   2 小时 42 分钟前
@archxm 手机也一样,现在 2 纳米就接近极限了。硬件没有革命性的性能提升,软件的发展脚步也会停歇不前。。。

不然小米也不会向汽车产业发展了。。。。小米已经没有退路了,su7 和 yu7 如果大败退,小米后面结局会很惨的

早再 20 年前,网络基建市场开始萎缩,华为求变,转向移动市场,政策导向,国家希望给国内网路设备厂商留活路,驱赶业界顶级天花板,业界的标准制定者 思科和 juniper

早在 10 年前,智能手机的市场就再度开始萎缩,进入红海市场,一堆手机厂家转向出口谋求出路,国内手机销售策略从卖低端机抢占市场转变卖高端机,讲究毛利率和溢价。

现在?华为依靠 5G 专利和授权费,赚的彭满钵满,加上国家的支持,即使被美国全力制裁下还是活的很好,每年华为有大把的钱砸到研发里,这像是快倒闭的公司吗?
tonynothing
    20
tonynothing  
   1 分钟前
好文,已收藏
关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     3200 人在线   最高记录 6679       Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 22ms UTC 10:52 PVG 18:52 LAX 02:52 JFK 05:52
Do have faith in what you're doing.
ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86