@xtreme1
黑神话悟空才刚打到第三章，周末还是用来打游戏吧，根据一些帖子所说现在能随便打到 2200 没问题

9950x CPU ，功耗全解锁温度墙 85 度
跑 3D mark time spy extreme ，在补丁前 CPU 分数 13829 分，位于 3D mark 9950x CPU 排行榜第 48 位
补丁后，CPU 分数 14694 ，排行榜提升到 15 位

@JerryLF findroid 只有 directplay

这种规模得优先考虑端侧或者专用机，海康自己有一个融合超脑产线，单机有最多能承载 256 个流的产品。
先不说别的，同时维护 1800 路流的实现难度比同时算 1800 规模的图像高多了

@shineben https://openwrt.org/docs/techref/initscripts

@piero66
vcb 的系列教程都看过，handbrake 还是主要给日常工作用途的压片降体积，用 vs 有种牛刀杀鸡的味道，专业的事情、专业的作品发行，还是让专业的人来吧

我个人认为：
便捷度 <------------------> 专业度
Handbrake 小丸 megui 、vs 等

@icaolei
码率爆炸了，压制的第一个字是首先是压
nvenc 和 qsv 设计上都是适合 CBR 场景，比如流录制、流直播、jellyfin 等服务器的转码回放，以 CQ 为控制目标用于本地存储的时候体积占用是纯 CPU 的 2 倍

@lazywen
Handbrake 出场预设叫 Fast 1080p30 ，使用的设置是
x264 ，30fps ，22RF ，Fast ，Main ，L4.0
不知道你说的 1000K 码率从何而来。

@PopRain
恰恰相反，我们这边的信创流程都是先把数据迁移弄好，迁移完之后带着迁移报告、开发规范、改造指南一并交接应用，再让应用接入适配、改造、联调联测
“迁移工具毕竟不是数据库厂商的主业”，常规开发是这样的，但是信创信创，讲国产替代就一定会有被替代的 DB 在，所以信创数据库的迁移工具都会全力以赴去适配某些 DB ，尤其是 Oracle 。迁移都做不好怎么去替代呢？

@PopRain
强制要求全部应用系统使用 ORACLE 模式是客户方数据库中心定的开发规范，类似的规定还有禁止使用 Procedure 等。
迁移到新的数据库，就要从头树立新的、良好的开发规范。不然以后随着业务迭代，留下来的屎山就又收不住了，比如 MySQL 的 UTF8 和 UTF8mb4

@codingmiao
自主可控，意味着“代码 100%纯自研”，意味着名义上“不借助任何的开源项目实现”，既然我名义上都不用它的代码了，我当然不需要遵守它的 GPL 协议

信创客户都是国产企业，都是国内自产自销，私有化部署的全是银行这种高度隔离的大客户，其它客户只能用云上服务和云底座，很难接触到数据库二进制程序。用户群够小，出了舆情精准定位和处理非常轻松，谁会因为所谓的开源正义丢了自己饭碗呢？

而且真有人能把这整个数据库系统的代码或者二进制文件偷去给国际的开源警察审查，他首先会吃到国安+法务的组合拳，这可是正儿八经的泄敌

再说了，国内目前处于蛮荒的开源环境，不遵守协议，他又奈我何？……

@sun1991
源库里`''`是有效的非空值，比如 DB2 、SQL Server ，但客户方统一规定信创数据库使用 Oracle 兼容模式，即`''`等价`NULL`。
预期当中，这个库里的数据应该根本导入不了信创数据库的，在导入过程就应该触发违反非空约束。

再补充一个很难绷的事情 差点忘记了
6. 这个数据库一开始大肆宣传建设开源共创社区，发行了一个开源版，还煞有介事地搞了一系列的培训和认证体系。本质上是因为要遵守 GPL 协议必须开源，开源版的发行基线基本上是比商用版落后 1-2 个大版本。
最近这个数据库艰难地完成了 100%国产自主可控的认证，代表着对于工信部，它所有的代码都是自己的，因此也不再有遵循 GPL 协议的需要，后续开源版将会直接放弃。

小海豚 6530 、CM6-R 、镁光 7500 、大普微 R5101 这种 1.92T 的读密集型盘足矣，他们就是为了这种负载设计的

@OliverLee 带宽受公有云是的 Hub 限制，而国内云服务带宽费是最贵的，so……这玩意儿更像是一个带路由的公网中转

Update:
今天的紧急固件已经修复了显示温度过高的问题
但坏消息是，更新之后通过 lm-sensors 对比显示温度过低了

@yoiteshaw
没办法，毕竟绿联的宣发力度非常大，总有被蒙蔽的人
要不是联想和海康威视稳定垫底，绿联从以前到现在都是最烂的那个，压根没法比
UGOS 这边老系统缺功能更新停滞半个月，新系统连基本的稳定性都没有

联通的光猫现在后台每半小时更新一次随机密码，跟所在片区运维小哥搞好关系，每次要查的时候找他

有点 off topic ，但是想分享一下微博 PC 端的显示逻辑

微博自始至终只有出现在屏幕的几张卡片渲染，当滚动时，重复：移出屏幕外的卡片销毁-渲染进入屏幕范围内的卡片，这一流程

但如果有去广告插件，一些广告的 Dom 被屏蔽/删除之后，会导致相邻卡片的高度计算错误，从而经常导致某些地方的微博卡片错位或者重合

既然微博能够实现这种用法，就代表你所设想的这个类似&简化的逻辑必然能够实现