@MilkyWayne 有 19 英寸机柜一样宽度的组装式家用杂货架，甚至立着的四根角铁上的垂直孔距都是按机柜距离打的，唯二问题，一是深度远远不够，二是强度恐怕没法撑住大多数机架式设备

不过在 PVE 的 web UI 里搞这种操作改配置有可能不小心搞断网

PVE 里个给 eth1 、2 、3 做 bridge ，在 bridge 上配置管理 IP ，OpenWRT 的 LAN 口接到 bridge 上

不考虑一互大的秒杀这种极端需求，在普通的信息系统应用场合，绝大多数“顺手写出来”的 log 库，还不如打到 syslog 再用 logrotate 做切分更方便。用 logrotate ，至少我可以配置切分前、切分后调用自己的脚本来做预备和善后处理。而用业务纯程们自己写的日志，十有八九只有他们自己调试时用起来顺手。

@ql562482472 甲方一般不关心技术。我是异种。

@ql562482472 主要是后者。

因为面向行业信息化的软件系统里，业务功能和基础设施功能可以看作是两个不同的领域。既然是不同领域，就有不同的知识模型。不排除做行业信息化的公司里也有相当的专家熟悉基础设施领域的知识，但因为做行业信息化的公司其核心价值是解决客户的业务发展需求，所以首要的关注点、投入最大技术人力成本的方向是实现业务功能。而基础设施领域里则有更擅长的参与者。对于做行业信息化的公司来讲，要业务功能开发人员兼顾基础设施开发，实际上是逆分工而行，出力不讨好。尤其是，相当一大部分程序员是没有能力写高质量的基础设施的。

给你举个我遇到的真实例子。上级信息主管部门发来安全通告，某个业务系统的后台管理模使用的开源组件老版本爆出 CVE ，要求限期内处理。问供应商，答曰我们用的这个业务系统已经是老版本了，他们公司现在主推新版，老版不再更新，而且那个开源组件直接换成新版的可能不兼容……可以给我们安装新版本的业务系统并迁移数据，不额外收钱。但是新版本安装实施时间挺长的，超过处理期限了。我说你们老系统的 web server 是 IIS 这种通用的玩意，你后台管理模块路径是确定的，在 IIS 里配一个 ACL 规则，先把后台管理限制在我们单位的 IP 范围内，对最终用户还是全部开放，这样不行么？对方说，加上限制 IP 的功能要排期做开发，旧版系统他们不改动了。我说这是运维手段解决问题，不需要你们程序员改代码。对方还是坚持这是功能变更。吵了好几轮，最终还是我放弃了。先停掉有问题的旧版系统再说。

举这个例子是想说明，像分模块做 IP ACL 之类的功能，其实是和客户的“业务”功能没有关系的基础设施功能。做基础设施软件的开发商（不论是 IIS 开发者微软这种真的“商”，还是免费的 Apache 、Nginx ）早就把基础设施功能玩得溜溜转，你能想到的基础设施功能需求很可能就是用现成软件做做配置就好了，你没想到的，他们也都早替你想到了。而他们在基础设施领域的经验、技术能力、成本投入，都不是做业务系统的开发商在完成客户业务功能开发这一核心价值之外顺便来开发基础设施功能所能比拟的。善用成熟的第三方基础设施软件，善用运维手段解决非业务方面的功能需求，这在某种意义上也是解耦，不次于“开发”中所做的解耦。尤其是复杂的软件系统会跨越不同编程语言、运行在不同进程甚至不同机器上，用好成熟基础设施，往往能比业务纯程们在写业务功能之余自己去造基础设施的轮子，甚至比起用现成的基础设施库或框架嵌到自己写的程序里调用，都有更好的收效。据说 Spring Boot 时代，主流的做法是构建一个巨大的 jar 用 java 命令启动，不提倡构建成 war 放到 tomcat 之类容器里运行。这种做法当然有其应用场合和原因。但是我想问一下，从来不碰生产环境运维配置的纯程们，是否知道只靠修改 tomcat 的 server.conf 、不自己写代码，能对 tomcat 的行为做多少控制，能解决多少你们第一反应是写代码实现的非业务功能需求？这些如果都靠业务纯程们来写，要多少工作量？代码质量如何，是否能担得起“基础设施”的质量要求？即使不自己写，靠项目里 embed 一个 tomcat 或者 jetty 的核心包，如果要达到打包好的 tomcat/jetty 的可配置程度，你又要在自己的项目里写多少代码来处理配置？

Everything in Java, everything in coding……反正我是不太喜欢这样的乙方团队给我干活的。

跟业务功能无关但又需要根据项目实施场景来定制的基础设施是放在哪里？通过库 /组件引入业务系统，还是在业务系统之外作为独立的基础设施用运维手段搞定？不同背景的人有不同的答案。

单一技术栈、以纯程序员为主的团队，用 SpringCloud 或者类似的其它能把基础设施集成到程序里的“全开发”式方案会比较顺手，而混合技术栈、运维技能全面的团队，可能更适合业务逻辑归业务逻辑，基础设施归基础设施，后者多使用运维手段来解决。

如果这两个节点在同一二层网络，把做配置的拖出去打死。
如果在不同的二层网络，把提要求的拖出去打死。

@JoeoooLAI 但是 UISP 那个 OS 目前还看不到详细资料，尤其是 CLI 的资料……如果是作为 EgdeMAX 的后继，这样很难平替的。

我的路由器默认是对 IPv6 （包括用 PD 送进 LAN 里的网段）启用防火墙规则的，需要对外放开啥端口要自己配置。当然，IPv4 也是默认启用，就像#7 说的，防火墙和 NAT 是两回事。

居然还招 Haskell 开发……

让产品主管、技术主管、经费主管人肉 PK 先，谁活下来听谁的。
产品主管壮烈了，就不用做这个需求了。
技术主管壮烈了，可以换掉怕多酱的 MySQL ，改改规矩。
产品主管和技术主管联手打得经费主管趴下做舔狗，可以加预算把事务和分析解耦，分析操作用数仓。

另外，从回复可以看出，OP 标题这种网红自媒体风的表达方式会激化矛盾 ^o^

其实 Windows 里的 UI 逻辑也有 drag object vs move viewport 的区别，只不过前者一般对应点按后移动鼠标（ viewport 不动，object 根据鼠标底座移动方向跑），后者对应转动滚轮（ object 不动，viewport 根据滚轮转动方向跑），大部分 UI 都遵循这个区分，鼠标主体动和滚轮动是两回事，所以习惯 Windows 的人认为两者应该区别开。而当代 Mac 似乎有意融合触摸板和鼠标，滚轮的动作也是相对于把鼠标当成一个固定的触摸板底座来判断方向的，那么原生 Macers 就更习惯两者一致。

没有好坏。但我认为，Mac 的模式是为 Mac 的融合式鼠标硬件妙控设计的，外接第三方“传统”鼠标时，这种操作其实并不是很协调。毕竟，就像前面有 V 友说的，向上推滚轮时，跟底下的“纸质文档”发生“摩擦”操作的是滚轮的底部，是把“纸”向下拉的。

其实，以前日本的 PC9801 时代，也有过跟 IBM PC 相反的设计。9801 里 Page Up 是把“纸”向上拉，Page Down 是向下拉，类似触摸屏的拖放，正好跟 IBM PC 里文档不动移动视线的操作是相反的。不过 9801 基本没在日本之外流行过，而且后来也消失了。直到触摸屏时代，又在 Mac 外接第三方普通鼠标的场景里成为网友们争论的焦点。

图书馆行业的路过。表示这种自己拍脑袋做的只能当 CS/SE 的课程大作业。真实世界的图书馆系统业务逻辑其实还是很复杂的。

U 家的东西……除了贵之外都挺好。贵也只是相对的，品牌定位是高于普通家用级但低于企业级，价位也卡在这个中间。

我家是老款的 USG8-60W 带两个 UAP-AC-Lite 、一个 UAP-AC-Pro ，凑合用着没动力升万兆和 AX 。网关是 EdgeMax 系列的 ER-X ，没用 Unifi ，因为有些不可名状的配置需求在 EdgeMax 上很好搞，Unifi 上不那么顺手，甚至不保证能不能支持。

同意 #2 对存量的兼容是遗产也是屎山。

同理，X86 CPU 也是这样。所以 Intel 在搞 X86s 去掉 16 位和纯 32 位模式。