如果服务器数量比较多，而且都是异质的（企业信息化环境里很常见，没有那么多像互联网环境那样一大堆同质节点做横向扩展的架构），那么一个带 GUI 的客户端对日常琐碎操作还是有点用的。至少，从 connection manager 里用眼睛看文字识读挑选目标服务器打开，比在命令行上输入 ip 或者别名要舒适很多。服务器多了，记不清 ip 或者名字很正常，但是看着列表挑选就容易很多。而且，既然是跑信息化业务的，还有很多名字是中文业务名，能挑选还是不输入了吧。

NetBSD 倒是很多年前就在内核放 Lua 了

这种打字机敲文稿时代形成的手指分工规则，对于 PC 键盘敲代码来说……还是不要奉为圭臬的好。

安全部门一般会要求至少保证 security 的及时更新。业务部门一般会抵制更新。屁股决定脑袋，都希望出问题了责任不在自己。

但是 esxi 是免费的，要上 vcsa 就得掏钱了。破解另说。

esxi 只是个 hypervisor ，要多机集群用得上 vcenter server appliance 做管理。用上 vcsa 之后你会发现世界完全不一样了。

只有等翟天临博士动嘴才能治得住这种无良商家😄

看这架势很快会有人实现类似 dnsmasq 的 ipset 分流功能……

这么执着 wine…有没有考虑过用 Windows…

方法四，加一个命令行参数，用于指定从哪里读取配置文件。默认是从项目内部路径，可以指定覆盖。服务器上部署时，就在 systemd unit 或者其它启动机制里指定。

我自己做的小项目或者要供应商做的大项目里主要用方法三和四。

只写过业务代码没在生产环境玩过服务器运维但是对这个问题又困惑并且愿意较真的小盆友们还是认真玩玩服务器。比如用 Linux 的，至少了解文件系统的各部分，知道发行版打包好的基础软件是怎么使用文件系统里不同目录结构的，File-system Hierarchy Standard 是什么。虽然发行版打包好的基础软件的惯例通常不太适合 100%照搬到业务系统上，但有很大的借鉴价值，会让你们的系统部署跟运维老司机的对接更流畅。

只写过业务代码，没在生产环境玩过服务器运维的小盆友（也不排除有很多老手甚至所谓架构师）可能潜意识里默认认为配置文件“只能”或者“应该”从项目路径结构（当前目录或者下面的子目录）读取，所以在这个问题上会犯难。其实哪有这么愁呢？
方法一，程序里指定从 /etc/<my_project>/<some_item>.conf 这样的 site-wide global path 里读取配置，开发机和生产环境各写各的配置，互不影响，提交的代码里根本不包含配置文件，而且做部署的时候也不会覆盖现有的配置文件。缺点是如果配置文件语法、语义有版本变化，需要生产环境的运维人员配合做升级。
方法二，做两个不同的 profile ，但都是从项目内部路径读取配置。开发机用开发的 profile ，部署到生产环境用生产的 profile 构建打包。两个 profile 的配置文件加入.gitignore 确保不会提交。缺点是每次在新的开发机上 clone 出来需要自己准备配置文件。
方法三，做两个不同的 profile 。开发机用开发的 profile ，从项目内部路径读取配置。部署到生产环境用生产的 profile 构建打包，不打入配置文件，而是从 site-wide global path 里读取配置。开发 profile 的配置文件加入.gitignore 确保不会提交（其实提交了也无所谓）。集一和二的部分优缺点。
当然，做不同 profile 也有多种实现方式。一般 Java 项目是在构建时区分，某些脚本语言的项目往往在运行时通过读取环境变量或者命令行参数来区分。只要能分开，都不是大问题。

用窗口函数

诸君哭到天明也哭不死董卓

@A01514035 短期关掉测试一下看是不是运营商从 ipv6 栈推过来，又不会怀孕的。

关掉 ipv6 看看

什么类型不类型的，C 又不是 Haskell

举个栗子：过程 A ，从界面获取用户输入；过程 B ，检查用户输入的格式正确性；过程 C ，拿用户输入调用后端业务。
业务逻辑是按顺序调用 A 、B 、C 。

过程 B 里判断输入格式是否正确，用 if ，因为不对的格式是用户输入的，程序不可控，遇到了不是程序的错。

过程 C 里要再检查一遍用 assert ，因为这里数据不是直接来自不可控的用户输入，这是程序员可控的环节，格式再不对就是 B 写错了，写对的程序执行到这里不应该有不对的数据。