用了一定的流量以后直接给你干回 2G 限速。

syncthing 要把同步时间改小，我是改到 3 秒左右，不太容易炸。默认的 10 秒延迟不适合同步代码。

@blueboyggh PCIe 可以热插拔，但是：

@freevioce 会蓝屏或者死机，如果主板、设备和系统不支持的话。

我前公司倒是无所谓，但是还是发了一台 ThinkPad 顶配来用。
我先公司也无所谓，但是也发了一台 ThinkPad 中配来用。

可惜 ThinkPad 本身性能就不行啊，牙膏厂太拉跨了，随便一台 Ryzen 游戏本就是三倍性能。
搞 Java 项目慢得想哭。

面试一般四块，项目经验，行为，算法，设计。

恕我直言，算法是最简单的部分。我去亚麻之类的店面试，基本都是 LC 的 Easy 题，撑死到 Medium，看的一般不是你能解决多难的面试，而是看随便交给你一个简单的开发任务以后你能不能在很短的时间内实现出来。
如果给你一个简单题你在那磨磨唧唧半天出不了代码，那难道你在工作岗位上就能出代码了吗。

当然这是最基本的要求。往上还有设计题，还有行为题，还要聊之前的项目。这些要比写算法难多了。

🐶I'm fired🐶

不考虑 DIY，那不就等于是找软硬件打包的成品吗？
单卖硬件不卖软件，市场需求太小了。
就算是买二手服务器，也可能要自己动手换硬件的。

感觉和上门安装的师傅不小心把路由器带到地上摔坏的概率差不多。

给我装宽带的师傅就把我的猫甩到了地上，重重地砸在地板上。还好没砸开。
当时心中一万只羊驼飞过。

ermmm 你们睡觉的时候不充电的吗？

笑笑，有谢到。

@MengiNo 主要是我们本来就是写 Java 的，总觉得公司应该要考虑一下实际需求……

回国速度好的都不会便宜。带宽多贵啊。

merge 会产生一个新的 merge 节点。
一般个人项目可以一路 rebase，稍微大一点点的可以按照 feature 来 merge，大公司的话可以考虑 squash merge 。

然后最主要是要分清操作的方向。
比如说你有一个主线 dev 分支，然后有各种 feature 分支。
把更改从 dev 搬到 feature 一般用 rebase，把更改从 feature 合并进主线一般用 merge 。
因为一般用 rebase，所以 conflict 应该在 rebase 的时候解决。
用 merge 解决 conflict 是很坏的习惯，因为一般习惯是 merge 本身不包含改动，只包含合并。
如果你在 merge 里偷偷藏了改动的话，需要 revert 或者 blame 或者 cherry pick 的时候就容易漏掉改动。

@PrinceofInj Vivaldi 是纯正的 Opera 血统，不能算换「其他」浏览器吧。
Opera 12.16 也老了，该换了。

别的就不说了，就稍微吐槽一下 Mac 。
我们是写 Java 的，组里一共 5 个人，除了我是 ThinkPad 其他人都是 Mac 。
公司发的 Mac 全都是翻新机，只要没过 3 年支持期的，前人离职以后搞搞干净就发给下一个人用。

远程开会的时候经常遇到谁突然就不见了，然后过一会儿发条消息说 Mac 死机了正在重启。
搞得我都有点开始同情他们了……

然后我们写的代码基本上一个 Java 进程就要吃几 G 内存，而他们的 Mac 好像都只配了 16G 。
我估摸着就是内存不足导致经常挂掉。

Vivaldi，纯正的 Opera 血统。

罗技就是要自己换微动啊。
手持 5 个 M570，每个都双击，淘宝上 F-3-7 买了一包回来一个一个换上去。
罗技原厂给 D2FC-F-7N 辣鸡微动，5 毛钱一个。
高质量的微动，像是 F-3-7，5 块钱一个。
不双击就有鬼了。

@justrand @a1gslyghmqnl
如果 GUI 做不到 CLI 能做的工作，那说明这个 GUI 还有待改进。
我几年前就和别人辩论过一次。我的观点是，人类的大多数操作还是要依赖直观的图形界面。就比如人们常用的文本编辑工具 vim 就是图形界面，CUI/GUI 。对于简单的或者批量的操作，sed awk 之类的 CLI 工具更方便，但是任何复杂的交互还是 vim emacs 甚至是 nano 这样的图形界面工具做得更好。

另外我用的 GUI 在切换分支时如果要重置文件的话是会自动提示 stash 的，CLI 反倒是严格要求用户必须记得手动执行 stash 。所以我以前教人用 git 的时候，都是给 GUI，然后让他们看看在做一些复杂操作的时候，GUI 是怎么调用 CLI 的，然后再学习对应的 CLI 以备不时之需。在我这里，CLI 基本上才是做一些无关紧要的操作（比如 pretty print git log 之类的）。