@julyclyde #14 另外把 nested containerization (比如 docker in docker) 这样的情景也考虑到，有一些环境就是比较简陋没有 syslog server 和可以 bind mount 到容器内部的 syslog socket 。

@julyclyde #14 那宿主机不装 syslog server 您的容器就永远不调度到这台机子上了是吗？

@patrickyoung 第三，cat 和 shell 做的只是简单的 stream 重定向，纯粹转发 byte stream ，几乎没有任何的计算或判断，这也能成为你的攻击点？这也能造成性能问题？我不理解。

@patrickyoung 第二我有我的时间安排，是不是我得像人工智能模型那样，表达任何内容的时候，要检索整个互联网的所有资料呢？我有义务，或者我做出过任何保证，一定要提供最优的方案吗？

我不知道长期陷入信息茧房的人是什么样的，但是从您表现出的偏执和狭隘来看，症状非常恐怖。仅从性能出发就否定一切。建议看一下心理咨询或者自测。

另外，如果您追求效率，那么你不需要在这里显摆您的知识，应当自己去改代码让它直接打印到 stdout ，以此实践你的观点。

@patrickyoung 简洁高效不是你张口闭口定义的简洁高效，你应该自己去跑个分比对多种方案，从中找出显著差异， 来支持您的主张。

我发现您没有没有耐心或者理解能力读完全文，我完全没有声明我的方案是效率优先的，我表达的内容是如果遇到了只会输出到 syslog 的应用，对它容器化时怎么把 syslog 日志输出重定向到 stdout 。怎么就莫名其妙和效率扯上关系了呢？

喷子的常用诡辩逻辑时找到一个缺点，效率看起来不是最优的，就全盘否定一切。在您这里就非常明显了。

要在 opendkim 的配置文件里面启用 Syslog 选项，抱歉我在正文没把这个说明白造成了一些误解。

而且你们难道都没理解对？`-f` 是让进程留在前台，但是和把日志打在 stdout （这属于日志输出路径）没半毛钱关系啊？

@patrickyoung 我觉得像你这样的人还真不少，遇到任何问题就只会问 AI 和搜索引擎，如果找不到答案就否定需求本身。你应该提高自己的阅读理解能力，我只是用 opendkim 举一个例子，我描述的是针对一整类 syslog-only 应用程序的日志重定向方法。如果你需要容器化 10 个不同的 syslog-only 的容器，我希望你每个都去搜一遍，最好是停止维护 4 、5 年的也继续拿来用。

@defunct9 我用的是 exec 命令，就是故意让 opendkim 留在前台，是你理解的不对。麻烦再仔细看一遍。

@patrickyoung 谁都会用搜索引擎，不要再我的帖子用你的废话占用空间。另外，每个人都可以独立探索得出自己的发现，如果你擅长用搜索引擎你会发现类似的玩意还不止一个，我没工夫看别人的 Dockerfile 怎么写的，自己手挫出来只用了半个小时还加深了自己对容器和 linux 的理解。你自己的偏好是用现成的东西没问题，但是把自己的想法套在所有人身上就是你的傲慢了。

`-f` 是让 opendkim 进程留在前台，exec 是在当前 entrypoint.sh 的进程继续执行 opendkim 的内容，而不是为 opendkim 单开一个进程。

还有一种方法是在 Dockerfile 编写自定义的 healthcheck ，docker 应该会自动重启 unhealthy 的容器

@defunct9 或许会考虑用 tini 作为一个轻量的 supervisor ，或者 docker run 加 --init 参数。

应该问哪些是之前重要并且现在仍然重要的，编码只是解决问题的一种方式，重要的是背后的思路：你想通过编码解决什么问题以及以什么样的方式去解决。

AI 可以在术的方面补齐开发者的短板，但是道的方面还是看开发者自己。

1. ISP-光猫-交换机
2. 交换机-dot1q VLAN-软路由
3. 交换机-WiFi
4. 交换机-其他有线设备

1. 我不同意像是“家庭用户比云服务商 ICP/IDC/ISP/Cloud Provider 更加需要 IPv4 地址”这样的说法，反过来也不同意。点对点连接是双向的，也就是说任何需要点对点连接的情景，都需要两边有路由可达的 IPv4 地址，否则就只借助于 STUN 这样的服务，牺牲了端到端原则。
2. 如果说在云上，你让各个网站/app/服务都共享一个 IPv4 ，那压力就会集中到应用层网关上，无法 scale ，而路由器完全可以仅根据 IP 头部的地址进行路由，不需要解析应用层标签，比如 SNI, Host 之类的玩意。同理，在云端进行 TCP 端口转发和 SNAT 也会增加对有状态防火墙的压力。所以云上的服务和应用，也同样需要单独的 IPv4 和 IPv6 。
3. IPv4 的地址短缺是分配问题造成的，早起做出了一些（在今天看来）错误的、不合理的分配。IPv4 地址是要钱的，从经济角度来说，指望囤积 IPv4 地址坐地起价获利是不现实的：首先云服务是一个充分竞争的市场且价格透明，其次用户群大部分都是价格敏感的。

我觉得 NAS 就专注于存储和以太网就行，任何额外的功能都会导致成本提升，从而体现在价格上。

云桌面 云游戏 startups 都死得差不多了，一整个夕阳产业，本来就是个伪需求。上世纪 client 性能还很弱的时候才流行的种架构，如今 client 和 server 性能差距不大。

server 就干 server 擅长的事，client 就干 client 擅长的事。让 server 渲染桌面 gui 再通过网络串流回 client 播放是很低效的事。

人为制造的稀缺，实在想不出都 2025 年了 dual-stack 还存在什么技术上的困难