@vtgoal 后面我思路被他带过去了，在吐槽他说的管理上万台物理机的假设对我的现实情况没意义，看起来好像我要表达的重点成了大 vs 小的规模……其实我本来不是要说这个的。

不过说起来，规模大的场景里，对技术细节的要求的确不是重点考虑的，而且也是难以去重点考虑的。只要钱到位，用管理手段和所谓的职业化精神，总可以包装出巧克力盖浇屎，来掩盖内部实现的恶臭。

但是没这条件的时候（所谓没条件不一定是因为小厂，也可能是因为体制问题，比如叠床架屋的婆婆机构，业务单位拿不到 infra 的经费，只能做纯业务系统，而且经费只够勉强把业务功能做好，不会有余量来提升 infra ，但同时本该负责 infra 的信息化平级负责单位的 infra 水平又不够让业务单位放下心不去考虑 infra ），没办法像他说的用当代一互大的先进运维方式去提升 infra 水平，只能去抠类似“在 RH 系上，自己手工编译一堆基础组件，装好的路径乱七八糟各种不可预测，可执行程序的 FS owner 和启动的 euid 一样，在 shell 里手工 nohup 交互启动，而且从来特奶奶的不管任何更新”的 bad practice 细节。

他以为我不想“清楚自己的定位”，以为我想啥都管，以为我不想搞 baseline 每个基础组件变更都审核，不想用一互大的先进理念吗？除了你说的小规模（另外提一下，小规模不一定是小“厂”）条件下不一定有必要用大长的思维，再就是没条件啊。除了没钱，也没这样做机制。

他说我关注的这些技术细节的玩法是 10 年前的……可是如果我像业务部门人员、技术部门里技术能力停留在入职前永远不再更新的伪技术人员一样只关心业务功能实现，不关注这些东西，那我的“地行小”vendors 送给我的可不只是 10 年前……恐怕放到 20 年前都算烂的了。我在没条件把我手上的 infra 拉到 1 年前的情况下，至少还努力尝试从 20 年前拉到 10 年前。他说的那些再先进的，臣妾真的没力气做到了。

另外，我认为，以前做事不讲究，动辄搞出“在 RH 系上，自己手工编译一堆基础组件，装好的路径乱七八糟各种不可预测，可执行程序的 FS owner 和启动的 euid 一样，在 shell 里手工 nohup 交互启动，而且从来特奶奶的不管任何更新”等各种运维屎的那些乙方“（又做业务对接又写代码又勉为其难给甲方做部署和运维的）综（合）信（息化人员）”们，在现在流行的容器化 infra 下，实际上只是在做巧克力盖浇屎，虽然容器化在一定程度上可以减缓原来不懂 infra best practice 带来的问题（比如容器内环境较为精简可以减少攻击面，比如可执行程序文件的 FS owner 和启动的 euid 一样导致的远程溢出获取 shell 来修改可执行程序埋桩可以随着容器的毁灭重建复原），但屎还是屎，不能因为浇了一层巧克力壳就变成巧克力。

无关对错。无软肋则硬。

原来如此。越发坚定了以后永远不使用这种所谓自动区分主副路由、LAN/WAN 混插自动识别的哄小白的玩意。

有个 OpenWRT 设备的 LAN 口接在家网的 LAN 里？

我猜是 negotiate 的时候抢一下看运气

有没有可能 Python 标准库里有个 http

“下定决心跟这个问题杠上了”和“不影响长辈用这个特定的 app 看电视”，在短期内是矛盾的。
要么改造网络拓扑（比如划 VLAN 或者改用其他科学上网方案），不影响长辈，但要牺牲你的求知欲；要么慢慢排查，最终找到原因，但天天挨骂。

何不食肉糜？

@tin3w5 所以我说不同场景的人需求不一样啊。你可能跟高大上的金主爹型客户、高大全的一互大型技术方接触多了，真的想不到都这个年代了还有这种很落后的信息化环境（而且还是这个行业里有话语权的一流单位），还有苦逼的从写报告写 PPT 申请经费开始一条龙都要管的“综合信息化”人员，还有法人单位的信息化部门技术能力乱七八糟给下面的处级业务单位提供不了足够的基础设施支持业务单位只好自己搞的苦逼场景。定位？定他妈的位。你说的那些都对，都对、都对！但是，如果换了你在我这里，恐怕比我还瞎搞。还特么的给我一个十万台级别的物理机的环境……别拿一互大的做事条件来 PUA 我了。在这种综信岗位上做几年，跟一堆地行小斗争上几年还没走人的话，这些一互大的美好理念都特么的……还十万台物理机……我真不是在一互大干活的，我单位再怎么自我膨胀也就百来个虚拟机几十个系统，真的经不起您这种一互大场景 PUA 的指导。

@huangya 对，MAC 在路由器这边，换 SFP 模块后在路由器 OS 里看大体上仍然是同一块“网卡”。两头 SFP 的较 DAC 线，可以理解为是电口的线，只不过不是用的以太网规格。因为主要是近距离使用，比如同一机柜里的交换机堆叠，所以可以做到相对比较低的成本。长距离的 DAC 线就贵得不成比例了。

答案取决于你的现实情况。比如你所在的行业/领域要求，比如你的角色（做信息化还是基础设施服务还是业务开发），你所在团队的已有技术栈，替代目标是应用平替还是渐进切换等。

@Maboroshii 打个比方吧，深交所的某个系统出错了，领导一声令下：会诊！业务系统厂家 1：到！业务系统厂家 2：到！……业务系统厂家 N：到！服务器厂家：到！存储厂家：到！网络设备厂家：到！操作系统厂家：？？？

其实还有个问题就是，不知你有没有注意到最近 Alma 说的：AlmaLinux 不再 1:1 兼容 RHEL ，未来致力于兼容 ABI
https://www.oschina.net/news/249342/almalinux-no-1-1-rhel
实际上很多做业务系统开发的团队在遇到 OS 基础组件级别的 bug 时，有很多靠速查 CSDN+猜测+尝试来编程的程序员其实没能力判别这是基础组件 bug ，所以按照“当前这样的行为就是正常的”来写业务了；或者即使有能力发现 bug 但因为工期或者依赖可控性等原因没办法等到操作系统厂家的下一次 update ，于是就把 bug 当 feature ，自己在应用层面去 workaround ，同时又因为工期等原因并没有写下这个 bug 如果被 fix 了之后按照正常预取应该有的行为要怎么做。然后这个业务系统的正确性就依赖底层的 bug 了。那么操作系统的仿品如果要去争取各种行业用户就要维持一个“bug-for-bug compatibility”才行。

@tin3w5 byebye~~确实不同场景的人的需求不一样。可能你们的土豪客户有钱堆起来让供应商跪着添爸爸所以可以不在乎 RH 系的各种操蛋。像我这样只能小成本接触“地行小”供应商的，用 RH 根本是在作践自己。麻辣隔壁的那些狗屁地行小供应商，根本没有能力做所谓的整体交付。他们在 RH 系上，自己手工编译一堆基础组件，装好的路径乱七八糟各种不可预测，可执行程序的 FS owner 和启动的 euid 一样，在 shell 里手工 nohup 交互启动，而且从来特奶奶的不管任何更新，直到被同单位的信息主管子单位送来安全通告。这种情况下，反而用你们觉得不够职业化的 Debian 对我来说更省心。至少大部分基础组件都是一句 apt 就装好的，是版本不太老可以拿来用的，是有 update 的，是按照 FHS 等最佳习惯打包好的。至少不用让那些连把业务功能开发正确都要靠甲方反反复复督促才能做到的地行小来一脸懵逼勉为其难自以为是狗屁不通地负责我的基础设施。

@huangya 就算是床用路由器，SFP 口也要插模块才能接线。

SFP 口本身不存在什么“cooper 居多”的说法。

SFP 口接线缆是要先插模块的。光模块的外侧是 LC/FC/ST/SC 等光线插口，电模块的外侧是 RJ45 口。

另外 N+1 ，你们不会真的没见过在部分（甚至超半数）标准的 supoort matrix 里有 Debian 的服务器厂家吧？

另外，你们说花钱买 RHEL 那我没啥好说的，按职场套路，这是最明智的选择。

但是我遇到更多的是他麻辣隔壁的一帮沙雕用着 CentOS 还跟我讲爹味的职场责任。比如知乎上曾经有一个 CentOS vs Debian 之辩话题下一个叫袁昊洋的无脑 CentOS 粉……对此我只想说：我支持孔庆东教授。