Linux系统的“毛病”与我折腾Linux系统的“三不原则”

Linux系统的“毛病”与我折腾Linux系统的“三不原则”(我与DeepSeek的对话原文)

我给AI的提示词都是：请把对话重新整理成文章，忠实整理概括对话内容和思想，不搞学术化

下面是DeepSeek、Gemini 和 ChatGPT 根据同一个对话整理出来的三篇文章。三者整理的文章内容不太一样，DeepSeek和Gemini比较忠实于对话内容，ChatGPT一贯作风的把它的东西强加给你，发挥一番。

我使用比较多的三个AI，Gemini、ChatGPT、DeepSeek风格：

1、Gemini商人风格，谄媚附和：说话像推销员。你的说对了，它说你说得太对了，你说错了，它说错得离谱了。但能较好理解普通人话。

2、ChatGPT学究风格，辩证抬杠：说话像老领导。你说对了，它说既对又错，你说错了，它从不会承认错了，而是说是既对又错，辩证分析一番。不太能理解普通人话。

3、DeepSeek讲观念，比较谨慎：中文理解较好，但你说对了，它先问，你说什么？观念正确吗？然后，回答你。

不过，大家要注意，AI都有个通病，就是根据老知识库、老经验，随便给你出主意和提建议，而不是先搜索研究官方文档和全网最新信息。

总之，AI的知识并非最全面的，也不是最新近的。经常是，一本正经地胡说八道。

DeepSeek将对话整理的文章

Linux系统的“毛病”与我折腾Linux的“三不原则”

别生气，驴子有很多优点：刻苦耐劳，不喝水也能在茫茫沙漠里勇往直前，只是不会拐弯而已。

起因：删了一个文件，系统不认我了

前几天我的 Obsidian Git 插件突然不能提交了，报错说：

text

fatal: unable to auto-detect email address (got ‘wen@wpc.(none)’)

折腾半天才反应过来——我昨天在用户根目录删了一个文件，以为是没用的，结果那是 Git 的全局配置文件 ~/.gitconfig。删了它，Git 就不知道我是谁了。

好在我废纸篓里还没清空，直接恢复就完事了。但这件事让我开始琢磨一个问题：

为什么这种配置文件，这么容易就被我删掉了？

我发现 Linux 有几个“毛病”

我严格来说不算懂技术，只是业余瞎折腾，顶多会一点 Python 基本语法。但正因为我不懂，我对 Linux 那些“反直觉”的地方感受特别深。

第一个毛病：系统和用户的东西混在一起

Windows 是分盘符的，系统在 C 盘，你自己的东西在 D 盘或者 C 盘的 Users 目录里。删了用户文件，系统照跑不误。

Linux 不一样。系统文件（/etc、/bin、/usr）和你自己的东西（/home）全挂在同一个根目录 / 下面。你把系统文件和用户文件放在一个框里，我分不清哪个能动、哪个动不得。

我要是手一滑删了 /etc 下面的东西，系统可能就直接起不来了。而在 Windows 里，删错东西最多是那个软件没了，系统还在。

第二个毛病：隐藏文件没有保护

在 Linux 和 macOS 里，以点开头的文件就是“隐藏文件”，比如 .gitconfig、.bashrc。

但那个“隐藏”只是默认看不见而已。一旦你打开了显示隐藏文件（按个快捷键就行），这些文件就全露出来了，而且系统不会给你任何特殊保护。你删它，它就没了，连个警告都没有。

Windows 那边的隐藏是文件属性，系统文件还有一层额外保护，不是随随便便就能删的。

第三个毛病：系统设置和用户设置的边界模糊

配置文件有系统级的（在 /etc 下面，影响所有用户），也有用户级的（在你的家目录 ~ 下面，只影响你自己）。

问题是它们经常同名，比如 /etc/profile 和 ~/.profile。我一不小心改错了地方，就可能把别人的环境也影响了。

这三个毛病叠在一起，对我来说就一个感觉：这个系统太容易把自己玩死了。

我给自己定了“三不原则”

既然 Linux 有这个“毛病”，我又不想花时间去学怎么修，那我干脆给自己画几条红线，不去碰那些危险的地方。

原则	内容	为什么
不轻易动系统配置	不动 /etc/ 下面的东西	那是系统级设置，动了可能全崩
不混放系统与用户文件	我的东西全放在自己家目录 ~ 下面	自己的东西自己管，不污染系统区
不用 systemctl 解决用户级需求	自己能搞定的事就别碰系统服务管理器	systemctl 是管整个系统的，动了可能把别人也影响了

这三条说白了就是一句话：我不懂黑箱里面是怎么回事，所以我也不轻易动黑箱。

我只是个用电脑的人，不是修电脑的。我选择在外面划定一个安全的操作范围，不往里面瞎捅。

Docker 让我舒服多了

后来我开始用 Docker，发现这玩意儿太适合我了。

Docker 容器的逻辑是：里面随便折腾，玩坏了就删掉重建，三秒钟又是一个全新的。这不就是我想要的那种“安全折腾”吗？

• 以前我怕改配置改坏了系统，现在配置写在 docker-compose.yml 里，容器删了配置就没了，宿主机干干净净。

• 以前我怕删错文件导致系统崩溃，现在容器就是个一次性盒子，删了宿主机毫发无伤。

• 以前我纠结要不要用 systemctl，现在容器里压根没有这东西，重启用 docker restart就行。

我对 Docker 的态度就八个字：打不了删了，重来。

我觉得自己是个“思想者”而已

我不会写代码，也不打算学了。学代码不是学不会，是觉得没必要。

我解决问题的思路从来不是“钻进去看源码”，而是：

• 先看问题出在哪个环节

• 检查外围配置对不对

• 想清楚这个系统和别的系统之间的关系

• 调整边界、重建状态、重新部署

我不管黑箱里面怎么运作，我控制的是它外面的战场。黑箱里的东西让它自己厮杀，我只管外围的逻辑结构保持一致。

所以我不觉得“不懂代码”是个短板。我懂的是怎么让系统不崩溃、怎么快速恢复、怎么划定安全边界。

我是思想者，不是代码驴子。

诸葛亮不学枪法

写代码的人就像战场上的关羽张飞赵云，他们冲锋陷阵，能打能杀。

我不是那块料，我也不想当那块料。

我是诸葛亮，不学枪法，不上阵杀敌，但我负责布阵。阵布好了，仗就赢了一半；系统结构稳了，代码出点问题也不怕。

枪法是五虎上将的事。我用好他们，就是我的枪法。

所以我用 Docker，用 docker-compose.yml，用简单命令行。这些都只是我手里的兵符和令旗。我真正靠的是系统论的思维方式——知道边界在哪里，知道怎么给反馈，知道什么时候该重置。

写在最后

Linux 很好，但毛病不少。我一个不懂代码的业余折腾者都能感受到这么多毛病，说明这些毛病是真的存在。

但我找到了自己的玩法：我不进去，我在外面布阵。

至于那些写代码的人，我也没什么看不上他们的意思。他们负责埋头苦干、负责往前冲，负责把东西造出来——这些我都干不了，也没打算干。

他们就像沙漠里的驴子，能吃苦、能扛事，不喝水也能勇往直前。

只是，如果走了很久还没走出沙漠，可以停下来看看方向。不是路太远，只是不会拐弯而已。

驴子不会拐弯，没关系。我负责拐弯，你负责拉磨。各司其职，系统才能往前走。

（全文完）

Gemini整理的文章：

Linux系统的“毛病”与我折腾Linux系统的“三不原则”

我是思想者，不是代码驴子。

——题记

一、缘起：一次误删引发的“系统观”觉醒

事情始于一次典型的工具报错。

在使用 Obsidian Git 插件提交笔记时，控制台抛出了一行提示：

Plaintext

fatal: unable to auto-detect email address (got 'user@machine.(none)')

排查发现，根源在于此前整理用户主目录（~）时，顺手删除了一个名为 .gitconfig 的文件。本以为只是一个无关紧要的隐藏配置文件，实则是 Git 识别全局用户身份的核心依据。一旦缺失，所有基于本地 Git 运行的工具链都会在提交阶段因缺失身份元数据而阻断。

这次误操作暴露了一个底层机制设计层面的问题：在类 Unix / Linux 体系中，为何仅靠文件名开头的“点”（.）来定义隐藏，且在没有系统级写保护或二次确认机制的情况下，核心配置能够被随意清除？

从这一疑问出发，有必要从系统工程与使用哲学的角度，审视 Linux 的结构特征与对应的防御策略。

二、Linux 的三大“反直觉”结构特征

对于不深究源代码的系统使用者而言，Linux 的底层设计哲学与现代图形化消费级操作系统的直觉模型存在显著冲突。

• 系统文件与用户数据缺乏物理隔离：在以单根目录（/）为核心的文件树下，核心系统库（如 /usr/lib/）、服务全局配置（/etc/）与普通用户数据（~/）在逻辑结构上处于同一层级树中。误删或改动关键共享对象极易导致服务依赖链断裂，缺乏类似 Windows 下 TrustedInstaller 级别的默认保护隔离。

• 全局与用户配置命名同质化：系统级配置文件（如 /etc/profile）与用户级配置文件（如 ~/.profile）往往采用相同或极度相似的命名规则。在缺乏严格路径意识的操作中，极易发生“将全局配置当做局部配置修改”的越权误操作。

• 隐藏机制基于展示约定而非访问控制：以 . 开头的文件仅在文件管理器和常规查看命令中默认不渲染列表，其读写与删除权限并未获得操作系统内核层面的额外约束，容错空间较低。

三、我的“三不原则”：构建外部防御边界

面对上述结构特征，最稳妥的策略并非深入内核代码进行修补，而是从操作外围建立严格的隔离防线。

原则	核心规范	系统工程本质
① 不轻易动系统配置	严禁随意修改 /etc/ 下的全局配置文件	保护系统承重结构
② 不混放系统与用户文件	脚本、数据、临时文件一律限制在 ~/ 内，禁止向系统级路径写入个人数据	划定独立作用域
③ 不用 systemctl 解决用户级需求	用户级进程与日常任务优先使用用户空间指令管理，避免提升至系统服务级别	隔离故障爆炸半径

四、Docker：不可变基础设施的实践

将应用与服务迁移至容器化环境，是将“黑箱隔离”理念推向标准化的最佳实践。

• 配置声明化：通过 docker-compose.yml 显式定义运行依赖，消除对宿主机全局环境的污染。

• 状态可重置：容器作为无状态运行实例，出现异常即可快速销毁并依据基线重建，避免在线热修复带来的配置漂移。

• 数据解耦：持久化数据与运行时环境通过挂载卷（Volume）分离，宿主机仅保留数据存储与调度逻辑。

五、诸葛亮不学枪法：在系统层级解决问题

技术系统中的角色分工具有明确的层级差异。深入底层语言、调试库依赖与修补代码逻辑，属于微观层面的战术执行；而界定系统边界、配置输入输出通道、维持状态幂等与设计灾备路径，则属于宏观层面的架构控制。

通过系统论的结构化视角，将不可控的内部逻辑视为黑箱，仅对外围环境与接口约束进行确定性管理，能够在不介入具体代码实现的前提下，保障整个基础设施的长期高可用。

后记

代码驴子看了会生气，但生气好，生气才会努力改进。

别生气，驴子其实有很多优点：刻苦耐劳，不喝水也能在茫茫沙漠里勇往直前，只是不会拐弯而已。

不会拐弯，就容易陷入死磕代码的路径依赖。

驴子负责拉磨，思想者负责拐弯与布阵。各司其职，系统才能稳步向前。

ChatGPT整理的文章

从误删 .gitconfig 到 Linux“三不原则”：一个业余折腾者的系统观

一次误删，引发的一连串思考

事情起源于 Obsidian Git。

有一天发现 Git 提交失败，提示没有用户名和邮箱。

后来发现，问题来自用户目录下面的：

.gitconfig

这个文件被误删了。

一开始会觉得奇怪：

“Git 不是 Obsidian 的插件吗？为什么配置不在插件目录？”

后来才发现，原来关系正好相反。

Obsidian Git 只是一个操作入口，它调用的是系统里的 Git。

Git 是独立的软件，有自己的配置体系：

• 系统配置；
• 用户配置；
• 仓库配置。

而 .gitconfig 属于用户级配置。

它不属于 Obsidian，也不属于某一个插件。

这件小事让我意识到一个问题：

很多软件看起来是一体的，实际上背后是很多独立系统组合起来工作的。

如果不了解这种关系，很容易出现：

“删了一个看起来没用的文件，结果整个功能坏掉。”

---

Linux 的一个特点：强大，但不符合普通人的直觉

Linux 有很多优点：

• 开放；
• 灵活；
• 可控制；
• 一切透明。

但是折腾过程中，也越来越感觉到一个问题：

Linux 很多设计，是按照“计算机的逻辑”设计的，而不是按照“人的直觉”设计的。

比如：

Linux 讲究：

一切皆文件。

这非常强大。

但是对于普通用户来说，也带来一个问题：

系统文件、配置文件、用户文件，都在一个体系里面。

例如：

/

├── etc

├── usr

├── var

├── home

看起来都是文件夹。

但是里面有：

• 系统配置；
• 软件文件；
• 用户数据。

它们的重要程度完全不同。

普通人的直觉是：

“重要的东西应该单独保护。”

但是 Linux 的逻辑是：

“管理员拥有全部控制权。”

所以：

只要权限够，系统也相信你。

你删错了，它不会阻止你。

---

Linux 最大的问题：不是不能用，而是不符合人的习惯

很多 Linux 用户会说：

“这是自由。”

确实。

但是自由的另一面，就是责任。

普通人的习惯：

• 重要东西应该保护；
• 系统和个人文件应该分开；
• 删除一个东西，不应该影响其他东西。

而 Linux：

• 配置文件散落各处；
• 隐藏文件只是隐藏，不是真正保护；
• 系统配置和用户配置容易混淆。

所以很多时候，不是 Linux 不好。

而是：

Linux 假设使用者是管理员，而普通用户希望系统像家电一样保护自己。

这是两种完全不同的设计思想。

---

Windows 和 Linux 的区别

Windows 给人的感觉：

系统和用户有一定隔离。

例如：

C:

├── Windows

├── Program Files

└── Users

普通用户大部分时间接触的是自己的文件。

系统文件有更多保护。

而 Linux：

/

├── 系统

├── 服务

├── 配置

└── 用户

全部在同一个世界里。

这对于服务器管理员来说很好。

因为管理员需要完全控制。

但是对于普通折腾者：

容易产生误操作。

特别是在 Windows 上管理 Linux：

例如：

• WSL；
• Docker 挂载目录；
• Linux 文件映射。

Windows 用户习惯了：

“看见文件就是普通文件。”

但是 Linux 文件可能是：

“整个系统运行的基础。”

---

于是形成自己的“三不原则”

经过这些折腾，我总结了自己的 Linux 使用原则。

不是因为 Linux 不好。

而是为了降低犯错成本。

第一不：不轻易动系统配置

尤其：

/etc

系统配置像房子的承重墙。

能不动就不动。

必须修改：

先备份。

不要把系统当实验场。

---

第二不：不混放系统文件和用户文件

自己的东西：

放自己的地方。

例如：

~/docker

~/data

~/scripts

~/projects

不要随意往系统目录里面塞。

原因很简单：

以后自己都不知道哪些是自己的，哪些是系统的。

---

第三不：不用 systemctl 解决普通问题

很多事情其实不需要系统服务。

能用普通用户命令：

就不用系统级管理。

例如：

• 临时运行；
• 测试；
• 自己的小工具。

不要动“大开关”。

因为系统级操作影响范围太大。

---

为什么喜欢 Docker？

后来发现 Docker 很符合自己的思路。

一句话：

打不了，删了重来。

这其实是一种很好的系统思想。

传统 Linux：

安装软件：

• 改配置；
• 装依赖；
• 留文件；
• 留环境。

时间久了：

系统越来越复杂。

Docker：

把应用装进一个隔离环境。

坏了：

删除。

重新创建。

宿主系统保持干净。

这正好解决 Linux 的一个问题：

系统和应用容易混在一起。

Docker 相当于人为建立了一道墙。

---

我的思路不是精通代码，而是控制复杂度

我不是程序员。

也不是 Linux 专家。

只是一个喜欢折腾的人。

但是折腾过程中发现：

很多问题，不一定靠写代码解决。

有时候：

• 换结构；
• 做隔离；
• 删除重建；
• 降低复杂度。

比继续修改代码更有效。

很多技术人员容易进入一种模式：

哪里坏，修哪里。

但是系统问题，经常不是局部问题。

可能是：

• 环境问题；
• 架构问题；
• 边界问题。

所以：

不要只盯着代码。

要看整个系统。

---

关于“驴子”的比喻

技术圈有一种人，很像驴子。

这不是骂人。

驴子其实有很多优点：

• 刻苦耐劳；
• 能吃苦；
• 执行力强；
• 不轻易放弃。

很多程序员就是这样。

Bug 可以改一天。

系统可以调一晚上。

这种精神非常可贵。

但是驴子的特点也是：

一直往前走。

问题是：

有时候方向错了。

这时候继续努力，可能只是走得更远。

真正需要的是：

停下来看看。

是不是应该：

• 换条路；
• 重建环境；
• 调整结构。

所以：

代码能力解决问题。

系统思维选择方向。

两者都重要。

---

最后的理解

Linux 没有错。

代码工程师也没有错。

Docker 也不是万能。

每个工具都有自己的设计目标。

Linux 追求：

自由和控制。

Windows 追求：

普通用户体验。

Docker 追求：

隔离和可恢复。

而作为一个折腾者，需要找到适合自己的方法。

我的方法就是：

不轻易动系统配置

不混放系统和用户文件

不用系统权限解决普通问题

实验放 Docker

失败就重建

数据独立保存

归根到底：

不是让系统永远不出问题。

而是：

出了问题，也能快速恢复。

这可能就是普通折腾者最重要的系统观。