@wangyapu 因为对于这类 HTTP 客户端库，如果你直接用解析出来的 IP 构造 URL 传给这种库的话它就会在 Host 头和 SNI 扩展头里填 IP 而不是域名。所以才需要定制 SocketFactory 或者替换 Vertifier 。

如果你是直接用 TLS Socket 或者 TCP Socket 并自己实现 HTTP 客户端逻辑，就可以根据上面的要求调整。

nginx 并不知道客户端用何种方式得到服务器的 IP 地址的，可以是 DNS 也可以是 DoH 。

HTTP 请求的 Host 头会包含域名，HTTPS 会包含 SNI 扩展指定域名，nginx 是认这个的。

这玩意你可以类比为国内不让用微信。

是不是没微信就联系不上人了？那肯定不是，IM 软件多得是。但你要说对现状有没有影响？很大影响。在我看来很多仅仅靠浏览器就能解决的应用需求就强行跟微信绑死了，例如各种行政和事业单位用的公众号和小程序。你说他们跟做成完全不依赖微信的 Web APP 行不行？当然可以，但懒得搞。

GMS 在海外的现状也是类似，很多 APP 已经事实绑死 GMS 了（推送、分发、付费、广告、同步、DRM ），要说动 APP 厂商搞个脱钩版本可不容易。

OpenGapps 是为了解决非认证设备装 GMS 需求才弄出来的，严格来说它的分发方式是违反 EULA 了，所以被 github 封杀过。不过这个项目就是变相推广 GMS 了。Google 之所以需要明面上反对这种行为，是因为通过认证授权，Google 可以维持对硬件厂商的话语权。

事实上，国行机能在不 root 和解锁 BL 的前提下装上 GMS 核心组件因为国行 ROM 给开了后门以满足 GMS 的特权需求。因为直接预装是侵权 Google 的，所以得用这种方式曲线救国。

不是很清楚这种 DAS 设备的可靠性。

这玩意得接到某个主机才能用啊，能不能手机访问看你在主机上跑啥共享服务，SMB 、FTP 、WebDAV 都可以。

如果真要搞，用这个也不是不行，建议不要使用任何硬件 RAID，只使用软件阵列的方案，例如 ZFS 、LVM 、Windows Storage Space 。

你火星了吧，早就放了。
只是放弃了刑事诉讼而已，民事诉讼继续有。
说起来 Rambler 这招也是挺耍赖的。

@programV2 SATA SSD 的硬盘盒要求比较低，有 USB3.0 和 TRIM 支持就够了，主流就 VL716 和 ASM1153e 这两个芯片的方案，看外观和价格选就是了，靠谱的方案都会说用啥芯片的。

这篇文章有一个问题，通常情况下为了缩小最终镜像体积，会使用多阶段构建，临时容器中编译二进制库后复制进最终运行镜像中，可以除去占用大量空间的编译依赖、源码、中间产物。

alpine 更多的问题还是在 musl 上，要是用到了针对 glibc 编译的闭源库就没法用，以及 c 库的一些行为差异。

你说的这种应用部署模式已经有了，就是 snap/flatpak,不过主要是大型 GUI 软件在用，开源软件用得少。
非图形应用有比较重量的 docker 用来解决依赖隔离问题。

主要是 linux 默认使用共享库的模式使得单独升级比较麻烦，你完全可以将你想用的软件及其依赖的 deb/rpm 包全拉下来，这样就可以离线安装了。因此如果不怎么用发行版外的软件，全发行版升级有可能是更好的选择。

理论上 windows 应用也有不少共享库的，例如 Visual C++ Redist 和.Net Framework，不过分发程序多数还是选择自带依赖的模式。

不买游戏本的不用太考虑这个问题,轻薄本顶多等等 11 代。
游戏本的话至少得等半年，自行判断等不等得起。

论平台保障力度（注意不代表商品可靠程度）：京东自营售后>京东自营送货>淘宝商家>天猫商家>京东第三方>PDD 百亿补贴。
通常不是为了 PLUS 会员券我都不太愿意买京东第三方。

你要是之前完全没碰过 linux 的还是老实用虚拟机玩着吧。玩熟再上 DualBoot

DualBoot 很常见的问题有两个：内核驱动和引导器配置

1. Linux 对某些硬件的驱动支持不如 Windows 完善，虚拟机不会有这个问题。例如 AMD Renoir 推荐用 5.8 以上的内核及最新固件，基本上只有滚动发行版能在包管理器提供这么新的内核，还有老生常谈的 N 卡驱动、博通网卡驱动

2. 有些机子的 UEFI 实现比较奇葩，会莫名其妙认不出 Grub2，例如某些老款 Acer 必须在 BIOS 设置里手动添加 efi 文件作为启动项。Intel NUC 的 Visual BIOS 也会有类似问题。

你的手机是在线下渠道买的吗？是的话首先怀疑是不是桌面程序被替换了。我遇到过这种套路的。

然后可以通过锁屏显示权限和浮窗权限检查其他 APP 。

不转码是不可能的，加字幕那种纯属骗自己。

虽然说 ffmpeg 可以用 A 卡的 VCE 加速编码，但据说 H.264 编码质量特别烂，不建议用。

考虑下用 ffmpeg x264/x265 medium 预设，或者搞块 GTX1660 以上的 N 卡(注意不能用 1650 或者 10 系)用 NVENC 编码，据说两者质量相近。3950X 已经算是强悍的编码 CPU 了。

@maopian @Yut

更新内核到 5.8 以上并安装最新的 linux-firmware,可以去 packages.ubuntu.com 下载 eoan 使用的 1.190 版 deb 包。
实测升级后无需调整 cmdline 即可使用背光调节

根据 changelog，kernel 5.8 有不少 Renoir 的新驱动，看来至少要这个版本。
顺带解决 RTL8822CE 的 bug，实测蛮有效的。当然你也可以选择自己换 AX200 。

关于这次次性能增长的问题，目前只是 PPT 发布，实测表现得等开卖后才知道（通常也是 NDA 解禁时间），NV 自己吹有这水平但不见得就是真的，NV 不是没吹过头的历史。

不过在接近新卡发布的时机买高端卡本身就不太明智，买甜品卡都还好，当然你要是急着用也没办法，愿意等的前提是你能等。

至于给面子的问题，由于 NV 强大的市场把控能力，老卡能原价退市甚至涨价退市已经是对你很仁慈了，换 A 卡那种跳水，别说入国军的，手里有库存的经销商更想骂娘。

我觉得还是 StackOverflow 更容易遇到吧，现代 OS 的栈功能实现时需要硬件支持的，而空间大小有限制，通常只有几 MB，而最容易导致溢出的方法是递归调用。要撑爆堆空间得大片申请内存，不太容易因为误操作引发这个问题，通常得是长期运行的程序。

虽然说线缆成本低，但是端点设备成本高，现在之所以没这感觉是因为我们习惯捡拆机网卡。不过你可以两种线都留着。

对于未来也没有高带宽（>5Gbps ）需求的设备，例如电视盒子，还是建议 Cat6 UTP 网线来满足 NBase-T 的需要。

AP 我觉得也不太适合上光纤，光纤没有 PoE 能力，目前 Wifi6 在 2x2 MIMO 的上限都达不到 2.5Gbps，还是 UTP 比较合适。

无论哪种方式的二维码支付，都要求其中一方要联网，在网络覆盖不好的地方是个问题，而且速度不如 NFC 。大城市良好的网络覆盖让很多人忘记的这个问题。

我印象里上海地铁推扫码乘车时拖延了不短的时间就是流程耗时不好优化。教育用户也是个问题。