@atom42
b 站动态我记得是时间线啊，这个应该是新功能。
但是为啥没有稍后再看，有点奇怪。

业务不写，infra 写

@pcxys
少部分“三层”交换机具有静态路由功能，一般可以配置最多三位数条目的跨网段静态路由，目的是把超大规模部署的物理网络划分成多个小的逻辑子网（一般按楼宇、楼层划分），同时可以跨楼层互访而不需要经过路由转发，算某种意义的 offload 。

@pcxys
access 口确实是不 tag ，但是交换机是二层设备，除了少数可以配跨网段转发，大多数跨网段转发都得依赖 trunk 口接路由才行。

你华为交换机上都套 vlan 了理论上应该直接 trunk 口接路由，不懂套个傻瓜交换机意义在哪，傻瓜交换机不识别 vlan 直接按 pvid1 处理的。
而且我记得 vlan tagged 帧也无法通过傻瓜交换机。

middlebox 常用于描述中间网络的 transparent proxy 、relay 等网络设备。一般来说对用户是不可见的。

你这个就是 gfw （

2035 年，一个互联网公司，一名 10 后的的产品经理，在台上宣布着自己的产品规划，他想做一款产品，不论是什么操作系统，什么设备，什么软件，这个产品的内容都可以正确的显示。不需要下载什么 App 或者小程序，不需要特定的应用才能打开，到时候一定可以统一整个互联网。
这时候，台下有一名 90 后的老年员工举手：
你说的这个东西，是不是叫「网页」。

光猫应该是不支持 ipv6 ，国内 ipv6 纯减速，压根没必要开

看到一半我就猜 op 是不是字节的。
点开博客，果然。

有无关键指标透露下，比如需求吞吐量和 go 转 rust 的研发消耗情况如何？

作为一个被 nexusphp 折腾过整个学生时期的告诉你。。
这玩意 ipv6 的支持稀烂（

@jlak
老实说，写 go 也五六年了，除了业务代码 AI 有点用以外，大多数情况我体感是 AI 只能帮倒忙。
尤其在写一些很底层的部分时，由于变量名称省略较多，经常都是 1-2 个字母的变量名，然后 AI 给你写的代码光给它 debug 就要费劲很多，还容易看错。

因为 go 最初设计就是，尽量抹平新手和老手之间的理解与认知 gap ，让一个团队里不同水平的工程师都可以互相合作。

简单点说就是下限和上限差别很大。这点在框架开发上其实蛮牢的，你要么接受设计者的哲学，要么就自己另起炉灶。
这可能也是 go 在社区口碑两极分化的原因，喜好的人很喜好，不喜欢的人就是不喜欢。

另外，你才刚碰到资源规格的问题。
如果你的资源池有好几代机器，具备不同的 cpu/内存/网络甚至磁盘速度。
你还得考虑基准核/node taint 之类的指标。

平台得定义一个基准性能指标，或者避免同一组工作负载分布在不同规格的节点上。

只要你不是无良云厂商，就
不要碰 overcommit ，不要碰 overcommit ，不要碰 overcommit
重要的事情说三遍。

正规做法是接入 VPA ，根据汇总的监控数据建议合适的 request/limit ，督促设置不合理的应用负责人调整资源配置。
通常来说 request 比 limit 小 0.01 就行了。

乱用 request/limit 后果就是你的成本预算和资源核算压根没法做。更不要说做保障了。
k8s 之所以有 request/limit 概念是因为它底层使用的 linux cgroup 有这套东西，所以单纯就搬了上来，实际上这个东西大多数人玩不好，而且 BestEffort 策略本质上是算是舍弃 QoS 的，这又和很多服务场景需求矛盾。

结论：别给你的 user 灌输这堆垃圾概念，直接告诉他实用实报，可以随时通过 VPA 调整就完事了。

声明式+agent ，自研吧。做好任务管理下发，执行和回报交给 agent 。
超大规模的想走 worker+shell 真的是坐大牢。

当然，我觉得最简单的方式。k8s ，damonset 跑 agent ，或者直接上 job ，日志也能统一回收。以 pod 状态/job 状态作为任务执行的结果标识。