ecnelises

@ecnelises
另外我好奇楼主说的「往用户目录拉坨屎」指的是读写主目录的 Documents/Downloads/Photos 这些目录呢，还是在主目录~下面创建点开头的隐藏目录，或者是~/Library ？

1. 从之前和 Epic 打官司期间，苹果高管的言论来看，他们对 Mac 可以 side-loading 这个现实的态度，基本类似父母对待自己眼中不争气的孩子，躺平了。当然不排除他们真的在未来某个版本这么高，但鉴于只允许从 App Store 安装这个选项已经存在多年，而且真的要搞，Big Sur 那么好的机会没搞，可能就是没这个打算。

2. macOS 上有大量脚本程序、仅命令行的程序、用户自己编写的程序，这些怎么办？好，可以说允许用户自己签名，那跟现在不是没有区别了吗？ M1 上本来每个二进制可执行文件都要签名才能运行。

3. 现在发布一个 macOS 上用户可以直接打开的软件，你需要：一个 Apple Developer 订阅+用这个订阅相关的密钥签名+发到苹果服务器自动化跑一遍查毒 (notarize)，理论上如果一个软件出了大问题，苹果可以给所有 Mac 远程发指令撤销该开发者的签名以让其打不开。这个流程和 App Store 就差一个人工审查。

4. iOS 的封闭软件生态工作得很好是因为它从一开始就这么运行的。苹果迁移到 ARM 都快两年了还有很多软件没适配，短期内整个这个限制对 macOS 生态就是灾难。而且 iOS 不可控的下架行为已经让人意识到禁止 side-loading 就是有两面性的，禁止了对属于生产力设备的电脑伤害更大。

5. Mac App Store 限制本来就比 iOS App Store 松，JIT 权限也是放开的，Slack 等软件也是 Electron 做的，上架 MAS 一点问题没有。所以这些倒不是障碍。

Sigh.. 网站把我 List 的缩进吞了。

然后在上面提到的统一数据库基础上，提供一套 CRUD 接口，每个应用对应一个私有子库，也可以通过认证获得其他库的权限。并且这套接口不只是服务端可以用，客户端也可以用（本地数据库），因为它更像是点对点之间的 sync 而不是全靠请求获得资料的 B-S 模式。

但在客户端，这样有一个问题：数据库对客户端而言非常大。我们可以按需下载那些 Blob 文件，并且不下载过往的操作日志，剩下的数据库不会很大，还可以辅以压缩。（ V2EX 全站的用户和贴子数据装 Sqlite 里应该也只有几个 G ）

有了这套协议，我们就可以实现真·前后端分离的系统了。说简单一点，就是在本地实现了一套类似 LeanCloud 的东西，前端和客户端只需要假设本地或服务器有这个模块，连同步都是由这套实现自动完成。

OP 在那个贴子里提到的存储在用户本地的信息集合，有些类似 Tim Berners Lee 搞的 Solid ( https://en.wikipedia.org/wiki/Solid_(web_decentralization_project) )？不过它更强调的是不同节点之间的互联。

---

有关同步的问题，我有过类似的想法：定义一种协议，它可以描述确定两个节点 A 和 B 之间的数据可以如何同步，并且

- A 和 B 不一定要相等，可以是 A 的子集和 B 的某个子集进行同步
- 比如 A 是一个人手机上的各种类型数据的集合，B 是一个服务器，那 A 只需要把照片这个子集和 B 里面属于 A 的部分同步
- 这个模式已经很常见了，但还没有发现有通用协议去规定它
- 同步当然要是增量的，但基于文件的同步不太靠谱，因为我们没法假定同步工具支持增量同步，也没法假定数据库到底是以何种方式存储的
- Event Sourcing 是个思路：每次修改会产生一条记录，当前数据是所有记录执行后的一个快照。这个设计类似 Flux 或者 Git ，所以很自然地，如果同步双方的记录日志分叉了，还可以尝试 merge
- 继续从 Git 思路出发，客户端和服务端是多对多关系，甚至没有服务端的概念，因为服务端本身也可以作为中继，同步到上游数据库
- 如何避免环出现呢？
- 不知道 OP 用不用 iCloud ，其实 iCloud 就像时刻连接着的一根线，把设备的数据和苹果的服务器做 iTunes 同步。这里同步的是数据库而不是文件（ iCloud 云盘是后来才有的），所以后来它们还开放了 CloudKit 这个东西
- 苹果的自带软件和若干第三方软件都偏好用 iTunes 风格的数据库而不是文件夹存数据。我喜欢这种方式，因为数据库比文件要结构化得多，能存更多元数据，读写同步效率也都更高
- 但并不是所有数据都能放到数据库里，比如很大的照片或录像，它们适合存放在单独的文件里作为 Blob. 如果把这些数据库和 Blob 打包并规范化（开发一个统一 API 操作），那会十分方便，并且可以和第一点提到的协议结合，软件的各个小数据库其实是系统大数据库的一部分（有点像 Windows 注册表了？）
- 某些文档数据库已经自带了管理 Blob 到文件的功能
- 由于数据结构高度统一，快照、备份、回滚这些功能都变得很容易，可以用类似 zfs send/receive 的方法轻松备份和加密

- 苹果公司标榜隐私是一种营销手段，但是营销不代表不做事。小米是不是标榜性价比？是。小米的性价比有没有代价？有。但小米依然有性价比。除了少数手机厂商，你很难看到互联网公司出来在隐私保护上内卷，打苹果的脸，这本身就能说明点问题了。
- 反对苹果的人最爱举的例子是 2014 年 iCloud 照片泄露事件以及和有关部门的合作（喷棱镜门的和喷云上贵州的建议先打一架），支持苹果的人最爱举的例子是 iOS 14.5 反广告追踪功能。但在楼上说的房间里的大象面前，这些事是否……太片面了些呢？举个例子，居民身份的数据泄露了，这恐怕比京东广告精不精准的负面影响高了几个数量级，但它和你用什么手机，有关系吗？
- 不要试图在网上和人就这些话题吵架：你说隐私保护，他说 iCloud 泄露，你说那是撞库，他开始复读一百块的布。

联想到了吗，对 HTTP 是否应该使用状态码来表达业务状态的争议，其实颇像「使用异常还是错误码」这个同样老生常谈的问题。有些人大小事都要抛异常；另一些人尝试 catch 一切异常，并永远使用错误码。而当代码要接入一个现有模块时，事情变得更复杂了。

HTTP 通用的错误码（ 4xx, 5xx ）很有限，就像系统定义的异常类型，必然无法涵盖所有错误的情况。但我们不必做二极管，始终在上面提到的两种人间反复横跳：尽管很多错误码是和 HTTP 协议强相关的（比如 411 ），至少常用的 401/403/404 语义可以完美对应项目中一定会出现的几种错误情况；除此之外，简单用 400 表达请求有问题，500 表达服务端有问题，搭配自定义的错误代码即可。

另一个和是否使用 HTTP 错误状态码相似的争议，是「是否要以 REST 方式组织 API 」。是的，生搬硬套的 CRUD 语义没办法定义现实中的所有复杂情况，但也不该因此就彻底抛弃这套被广泛接受的代码组织思路：GET 不应有副作用，PUT 相比 POST 有幂等性；实在不行把一些操作都抽象成某个 Action ，然后所有有副作用的操作一律 POST 也比一团乱麻来得整洁。

稍微改了一个，不完美，可以加到自定义 CSS 里