@zagfai @no1xsyzy
看看会被别的 Python 程序员骂成啥样。

我说的不是语言本身的能力。Java 你也可以从头到尾反射个遍，问题是有人这么用吗。写 Python 的是不是宗旨是每件事都应该用一种最优做法？是不是显式优于隐式？这些信条最终是不是造就了死板的语言？你炫技，别人劈头盖脸来一句，这 pythonic 吗。

我承认我没有认真用过 Python，因为我在其他语言中写 block 的习惯，放到 Python 上根本没法实现，因为我发现 lambda 好像只能写成单行。就算是列表表达也只能表达很简单的句子。我自己的项目是不会用 Python 去写的，只有公司项目要写 Python 了才会照着别人的要求写出一样一板一眼的代码。Java 也是。

@roudancongji @learningman
习惯了 vector 和 map 存数据，智能指针管理内存，模板写类的人，你让他们回去写 C，这得怎么写。

有些语言，好玩，灵活，所以写起来爽，但是不容易集团开发。
有些语言相反，死板，固定，写了 2 年和写了 20 年的写出来代码差不多，适合集团开发。
大公司大都偏向 Java 和 Python 这两个死板的语言，因为没有人鹤立鸡群，每个人写出来的代码都差不多，每个人都能大致看懂别人的代码。这种就是最适合工业上用的语言了。

你要写点 lisp 啊 haskell 啊什么的，鬼才看得懂咧。

x265 就是用 CPU 的。你要用硬件编码器那就改用硬件编码器。
「显卡加速」有，但因为显卡并没有比 CPU 快多少，所以实际上并不能加速，也没人用。
要么就直接用显卡内部的硬件编码器来编码。这种和加速无关，是直接调用专门的电路来编码。
比如 qsv 或者 nvenc，就是调用核显或者独显内部的电路来编码的。

Console 我用 ConEmu 。

用 LTSC 开更新还不如用零售版然后关掉更新。
其实就是楼主帖子里所说的「企业用户如何管理公司电脑的自动更新」的方法。
用这个方法关掉的话就真的彻底关掉了。

至于其他一些现象的话，我也不知道算什么悖论或者理论，但是人确实是只会在自己熟悉的领域里发挥。
比如说劳动法合同，这是律师熟悉的领域，白领也好程序员也好本来也不熟悉这方面的内容，搜索了也不见得就是对的。
比如说操作系统更新，反过来你跟一个律师说为什么不去搜一下，那也没意义。

再换一个领域，比如说赛车选手，他们买车可能是按照改装标准来买的。普通家庭买车呢，肯定是看舒适性，可靠性，性价比，这些东西。那你说一个赛车选手跑过来指着程序员说，你买车之前怎么不搜一下，这个车悬挂开起来不舒服，那个车没有差速器过弯不顺滑，买前驱车还有扭矩转向问题，怎么不去买个 GT86 回来开？那大家不得一脸懵逼？

「外行」和「内行」终究还是不太一样的。人一辈子也就这么些年，不可能每个行业都精通的。在自己不熟悉的领域提问，再正常不过了。

组里有个印度小姐姐，老公也是程序员。具体体验就不清楚了。反正还是不算很少见的。

公司刚刚从 7 艰难升到了 8，新项目全都用上崭新的 8 啦（手动狗头

指令重排是编译器，微指令重排是硬件。

公司用 OL 6，自己 Debian 10 。

SMART 都是厂家自定义的，不知道怎么解读就没法知道这些值的意思……

GCP 性能测试，8c 的 EPYC 性能和我 4c8t 的 i7-3770 基本相当。
你这个 vultr 8c 我估摸着也就是个差不多的水平？
可以弄一台新一点的比如说 i3-10300 或者 R5-3600 这个水平的独服来跑一下分。

你可以先找找东芝 Raw Read Error Rate 的解读说明，看看这些值是什么意思，然后考虑挂不挂的问题。

打电话要收费这个前提并不一定总是正确的。
北美 Google voice 已经全免费了，普通的手机套餐也都自带无限量通话时间。
所以不排除以后打电话功能直接给你免费了。

只有联名账户，两个人的钱都扔里面。要花大钱的时候互相商量。

@gggxxxx 美国这边 AA 是普遍现象，吃个饭一人付 8 块钱的现象很普遍。

1. 如果要造矿脉，越早造越好。
2. 造矿脉会拖累游戏进度。

所以写个函数，有钱就造矿脉，造到上限，然后对比一下总的时间就行了。

10240 的话，造出来不划算。
Reaching target at time 385s, gold 17120, lumber 19110, seirei 10, mines 0
Reaching target at time 386s, gold 8976, lumber 19200, seirei 11, mines 1
19110 个内，造矿脉都是不划算的。

从目标 19120 起，造 1 个矿脉追上不造矿脉的时间，21190 起，造 1 个矿脉比不造要快。
23960 起，造 2 个矿脉更快，26440 起 3 个，28970 起 4 个，33170 起 5 个，35560 起 6 个，37900 起 7 个，40200 起 8 个……

代码在 gist：
https://gist.github.com/msg7086/9b9f517209c655045c2ecc21994ac0ea

我们组小，on call 是一个人代表一个组，一次一周，一个月轮到一次。
on call 的那个人需要诊断问题，和用现成的 Wiki 文档去走检查流程，如果都不行的话，再拉 service 对应的开发者来一起看。

我司的做法是主干修复然后 cherry pick 移植到老版本。

你现在应该有 release-1.1 release-1.2 release-1.3 等等的发布分支吧。
比如你现在的版本修复了，发布了 1.5.0，那么你把修复 bug 的这个修改补丁，打到 1.4 、1.3 、1.2 、1.1 的发布分支上，他们就分别变成了 1.1.1，1.2.1，1.3.1，1.4.1 版本。

当然这前提是你遵循 semver 规则。
如果你本来就是滚动更新的话，那老版本也就没必要修复了，直接让人用新版就行了。