jim9606

都有众包了，质量下滑是明摆着的事

@seers
大页的好处是提高 TLB 命中率和减小页表，坏处是可能加剧伪共享和碎片内存浪费（这会导致某些假定 4K 页的多线程优化变成负优化），是个有 tradeoff 的选择

@Venjer
这跟迁移 64 位不太一样，现在迁移 64 位态度强硬是因为上游 ARM 的新公版 IP 核去掉了 AArch32 支持，在这之前迁移态度并不强硬，所以不算是 google 自己决定的，虽然肯定是跟 ARM 在 roadmap 上通过气。而这个 16K 页并不需要硬件支持，纯是 google 自己决定了。
国内迁个 arm64 都那么费劲，别说这种不影响可用性的调整了。

毕竟是说过只有无产阶级才需要快充的神论的人

@NewYear
好写代码可以是指人好招好培训，你觉得招个 c++客户端程序和 web 前端程序哪个更容易。
真要偷懒只写一遍那就把移动版的界面拉长硬搬到桌面上，我们一般称这种为暴力移植。
你说的那些新版的问题就是迁移成本。
自己小打小闹肯定考虑开源方案做基础吧，反正你也不可能有精力自己写一套 UI 轮子，就算有，大概率不如现成的好用。这跟 QQ 当年的行业情况不一样，那时自造轮子算是基础需求。

QQNT 的大一统是为了桌面平台的大一统，可以方便支持各种国产 linux 和 WoA ，老 QQ 原本深度耦合 MFC ，后逐步迁移到自研 Hummer 框架，跨平台不那么容易。
至于手机桌面统一路线那就不见得很有必要了，毕竟交互 UI 啥的本来就要写两套的，强行统一并不能减少维护量还要付不小的迁移代价。
这跟生于移动端的平台不一样，后有桌面端的应用会选择尽量沿用移动端的路线，一是从零开始不存在迁移成本之说，而且沿用路线可以直接调原有的人力和流程去做，不用费劲重新组团队。
实际上 QQNT 相比老版的好处还没体现出来，虽然我个人偏好这个新架构客户端，但不否认其性能和功能在短期内都不会超过老版，我也没少听人嫌弃这个新版。

本来就觉得服务器加密没什么意思，将存储和加密密钥分开两个库存放只有内控上的意义，例如一个库被拖了不会泄漏数据。
面向 C 端的用途想用加密替代实现认证功能基本不可行。

我觉得 WebDAV 最容易优化。
考虑通过 WebDAV 下载大量文件相当于大量 GET 请求，那就可以用上 HTTP 的那些优化技巧，例如 stream multiplexing 。这个甚至不涉及协议定义，看客户端有没有实现而已。
FTP 是一个有状态协议，所以搞并发要靠多连接了，而且要把数据连接和控制连接复用一下。
按微软说法，SMB over QUIC 是会用上 QUIC 的并行、拥塞控制和丢失恢复的，所以看 smb 核心协议有没有充分利用了。不过看文档 SMB over QUIC 好像没法在非域控环境下使用。

你把 myhome.itismydomain.guru 设成 dns 后缀了吧？然后标准 dns 解析没回应就会尝试拼接 dns 后缀
组策略-管理模板-网络-DNS 客户端有一个“允许将 DNS 后缀附加到非限定性多标签域名进行查询”，看看管不管用？