@66450146
考虑过这个方法了，但遇到了一些问题。

是我把背景过于简化了，没有讲清楚。因为我想着把大致背景交代一下，就能遇到解决过类似问题的人。
毕竟 V2EX 上应该有不少人都在 NAS 上通过 docker 自建自己的各种服务，应该遇到过相似的问题。

实际上，B 是包含多个容器的服务（独立的一个 compose.yml 管理的）。一个 php-fpm 容器，一个 db 容器。如主题所说，caddy 通过容器名访问并反代 php-fpm 。而 php-fpm 实际上也通过容器名访问 db 容器。如果把 php-fpm 的 network_mode 设置成 vpn 的话，就会导致 php-fpm 的 DNS 服务器也变成 VPN 的 DNS ，导致 php-fpm 通过容器名访问 db 失效了。

有时候还真的挺担心 stackoverflow 这类网站的。
以前受到这类网站帮助很大，现在虽然有了 AI ，但其实很多东西都需要人类的回答才能验证 AI 给出的答案是不是正确的。我拿到 AI 给的输出经常都会用一些关键词搜索找到相关的人类回答才敢用。

如今 AI 对 SO 这类问答网站打击太大了，以后要是没了这种网站估计各种 bug 满天飞了。

@w568w #39
除非有什么东西是非 podman 不可的。
我觉得服务器不如就直接用 stable 和 docker 上游直接提供的 docker-ce 了。
docker 上游直接推送新版本再加上 stable 的稳定。

@NewSunH 这也是你的错觉吧。

debian 的包基本是经过 unstable -> testing -> stable 这个过程的。
一般一个包出新版本就会被打包进 unstable ，然后经过几天没有严重问题就会被推到 testing 里。
而 stable 则是每两年一次对当时 testing 的进行冻结测试然后作为一个新的大版本发布。

这个过程软件版本如果真比以前激进那也多半是某些软件本身开发变快了。

只要把 config 的初始化集中在一个地方，初始化后就不要修改，一个 config 到处传我感觉问题没多大。这样，很多时候还方便加新的键值对，而不需要一个一个方法/函数的改签名。

但如果把 config 当返回值使用，代码随处在修改 config 的值，然后再到处乱传就恶心了。这种代码读起来简直要命，一般读一遍下来根本不知道哪里传来的值。

flatpak 版 wechat 没这个问题。
或者用 https://docs.flatpak.org/en/latest/tips-and-tricks.html#configuring-resource-limits-for-apps 提到的方法。
试试把`TasksMax`设置成一个比较小的值。比如，创建~/.config/systemd/user/app-flatpak-com.tencent.WeChat-.scope.d/task.conf
内容设置成
```
[Scope]
TasksMax=16
```

试试用 flatpak 装 dingtalk
然后再用 systemd 的 resource control 限制一下？

比如
`cat ~/.config/systemd/user/app-flatpak-com.dingtalk.DingTalk-.scope.d/tasks.conf`
[Scope]
TasksMax=256

https://docs.flatpak.org/en/latest/tips-and-tricks.html#configuring-resource-limits-for-apps

我觉得不要太纠结原则这个东西。哪个方案能解决问题就用哪个方案，都能解决就选择最方便自己的。
如果通过 layering 更方便，就选择 layering ，没必要为了原则就非得避免更加方便的做法。

曾经我也想避免所有 layering ，全利用 distrobox 解决问题。
比如把 git 、zsh 、tmux 之类的包全装 distrobox 里，使所有开发环境能共享工具链，结果发现 tcpdump 、nvtop 之类的包需要装在 rootful 的容器下才能用。
等全部迁移到 rootrul 容器里之后，又发现启动容器得输入密码才能打开。
于是又同时使用两个容器：rootful 容器和非 root 的，只把必要的工具装 rootful 容器里，其他装非 root 的容器。

后来一通折腾下来发现，我还得想办法把带 systemd-service 的包也给迁移出来。
结果最终发现，与其为了一些原则而避免 layering ，反而带来更多麻烦。所以我现在如果 layering 方便就直接 layering 了。

layering 的缺点也有，比如安装后需要重启（虽然可以通过 apply-alive 缓解这个问题）。在安装新的包时，所有 layering 的包都会再被重新安装一遍，因此 layering 越多，每次安装速度也会越慢。

目前也有人提出利用 sysext 来安装一些包，从而避免每次更新都得重启： https://travier.github.io/fedora-sysexts/

我个人觉得 atomic desktop 还在发展中。包括 rpm-ostree 也在向 bootc 方向迁移。
因此各种方案都有，也不一定成熟。
最终会在哪种方案上稳定下来也还不确定，所以别纠结太多哪种方案了，选择自己方便的来吧。

@GOVER
台词和 serif 没什么关系吧。
台词（せりふ）来自于「世流布」（せるふ）或者「競り言ふ｣（せりいう）。
serif 是有衬线字体的意思。

是不是我发放免费食物，在里面悄悄下毒，毒死人也不犯法？

个人的一些经验总结：

debian
更新最不频繁。两年一个大版本，中间会有小版本的更新，因此也最稳定。不过这也算是缺点，比如当前的 stable 版本里的 gnome-shell 还是 43 ，比目前 48 落后了不少。十分适合服务器那种使用场景（及时的安全更新，并且不会由于更新导致服务出问题）。

ubuntu 相对 debian 更新稍微频繁一点。一年一个大版本，中间也会有一些包的更新。当前 ubuntu25 里 gnome-shell 版本是 48.0 ，比最新版只落后几个小版本。

fedora 半年一个大版本，中间包的更新也十分频繁，因此也有人称之为半滚动发行版。频繁的更新也带来了各种不稳定，比如前些天 mutter 更新导致的窗口变得不可以点击。但好处在于，由于其是非滚动发行版的，因此你可以停留在目前版本不更新很长一段时间，之后再更新也不会挂掉。

滚动发行版（比如 arch 、debian sid 和 fedora rawhide 等等） 上游只要出新的版本就会被打包进仓库。频繁的更新带来的就是各种不稳定，比如上面提到的 mutter 的 bug 同样影响 arch 等其他滚动发行版。并且由于是滚动发行版，你长时间不更新之后再更新就容易挂掉。

除了包管理工具和更新频率以外，各种发行版在其他一些方面也有些细微差别。比如默认的文件系统是 btrfs 还是 ext4 ，默认 swap 是 zram 、zswap 还是硬盘的分区。还有一些 systemd 的服务管理方式，比如通过 socket 方式激活等。

我个人的建议是，一般就从 ubuntu 和 fedora （或者基于他们的衍生版）里选择作为个人桌面系统使用。debian 适合服务器，滚动发行版适合那种能给上游提 bug 和 issue 的人使用（否则当小白鼠也没有意义，只是折腾自己）。

arch 的一个优点就是 aur 提供了丰富的包，但要知道 aur 是谁都可以上传的，这意味着这并不比你执行`curl -s http://not.a.malware.com/download | sudo bash`安全。同时 flathub 的存在使得 aur 的必要性变低了很多，flathub 包含了 QQ 、微信、网易云音乐和 WPS 。最重要的是 flatpak 允许你控制文件系统和网络的权限，能够避免国产软件扫盘。

我个人的选择是 fedora 的衍生版 fedora silverblue 。
同样是激进的方案，fedora 的方案比 ubuntu 的方案有品位得多。
比如 fedora 是第一个采用 systemd 和 wayland 等新技术的发行版，而最终其他各种发行版也选择了这条路线。相比之下，ubuntu 的做法则就像是硬塞各种私货，upstart 和 mir 现在可以说已经死了。

类似的 flatpak 和 snap 相比较，flatpak 更有前景。对于某些包（比如 firefox ），fedora 同时提供 flatpak 版本和 rpm 版本，而 ubuntu 只提供 snap 版本并且把源里的版本替换成 snap 的。

只用 wm 的问题是你得自己一个一个安装需要的组件。这个过程看似简单，但实际上你很难找全所有需要的组件。当然爱折腾是另外一回事。

缺少部分组件，有时候问题不会马上出现，而会在你工作时出 bug 。比如前几天就有人问 vscode 每次启动都丢失登陆信息的问题。根据下面回复，多半是缺少了 gnome-keyring 这个组件。

我反而觉得单独使用 wm 带来的资源节省并没有什么用。以前单独用过一段时间 i3wm ，实际体验下来没感受到比 gnome 流畅，特别是打开浏览器、IDE 之类的软件，体感上区别不大。

kde/gnome 下，虽然的确开了很多用不上的进程，但实际上这些进程里，大部分占用不了多少资源。少部分进程的确很恶心，比如 gnome software 和 tracker-miner 相关的进程在后台运行的频率太高了，每次我听到风扇声音变大时，多半都是这俩在后台吃 cpu 。但光禁用这两个组件比一个一个安装需要的组件要简单得多。

@wuruxu #34
是的，linux 有时候的确需要折腾一下。在这个过程中，解决问题的能力也会提升。之后遇到问题也更容易解决，结果就是越用越顺手。

比如前面有人提到的 gnome 和 KDE 共存存在问题。假设是我遇到这样的问题，如果我想体验两个不同的桌面环境，第一反应就是 rpm-ostree rebase 到 kinoite 和 silverblue ，同时保持 kinoite 和 silverblue 两个分支，这样就都不会冲突。如果我只是想使用另外一个桌面的某个特定 APP ，直接用 flatpak 装特定 app 就好了。如果 flatpak 没有，再考虑 distrobox 创建一个容器环境安装，然后再 distrobox-export 就好了。总之解决方案是有的，但用户不一定知道。

对我来说，linux 就是越用越顺手，现在用 windows 反而各种不顺手。

实际上最大的问题是小白没觉得自己是小白，然后遇到问题之后第一时间不觉得是自己技术不够而是系统不行。很多声称 linux 不好用的人，都会加上自己用过 linux 多少多少年，或者说体验过 linux 多少发行版，又或者自己多久就开始接触电脑了，其实就是想说自己不是小白。

实际上，linux 桌面也有在往用户友好的方向发展。

比如有了 flatpak 之后，能很大程度减少各个发行版之间的碎片化。结合 gnome software 或者 KDE discovery 就能直接在应用商店安装软件包了，根本不需要接触什么 apt 、dnf 了。

并且，由于不可变桌面的兴起。上游发行版想要给下游用户推送新版本也变得更加容易且不宜出错了。并且由于 flatpak 和底层系统隔离，你升级发行版也不会影响 flatpak 里的软件了。

其实说下来就是以下两个问题：
1 、生态问题
2 、linux 不面向小白


第一点：
虽然楼主提到的 Spotify 、QQ 、微信等，都有 flatpak 版本的了，但是 linux 生态还是不够。
没有足够的用户，开发者就没有动力维护一个 linux 版本；而没有 linux 版本，则新用户也不会来。这点几乎是无解的，只能等着时间慢慢解决。

第二点：
linux 的问题不在于“日常不能够稳定使用”。而是在于小白想要找到一套稳定使用 linux 系统方案太难了。
比如安装软件：安装软件有一大堆方法，对于小白来说根本不知道该怎么选。什么是 apt/dnf ？什么又是 snap/flatpak/appimage ？即使正确的选择了其中一种方式，又搞不好会遇到网络问题。对于小白来说，首先就不一定知道代理是什么，其次要正确设置代理并让他起作用也得花上一堆时间去查。

linux 桌面的本身的问题就在于他是由一群志愿者维护的一堆软件包的集合。而这堆软件包本身又是由不同的软件开发者凭着兴趣维护的，而非受雇佣维护的。这和 windows/macos 最大的不同就在于不存在单一实体能对其整体的软件质量负责。一个 bug 可能会在软件开发者和发行版维护者之间踢皮球。甚至可能由于发行版的碎片化，在某些发行版里根本不会被修复。又或者出现兼容性问题，开发者可以自己搞一堆不兼容的升级，导致下游的依赖出问题。毕竟一个为爱发电的项目，开发者可以按自己喜好来。

以上各种问题其实都导致用户自己必须得形成一套自己的方案来使用。而形成这套方案，还得不断踩坑。