20240610

20240610-1.txt

https://www.bilibili.com/video/BV16y41187mX/

是否使用目录结构部署相对只是个次要的细节。但其它方面越想越罄竹难书，还是记个笔记（其实可以写技术报告，这里也就是提纲）吧。

其实技术上来讲，现有的通用软件安装部署方案基本都是乐色，不是这里缺了一块就是那里多了一块，都不能满足全面一些的需求场景。
还有PC和移动设备其实本来就不应该在这种层次上搞煋闻，除了嘲讽之前的方案残废然后搞了自己新的残废（TODO：插入xkcd多少来着.png）和刻意制造分裂形成生态护城河的错觉外完全没有技术意义。
预测一下以后正常的方式吧：大概就是基于nix/guix store的形式集中分配存储池，然后mount出来目录。这样能精确控制权限，确保就算拉屎范围也有限保证用户（系统管理员）可控，开发测试规模部署都容易自动化，同时满足部署到不同物理安装介质的需求。
现在这些屎的体验主要体现在以下一些方面：
1. 部署后映像和配置分离基本完全靠开发者自觉，然后多数开发者的素质难以支撑起这种自觉。
大多数情况下，乱拉屎直接就是开发者不自觉的问题。失误了拉错地方是很少见的。
然后权限限制少了，管不住乱拉屎的；权限限制多了，又阻碍自觉的开发者发挥。
更要命的是，实现权限的元数据本身可以说就是屎。
越是复杂的元数据，可移植性问题越多，于是动不动就增加用户维护时的互操作负担（比如想确保备份全文件系统元数据就麻烦很多）。
就算是最简单的UNIX文件系统权限……看看有几个chmod -R 777受害者？
2. 一些方案的管理员用户体验特别辣鸡。
特别点名Windows，上面一个问题注册表本来能挽回颜面，但注册表明明是NT挂在对象树上的非得和文件系统对象分离搞得UI体验辣鸡，对个别配置编辑维护极其低效，倒扣分。
类似的UX问题还有NTFS ACL，本来是比SeLinux那坨欠扁的正常的，但一看UI……
另外，长期以来缺少默认包管理器维护起来傻大粗黑也可以归为一类。Windows又是反面典型。
3. UNIX这种传统上写死路径的奇葩的导致系统动态库加载默认规则也奇葩，非默认规则要么在映像上开洞，要么就得污染全局配置（不管是环境变量还是配置文件），很难批量统一部署，而且全部搜索路径一旦冲突就作大死。
相比之下，Windows默认dll搜索当前目录就比较正常——就像正常的语言大多允许局部变量先于全局变量搜索到，不需要另行配置。
不过，不管是ld.so还是dyld，主流类UNIX系统上的动态库加载器一般都允许通过配置实现dll搜索的方式，在功能完整性上算是可以接受。
然后开发者素质欠费的问题就出来了：因为相对过于灵活，用什么方式折腾全局系统配置，冲突的可能性也大。
4. VFS和文件系统自身能力问题也是一大堆。
这里Windows扣大分，因为长期以来的显著拉胯。除了注册表和文件系统在NT层面上就合并无望外，文件系统自己就一堆弱鸡。钦点系统盘要求NTFS支持winsxs已经是很晚的事了，最近几年前创建符号链接居然还要权限。然后ReFS呵呵。
另外挂载磁盘，虽然其实NTFS早就支持装入文件夹，但几乎就没看到有谁用；根本上也没有bind mount之类的东西，更别指望OverlayFS layers了。
Windows这里的思路向来小家子气，兼容DOS搞了盘符和保留DOS设备名这样的奇葩不说，新增功能也基本不会往简化互操作的方向上走（比如存储池），基本是没救的。
这类卷管理在VFS先天不足的情况下只会增加工作量而不方便复用方案节约配置复杂性，给图形界面反而鸡肋，压根就没打算给个人用户用得舒服。
然后，文件系统长期以来解决不了TOCTTOU，不过这个不只是安装部署还涉及运行，是个原则上严重得多（应用层面不可能完全克服）的设计缺陷，而且是所有市面上的系统都要扣大分。像POSIX-1.2008的at API根本解决不了这个问题，要解决基本得魔改内核支持文件系统事务。
最奇葩的是NTFS本来有TxF，莫名其妙就deprcated了，居然推荐让位给msi，真是岂有此理。
5. CI/开发语言上的包管理碎片化就算了，系统软件包管理（如果有）和安装部署方案的生态上都碎片化得相当稀碎。
这个不管是Windows各种备胎方案还是Linux之类的各种分裂以及mac这种官方和第三方包管理格格不入，都是一坨，只不过形状各异。
VFS本身也可能作为接口约定导致各种兼容性问题。比如procfs。
这些可移植性上出幺蛾子的问题，都有潜在的可能损害开发者避免拉错屎的专注性，结果可能就更不自觉了。
注意移动平台上只是最终用户看着简单，建立在大量牺牲开发者和系统管理员定制安装选项（比如连个路径都不能选、比如有些屎只能当做没看见用户自己动不了）的前提下。
6. 就配置安装路径这个问题，其实大部分用户都可以不管，但实际么……用户可以不用，你不能不给。
安装路径其实就是个资源所有权的约定：把安装路径掀翻了，就相当于反安装。而如何不在涉及所有权下访问资源（比如通过快捷方式或者符号链接），其实是另外的问题。搞清楚这点，大部分对安装路径的纠结就不再重要：装哪不都一样？
如果能解决上面提过的动态库在内的搜索路径（其实至少还有如何管理PATH环境变量这个更直接的问题），那么大部分情形的安装位置问题，就退化为外部依赖如何管理的问题。这虽然是个复杂的问题，但是包管理而非单一部署方案的主场。到这里就已经可以消解定制安装路径的需求了。
剩下的一个合理需求是纠结指定安装在哪个介质上（装哪个盘上效果还真不一样）。但这实际上可以直接用符号链接解决：配置一个符号链接以后，安装在哪可以完全没体验上的差别。
只不过大部分安装程序都不会给你指定符号链接的机会（甚至Windows上系统管理员长期以来都根本没有这种选项），想要用就得安装前自己创建或者安装后移动，这就导致体验上完全变成了非正常流程。
所有这些状况叠加，才强化了指定安装路径这个选项有“你不能不给”的必要。（否则，Chrome的安装程序也未必显得那么欠揍。）
7. 软件包本身具有一些存储和传输经济性的问题。
比如Windows几十年如一日最近几年才更新包格式提升压缩率。
这个与其说是用户侧基本无解，倒不妨说是其它破事太多了，导致相对不那么显眼。但算上规模，其实浪费也够大了。
8. 签名和信任。
这个虽然很大程度是UX问题（就像Chromo遇到证书失效不给添加例外总是得一次次手动操作那么欠揍一样），但如果放到垄断环境就很不好笑了，单独提。
比如什么时候侧载这种系统管理员的固有权利居然需要用户自己争取了。
（其实root也是。）
9. 以上其实还没涉及最麻烦的问题：依赖管理。
特别是保证可稳定重现和多版本在同一个环境的共存，对多数主流包管理器都是死穴。这些对有些用户（比如一些开发者）可能是刚需。
因为这涉及运行环境，和系统耦合得太紧了：PATH、加载路径、文件系统布局和权限……没个省心的。
实在没办法，就用容器——这货专门干这事。再不行，就上虚拟机。
（这里并非都有严格的边界。其实只是要隔离文件系统chroot下越狱不出去就算能是丐版容器；而Windwos上Linux容器可能直接就是WSL2这个虚拟机实现的。）
但根本上，利用系统机制强制隔离运行环境，这都是应用层次上主动隔离失败后弃疗的妥协表现。系统机制虽然容易确保全局有效，但更重量级，不管是部署还是运行都有更大开销，而且往往因为强调普遍场景和专业用户（运维），一般用户可能不大易用。
现在远远不是在软件包的安装部署和运行环境方案上弃疗的时候，因为至少部分操作系统其实是能支持起这样的方案的。
这是我为什么提nix/guix的主要原因，因为就是这层套路：通过纯函数式DSL确保配置和环境可重现，通过符号链接隔离文件系统资源，顺便把版本号编码进去支持多版本共存。
当然权限这里还缺了一些，但至少已经做到了大多数其它方案原则上不可能做得好的，所以姑且算是个看来更正确的方向。
但是普通用户就得猴年马月才能用上了。