@Y29tL2gwd2Fy #4 飞书里面那个应该不是抄的，极大概率是直接拿代码集成进去的，毕竟是开源软件，只要 License 允许就可以拿走商用。

没试过，理论上 WSL2 就是在 Hyper-V 虚拟机里面跑的 Linux ，只不过没有启动过程，类似于 chroot 环境。

一般编译工作都只是涉及编译工具链、依赖库，不会涉及到硬件设备和系统服务，应该问题不大。

不过你完全可以用系统自带的 Hyper-V 开个虚拟机装个完整版的 Linux 来编译，网上针对 Linux 环境的教程应该都适用。

蹲一个试过的大佬。

@monetto #25
Ubuntu 专门有一个设备认证，就是厂商的台式机和笔记本通过这个认证就可以在 https://certification.ubuntu.com/ 查到，说明了与 Ubuntu 的兼容性，而且有的品牌比如 ThinkPad 在海外专门有预装 Ubuntu 的版本发售。如果想买笔记本用来跑 Linux 就可以参考这个。

Ubuntu 牵头支持了不少重要的 Linux 生态项目，比如 OpenStack 、Docker ，现在又跟微软深度合作给广大开发者带来了 WSL 。

同是商业发行版，Ubuntu 比较普惠，RedHat 的风格就更像一个传统商业公司，RedHat 做了一套很成功的培训和认证体系，早年技术人员拿个他们的证是比较有含金量的，导致技术人员倾向于使用 RedHat 的产品，这也是为什么国内一些大型传统企业、事业单位转数字化会比较倾向于用 RedHat 的产品（当然现在逐渐迁移到云计算和国产化了），一方面技术人员有认证体系可以参考，另一方面任何问题花钱就可以解决。Linux 在服务器市场大获成功，RedHat 功劳是不小的。

还有个比较有趣的商业发行版是 System76 ，他们专门做 Linux 笔记本及其他硬件产品的，并且自行维护了一个发行版叫 Pop!_OS ，据说跑 Steam 比较方便。

跟结婚前没啥区别，大支出需要商量，有需要就互相匀一匀。

不同发行版的方向不一样，Arch 的存在其实就是给你一个架子，然后给你一堆好东西，让你自己按照自己的喜好把东西往架子上摆，如果这种需求场景用 Manjaro 或 Ubuntu 的话，就得需要你自己把一些东西先从架子上拿下来，再想办法摆东西上去。

Debian 一类的其实也并不是特别依赖于官方软件源，想用新版本软件可以自己编译，有 make 那一套工具大多情况下也不是很麻烦，软件依赖的库也可以自己编译（ Gentoo 了解一下），只是如果真的需要稳定且不要求新特性的话，官方源可以给你这个保障。

很多 Linux 发型版是继承了 GNU 那一套价值观，希望发型版主体遵循自由软件（ Free software ）和著佐（ Copyleft ）的精神（以及法律风险），所以像微信之类的既不开源又不自由的软件大多发行版官方都不提供。Arch 的 AUR 和 CN 源实际上是属于用户社区，本身不代表 Arch 发行版的官方社区。其实 Ubuntu 也有 PPA ，CentoOS 也有各软件维护方的源，但都不及 Arch 的这一套灵活。

Linux 发行版也分公益性和商业性的，像 Ubuntu 和 RedHat 背后都是有商业公司支持的，需要用 Linux 的企业可以花钱买解决方案，工业化的生产和质量保障流程也让发行版本身用起来更可靠一些。

MacOS 毕竟是 Unix ，而且是商业封闭系统，跟 Linux 差别比较大，POSIX 实现有一些区别，比如自带的 Shell 工具，以及一些环境变量和设备，并不能 100%兼容 Linux 使用方式，愿意折腾的话也可以尽量折腾地兼容。

我以前用了好几年 Arch ，后来懒得折腾了就开始用 Manjaro 了，几种桌面环境其实愿意折腾都可以搞得挺好看，甚至可以自己做主题和插件；我个人的使用习惯比较适合 Gnome ，操作起来效率会比较高。

可以参考这个流程：
1. 开个虚拟机，装个 Ubuntu ；
2. 尝试找和折腾各种以往在 Windows 、Mac 上的替代方案；
3. 尝试自己编译软件；
4. 尝试直接在电脑上装双系统，或者单 Linux 系统；
5. 尝试调校和折腾各种硬件驱动和配置；
6. 换 Arch 或 Gentoo 。

看到一个自己不了解的概念就去了解一下是什么。
任何信息都可以优先去 ArchWiki 上查（这个 Wiki 对使用各个发行版都有一定的帮助），不行就去 Google 上搜。

大概有个一两年可能就稍微了解了吧。

我目前已经有 15 年 Linux 使用经验了，但最近在折腾 OpenWrt 依然让我产生自我怀疑。

Hype Cycle ，目前 Go 应该是刚过低谷，开始逐渐成熟应用； Rust 应该正在爬高峰。

Rust 主要还是活跃在系统开发领域，Go 主要在 Web 服务领域，两者不太形成竞争关系。

Rust 语言特性跟现代化，现在大多语言基本都是互相抄特性，了解一下也是不错的。

不过 Rust 语法糖很多，而且大量使用符号而不是英文短语，同时一个符号在不同地方可能代表不同含义，再加上 ownership 的管理对于用惯 GC 语言的人来说多了些心智负担，学起来会比较难。

有这种开源协议，上面有提到的 996.icu 就是。

问题是假设企业违反开源协议，就得有个主体去告这家企业，比如项目所有者，即便法庭支持项目主体的主张，也是会根据项目主体的损失进行赔偿裁定（法律上一码归一码，违反劳动法的事情得监管部门主导额外开庭），最终受益人是项目主体，而不是企业员工。
起点是有组织主导，终点是法律解决，那么相同的模式其实不如直接去解决 996 本身，而不是绕个远路，比如直接针对 996 的 NGO ，或者进入工会组织发展。

三观不同。

我发小就是会主动还钱，属于那种特别会做人的。

上面的思路都可以参考，个人建议既然用 git 就把所有方案限定在 git 体系内，尽量不要自己复制代码。

不必要，但不是不可以，如果感兴趣而且时间充裕也可以考。

如果是想生活得更好的话，不管去哪，建议了解一下当地就业情况和生活成本，看看自己的能力是否可以在当地比以前更好。

据个人了解；能走的要么是自身能力超群赚钱能力很强的（比如学霸）；要么是本身资本够厚，在国内属于中上层阶级的。普通人路子应该是存在的，只不过活得不一定比国内轻松，到了欧美成了人下人的也有，再加上阶级锁死难以跃迁，可能没必要。

假设题主用的是 OpenSSL ，假设这个版本支持 AES 指令集，假设题主用的 CPU 支持 AES 指令集，假设没有其他性能瓶颈，那么测出来的应该是当前硬件上比较极限的速度了。

比硬件效率更高的应该也是硬件方案，当前主流 CPU 是否支持其他密码学指令集我就不大了解了，题主可以自己查一查。

很多程序员都习惯了跟机器打交道，对他们来说跟人打交道比跟机器要难很多。

你离职的情况应该属于《劳动合同法》（注意不是劳动法）第四十六条第（二）项，引用第三十六条的情形，这种情况是有经济补偿的。

《劳动合同法》第四十七条规定了“N”。

《劳动合同法》第四十条规定了“N+1”的“1”，但好像并不包括你的情况。

其余就是地方性法规是否有相关规定，比如北京地区有《北京市劳动合同规定》，其中的第四十条、第四十七条规定如果没有提前一个月告知解除劳动合同，需要赔偿 1 个月工资（注意上文是经济补偿，这里是赔偿），有些企业为了避免扯皮风险，不论是不是提前一个月告知，都给这一个月的赔偿金，这个赔偿金又被称为“代通知金”，就是用来做实代替提前一个月通知的。但注意这个是企业自愿的，不是强制的。

这种情况，较大概率是技术和架构方面扎实一点，但团队协作弱一些；所以重点考察一下团队协作能力有没有退化，是否愿意听他人意见。

建议建立一个心态，就是跟人打交道不是跟机器打交道，机器可以严格按照既定程序执行，只要程序正确就不会出错，但人是需要培养默契和强化协同方法的，先天就会比跟机器打交道麻烦很多。

对于提问题的人来说，他们看到的那一小部分是问题，其他地方是正常的，所以只会截那一小部分。
你是解决问题的人，知道什么问题应该进一步看哪些信息，于是先入为主认为每个提出问题的人都应该和你一样知道需要截哪些信息，不光是当前页面的信息，有时候需要提问者截另一个界面的信息，你也可能会想当然觉得提问的人应该连着那些信息一起截图给你，但实际上别人是不清楚的。

这种小事没必要上头，既然是服务别人就得有些耐心，如果大多问题都需要且仅需要截全屏就可以解决，那么你大可每次跟提问者要全屏截图，反正只是说一句话的事情；公司有良好的流程管理制度可以把截全屏这个写入到流程文档中，甚至某个简单解决的问题太常见，也可以写成 FAQ 放到文档里或产品界面上。