你还不如考虑 Windows 10+组策略+标准账户+火绒。去掉管理员帐户就能拦住不少软件了。
顺便装个向日葵方便远程排障。

我倒是不担心苹果在这套扫描系统上运用密码技术进行保护的完备性。要是不完备，Apple 也不会那么详细地把运作机制抖出来了。看这方面的分析还挺长见识的。

我就是担心这个 NGO 提供的数据库，这玩意既不在 Apple 掌控下又不能通过公共途径进行监督和审查。简而言之，为啥我要把判断的准绳交给一个 NGO 而不是行政机关呢。

还有个问题是 NeuralHash 的 false positive 该怎么控制，这个我也没谱。

我觉得主要是为了方便将 C/C++的应用搬进浏览器里，顺便做一些需要高性能但只需要 cpu 就能做的事。

我目前觉得合理的用途是跑 ffmpeg 做一些 MediaSource Extensions 不支持的转码转封装操作，还有实现浏览器未支持的图片 /音频解码渲染,例如在 Chromium 上解码 HEIC 。

@kakukaiki 锂电池可能有钴、铅等重金属，而且锂电池破损有导致自燃和爆炸的风险，算有害垃圾没啥毛病。

如果明确有“有害垃圾”分类的市政垃圾桶，直接扔那就行。

@leavic 回收机构不可能对一般用户收费处理废电池的，也就工厂大量产出的有害废料做处理有可能要收费。

你这个例子只有新增文件，大小区别基本没有，只有包含删除文件的操作才能体现区别。
如果你这里的增加到下载、解压、编译、安装步骤，那么后面把源码和中间产物删掉才能体现区别。
我个人并不喜欢将这几个步骤合并，因为 build 镜像时没法保留中间结果，导致每次出错重试都得重下源码。我倾向于用多阶段构建（ Dockerfile 包含多个 FROM ）

存个图片的话还是用网盘吧，除非你的分享对象都在一个局域网里，否则自建的速度还真不见得高，家宽的上传带宽一般就那样。

我是不愿意这么干的，如果认为这事排版引擎的缺陷，那应该让引擎去解决，而不是让难以教育的用户群体自己打补丁。就算用户配合，先不说用浏览器插件了，手机上咋办？语音输入的咋办？触摸键盘不支持咋办？

我写毕业论文都没有这种要求。

如果一个网站认为空格（包括中英混合标点、多字体）应该遵循一个强制性规范，那就在后台加过滤器去处理，而不是让用户自律。

Let's Encrypt 老早就支持通配符证书了啊。
你要不要找个集成 ACME 支持的 Web 服务器做反代，例如 caddy ？

谁叫 type-c 晚那么一点才问世呢。
至少现在 type-c 还没有体现出远超 lightning 的优势，木已成舟就缺乏理由换掉了。apple 还可以靠这个收授权费呢，等于顺带对周边做品控了。

狂热果粉的观点也可以参考一下 ( https://www.bilibili.com/video/BV1mq4y177pN )不统一这事在果粉眼里叫优势。

这些云服务针对特定版本做了大量的魔改和优化才做成公开卖的 serverless 产品，而基线是立项时就定下来了，内部开发的很长时间才能拿出来商用，对于迭代比较快的技术，一出来就过气实属正常。

如果这种云服务追版本很快，那通常是厂商在上游有话语权，或者干脆就是上游主要维护者，可以对上游开发路线进行干涉。

淘汰是不可能的，xml 都还活得好好的。注释的话 json5 是无痛解决方案，顺带解决手撸 json 总少了引号逗号导致出错的烦恼。

json 好就好在稍微新点的编程语言都直接在标准库包含 json 实现了，省去外部依赖的麻烦。

专门做投屏方案的公司。主要好处是全平台通杀，AirPlay+DLNA+Miracast+私有协议都有。MIUI 手机投屏直接集成了乐播的方案，可以走局域网而不是用质量超烂的 Miracast 。

无线投屏就没哪家做得好的，可能是业界不看好吧。乐播在我看来是在 Android 这边比较接近及格线的方案。

另外 Android10 之前没有内录音频的 API，必须 root，所以之前想让投屏有实用意义必须依赖系统内建的投屏方案。

这个投屏还是不适合高画质或者低延迟的用途，有线方案（ MHL 或者 Type-C DP Alt Mode ）是最佳选择，但又不是什么中端机型都支持，厂商经常不标注。5 年前想要有线投屏的买索尼是最省事的方法。

DoH 并不能防止国内的 DNS 服务器被污染，DNSSEC 才能做到这点。
何况你全配了国内的服务器。

@titanium98118 主要是安全问题吧，这种小型基站可以集中管理，整个电话网络链路都是运营商控制的设备，也不用怕外部设备攻击或者影响服务质量。

这算是白嫖了个手机信号放大器了。没想到国内居然有这种进户的微基站业务。运营商用同一个接入网解决宽带、固话和蜂窝网络问题不大，光纤到户带宽管够。

以前我就想过由于 5G 的频段高不好搞覆盖，可不可以将小功率基站集成到家庭网关上，用来解决室内信号覆盖问题。个人感觉主要麻烦是信道规划比较麻烦。

@kaedea
升级安装会检查 apk 签名是否一致，能装上就行，顶多就是同一开发者不同分发渠道，通常设计上都不会有问题。楼主遇到的是 App Bundles 相关的问题。

@fishrimp
虽然 apkmirror 说会人工审核，但并因为都是用户上传，没法可靠地标注来源，所以建议下载之前现在 play 市场查一下上架的最新版本，例如现在查到是 8.0.2 那就只下 8.0.2 。

这里我之所以选的不是 versioncode 最大的 1860 而是采用 bundles 格式的 1852 是因为我手工检查过几个支持 arm64 的版本的内部情况，只有我发的那个版本符合“单一 ABI”+“未压缩原生库”这两个要求。我也不明白为啥单一 ABI 的包还要压缩来浪费安装空间，连 Google 自家产品都没统一这点。

只是一种猜测。

国外大厂商例如 MS 和 Google 是因为 TOTP 只是其中一种可选的 2FA 手段，其他 2FA 手段有电子邮箱、手机验证码、硬件密钥等。其中电子邮箱、手机验证码会暴露部分隐私信息，所以需要先行验证 PIN 才能暴露这部分信息。

国内的话也会在输密码之后进行一个黑箱的风控检查，用以决定是否需要进行额外身份验证。另外不知道是不是觉得用户教育不足，对 TOTP 的信任度还不如常用设备验证。