@duke807
我说的完备可不是引用成熟的 AES 实现那么简单。密码原语基本都不是弱点。
PIN 要通过 salt 和 KDF 函数转换成 AES 使用的主密钥来提高暴力破解难度；需要认证（ AEAD ）来防篡改；流密码模式的 IV 怎么产生；主密钥多久替换一次；怎么做 padding ，如果明文片段可以被猜测，能不能抵抗选择明文攻击。

当然对于个人用途，这些都不做可能不是什么问题。

@424778940
我没说错。
我说需要 TPM （ TPM Protector ）的是操作系统驱动器的**自动解锁**，使用 recovery password （ Numerical Password Protector ）解锁的不属于自动解锁。本来恢复代码就是最高安全性的方法，增加其他 protector 都只是为了省去每次解锁都要输恢复代码的麻烦而已。恢复代码本身需要比 PIN 更严格的保密措施。企业环境可以仅创建唯一的 AD Protector ，避免员工拆硬盘在非域控主机上解锁驱动器盗取数据。

不可能在不掌握 recovery password 又不通过其他 protector 解锁的情况下，使用 Numerical Password Protector 解锁驱动器并获得 recovery password （这都是废话了）。如果楼主自己不知道 recovery password ，除非想办法恢复送修前的 PCR 使得 TPM Protector 可用，无法解锁。

如果通过组策略选择使用 TPM+PIN 联合，系统会创建另一个 TPM&PIN Protector 并删除 TPM Protector ，正如你所说的，两者是完全不同、相互独立的 protector 。接受 PIN 输入的不是 TPM 固件而是引导器 BOOTMGR （所以一定需要 Secure Boot 避免被篡改的 BOOTMGR 实现邪恶女仆攻击）。

@duke807
不是说 cryptsetup 不行，是用这个东西为基础做 Windows 那套基于 TPM 的无密码自动解锁太麻烦了，这套东西凑齐 SecureBoot(MOKManager)+shim+grub2+LUKS+TPM ，还要不能把内核更新、DKMS 模块搞崩。我都没心情实战操作一次。如果无所谓每次输 PIN 的话那确实够了。

且不说你这个轮子实现是不是完备吧（造密码学轮子极易犯错），“可否认性”是不符合的，“文件没有特征”也是特征，防不住五美刀扳手( https://xkcd.com/538/ )。 你还是得藏得够好没被搜出来。但你要是自信能藏好，那不加密也没事。

看你装在哪，自行安装一般放在 /usr/local 下面，默认的 ld.so.conf 里， /usr/local/lib 优先于 /usr/lib 。
你可以用 ldd 检查加载了哪个版本。
听不懂我在说啥的就先卸载自编译的版本。

怕这个的留一个本地密码库。只用云密码库的早晚要栽在云上。

@zddwj
忘了提一个。
Window 账户登录选项有一个“使用我的登录信息在更新后完成设置”，启用这个选项会导致用户会话在登录前就打开，并运行所有用户登录后会自动运行的程序和服务。可以将这个理解为系统帮你自动登录但把屏幕锁了。这个选项会扩大攻击面，不在意登录后后台忙一会的建议关闭此选项。

@zddwj 基本是的，TPM 自动解锁是通过 PCR （平台配置寄存器）验证实现的。典型配置下，自动解锁的唯一方法就是引导原系统，RE 和 U 盘 PE 都不能解锁。（参考 https://zhuanlan.zhihu.com/p/29840740 ）
系统启动后就是登录界面了，如果你有什么拥有管理员权限的程序在用户之前会运行，它们是泄密的弱点（还记得输入法提权漏洞吗，第三方输入法很容易引入这种问题）。否则，除了输密码，没法运行任何接触到恢复代码的命令。

售后能获得恢复代码的前提是能登进机器里的管理员账户（可以是本地账户也可以是微软账户），否则无法获得这个恢复代码。不想让售后接触数据就不要提供账户密码。从你的情况看售后已经是最低限度接触你的密码了，而且你完全可以要求你自行操作解锁机器。
如果你追求更高的安全性，可以在组策略选择对操作系统驱动器启用 PIN 或 PIN+TPM 联合保护，这个坏处就是每次开机 Bootloader 阶段要再输一次密码。

因为现在符合设备加密硬件要求的机器会在 OOBE 后自动启用加密，网上能搜到一堆因为解密不了对微软或者厂商破口大骂的帖子，售后顺手关掉减少售后压力实在太正常了，在意的最好预先叮嘱一下。


@duke807 你说的这种是可否认加密，目前 VeraCrypt 有这种实现。不过没有任何实践案例验证可行。例如你怎么让调查者相信你在用 VeraCrypt 但不拥有秘密？ Bitlocker 反而好一些，因为有很多人在用着 Bitlocker 而浑然不知，宣称不知道恢复代码很有可能是真的。你说的这个问题不是一个技术问题。

跟公司商量换硬盘吧，这个没啥办法，SMR 额外忌讳小文件写入。
128G+1T 典型坑企业采购的组合，真不如一个 512G SSD 。

@RIDESU 不是 Mac 用户不了解机制。Android 的 APK 和 Windows 的 MSIX 都有 OS 提供的签名验证和完整性保护机制，不允许对包内文件做任何改动。也就是说，开发者和 OS 都假定所有包内资源是经过签名保护完整且永远可用的。
实际上通常占体积的都是贴图等多媒体资产而不是可执行代码，这种选择在首次运行时下载算是可以接受的。不提供清理功能我觉得 PM 觉得需求少。通常用户不会特意想起要删掉不需要的功能。我在 Windows 上不是空间紧张也不会专门去删除功能组件，而且真遇上这种情况，删组件不如卸载不常用 APP 或者买硬盘那样立竿见影。

@Juszoe 楼主那个视频，Potplayer 用 equirectangular 就可以了。这种投影跟世界地图投影差不多，把一个球体表面投影为矩形平面。
B 站这全景视频其实不能算 3D ，因为它的画面依然是平面的，没有景深信息。如果你有 VR 头显，这种视频相当于你在球心看一个正球面。

那种左右双画面的才是有景深的真 3D 。
https://www.youtube.com/watch?v=0UzkdPAnGCY

我没听说过哪家支持组件删除的，按需下载倒是可以做到，例如 Google Play 支持基于 App Bundles 的 Feature/Assets Delivery 。

这玩意最严重的问题是 APP 要与应用市场耦合，如果你要上华为应用市场（好像是目前唯一支持 App Bundles 的国内渠道），开发者得针对不同市场改代码和打包。

另外，这个按需下载的特性对用户也不一定是好事。想想在一个不稳定的网络环境下载一个上百 MB 的用户急需使用的组件，用户会骂谁？还不如一开始在 wifi 网络全安装上备用。

在七八年前，流行的方法是将可选组件作为一个分离的不能运行的库 APK 安装，但我可以保证，绝大多数用户会觉得这种部署方式是垃圾，不如单一的超级 APP 省空间。

还有一种方法是运行时静态下载可执行代码（腾讯 TBS 用了这种方案），也就群魔乱舞的国内 Android 市场允许这种危险而难以监管的行为。

@gam2046 目前 Play 版本不支持小程序组件（例如 B 站分享），会显示一个加载中的灰框，你运气不错没遇到。

要真纯业余做技术分享不盈利的，能月更都算不错了。
能周更甚至日更的，要么全职，要么团队化运作，不灌水是不可能的。
另外，监管部门已经开始吹风了，以后做金融产品推广要持牌，自媒体以后接这种生意可能会有麻烦。

如果你要的是实时回放，听力障碍辅助用的声音增强器可能符合你的需要。
https://play.google.com/store/apps/details?id=com.google.android.accessibility.soundamplifier

我觉得 zstd 用的范围更广。目前可以用在 Linux 内核镜像压缩、ZFS/BtrFS 透明压缩、PKZIP （ zip 文件规范）可选编码算法、deb/Arch 软件包压缩算法。brotli 目前主要就浏览器和 Android OTA 包在用。
7z 默认算法是 LZMA/LZMA2 ，也就是 xz 用的算法。LZMA 是典型用于极限追求压缩率的场景，例如冷存储和路由器 ROM 之类需要极限紧凑无所谓慢的场合。要速度都不会用这个。zstd 在此的对比优势是在高压缩级别能达到 LZMA 近似的压缩率（通常还是大一丢丢）但解压更快。
brotli 有一个硬编码的静态字典，zstd 没有，但可以训练生成一个定制字典。也就是说 brotli 的高效是建立在对输入内容有偏向性假设的前提上的。所以我不否认 Web 内容上 brotli 是个好的选择。至于 brotli 和 zopfli 选哪个看你网站的客户端统计吧，或者全都要。
另外我不知道你图里的 zstd 是不是用默认的 3 级压缩，你有没有试过 19 级？

@timpaik
RFC8478/RFC8878 已经标准化 zstd 对应的 HTTP Content-Encoding 和 MIME ，想用都是能用的。
Chromium 拒绝支持竞争技术也不是一天两天的事了，到现在都没支持 HEVC 。

@yezheyu
可以这么理解，一个支持并发读写（多进程读写相同项）和权限控制的结构化数据库。
在 HDD 和小内存时代，注册表可以减少大量小文件的创建和读取操作，提高启动速度。现在随着 FS 改进和 SSD ，这个积极作用已经不太重要了，所以追求跨平台能力的程序又回到配置文件了。
通常，环境变量和命令行是传递一次性使用，不需要持久化的配置。密码类参数通常用环境变量传递。
Linux 类似注册表的技术是 dconf ，主要是 GNOME 全家桶在用。

这明显是用了日本字形了。
可以考虑设置里调整使用 Language-specific Fonts ，选择。例如思源黑体选用“Source Han Sans SC”

如果第一层 VMM 也是 VMware 的话，需要在虚拟机设置启用“虚拟化 Intel VT-x/EPT”和“虚拟化 IOMMU”。如果这里用了 WHPX （也就是 Hyper-V ），这个选项不可编辑，建议考虑禁用 Hyper-V 换用 VMware 的虚拟化实现。

一般程序启动设置是有一个覆盖顺序的，例如硬编码默认值-全局配置文件(%ProgramData%或 HKLM)-本地配置文件(%APPDATA%或 HKCU)-环境变量-命令行，后者可覆盖前者的值，main 函数按顺序读取，生成完整参数表传给程序入口。