@asnldm #55
元音少正是日语很好听的原因，日语公认比中文好听，怎么在你这里成了缺陷？
日本人塑料外语那是外语没学好，怪到日语上属于是拉不出屎怪引力不够了。反过来说，正是因为没那么多复杂的发音，外国人学日语就变得更简单了，这是个优点才对。

日本现在滥用片假名，应该说这是现代社会的大趋势。
现代社会有了互联网，各个国家之间的交流更加的频繁了，新概念每几年就会出一堆。
当一个新概念从外国出现的时候，你指望每一个新概念都等待一种“官方”的翻译然后再使用本来就不现实。而日语正好存在一个书写系统能够直接音译他国的概念，所以这个机制被滥用了。

日语的书写系统结合了多个国家的书写系统，你单单站在中文的角度才觉得日语是屎山代码而已。
从其他语言来看，中文也是屎山代码。公交车也可以叫巴士，出租车也可以叫的士，互联网也叫因特网等等，中文怎么一会音译一会意译？

而且由于中文缺少借鉴外来语的书写系统，这导致了一堆词只能直接用英语。比如像什么 brunch 、神经网络中的 transformer 之类的词，至今没有“官方”翻译，完全用的英文，这难道就不是屎山代码了？

@IchinoseChiya #144

>为什么 “在 nas/软路由 上用 docker 玩与其初始职能无关的应用” 成为了社区主流
我的回复已经解释了这点，那就是 docker 这种方式是更先进的方法，所以“市场”（ NAS 社区）选择了这个方法。

我之所以举其他例子（比如说不可变系统）也是想说明这点。
本质上，它们都实现了以下几个特性：
1. 底层系统和应用相互隔离，应用和应用之间相互隔离。它们各自更新不会相互影响。
2. 基于镜像的管理方式，因此更新、备份、回滚等等都变得十分方便。
3. 不对底层系统进行修改，系统保持和原厂出厂设置一致，因此不会出现“works on my machine”的问题，并且系统更加稳定。

无论是手机系统，还是不可变操作系统，都是上面提到的特性的一种实现。
虽然它们底层实现的方式各自不一样，无论是通过 selinux 实现，还是说通过 capability 和 namespace 实现。

在 NAS 上使用 docker 也是，避免使用包管理器或者说编译安装对底层系统进行修改，相互隔离以及基于镜像的管理方式。

实际上也可以观察到越来越多的发行版开始采用不可变系统的方式，并且手机操作系统比桌面系统稳定多了。

NAS+docker 这种方式就是更稳定更先进的办法，所以“市场”（ NAS 社区）成为了社区主流。

docker 把底层系统的差异给消除了，还方便部署、迁移和备份。稍微有点经验都知道 docker 的优点，楼主声称自己站在专业的角度来看却觉得很奇葩，才是显得有点无知了。

>说实话主流 Linux 发行版不都能做到直接运行这些应用
但凡真的自己维护过几个服务器就知道直接运行这种做法有多么麻烦和脆弱。

如果你用包管理器来安装各种东西，那么不同应用之间很容易产生一些依赖之间的冲突，比如说应用 A 的最新版仅仅支持系统版本 2.0 ，而应用 B 的最新版又需要跑在系统版本 3.0 上。这时候你得自己取舍应用 A 和应用 B 的版本，让它们能够同时跑在同一个底层系统上。有时候你想升级某个应用，就必须得升级底层系统。一旦升级底层系统，就得考虑所有应用是否支持。

如果你不用包管理器，那痛苦的又来了。相当于你得各自处理所有依赖，同时还得考虑依赖库的漏洞修复（此时可没有包管理器推送补丁让你更新，你得自己监测使用的版本是否存在漏洞需要修补，除非你不考虑安全性）。并且一旦面临需要升级的情况，那依赖处理的痛苦又得来一次。

事实上就是，类似于 docker 的理念在各个领域都在使用。很多地方都在推不可变系统，把应用和系统隔离开来，把应用和应用隔离开来，它们独自更新而不影响，这种基于镜像的管理方法还很方便的支持备份和回滚。
这种基于镜像的管理方法本身就是更先进的。楼主声称自己专业，觉得 docker 和 NAS 社区关联很奇葩，还觉得直接安装就能解决，的确显得楼主无知了。

还好我用 lineageos ，只是通过 google play 实现的话，完全可以不管。

大不了以后不用 google play 了，换成 aurora store 和 obtainium 就行了。

至于 google play services ，反正国内的聊天软件都不用这个，影响也不大。

有人拿刀砍人，如果以后买刀要实名了，用刀每次都得扫码报备了。有些人也会站在它们的角度上为它们辩护的。

居然有人说开放 BL 是为了 0.1%的用户，损害 99.9%客户的体验。简直把我前列腺液都给笑出来了，说得好像我解锁了 BL 导致别人手机出现的广告更多一样。

这堆人不明白唇亡齿寒的道理，保持系统的开放性意味着促进竞争，能够促使厂家把自己的 ROM 做得更好，而不是肆无忌惮的塞广告、限制修改 WiFi 名，内置监控软件。

温水煮青蛙。

哪天开始不能解锁就完全不考虑这个手机了。

从来没觉得需要等那么久。debian 推送更新的机制已经是够稳的了。升级过程出问题的，多半是自己魔改过哪些地方（比如本身非纯 debian 系统而是下游魔改过的，又或者自己修改过系统的文件等等）。

升级要注意的是兼容性问题（ breaking change ），比如新旧版本配置文件不同，默认设置不同等等，这种问题也不会随着小版本的发布而改变，除非你永远不更新，否则迟早都会遇到这个问题。

我觉得这取决于系统。
我曾经用过 ColorOS ，ColorOS 的音量调节就很不便。默认情况下，音量键调节的音量会是手机响铃的音量，而不是媒体的音量。并且还没有快捷方式切换选择。只有在你播放媒体的时候，音量键调节的音量才会是媒体的音量。

这就导致了一个问题，如果你想静音地看个视频，你没法直接调整媒体音量，要么你一步步打开设置找到音量设置找到媒体音量，然后设置为静音，设置完再打开视频。要么你得先把视频播放出来之后再用音量键调整。有些视频开幕雷击发出不雅的声音，根本来不及调小音量，当初我因为不习惯 ColorOS ，被坑了好几次。

@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 的稳定。