一般还是会建议直接上 CentOS，毕竟源代码是一套。

都花了那么多钱了，为什么不去找客服问呢？

@zero47 唔，不能跨机房调用，性能问题。一台机器上每秒上万请求，跨机房访问必炸…

把全国的挖矿机一关，能出来多少能量，你这 CPU 的一丁点热能没啥利用价值……

借贴问问题。

手里有一个场景，两台服务器在两个机房，服务器上有相应的应用需要对本机 Redis 节点做大量读取和异步写入，所以需要数据在两边都完整地存一份，支持两边同时读取和同时异步写入。这种场景现在 Redis Cluster 能实现吗？

现在是用 KeyDB 的双主节点异步 Replication 来做的，稳定性存疑，但是一直找不到替代方案。

@reus 问问哪个国家没有不守规则的人。

不过我寻思着中国并不允许爬墙，所以其实爬过墙的人应该都属于不守规则的人。
这么看来中国的确不守规则的人比较多……

夏令时的时候时区本来就会偏移。比如美国东部时间在冬天是 EST，到了夏天就是 EDT 。你冬天取到 EST 然后按照 EST 转换，夏天取到 EDT 按照 EDT 转换，应该是没有问题的。
那么你说根据用户设置的时区来转换，这步就有问题了。比如说夏令时结束的这天的凌晨 2 点半 ET，就有可能是 EST 的 2 点半，也有可能是 EDT 的 2 点半。如果用户只是写了纽约时间的凌晨 2 点半，EDT 和 EST 都是有可能的，你怎么去判断呢。

我觉得你提的这个需求是有点问题的，最好再考虑一下到底要做什么比较好。

现在直接传 4K 就行了。
B 站有小丸可以用，很适合新手。
Pr 这些也不是专门压片的，可以不用考虑。
现在 Dash 化，基本都要二压，所以直接传个大文件上去让服务器自己做码率梯子就行了。
x264 的话，preset fast crf 21 直接出就行了。（当然，要注意不要超过上传文件大小限制。）

再高级一点的话，可以考虑看一下降噪滤镜，抹一下 fft 或者 mdegrain 之类的……

只开放给指定 IP，其他 IP 一律 drop 。

因为他是 Python，他不是其它语言。
而且 C++之前的 for 循环声明的变量也是会算在外作用域的，后来规范里明确要求放进内部作用域，才改成了现在这样。

刚开始逛 v2 的几年，一直以为自己不会去 Block 人，毕竟观点不同很正常。
近几年疯狂 Block 。

@iblessyou 分页不加排序可还行。
而且插数据的话应该用流式取数据而不是分页吧，要不然每次取下一页的时候还要重查……

电高压锅，一个小时出来什么都有了。

还好吧。
我们做的片子，被人搬运到了 B 站，最近 4K 开放以后我们自己上传了新压的 4K 版，结果稿件被锁定，理由是已经有搬运工上传过了我们之前发的 720P，所以现在我们自己传 4K 就属于重复上传。稿件锁定，访问视频链接自动跳转到低清版。
怎么样？

大公司和小公司不一样，顾及的受众群体要大得多。
比如对我来说，我最好希望 Windows 什么功能都不要有，就最基础的桌面，一些管理工具，结束。
很显然，我的需求和你的需求就完全不同。

又比如你说 Everything 这样的软件，这是一个很小的软件，就一个人或者几个人开发，他的体量和巨硬这样的公司体量就完全不一样。如果 Everything 有一个 Bug 会导致用户文件丢失，那可能丢了就丢了，报上来 Bug 修复了就完事。如果放在巨硬呢？十亿台设备上运行，一个 Bug 导致 0.1%的用户丢失了他们的文件，那可就是一百万台电脑啊。那你说，这团队得放多少工程师进去控制质量呢？（考虑到印度人的数量，这数字还得再往上加……）

这还只是一个软件。如果像你说的，图片查看也要做好，别的七七八八的功能也要做好，那怕不是得再招几十个团队进来了。

再加上上面也说到了，垄断。你要是都做出来了，那就准备好几十亿美元等着罚吧。

@anticipated #6 有不少概念是错的，当科普看看没问题，不要完全当真就行。

码率有边际效应，大部分可见的画面实际需要的码率并不大，最吃码率的那些是肉眼不太能分辨的小细节，所以现代的编码器会对画面（ DCT 后的部分）做一次量化，把吃码率且人眼分辨不出的那些频率直接砍掉，这样码率一下子就能下来 90%甚至更多。另外，优秀的动态预测算法也可以有效提升编码效率。

反过来说，要达到极限的画质保证，就必须堆下数倍的码率下去。比如为了保留人脸上的几根胡须，码率说不定得提高 5 倍才行。具体上多少码率还是看用户眼睛的刁钻程度来决定。

比如动画圈，字幕组一般给个 300M 一集的片，压制组可能会给 1.5G ，因为受众群体不同。