后来随手发的一条有幸被 saka 回了。回过头来看自己都觉得之前的频道消息没把自己的想法讲清楚，所以在炎上被骂之前先叠个甲，重新梳理下我想表达什么东西
首先阅读理解一下引用的部分哈，我只是想表达两件事：
1. 我完全理解 nerdctl 为啥会有这些和 docker-ce engine 不同的行为。一些 docker 做得不太好的设计，nerdctl 是完全有理由不去继承的。何况 containerd 和 docker 并不是两种相同的东西，在 containerd 之上构建的东西经常需要去实现很多以前 docker 自己底层替你做好的事
2. 但是站在用户视角，从 docker 切换到 nerdctl 以后一些很简单的事情都变得很麻烦了。以前跨网桥的两个容器默认可以互相访问，迁移过来却遇到了问题。而在设法解决这个问题时，照着官方文档创建关闭 firewall cni 插件的网桥的说明操作，没有跑通，忍不住吐槽两句我觉得也是人之常情？
总结一下，我不觉得 nerdctl 有什么问题。不然肯定积极地尝试提 pr 修复。就算我技术能力不行，至少也可以去骚扰 saka 不是？（笑
我也不是马后炮，在调研过程中翻 issue 的时候早就看到了这个熟悉的名字。而且我和 saka 也互相交换过联系方式，并不觉得找他帮忙有什么心理或技术上的障碍
推上有 nerdctl 的 maintainer 也回过我，说 nerdctl 算是技术实验场，所以不应该把 nerdctl 看作是 docker 的替身。我现在对这一点完全同意，但是在遇到这次事之前，我以为 nerdctl【首先】是 docker 的替身，【此外】还有一些新的功能
这个看法是不准确的，所以最开始发这一条，说 nerdctl 厨体验卡到期，就是这个意思。通过公司安排的调研任务，我对 nerdctl 的错误认知被改正过来了。从今往后，是又爱又恨的新篇章
首先阅读理解一下引用的部分哈，我只是想表达两件事：
1. 我完全理解 nerdctl 为啥会有这些和 docker-ce engine 不同的行为。一些 docker 做得不太好的设计，nerdctl 是完全有理由不去继承的。何况 containerd 和 docker 并不是两种相同的东西，在 containerd 之上构建的东西经常需要去实现很多以前 docker 自己底层替你做好的事
2. 但是站在用户视角，从 docker 切换到 nerdctl 以后一些很简单的事情都变得很麻烦了。以前跨网桥的两个容器默认可以互相访问，迁移过来却遇到了问题。而在设法解决这个问题时，照着官方文档创建关闭 firewall cni 插件的网桥的说明操作，没有跑通，忍不住吐槽两句我觉得也是人之常情？
总结一下，我不觉得 nerdctl 有什么问题。不然肯定积极地尝试提 pr 修复。就算我技术能力不行，至少也可以去骚扰 saka 不是？（笑
我也不是马后炮，在调研过程中翻 issue 的时候早就看到了这个熟悉的名字。而且我和 saka 也互相交换过联系方式，并不觉得找他帮忙有什么心理或技术上的障碍
推上有 nerdctl 的 maintainer 也回过我，说 nerdctl 算是技术实验场，所以不应该把 nerdctl 看作是 docker 的替身。我现在对这一点完全同意，但是在遇到这次事之前，我以为 nerdctl【首先】是 docker 的替身，【此外】还有一些新的功能
这个看法是不准确的，所以最开始发这一条，说 nerdctl 厨体验卡到期，就是这个意思。通过公司安排的调研任务，我对 nerdctl 的错误认知被改正过来了。从今往后，是又爱又恨的新篇章
