对一般用户来说管理版本和测试各个版本太麻烦了，还是交给分发渠道用遥测和灰度推送解决吧。
但对开发者来说这算工作的一部分，觉得麻烦也得做，毕竟能赚钱，苦也比全部自己造轻松吧。
作为高级用户，我头疼的是发现 bug 的时候是降级还是升 beta/alpha 。降级（保留数据）在多数软件上是很难操作的，因为开发者基本不会对这个用例做很多测试，可能会扩大 bug ，甚至一刀切禁止这样做（手机系统）。因为这个我现在用着 Win11 Dev 。

另外提一嘴，语义化版本不能应对一些情况，我列举一些情况：
1. 新版本删除了几个过时 API ，反正已经很少人用了，或者有重大安全缺陷，那这种 API 不兼容变更一定要升 Major 吗？如果 API 兼容但 ABI 不兼容，那怎么办？
2. 升个 Major 真的意味着 API 不兼容吗？作者可能只是因为加了一个重大功能加了一组 API 而已，按理说升个 Minor 就行，但没存在感啊！
3. 联网软件功能很多都是靠云控或者热更新的，功能早就有了只是没激活而已，那版本号有用吗？

所以现在，对于功能未完善的软件（意味着不存在更好的旧版本），和功能架构已经完全稳定下来基本不会大改的软件（用哪个版本都差不多，新版加的都是可有可无的东西），会倾向用单一顺序主版本号或者基于日期的版本号。例如 Chromium 、systemd 、Windows （主要看 build 计数）。需要某个功能就设置个最低版本限制就是了。

utorrent 不是可以直接下磁力链吗？
也有些在线工具可以做转换,google 搜“magnet to torrent”就有很多结果了。

随机性获取资源不算啥新鲜事了。
国内课金抽卡启蒙者应该是扩散性 MA 吧，真实先帝。
国外现在有抽卡的那真是一抓一大把，免费付费的都有，。什么 CSGO/Dota/OW 开箱子饰品。
参考：
https://www.bilibili.com/video/BV19X4y1P7H8

@20160409
收费版 App Ops 功能合并到免费版里了，可以给作者发邮件换兑换码。

@20160409
因为“读取应用列表”（ QUERY_ALL_PACKAGES ）到目前为止都是常规权限，无需用户授权。所以按照 API 规范，APP 无需考虑读到空白数据或权限被拒的情况。作为魔改的一部分，默认授权是合理的。目前还有的属于魔改的权限还有读写剪贴板和媒体音量控制，都是默认放行，否则就是破坏兼容性。

这问题也没那么悲观，Target 为 Android 13(API30)的应用需要显式声明关注的软件包。
https://developer.android.com/training/package-visibility?hl=zh-cn

Google Play 已经有动作了。
https://support.google.com/googleplay/android-developer/answer/10158779?hl=zh-Hans

你用的是谁提供的 DNS ？运营商 DNS 不行的话试试用公共 DNS ？
另外这可能不能算 IPv6 的问题，因为 IPv4 的 DNS 一样会返回 IPv6 （ AAAA ）记录。你可能只是需要一个靠谱的公共 dns 服务器。

所以你的标题不应该是“显示器防窥膜是真的好用”？

Android 这边的问题是国内的商店不像 Google Play 那样激进地推动 SDK 和 TargetAPI 升级。系统这边最近几个版本算是有明显进步的，至少方向对了。

后台管控这方面反而是国行系统比较在行，原生和外行系统反而功力不足。

从 Android10 开始，大部分永久性标识符都不能读取了，无关 TargetAPI 。但非永久性标识符就没有标准化。例如启用隔离存储（ Target>=30 ）的应用有往 MediaStorage 放标识文件的（这个问题有望在 Android13 解决），ios 也有用 keychain 放标识符的。

你现在要担心的一些共通问题是：APP 可能利用电信运营商认证 SDK 的缺陷标识用户，以小程序宿主（微信支付宝）为基础滥用定位权限。这些问题在短期都不是系统厂商可以解决的问题。

Android 也有一些我认为的权限系统设计缺陷：1. wifi 和蓝牙扫描纳入精确定位权限中，直到 12 才分离出来，为此类 APP 提供了滥用定位的机会； 2. APP 或授权后可以读取所有媒体文件而不是通过系统图片选择器选择性提供，直到 13 才解决； 3. AOSP 的权限管理器菜单过深，改个授权要多点几次

il2cpp 出生的目的不是防反编译，而是解决 Mono VM 不好跨平台移植而生的，增大反编译难度只是副作用。
.NET 现在也有 AOT ，但能不能提供防反编译能力就不知道了，就像把 Java 编译成 JVM ByteCode 后反编译还是相对容易的。

@abersheeran
轻负载如果没有什么应用需求上的困难（例如铁了心要无风扇，功率 15W 以内），上 M1 没啥毛病。
M1(包括后面的增强版和胶水版)的很多还是上不了高功率，例如给你 65W 的功耗预算去跑，通用计算跑不过 x86 我是毫不意外的。拿 ASIC 刷分的部分。。。懂的都懂，能用上这个需要很多假设的。

@fengyaochen
我不是不相信 P 核 Golden Cove 的能效。
如果你对能效的描述属实，那 CPU 还要能做到自动降频降压才行，不能靠发烧友或者 OS 调整，对笔记本的话 OEM 得在固件里调好这个（看 OEM 研发水平，不好做评测）。而且这不就佐证 E 核就是拿来刷多核跑分吗？

目前 12 代关 E 核用 Win10 并没有太大问题。
发布前大家对 Win11 调度器的预想是：高性能模式时优先用 P 核，节能模式和待机限制只用 E 核，满载了才启用 P 核。然而实际测试的结果是：不管是高性能还是节能模式都是优先用 P 核，在多核任务重载时再启用 E 核提高多核性能。所以 Win11 这个调度器（我不知道这个锅是 Intel 还是 MS 来背）并不能实现大家预想的轻负载省电，而是方便刷跑分。
至于预想的那种策略好不好，我也不知道，有人说那种策略并不适合桌面用户使用。

这种很多企业网络管理解决方案都能做到的事吧，直接买方案就是了。
还有不要排斥 802.1x ，这是为数不多比较可靠又不需要装客户端实现接入主机认证的方案了，只靠 MAC 认证防不了克隆 MAC 这种低成本欺骗手段。

通过手续费阻止你的资产流出交易所。
注意交易所内的账户间交易是黑箱+中心化的，可能跟区块链毫无关系，账户所有权也不属于你，所以可以随时给你没收了。

apt update 时先下载总清单 InRelease ，这个清单是有 PGP 签名的,包含包清单 Packages.xz 的 hash 。而 Packages.xz 包含所有 deb 包的元数据和 hash 。所以只要 InRelease 通过 GPG 验证就可以保护整个软件源的完整性。
使用 HTTP 的话可以安全地通过 DNS 劫持实现透明缓存加速，这在容器中很好用。

实现这个也没多复杂，剪贴板工具一直监听剪贴板，发生变更事件就复制一份给自己，用户点击再进行逆向输出。所以通过 API 只能读最新一次的数据。

Android10 开始只有默认 IME 和焦点应用可以访问剪贴板，惯例是由 IME 实现历史记录，没什么问题。