计算机技术是博大精深的，需要打好好几个方向的基础，再在好几个专业方向深耕。不是凭直觉看了几门编程语言的语法入门，再凭小聪明就能学好的。
有很多人在成体系长期学习计算机技术之前容易误以为自己对计算机技术很感兴趣或者有才能。实际如何还是需要事实来检验。
还是建议 OP 先解决了养活自己的问题的前提下，抽出时间来慢慢学习，补好基础。以前逃避学习，欠下的人生债，终究是要还的。
其实 OP 不必焦急。大概是互联网时代容易看到被刻意渲染出来的“成功 IT 人应该 35 岁退休”的鸡汤案例和更多 35 岁没成功退休只能被裁员的极端真实毒案例，有的人会觉得在这风风火火的速度下已经不能再静下心来花几年时间学习，学几年就错过了同龄人的成功之路。其实就算你现在补回以前逃避了的学习，几年之后再入场，人生也还是上半场的前场呢。

另外虽然你看到有些批评你的表述可能正好触动了你心里最脆弱的地方，但希望还是能尽量让自己静下来，不要急着反驳，更不要明明是抬杠了还一遍遍强调不是抬杠。比如关于 unsafe rust 的认知，只能说你根本没理解 rust 的 safety 背后的理念和 unsafe 的使用场景。基本功和见识不够，还是尽量谦虚一点吧。

打字太多，拆键盘太少

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

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

看到这名字我第一反应是支持 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 在一起）后再压缩。