@Macolor21 因为数量广大的地方性、行业性、小体量的行业信息化系统开发商可能不太撑得起独立的 infra 组这样的组织架构。而 crudboy 在这种团队里也不仅是因为分工不同而做专注业务的代码，而是新人进来只能先从 crud 开始。这样的公司，架构性或者基础性技术的人员基本上只能从做 crud 的新人里慢慢分化出来。在实际工作中，地行小的 crudboys 也不可能只管业务逻辑，肯定要去写一些具体的“技术性”的代码，比如跟操作系统 API 交互，比如处理一些安全相关的操作等。而他们中的大多数人，基本上都是基础知识很差，一到要写这些代码就麻爪。作为一个甲方的信息化综合管理人员，我甚至手把手教过一个乙方程序员如何写 Java 代码来调用我们在 Kong 网关下用 HMAC-SHA 认证保护的 API……

其实最主要的问题是，地行小没有一互大的光环，即使用同样的工资也是招不来同样的人的。l

去公证处做公证翻译。

双绞线，双绞线，双绞线。重要的事情说三遍。所以至少要保证绞成一对的两根线要接在水晶头里的配对触点上，也就是 1 和 2 必须一对，3 和 6 必须一对，4 和 5 必须一对，7 和 8 必须一对。

另外，不同颜色对的线可能绞合的紧密度不一样，传统上 1/2 和 3/6 更密一些。不过正经的线应该是各对都足够密。

@Illusionary 以我在 v2 上的观察，太多怀着雄心壮志想将来转业务线或管理岗的 crudboys 别说是 docker 了连复杂一点的 SQL 都学不会，操作系统 API 或者安全方面的知识也都不去碰，只知道业务功能业务功能业务功能。

先 strip 一下

动态链接库的依赖管理是个很复杂的事。Go 的设计目标之一就是避开业界著名的 DLL hell 问题，所以用了全静态链接，必然会导致单个输出变大。这是它的 trade off ，不是缺陷。你所遇到的这种业务场景不是 Go 的目标场景。换语言吧。

对了，说到 C ，在嵌入式环境里也有一种全静态的构建方式叫 busybox ，具体做法就是把多个不同程序的源代码稍作改造后拧在一起，通过单一的 main 根据 argv[0]的名字来决定其行为，编译安装好后 ln -s 创建多个名字的软链接。busybox 是全静态的，实际上比每个程序单独编译后加起来要小。不过依赖库太复杂时就不适合用 busybox 了。

@vicalloy 对……zip 是每个文件单独压缩后打包。可以测试一下原始 png 文件先打包（比如 tar ，甚至只为测试不为实用的话直接 cat 在一起）后再压缩。

“也不打算提高”……

给你的工作任务，你恰好完成（结果不一定完善，只是进度意义上的完成），除此之外不消耗半分心思去多想这个任务在更大范围工作中的前因后果，不消耗半分心思去想怎样能做得更好，工作过程中遇到的问题解决了不总结也打算提高自己专业技能的深度和广度来避免将来踩同样坑……等等，像一个任务进度机器。其实很多时候只要多花半分心思，效果就会差很大。但是需要经验才能判断怎样的主动能事半功倍，怎样的主动是给自己挖坑。

难道在某些一互大（或者精神一互大） cruders 的母校里软工是必修课而数据库只配选修

可以探讨。但在你成为业界大佬从而你的个性被业界普遍认可之前，径直这样做，会给别人阅读带来麻烦，提高沟通成本…

cherry stream

@liprais 是这样的，如果实际业务对一致性要求搞，那就要在业务代码层里重新实现 RDBMS 的功能了。我不相信从一互大输送到社会上的小厂里当 CTO 、当夹狗屎的 cruders 在这方面能做得比关系数据库系统的开发者好。

普通台式机主板很少有支持这个功能的，模块也很少见，一般要自己动手，比如 pi-kvm

试试老版本的 go
以前我在新系统里非交叉编译的拿到 centos5 上不能运行，查了一下因为 kernel API 变动而不兼容，于是降级 go 版本搞定

@moxiaowei 阿里那个什么 Java 规范里说连 JOIN 不得超过几个，是因为他们当时用的 MySQL ，对复杂 SQL 支持很差，多表连 JOIN 真的会搞死…但世间又不是只有 MySQL 这种残废。不说可读性、可维护性，只说性能，多表连 JOIN 根本不是 evil 。

@moxiaowei 10 来个 join 就搞死？如果不是 MySQL 的话没那么怕多 join 的。

随着时代的发展，计算机操作 modem 成为小众技能，熟悉这种技能的人已功成身退或撒手归西。

“某些要连的服务器是密码登陆的。不要问我为啥不设公钥登陆，问就是我不是领导”，但是你可以给登录用的帐户设置 authorized_keys 啊，除非领导在服务器上禁用公钥登录。