一般就是用在 tls 证书上，不少网络应用形式上要有一个域名。
不过我是选择每年换一个 8 块钱域名。

1. docker 算是多数时候最接近一键安装的方法
2. 需要用在一些限制很多的宿主 os 里，例如 nas openwrt 之类的，不一定有人帮忙搞定打包的事
3. qb 本身不是很健壮，用 base 镜像运行可以减少很多攻击面
4. 好像最近一段时间才开始有官方的 nox 版本，还是链接 musl 的，理论上省点资源，这个 config 的二进制的最简单获取方法就是用 docker ，否则基本要自己 build
5.docker bind mount 可以很简单地解决迁移目录问题

你这种案例不是 SIM PIN 的防护目的，那是防手机被盗的，如果你家人知道这个 PIN 是啥那也防不住。
本质上你是希望家人手机上有一个只有你能解她不能解的锁。

钉不钉得了要看历史的进程的
如果未来几年高通的旗舰都拉了，那就可以钉。
不过预测未来研发进展这事哪有那么容易。

1.有些软件习惯不太好，被 explorer 冷启动时会使用继承的工作目录，导致只要进程不关工作目录就是被占用状态
2.被内核程序占用是查不出来的(powertoys 可能显示 system 占用)，例如挂载了 vhd 之类的，或者被杀毒软件后台扫描 filter 占用。
3. 上面的情况只要确认没写入活动，直接拔对 ntfs 问题不大，不像没日志的 FAT 那样危险，磁盘管理里脱机也是种办法
4. 自动挂盘符怀疑是分区类型设置问题，MBR 下的 NTFS 是 07h,17h 是隐藏的。也有可能你把 win 的自动挂载关了

你不如说下为啥需要回锁吧？
据我了解就算是刷原版系统也是可以不回锁的

你又不考虑 AB 两边路由搞隧道把子网打通，就不要用同网段了。

edge 和 chrome 可以在 flags 实验开关里打开 parallel downloading ，至少中小型文件不再需要下载器出马了。
BT 类下载还是建议用下 qb 吧，虽然说现在公网 pcdn 刷流问题已经不容忽视了，但我还是不推荐无必要的 H&R

举个具体点的例子，目前 Google Play 要求所有更新及新增 APP 运用 App Bundles ，这项功能要求 Android5.0 ，因此目前几乎所有手机 APP 的 minAPI 都是 5.0 ，愿意提高要求的通常是游戏，因为有性能要求，愿意提高要求回避旧系统 broken 的问题，尽管不是非得这么干。
Google 提供 androidx 兼容库让一部分新系统特性可以在旧系统上使用，这使得如非必要，APP 并不愿意提升 minAPI ，所以我是有点不满为啥现在的 app 还总要带 libwebp 、ffmpeg 、openssl 、cronnet 撑大 app ，系统库有那么难用吗？
ios 好像没这种第一方 backport 的库，强制升级的 xcode 经常忽略老系统的兼容问题。

因为 iphone 用户很难坚守在旧版本，那个更新弹窗一天弹好几次，一点错就回不去了。
app store 对工具链要求极高，那怕这并不是必须。与此相对，google play 尽管要求更新 app 必须使用近一年发布的 target,但并不限制工具链，你用十几年前的工具链都可以。
android 这边很难升版本，想升都不容易。

felica 比较麻烦，毕竟霓虹特色，估计只有日版机器有支持的可能。
国内交通卡如果坚持不用各家的二维码方案的话可以考虑下移动的超级 SIM ，也支持门卡复制。不过这玩意的提供商有点奇葩，不一定能开到归属地的交通卡从而用不了地方票价优惠。nfc-sim 也需要手机支持，国行机通常可以，外行不保证。

startallback 是通过 hook 注入 explorer 实现的，严重依赖内部的实现细节，所以是没有兼容性保证的，可能一个小系统更新就会 break ，想稳定用要注意及时更新。
当然我知道你们只会骂 MS

我猜是 smartscreen 检查服务连接有问题。
如果你确定到微软的网络连接没问题，你可以试下在 internet 选项里，启用 TLS1.2 和 1.3 ，取消选择"检查服务器证书吊销状态"

忘说了我这是锁账号，要支付验证或者微信关联验证的那种，不过可以立即解锁。

我这没 root 的 miui14 也经常风控

如果你是用微软账号登录的，至少要在本地用账号密码(不是 PIN)登录过一次
远程登录可以尝试短账户名(c:\Users 下的目录名)或者 MicrosoftAccount\<邮箱>

你如果不纠结的话，你可以创一个略大于文件大小的 vhdx,格成 ntfs 并打开压缩，然后扔文件进去，然后开启 bitlocker 加密(仅已用空间)。
这个 vhdx 就是你想要的可以瞬间改密码的压缩包了，而且不用解压就能用。

ffmpeg 官方只发布源码，引用的第三方二进制分发仅仅是为了某些用户方便，官方不对这些二进制分发提供任何担保。ffmpeg 是以研究学习名义实现那些专利 codec 的，最终用户需要自行解决专利授权问题。

这样做的项目可不少，kernel.org 就是只分发源码的。
另外有一点，分发源码不受美国软件出口法规的限制，二进制可不行。

transmission 默认配置的 webui 和客户端功能太过精简，不过因此内存消耗小，理论上最适合服务器跑
qbitorrent 至少 UI 功能上追上 utorrent （这玩意自从某骗子收购后就不建议用了，你找到的建议都是用超远古版本，等于没维护），客户端基于 qt 打造至少不用太担心桌面 GUI 的适配，大部分 PT 站都允许用 qb

鉴于目前 PCDN 吸血客户端到处都是，但 PeerBanHelper 不支持 transmission ，我打算公网种全部转 qb 或者 BiglyBT

虽然 PBH 推荐 BiglyBT ，功能确实最复杂，但这玩意 java 写的还用来做 gui ，超吃内存，而且不少 PT 站禁用，只是有工具导入 ut 的任务我才考虑的。

理论上公网和 PT 全转 qb 最好管理，但我用的站有的禁用高版本 qb ，换言之怎么都要跑两个客户端。