OpenWRT 第一次启动时会生成随机的 IPv6 ULA 网段配在 LAN 上

大部分讲软件架构的书都会讲解耦

学术人：想办法搞一个可以没有 super user 的用户权限模型的操作系统。
运维人：限制无关人士登录/切换身份的权限。

买都买了，按懂职场的老司机 V 友们的说法，在品牌服务器上安装官方支持的操作系统的兼容性问题，找原厂技术支持人家是不会推脱的，你试试看

很有意思，Debian 的排名里美国才第三，中国连前十都没

1. 鸟哥的私房菜等早期教程
2. 不想买或者没条件买 RHEL 又想为了硬件和商业软件兼容性的白嫖党
3. 以上因素培养出来的大厂前辈们流落到民间给徒子徒孙的传道

安全是什么，safety 还是 security ，是当电器用的安全还是当通用信息处理设备的安全

不过一互大里的 infra 其实也很多草台班子。钱多人多市场近的行业，必然萝卜多了不洗泥，不过正是因为钱多人多市场近，即使 infra 草台，也有各种非技术的办法让他运转好。

托尔斯泰说得对，信息化搞得幸运都是一样的，不好的则各有各的不幸。^_^

其实这个世界上很多支撑着社会基本运转的单位的信息化水平尤其是 infra 水平烂到习惯了“一互大”的人无法想象。

@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