你不如问问运维用的 VMM 可不可以开启嵌套虚拟化，或者要裸金属的机器。
VT 通常都是要求打开而不是要求关闭的。

应该是可以的
按文档说法，新平台透过 VMD 支持，旧平台透过 RST RAID 支持，主要是注意装系统要预载驱动。
冥王峡谷的版本是 RST 16.x ，只能用 RAID 模式。
不过就算不支持也不妨碍当成两个盘用。

找一台干净手机或者 pc 转移聊天记录，去掉图片和水群，然后清空数据，再转移回来。

apt 主要是发行版帮你测试好兼容性问题，所以一般是

1. 用最新版本的发行版，例如非 LTS 的 Ubuntu 然后半年升一次级
2. 找软件厂商针对发行版维护的软件源，通常只支持 LTS 版本，这种更新速度最快，但只有热门 linux 软件有
3. snap/flatpack 打包的版本
4. 用 Arch 之类滚动发行版系统

@zhng920823 有可能，非商用系统可能没有正确实现固件保护。
至于固件防盗，例如 Intel Anti-Theft ，还有 Dell 电脑常见的 Absolute Computrace 。
这个东西需要针对 OS 设计，拿 Computrace 来说，启用后会劫持 windows 启动流程，在系统写入 rpc 服务，在完成启动后带起 rpc 服务联网通信。显然这些步骤都假定是 win 系统了。

想研究我建议硬盘拆出来镜像后研究，不过现在有 fileless 的木马不好找。
别想着修复环境，老实格盘重建。

-hwaccel 只影响解码是否使用硬件，不影响编码。

你如果没有指定编码参数（例如 x264/x265 的 crf/bitrate/qp/preset ）会有一套比较快但质量一般的参数，例如 x264 默认用 medium preset 。软件编码器上一般存档和流通用途的话推荐 crf 模式，preset 追求质量一般以 slow 为标杆，具体 crf 数值看 ffmpeg wiki 或者编码器的文档，有推荐经验值。

硬件编码器也有类似 preset 的选择，通常都很快，例如 NVIDIA 宣称 Turing 架构的 h.264 nvenc high quality preset 可以达到 libx264 medium preset 的水平。除非直播，一般尽量用最高质量的 preset

ffmpeg -h encoder=编码器名 可以查询可用参数

评测编码质量是个比较麻烦的事，一般是比 psnr/ssim/vmaf 分数，比较少媒体测这个。

参考 Android 的通知特性：
https://developer.android.com/develop/ui/views/notifications?hl=zh-cn

检查你的应用 target api 是不是>=26(8.0)，至少你说的淘宝京东美团都可以下 Google Play 版本，都符合要求，都已适配通知渠道。

通常禁用运营消息+一看就不顺眼的类别就行。

我也没遇到能突破系统通知限制的情况，该不会...你的手机系统有内鬼吧？

看你的 cpu 算力值不值钱。
静态 web 服务器，可以考虑 gzip ，因为有些 web 服务器支持预压缩文件，省空间还省算力，理论上 brotli 也可以
需要经常随机读写的数据不适合压缩。
高熵数据，例如已编码的视频图片，再压缩基本没意义。
文件系统级压缩(zfs,btrfs)提供最省事的迁移方法，但依然要拿一点点 cpu 性能来换。

1. 家用路由器默认阻止入站请求的，有些还不能关的
2. 由于政策要求，蜂窝网络的 ipv6 通常都有可用保障，不好的是到应用服务器的全链路网优，常见表现就是能连但是慢，这个只能等时间来改变了
3. 如果有多级路由，可能会出现前缀委派错误或者（由于重拨号导致）前缀过期不会续期等问题，我现在用的 openwrt 路由都没整明白怎么解决这个

我不知道你是在哪看病的。
国内是出过整治滥用输液的，有医生原因也有患者求快的原因，所以有些医院（至少我去过的三甲）儿童如果打算静脉输液治疗的还会让签告知书的，要能口服的能不输液就不输液。
如果是抗生素啥的还算正常，要质疑的是神 TM 的中药注射液。

按我理解，要么分开运营，要么要求提交实名资料，有点像 X 和 fb 账号申诉的资料。
而且非要杠的话，国内只要一个手机号也可以说不合规的，因为手机号可以不被视为真实身份信息。

准备涨了，清库存不是一直持续的

有些主板可以选择是 bios 还是 os 管理唤醒事件，选 bios 通常就能网络唤醒了。
同楼上的，深度节能 DeepS4/ErP/CEC Ready 要关掉

我知道的一些差异：
1. Windows 支持有状态 DHCPv6 ，但 Android 不支持；如果路由器设置不当，可能导致一方有 v6 另一方无 v6 的情况
2. DNS 相应有问题，部分 APP 自带替代 DNS 解析方案，PC 上通常不会动用类似机制（ chrome 就会拿 8.8.8.8 当备用，不知道能不能用组策略禁用）
3. 推送机制，例如手机上使用的推送机制相对被动一些
4. Windows 的启发式 TCP 流控比较怂，这个没实证过
5. 机场的话多数是客户端差异，PC 可能不会使用 TUN 模式接入，手机基本只能用 TUN

举些我认为新 target 比较重要的影响：
9：异形屏 API ，HEIF ，限制后台访问传感器
10：TLS1.3 ，模糊定位，分区存储，封杀不可重置硬件标识符，剪贴板访问限制，可折叠设备 API ，深色系统主题，AV1 ，Vulkan1.1 ，音频内录
11：强制分区存储，v3 签名密钥轮替，软件包可见性，自动重置权限
12：通知栏隐私指示器，兼容的媒体转码，AVIF
13：照片选择器，附近设备权限，BLE 音频，各应用语言偏好
14：限制 6.0 以下旧应用安装

其实 google 最近有点挤牙膏，重要的都在 10

如果是同一个 app 内外 target 不一样，那有一种可能，就是国内商店渠道自己的 sdk 还没适配新 target 。

我目前被这个 target 气死的只有宇宙行手机网银，因为 android10 把 imei 一刀切 ban 了，每次打开 app 都是新设备登录要短信+人脸。

事实上 AOSP 版本更新值得关注的都是针对开发者的行为变更，这会悄无声息地影响包括国内的 android 生态，但我是没见哪个自媒体能看懂这点的，就只会评 UI 和 GMS 集成。

针对 mime 类型进行分流需要 mitm ，还要处理 302 重定向等问题，实现比较复杂。
大部分流媒体网站的媒体分发都是有专用域名的，跟主站和 api 域名不相同，所以按域名分流通常就够了。

反正是 google 自己做 vendor ，AOSP 的最低要求也是自己定的，倒是没啥问题。不像用高通，没有上游支持下游也没法续命。
只是 google tensor 的性能比较拉，别说 7 年，5 年后的可用性都要打个问号。