认真的工作环境，应该拒绝使用家用路由器这种为特定场景优化从而导致对其它场景劣化的设备作为路由器角色。

好好写你的能“带来直接收益的项目”的代码，别胡思乱想。等你写多了，遇到的问题多了，现有的库、框架不能称心如意了，或多或少也会去动手搞点基础设施。人家厂子大，那搞的基础设施就更大、更多、更通用、更牛叉、更出名。

看到这名字我第一反应是支持 CAS 协议…

健身环大冒险，舞力全开

椭圆机

小型运动器械

@pusheax 甲方表示有苦说不出，做业务系统开发的那些地方性、行业性的供应商，除了被甲方锤着勉强把业务功能凑合实现之外，其它真的是什么都不懂……还一个个拽得。

不熟悉 MySQL……

对 Oracle 和 MS SQL Server ，N 和非 N 的区别在于如何算长度，非 N 的版本是按字节算的，N 版本是按字符算的，所以一个 NVARCHAR(6)是不论哪国文字都 6 个字符，而 VARCHAR(6)跟具体的库所用的编码和文字内容有关。

而 PostgreSQL 统一按字符数算，不需要 N 版本。也就是说 PostgreSQL 里的 VARCHAR 等于 Oracle 和 MS SQL Server 里的 NVARCHAR 。

运维和安全也是专业性很强的工种，有自己的知识体系和技能要求。会做开发、做职能管理的人并不是自然而然凭直觉就会做运维和安全的。

不怕出错，就怕前面出过的错后面还继续出同类型的。还是要有总结和改进才行。

硬撑。运维类的工作就是靠知识积累和经验积累。多撑撑，踩坑踩足够了，经验丰富了，就害了。
当然，持续学习是必须的。

@Macolor21 所以呢广大地行小的尴尬之处在于，“基础扎实（ cs 四大课）”的、“学习能力够好”的 crudboys 都去一互大了，地行小哪怕是开出更高一些的工资都招不到靠谱的人，更何况地行小不太可能有实力给基层的 crudboys 们全员开出一互大的工资……另外还有个尴尬就是，一互大们的一些相对资深员工被输送到社会，进入各行各业的业务信息化领域当 CTO 、架构师之后，会把一互大的方法论带出来，但是这些方法论有的是要一互大的规模才有条件实行，有的是要一互大的人才层次才能实行……

@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 在一起）后再压缩。

“也不打算提高”……

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