键帽撞键盘，要解决声音问题可以在下面加一个静音垫圈。

--dir-cache-time duration Time to cache directory entries for. (default 5m0s)

就是以前熟悉的元素又要重新满屏幕找了。
前面找个 Commit 记录，找了半天才发现链接在哪。

这个项目之前一直在 Windows 下跑，纯 32 位环境。前几年终于移植到了 64 位，最近开始往 Linux 和 ARM 移植，Linux 已经能跑起来了，ARM 好像还在挣扎。
SIMD intrinsics 出现之前，里面大量的 __asm 裸代码，MMX 和 3Dnow 是主流，SSE/SSE2 都是后来才加进去的。MMX 因为和 64 位指令集共用寄存器，所以在 64 位下编译就得把 MMX 全关了。像上面的例子就是相关函数只有 MMX 版，关了就只剩纯 C 了。
还有像裸 __asm 只有 MSVC 才认，所以 Linux 下把这些用宏关掉以后也只剩纯 C 了。
要往 ARM 移植的话，同一套函数得写三套代码，一套 C，一套 Intel SIMD，一套 Neon，可谓是蛋碎。

像这个例子还算好的，有纯 C 代码，重写的时候只是重新翻译一下而已。最蛋碎的是遇上只有汇编代码的，你得先把汇编翻译回 C，然后从 C 再翻译去 Intrinsics 。这搞一个项目，有时候一不小心就一个月陪进去了。

@shutongxinq
https://github.com/msg7086-forks/AviSynthPlus/commit/15ed33dc6e5d886d238e30de3dea79022306c0db

这两天正好在看的代码。

底层有太多太多涉及到汇编和 SIMD 的代码了。
换平台也不是软件重新编译一遍就解决的。。
像上面提到的，底层库怎么办？任何一个稍微大一点的项目都会涉及到很多 CPU 密集型的类库。视频，音频，UI，计算，等等，哪一个是不需要跑汇编的。那么重编译的时候你完全放弃掉汇编优化吗？不可能的，性能差多少倍啊。

别说 x86 到 ARM 的适配，就是 32 位 x86 到 64 位的 x86_64 适配有时候都要花很长很长的时间。你碰过那种代码里有 MMX 和 3D Now 指令集汇编的情况吗？试试看重写成 SSE 和 AVX 要花多久的时间吧……

多年价不就是已经把倒闭的风险考虑进去了么。

@XGHeaven 老莱他们厂做剪辑，内网万兆互联传素材。
你要在云端做这个东西，第一用户的网络行不行，第二服务器的网络行不行，第三服务器的托管费用行不行，第四服务器的处理速度行不行，第五这么高的成本用户愿不愿意买账。

一个小众的东西一旦成为了大众，就离忠实用户离开他不远了。
现在 B 站已经越来越「正常」化了，也离我们心目中 B 站应该有的样子越来越远了。

挺伤感的其实。
我以前是 Opera 的忠实用户。
当 Opera 踢掉了创始人，成为了祖国版软件，进入了大众视线的时候，我放弃了 Opera 。

B 站差不多也在走这条路，逐渐抛弃那些发家的根本，成为了一个与原本完全不同的网站。
当它开始吸引「大众」的时候，「小众」也该离开了。
虽然从一开始就知道这是个必然的结果，毕竟要恰饭要挣钱，这么做也是无可厚非。
只是真挺伤感的。

软连接相当于文件，不需要加斜线啊。

@Netfix 换个好点的 shell，不会乱加斜线的那种。

@flyingghost 写上解释比光发一个命令更利于新手避开错误。

没有备份的数据是不重要的数据。

@nguoidiqua 套娃。
如果虚构者知道你可以通过是否会怀疑来确定记忆是否是虚构的，那么虚构者就不会让你不怀疑他。

还有注意控制咖啡因摄入量。

800%的 CPU 占用，不是挖矿还能是啥？ root 账号挖矿，不马上重装系统？

@foreverstandbyu #3
「为何没有撤销消费的权力？」
因为航司要给你预留座位啊，你取消了，位子万一卖不出去，不是亏了嘛。

所以一般买机票要买联程，这样万一前面的航程出问题了，后面的航程是航司担责。
（比如前面的延误了，后面的航程航司是要给你改签的。）

搜了下教程，打开以下这个选项就行了。

https://img.vembu.com/wp-content/uploads/2019/12/Nested1.png

看教程里说是成功了。

另外你 ESXi 是啥版本？看看用新版本会不会好些。

E5v3 因为需求 DDR4 所以平台价格可能会高一些。毕竟 DDR3 REG ECC 实在是太便宜了。