那件事我到现在都没看到有多少靠谱的证据，最初是说西数蓝，然后说 SN750/500/550 也有（ SN550 我觉得纯属瞎编，上市不到一年的型号怎么会有冷数据的问题）现在地图炮都打到所有东芝 3D TLC NAND 上了，我一脸问号。

建议买企业盘是不现实的，你要求个保险就买三星吧。反正掉速这个问题还是等实锤状态。

感觉 RK3399 的两个 A72 大核用在软路由上有点浪费。也就两个 USB3.0 让它稍微适合做文件服务器，或者做影音盒子也不错。没这需求感觉用 RK3328 的 R2S 更节省成本。

@Neojoke
内核适配主要指外设驱动的支持，不过这些跟 ARM ISA 没有直接关联。还有一些是 ARM SoC 经常用到但实现是架构无关的功能（例如异构多核支持、调频的 cpufreq governor ）。
至于高性能方面更多是 userland 还有跟驱动配套的 library 的事情，例如在计算库和编译器使用特定的 SIMD 指令优化等。

而消费用户接触到的大部分应用都不是计算密集的应用，这类程序只要能跑就行，如果开源的话基本就是修改一下 toolchain 就能跑起来，但想性能更好就无可避免地引入一些架构相关的改动。如果应用是把这部分外包给 library 去实现的那就可以通过升级依赖来获得性能改进了。

能不能离开，取决于你有没有做好准备。你要是一根筋把自己 lock down 在一个厂商上，没人救得了你。
我同时使用支付宝和微信支付，也有银联卡，随身带现金。
你要是就带了个手机就出门，那就是你自己选择承担 lock down 在手机支付的风险，并享受带来的便利。
能算上 Too Big To Fail 的私企，我只在金融行业见过。

因为任何的计算芯片，厂商至少都会做一个 C 编译器给用户用（连 AMD GCN 这种 GPU 都有），不然芯片没有人能用，别的语言可不保证这点。
虽然这并不能保证 C 的程序可以零成本移植（写 OS 绕不开少量平台特定的汇编，没有 C 标准库支持）

华硕这些旧主板可以用 AI Suite 的文件验证漏洞绕过检查，就是选文件用原版，开刷前把文件原地换掉。

我只用过 Win-RAID 的方案，在技嘉 H61 和华硕 B85 试过都没问题，都是基于官网最新 BIOS 。
如果你是用 MMTool 进行插入的，试试换用 UEFITool 。
关于插入位置我都是按原始教程要求插在 Volume 末尾的，也见过有别的地方建议插在 CSMCORE 后面，你可以两种都试试。
另外务必反复验证文件修改和 Flash 烧写是否完整无误，后者很容易出问题，我都是写完重新读一篇验证 hash 的。

还有为了避免 CSM 的奇怪问题，建议用纯 UEFI 模式（ UEFI 引导，关闭 CSM，需要支持 GOP 的显卡）

还有一些我觉得可以碰运气的方法，Win-RAID 还有个 UEFI BIOS Updater(UBU)可以升级 iRST/Sata 固件，你可以试试用这个升级一下，注意保持大版本不变（ Z77 应该是 12.X ）

没用过多少，不好给意见。
扩展坞如果想防坑就避免串接电源（电源--扩展坞--笔记本），这使我想到的为数不多如果测试不完善有可能损坏硬件的 use case，因为这个涉及供电角色切换的问题。反正小新 pro 有两个 typeC
京造也是公模贴牌，个人感觉更不靠谱，除非跳楼价可以让你忽略这点。

@handylive 国内版和国际版公用用户 profile 的，卸载时注意不要清除数据就行。自动填充可以登 firefox 账户同步（安全性自行衡量）

那玩意直接忽略就好，就当是豫州背景辐射。
反正我是封掉密码登录的。
你要自信地相信 OpenSSH 是目前最注重安全性的开源软件。

一般买国行是贪便宜，后续用法是只玩单机卡带以及少得可怜的国行游戏，顺便有保修，或者加芯片玩盗版，纯白嫖游戏，不使用任何联机功能。
我有个同学就是这么干的。

像我这种蹲个打骨折的是等于只玩落伍游戏了。
基本上只有年货会有落伍这个问题，例如现在玩 F1 2011 这样。

建议用淘汰的 PC 串流（要求支持 NVDEC ）,树莓派的网络性能和 GPU 性能估计跟不上。
盒子的话只建议用在 2k 分辨率。
PC steam 内建的串流不知道能不能支撑 4k 。
另一个方案是无损级别的 Windows RDP

国内版好像会用 TX 的数据。
换国际版并删除国内版预装的所有扩展。

@S179276SP 如果是没法跳转 APP 的话会不会是因为没开银行 APP 的自启动权限？

@sjmcefc2 如果找不到这个类型，点一下“新建分区表”，如果还是没有，说明你不是以 UEFI 引导安装 u 盘。
安装 u 盘建议格式化为 fat32，然后把 iso 镜像里的文件拖进去，这样做出来的安装盘只支持 uefi 引导。

至于桥接至同一个物理网卡(lower device)的多个虚拟网卡（ upper device ）能不能互通的问题，取决于工作模式。

参考自这篇博文（ https://suhu0426.github.io/Web/Presentation/20150120/index.html ）

VEPA 模式下 upper device 的帧会通过 lower device 发送出去，如果要折返（也就是 VM 间通信），需要外部 switch 或者 router 转发，除非 lower device 支持 hairpin mode 。

如果是 bridge 模式，Host 的网络栈会转发 upper device 间通信的帧而不会到达 lower device，通常都是用这个模式。

@cxh116
确实我搞错了，没有用 PROMISC 。
冲突的定义我查了下是采用共享介质通信时通过 CSMA/CD 避免同一介质下的两个 NIC 同时使用介质发送数据。
这玩意只有物理介质（双绞线、同轴电缆）时需要吧，虚拟网卡和网桥只是内核中的数据结构，不需要处理这些 PHY 层才存在的问题吧。
例如两个 VM 通过虚拟网桥使用同一个物理网卡发包，Host 内核网络栈处理完这两个帧之后再插入物理网卡的 TX Queue 中，物理网卡的处理器并不知道这些帧是从哪来的，只是按照 Queue 的顺序发送出去罢了。

虚拟机用的虚拟网卡默认是 macvtap+bridge，Host 内核用 CPU 处理包交换的事务，物理网卡工作在混杂模式。
如果是用 NAT 转发，Host 内核同样要使用 CPU 介入 NAT 事务，不过物理网卡就不需要混杂模式了。
如果想提高性能，可以用网卡的 SR-IOV，需要 Guest 安装专用 VF 驱动，网卡自行处理交换事务，CPU 基本不介入。