https://www.gnu.org/licenses/gpl-howto.html
怎么用，这里说得够清楚了。
版权声明没有固定的格式；如果你提供了许可证，法律上也不是必须的，只是这样会留下更多漏洞而不符合原意。一般在每个适用源文件中明确提到遵循哪个许可证，整个项目附带许可证的文本文件。如果你没有单独的版权声明，可被认为所有文件都适用许可证。如果你修改的代码按适用的许可证条款要求标注修改，可以在源文件中一起标注（或者你打算准备另外的文档）。
GPL 要求标注修改的，并且合并的工作也要求用 GPL 分发。你可以对不被许可证涵盖的非衍生作品（或者说你自己完全作为所有者的作品）同时使用其它许可证并一并分发。是否允许文件的版权声明看原作者的许可。一般作者提供的许可证不包含所有权转移的许可，所以你不能移除原作者的版权声明，以避免对你实际上不具有所有权的作品主张所有权。
对衍生作品判定的范围有争议，但一般来说，“翻译”被版权保护的作品，构成衍生作品，这同样适用于程序源代码。按 FSF 的意思，链接的程序也属于衍生作品。按 Linux 项目的解释，用户空间的程序不构成内核的衍生作品。IANAL ，关于具体涵盖的严格的结论请咨询版权法律师。

@shijingshijing 我 1999 年注册的号隔几年就不存在，敢情直接给我吃了……

做内核和驱动可以考虑。
其它大部分都基本不用考虑（数据库之类，不是 C++就是 Rust ），基本不是过气选型说明 leader 技术栈和视野有问题，或者就是擦屁股。

前两天是有
warning: failed to update refs/heads/master; Internal Server Error
怎么还会抽风出玄学的……

@FrankHB typo：但总体还是比 git 那么让人火大→但总体还是比不上 git 那么让人火大
（ git 让人火大的不只是 CLI 设计，至少还有在一些小版本瞎改文件布局之类。）

@duke807 臆造“开源世界”把用户群体割裂是你的另一个明显的技术错误。
开源世界从来都不会整体认为 GUI 不重要。也没有显著的个体支持这种调调，相反的倒有不少。例如，Linus Torvalds 显然算是你所谓开源世界的一员；你可以参照一下他是否认为 GUI 的缺失对开源世界产品的用户更友好。
所以是否来自开源世界，用户对 GUI 的需求很大程度是共通的。要有差别也只是行业习惯上的问题（许多逻辑用 GUI 只会降低效率）；我举例的不属此例。

另一方面，你的说法暴露出你对你所说问题的很大程度的不熟悉。
首先一个事实错误就是 TortoiseHg 并不是所谓的“第三方 gui”，而是 Windows 上默认官方图形客户端。它很早（十多年前）就是随着 Mercurial 官方源一起提供下载的，甚至基本同时发布，只是早年版本号不统一罢了。这和 git/gitk 没本质差异，无非是 gitk 简单到之后直接整合到 git 的 repo 的子目录下一起管理了。
第二，你没看到不同 GUI 的差异。即使是同类的 GUI ，hg 和 git 差异也不小。不管是不是开源世界的，用过不同 DVCS 的用户，不少都认为 git 功能强大，但是命令行设计糟烂。有的用户会自己写脚本包装命令，而 GUI 就是另一种对更多新手用户解脱的方向。（虽说 hg 也有 amend 和 graft 都得 log --debug 才能看的笑话，但总体还是比 git 那么让人火大。）
遗憾的是，不少其它 GUI 也设计得很初级（特别是 git ，命令行的功能多得多，GUI 很多都没实现）。而同样叫做 Tortoise ，TortoiseHg 的 workbench 就吊打 TortoiseSVN 和 TortoiseGit （基本就只是复用了 troitoise 系的图标），功能覆盖度相对也很高，根本就不是一个档次上的产品。抛开 stash/mq 这种底层机制，像 diff/patch/shelves 编辑上的体验就不是一个等级上的，这完全是 GUI 自己设计的差异。
（ Atlanssian 的 SourceTree 就照搬了不少设计，和 TortoiseHg 主界面布局相差远不如 TortoiseHg 和 TortoiseGit/TortoiseSVN 差得多。）
至于 gitk ，说白了主要就只是 git log 的 wrapper ，就别提了。真要说的话，界面布局倒是也更接近 TortoiseHg 而不是 TortoiseGit 。

当然，这里的问题和 wx 还没太直接的关系。上面提过，这个问题是关于框架自身的，二次开发框架才会集中体现出来（死活都没法把 WinForms 改成 WPF 一样的无力）。应用开发者用 Qt 代替 wx 也经常有其它更显著的理由，比如工具和社区支持。

@duke807 抛开具体项目的选型来讲，你的一部分观点值得我单独点名反对。

（才不是看漏了呢，哼、、、）

如 v2ex.com/t/831456#r_11329552 分析的，所谓“原生”基本只是包袱，而不会是普遍意义上的优势。
首先，没什么最终用户就纠结真的 bug-to-bug compat 程度的“原生”。至少 GUI 用户是感知不到一个动作的响应是不是用 WM_SH*T 还是 signal 还是 std::function 来实现的。
所以，只要实现得了用户不需要分出差异的效果，这里的差别基本就只是对开发者有意义。但这个意义仍然是决定性的，存在高下之分。
根本上，就软件工程的一般方法论来看，实现用户需求的过程的正常方向是自顶向下的：了解主要需求，分解需求然后确定实现方案。
这个意义上，任何软件理想情况下理应都是所谓的跨平台软件，因为凭空依赖平台并不是一般用户的主要需求（用户只是“有啥用啥”而已）。这也跟这里分析的任何 GUI 都天然是所谓的 direct UI 一样。
只有为了照顾可实现性，开发者便宜行事，才添加实现细节而形成路径依赖，导致潜在的方案切换成本。这本质上是一种妥协，是一种 artefact 而不是 intent 。
是否使用所谓原生或者所谓的 HWND 都是这类细节的例子。把这种实现细节泄露到上层的方案中造成混乱的状况乃至坑到开发者自己，是到底，全体开发者的无能或者说失职。
具体来讲，现在需要纠结这方面的选型，直接原因就是 GUI 历史上的实现就很碎片化，导致能产品化的方案也很碎片化；而后来的开发者并没有能力把不同的方案统合起来（加上像 mac 阵营和早年 Windows 开发者都很多刻意搞封闭制造技术兼容性壁垒的），事实上根本没一般意义上跨平台的方案能用（ Web 也跨不了资源受限的一些嵌入式设备），所以才不得不去对照具体方案比较优劣计较得失（因为做不到面面俱到）。
想比较彻底地解决这种问题，专业搞 GUI 框架的都搞不定，作为应用开发者自然更加搞不定，这情有可原；但是不正面认识到这只是一种妥协，反过来以退为进，给碎片化继续火上浇油，不说技术上是否绝对正确，那起码算是个自私的方向。

@g00001 这里有个和上面相关的我需要批判的观点。
既然“桌面软件”这么个大概念的实现方案混乱如此，都快要指望全人类命运共同体都不见得能收拾得好了，那么纠结“一拖源码就可以导出来”就不应该强调。
或者说，为了实现刻意藏源码这种不是来自用户而是开发者自己的需求，增加另一个维度上的问题复杂度，这是唯恐天下不乱。
倒并不是说混淆源码的需求就一定是错的。而是说，即便藏起来源码开发者天然有权自决，实现成什么样的效果也是开发者自己负责，但一旦开发者行使这种权利，道义上就有必要需要理解这算得上是在薅市场羊毛，耗费本来就捉急的能系统性解决这类历史问题的公共开发资源。
这方面更应该鼓励的是把商业价值和源代码的可见性脱钩：在商业模式上做到即便随便让人扒源码也不会泄露商业秘密和损害销售，而不是道高一尺魔高一丈搞这种老实的最终用户只会凭空付出开销的军备竞赛。这样对谁都好。
如果能收拾好跨平台弱鸡可移植困难的局面，份额多少也会成为大多数开发者不用再操心的历史问题。

顺带说一下另一个问题：安装包体积和开发体积完全是两码事。安装包大是因为二进制依赖，这些依赖不需要应用开发者修改。而且只要系统自带就看不出来了。这个方面至少.NET 其实相当大，并不比 Electron 省地方。

挺尬的，半斤八两，尬的意义不一样……
如果你要开发体验的话，那么原则上是 C#，毕竟 Qt 你想用舒服基础姿势水平不低……C#的应用效果其实吃亏，但强在你能用更短的时间折腾出更多不同的方案试错。当然，前提是能实现。
.NET 在框架的意义上吹亏的就是定制起来没 Qt 那么容易折腾（或者说 Windows 以外基本就没稳定实现能用），Avalonia 这种比较新的，具体坑有多少没试过不好说。
Qt 虽然开发效率是个槽点，但是还有 Python 绑定能用（好歹没那么啰嗦），所以也算不上决定性的缺陷（用不用得惯 py 就另说了）。
如果你说做商业项目，要考虑让人接手，那么还是 Qt 忍忍吧。个人项目就随便了。
用不用 QML 看口味。我是不想用，主要是不喜欢各种 ML 那套（有这功夫还不如折腾 SGML+DSSSL 去了）。

Flutter 响应慢和资源占用糟烂是预料之中的，毕竟底层的开发者自己都缺根筋： https://github.com/dart-lang/language/issues/490 。
这类方案的开发者看上去的共同点是没有一个严肃的桌面客户端应用开发背景，整个技术栈的根本设计上就不用指望能解决此类问题，只能“优化”变通。
JS/Electron 之类的软肋也就是这个，而 Dart/Flutter 么，怎么说也不用指望有更好的资源来（各种意义上的）优化了。
大多数玩具也有类似的问题。Rust 实现的算是少数的例外，问题是 Rust 的这类项目都没多少存在感也活不大长，怕是所有第三方方案中最不靠谱的那类，支持就更加看脸了。

@duke807 wx 基本就是个跨平台 MFC ，除了用纯 C++而不需要 Qt 这种 moc 以及性能稍微（在 C++的意义上）更好以外，没什么技术上的优势。工具和开发者社区更不用指望了。
我见过有长期维护的项目从 wx 切换到 Qt 的，比如 TortoiseHg 早期用的 wxPy 后来就切成 pyQt 了。
虽然开发应用未必需要很在意，wx 这类“原生”方案有个致命的架构扩展性弱点：不是所谓的 direct UI 。（依赖 Win32 的 MFC 和 WinForms 也有类似问题，但大部分正常的都没有。）
参考 https://v2ex.com/t/831456#r_11329552 。

@neoblackcap 自己写一个当然是终极方案，不过就只是自己的项目用，太浪费了。
我就糊过能跨 NDS 和 Win32 的，上边 C++能做到都完全看不出是什么平台的（反正比 QtWidgets/QPA 那坨彻底得多），不过自己糊的开发体验嘛……mac 工作量不好估计，反正 Linux 的后端我是坑快十周年了。
imgui 这种 immediate mode 的半残基本也就算图形库了，都不算正经 GUI 库（撑死就是“画界面”外加输入套皮），GUI metaphor 基本都没在 API 体现，要在严肃项目里用还不如自己造轮子。
比起上面说过 wx 是缺乏可扩展性，imgui 这种就差不多没什么架构能被扩展。要从里面拆代码复用，那还不如自己照搬目的纯粹一点的图形库（ Cairo 、skia 之类）自己从头搭框架。

@ZSeptember 说 Qt 资源占用多，对也不对。
比起大多数其它 C++方案 Qt 往往因为不必要的运行时元数据访问而确实经常更拉胯，但一般同等经验的开发者写起来不会比用 C#实现的更慢。也就 QtCreator 这样规模的应用比较容易暴露出瓶颈。
更重要的是这里可是把 Electron 都拉上场一起遛了，正经写想更慢实在不大容易。

@wdhwg001 这只是相对其它成熟方案来说的，如果是相对自己糊界面库，这类问题就算不了什么问题，毕竟自己实现也得把这种东西折腾对，还是挺花资源的。
根本让 Flutter 无可救药的是上面说过的 Dart 的思路（同时也适用于 Electron ）。

@mmdsun 内置 POSIX 子系统比较早，Windows NT 一开始就有，但也不是一直。而更重要的是它本身不提供原先由 POSIX.2 提供的交互式环境，要 shell 和命令还是得另外安装；后来 SFU 基于 OpenBSD 的代码才提供了一套实现。但那个也就是聊胜于无，基本上目标用户都去折腾 Cygwin 了，而且 Windows 8 以来就移除了，横竖还是得用户自己搞定命令界面。

补充以上的个别零碎观点：
1.MAC 的概念应该在 1980 年代中期就算成熟了，比 Linux 早。
2.上面绝大多数安全值的都是 security 而不是 safety 。需要 protect 的也主要是这种安全。
另一方面，对 PL 用户来讲，所谓 safety （ memory safety/type safety/...）也的确主要只是为了防手贱的，并不能指望多 secure ；虽然：
(1)手贱了的确可能导致写出来的代码更容易有缺陷可被利用；
(2)违反 safety 在某些 PL 中直接引起未定义行为而破坏了 security 假设的常见前提。
这体现防手贱也有单独的必要性，某些情况下算是实现 security 的一种前提。

@james122333 尽管访问控制在描述计算机安全系统的文献中比较流行，访问控制既不是通用的安全(safety)也不是系统安全（或者说安保）(security)专属的特性，而是一种要求系统具有特定属性时的实现手段。

对上层系统的需求描述来讲，可预期应当是自然的，但实现上不可能无限担保，总有一些前提。逻辑上任何一个不满足假设前提的非预期行为的脆弱性都可以导致一整套机制实效。
例如，基本上重大的软件安全漏洞都源自于安全软件的实现违反可预期的语义保证的程序行为。符合语言规范要求的正确编码就是这里的一种前提。

如果真要用于安全目的，笼统的访问控制的效果除了“可预期”（但是因为许可证经常不担保承担责任，出 bug 嘛……），几乎等于没有。
即便说的是 MAC ，也要求区分正确不同的敏感性才可能提供有意义的保证。当然，不是说不满足 MAC 就无所谓安全，但说实话就算具有 MAC 的系统，也可能只提供很入门级的系统安全性。
对控制整个计算机的操作系统，没有 MAC 意味着系统管理员基本没什么手段最终可以区分针对系统资源利用的无意和恶意的历史行为，在此之上的保护仅仅是防止手贱的程度了。
所以光是考虑对非专业用户的认知友好（避免误导）上，这类访问控制还不如彻底排除出安全目的，就像设计用于摘要的散列函数不应当被视为“加密”一样。

处理文件权限的要求是软件接口的要求，包括 API 和 UI 。没什么实际应用故意去利用文件权限来编码无关的业务信息，所以如果放弃基于文件权限的访问控制，这就是多余的。考虑到上下文（比如沙箱）可以代替文件作为更强力的安全措施，这原则上不会损害安全性。
另一方面，摈弃权限的思路，特定的属性反而可以编码原先没有不能充分被利用的更上层信息。例如，限制写访问不作为访问控制，而是明确作为文件的只读属性的实现，可以类似 PL 中的对象引用的只读访问限制；如果能假定上下文而确保只读访问不和其它数据访问（比如并发写内容或者修改属性）冲突，传统 PL 上的优化也可以适用于 VFS 及其它持久对象系统。对只读属性，典型的优化是常量传播。结合这些优化，可以轻易地实现文件系统去重这样的高级功能，而不用单独重新实现（除非是为了性能调优进行特化）和验证。
遗憾的是，传统的操作系统设计并不适合这种实践——非但缺乏普遍可编程的上下文，还普遍不能排除 TOCTTOU 这种并发访问冲突。
（作为实现细节，虚存分页机制上的权限可以继续维持 RWX 的基础设计以避免开销；这不和上层的高级语言语义或者持久存储要求的属性矛盾。）

考虑这种遗憾的相当大一部分，来自系统和应用开发者的墨守成规（不愿意承认上下文的必要性），现在来看，UNIX 权限这种设计，还不如一开始就没存在过。
多用户自然还是得有的，但不应该和 UNIX 权限那么强绑定：而是更接近 NT 的 SID 这样的间接抽象；虽然 SID 用起来的体验嘛……

@tomychen 这里的阻碍很大程度上来自 UNIX 等上古系统设计的思维惯性，使系统设计和维护人员乃至大多数应用开发人员都难以适应范式转移，而不是具体维护工作的开销（虽然这对绝大多数组织已经够要命了）。
更根本地，这可以追溯为主流的设计人员没有理解清真正的需求，而直接偷懒复用了旧的设计，恰好旧的设计因为时代局限性等历史原因也没有解决一系列关键问题。这同时是懒惰和教条主义的体现。
这种消极的懒惰不是强到一定的地步，TOCTTOU 这种低级的问题不可能不被处理掉，而不是 POSIX.1-2008 这样一堆 at 补丁就能凑数了。

所谓设计模式是另外一种业界体系性缺陷的集中体现：www.v2ex.com/t/835769#r_11427195 ，所以看起来像设计模式味儿的设计，本身就暗示存在一些没解决的糊涂问题。
老实说，UNIX 这种一切皆文件的设计和 OOP 语言所谓一切都是对象的设计是类似的问题，比所有所谓的设计模式都高层一些，更应当是架构上的。
即便如此，这里也是高下立判。OOP 类似主张的主要问题是根本没拎清楚“对象”本来就应该有的含义，重要原则（设计上鼓吹 LSP ）其实也是老调重弹（这其实就是许多更传统多态类型系统上的公理），而在更具体设计（类型系统上基于继承这种序结构实现的包含多态）多少还有点进步意义；反观文件，则更像是需求假设破碎却又应对不了新的需求（要求常规文件和目录以外新的类型的持久对象）之后的近乎不作为放任自流的结果罢了，在古典设计之后基本就不存在实质的创新。

SELinux 的出发点（看到现有系统设计不足，应对真实安全保证的需求很无能）没太大问题，复杂主要也是来自安全保证需求自身。
但另一方面还有它是在传统 UNIX 的 VFS 上的强行修补的原因。如果 UNIX 权限不存在，那么结果大约会好那么一些。
（嘛，只是好一些，因为缺乏像样的 UI ，也确实太复杂了，并且这玩意儿文档也不大好找，具体配置非常依赖用户自己发挥； Linux 桌面系统要是开箱可用不折腾也就算了，Android 手机我是折腾吐了弃疗了。另外 Android 的魔改权限正是我黑 UNIX 的动力之一，即便折腾起来比 SELinux 仍然容易多了……）

没有后退的余地会让开发者使 UI 更加友好易用。这才是最终能使这种机制普遍实用化的动力，而现在做得还是很不够。排除掉上面的来自开发者懒惰和墨守教条的原因，还有个重要因素是最终用户推动不够。大多数用户甚至都未必知道这个难用到什么程度，知道“难关闭”（但这姑且算是个预期中的 feature……）就不错了。
这方面我强调：不好用，也尽量不要回避，否则只会恶性循环而无法改善现状。

TOMOYO 这样的尝试对引入安全保证的能力是好事，但是长期来讲，仍然不算受到足够的重视（这个应该 2.6 时代就有了，长期也没啥存在感）。
Linux 社区，特别是 Linux Torvalds 本人，传统上并不怎么在乎安全需求（传说中的 masturbating monkeys……）。
独立于内核之外的 Grsecurity/PaX 是早年一个比较著名的例子。
当然，其实我也没那么在乎……至少没在乎到像 old school hacker 一样亲自糊个类似 LSM 的东西；毕竟成本过于离谱。
我更在乎的是不合时宜的旧设计无法被移除，并且越来越没戏。
毕竟，软件安全的一个持久的重要未决问题是：现有代码写得太长了，导致看不完而没法完成审计。

源代码中的行和生成代码的顺序本来就不保证相同（其实都没法一一对应，因为有的可能根本不生成目标代码）。由于编译器 IL 和目标代码也不保证一一对应，指令重排序在后端也可能发生。优化可能会增加这种机会（因为不优化编译器可能会偷懒就默认源代码翻译顺序了）。默认顺序也不绝对，像 GCC 生成函数实际参数的代码中一般表现出从右到左求值，除非改-feval-order 。
既然用 gdb ，你 si 一下看看指令走的流程跟你源代码怎么对应的就是了。

@FrankHB typo ，闭包是 1964 年前后出现的（ SECD machine, P. Landin ）。

@tomychen 出现的先后不是重点。而推行的实际复杂度或者说代价对非专业用户来讲，很多情况只是错觉。
如果基于上下文的机制有像样的实现，完全可以让用户感知不到复杂性，并且可能简化自动管理和修复安全规则问题的 demon 实现，而避免绝大多数系统管理员还要手动处理文件权限之类的问题，反而能整体削减用户的成本。

这在其它领域中存在先例。大部分非研究者的普通开发者认为，在动态 PL 中实现静态的词法作用域因为需要单独管理更多的上下文而不易高效实现，因此即便知道显著缺陷（但“又不是不能用”），大多数动态语言的设计者和用户还是接受继续使用动态作用域。
尽管大约 1954 年就出现了一般的解决方案（闭包），直到 1980 年代 Scheme 的高效实现才让主流开发者认识到代价到底可以怎样被有效控制。这之后大部分语言都不再采用默认动态作用域的设计。

这个领域面临的问题类似：现有的机制看上去有时候能用，就被姑息了；而更完善或者说原则上更正确的方案因为少人使用，而仅限于少数专业玩家才会考虑使用，结果不够易用。这种情况迟早应被改变。

@tomychen @james122333 关键问题是所谓的访问控制本来就不应该是安全特性。
一般意义上任何可预期的访问都涉及访问控制，并且没有特定的规则的限制，默认就是 DAC 。
事实上非安全上下文的访问控制普遍存在各种具有一定抽象能力的可编程上下文中。例如 C++ 和 Java 之类的所谓 OOP 语言中，private 这样的关键字就用来提供基于名称检查的数据访问控制的限制，你能把它当作“安全”么。
这种基于名称检查的访问控制是为了实现信息隐藏来提供封装性。从这个意义上来讲，所谓的就是利用名称访问资源的日常操作的一部分，只要不是检查就不用强调。
并且，不管是不是系统安全的目的，实际上还有更靠谱的：直接不提供可见的名称，连检查都不用。（例如，包括基于求值环境的隐藏，或者弱化一点，ES 的 WeakMap 之类： https://github.com/tc39/proposal-class-fields/blob/main/PRIVATE_SYNTAX_FAQ.md#how-can-you-model-encapsulation-using-weakmaps 。）

在信息安全上下文的上下文，管理资源的 API 经常退化为 UI （例如 shell 命令），处理的输入限制也弱很多（例如 VFS 路径相对一般 PL 里的引用），这里的相关设计体现出在想象力就弱上许多，也更依赖具体名称限定的少数检查入口，以至于会滥用半吊子解决方案。
对用户来说，尽管 DAC 无处不在，去在乎权限位这种多数情况就是自欺欺人的机制只是浪费精力。

UNIX 的 FS 的这种设计其实就是附加了一些元数据，让 VFS 的系统调用保证可以获取。
这种实现手段是整体容易批判的：比一般编程机制的手段（比如说，类型系统）弱得实在发指而不成提供。
无能性首先体现在因为大部分情况下用户就不会关心这个，却又时常被坑；真要关心的时候，却又经常不顶用，而不得不指望另外的像样的 MAC 和审计措施来补救。
一部分代价跟用户是否容易误操作无关。比如，我凭什么要忍受 FS 多占用一个位来允许 drw- 这样没卵用的组合呢？（我知道扇区存储的磁盘不用纠结空间浪费，但是 tar 一下还是可以有感知的。）
并且，这还可能真的使用户增加看似便宜，实际坑爹的误操作的机会，像 chmod -R 777 这种低成本一键搞砸系统的冗余手段；如果说 rm -rf 姑且算是管理系统资源的必要手段的滥用，这就算是凭空多出来的 side channel 了。
另一方面，这种元数据就算留着，也没什么扩展性。类似的简单水平扩展，如 sticky bit ，也就是另外附加，而不是取代鸡肋设计。结果，整个设计还是同样的馊味。

于是，这样的设计，就日用来说，基本上还不如没有。如果非要实现现有 UNIX 权限位类似的功能，大可以让像样的实现（如系统级 MAC ）来作为基础，重新建立适当的 UI 。
遗憾的是，不管是 SELinux 还是 NT 安全性模型，这些系统级设计都过于依赖系统机制自身，也没有充分的 UI 来让用户便于使用。但我不认为这是个安全性原则问题；易用性上的尴尬是产品力缺失的表现。

那么，为什么 UNIX 的 VFS 会特别明显地暴露这类缺陷？这恐怕根本就不是安全设计或者“用户”应该代表什么的个别问题，而是更一般意义上的“哲学”出了岔子，导致各种抽象都和开始的原意若即若离地背离，却又无法甩脱兼容性而一直被滥用。这种鸡肋抽象，最典型的就是“文件”：
cf. https://github.com/FrankHB/pl-docs/blob/master/zh-CN/about-operating-systems.md#%E4%B8%80%E5%88%87%E7%9A%86%E6%96%87%E4%BB%B6everything-is-a-file
在用户空间滥用“文件”作为首要的操作实体，与其说这是简化用户的手续（不用去学 PL 而只用学 shell ；不用认真了解怎么折腾 API 去避免非预期行为而只要等待 CLI 的反馈），倒不如说是系统设计者没能力把两种面向不同用户的可编程手段统一起来。
更一般地，这表现在对“无名师和万行码”的吹捧上——表面上看，是让 shell 干 shell 该干的活，让 C 不要掺和，属于使用合适的工具完成任务的典范；而事实上，这只是掩盖了 UNIX 祖师没能力发明出涵盖 shell 编程和更严肃的“系统”编程的统一接口而已。
比如，要是当年有像 scsh 类似的实现，现在可能就不会坚持 pid_t 乱飞导致僵尸进程这种层次的设计问题暴露给系统管理员添堵了。

@imn1 “俄”的横空出世是最奇葩的，属实被蒙古人坑了……

@adoal 几乎从来就没有系统化的整理，光看社会群众按闹分配想到哪改哪，连基础教育的面子都不给，这怎么不是屈从没文化了？像主张合并还是区分“的、地、得”的几派，提出观点时好歹还是有各种论据佐证的，你个审音表脸咋就那么大，搁置争议搁置到不同意见都没了？

@DOLLOR 你说的使用繁体字的人，是不是包括你自己……

@imn1 涉及专名就无法有所谓。比如 Shell 翻译成的“壳牌”的“壳”读 qiao4 而不是 ke2 ，据说当年是厂家按翻译专家意思定的音；尽管按一般文白异读的习惯还是相反的。你读得不合原作的意思，那就是不对，都不需要拆字考虑来源。
这还是新造词。改既有地名甚至姓氏就比较损了。