ecnelises

ecnelises

V2EX 第 89617 号会员,加入于 2015-01-02 22:06:48 +08:00
根据 ecnelises 的设置,主题列表只有在你登录之后才可查看
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
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 也比一团乱麻来得整洁。
45 天前
回复了 dingwen07 创建的主题 反馈 建议 V2EX 跟随系统深色模式


稍微改了一个,不完美,可以加到自定义 CSS 里
94 天前
回复了 Geeker 创建的主题 分享创造 我的 newsletter 订阅数到 1000 啦
也推荐一下我的 newsletter😁 https://weekly.love
上次在别人那里听到一个说法:给自己固定的时间写,时间结束就发稿,写多少是多少,这样能够缓解压力。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1679 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 11ms · UTC 17:30 · PVG 01:30 · LAX 10:30 · JFK 13:30
Developed with CodeLauncher
♥ Do have faith in what you're doing.