diff options
Diffstat (limited to 'content')
| -rw-r--r-- | content/posts/weekly/48.md | 79 |
1 files changed, 77 insertions, 2 deletions
diff --git a/content/posts/weekly/48.md b/content/posts/weekly/48.md index ab465d06..94ec2ceb 100644 --- a/content/posts/weekly/48.md +++ b/content/posts/weekly/48.md @@ -23,7 +23,11 @@ toc: true ## ↯ · 当下 - 读完了另一本讲自杀的小说《[维罗妮卡决定去死](/library/2025/维罗妮卡决定去死/)》，相比[上一本](/library/2025/十三封自杀告别信/)没有很喜欢。 -- 废除了博客的[卡片](/cards/)分区，依然能够单独访问，但是不显示在标签页面和首页了，文中的卡片引用也被替换为了块引用。这么做的原因是我发现自己其实很少写卡片，一个卡片的大小其实也很难把一个概念讲清楚。一开始我把卡片定义为「个人词典」，希望标准化自己的用词，但这个效用也没有发挥出来。 +- 开始和室友看《绝命毒师》。周六的时候一起看了一部电影《Her》。 +- 博客做了一些改动 + - 废除了博客的[卡片](/cards/)分区，依然能够单独访问，但是不显示在标签页面和首页了，文中的卡片引用也被替换为了块引用。这么做的原因是我发现自己其实很少写卡片，一个卡片的大小其实也很难把一个概念讲清楚。一开始我把卡片定义为「个人词典」，希望标准化自己的用词，但这个效用也没有发挥出来。 + - 现在点赞（献上心脏）之后能看到自己和其他人献上的心脏（有时是大脑）。 +  - 给新家添置了一个吧台，作为咖啡角，不想坐着的时候也很适合站立办公。 {{< gallery >}}  @@ -33,7 +37,67 @@ toc: true ## ⋈︎ · 连接 +### 为什么本地优先应用没有流行起来？ +> [!note] 📜 +> 文章链接： [Why Local-First Apps Haven’t Become Popular?](https://marcobambini.substack.com/p/why-local-first-apps-havent-become) + +作者解释了本地优先 App 没有流行起来的原因：构建本地优先的应用就像维护一个分布式系统一样难。本地优先指的是所有数据都保存在本地，随后上传至云端，其他设备可以通过云端同步数据。本地优先意味着加载速度更快、数据更有保障，也比基于网络的应用更注重用户隐私。[^1] + +随后作者解释了构建分布式系统的两大挑战，顺序不可靠（Unreliable Ordering）和冲突（Conflicts），并分别提出了解决方案：混合逻辑时钟（Hybrid Logical Clocks，HLCs）和无冲突重复数据类型（Conflict Free Replicated Data Types，CRDTs）。 + +简单来说，作者认为构建本地优先应用不应该使用请求队列[^2]，应该合并各个设备的改动以保证一致性，使用行之有效的分布式系统技巧（HLCs 和 CRDTs）。 + +#### 我的观点 + +个人认为，本地优先意味着数据保存在本地，用户有更多的控制权，要迁移数据到别的软件也就更容易，这是许多网络优先应用留住用户的方法。大部分网络优先应用会提供导出数据选项，但导出的数据格式一般都很难用。 + +另外，作者提出的数据同步的解决方案其实有些可疑，作者举了这样一个例子： + +> 设备 A：`balance += 20` +> +> 设备 B：`balance -= 20` +> +> `balance` 原来是 100，如果设备 B 后操作（通过 HLCs 比较顺序，而不是依赖不可靠的系统时间），就应该采用 B 的结果，将 `balance` 改为 80，忽略 A 的改动。 + +这很反直觉，因为很明显，A 和 B 都对 `balance` 进行了变更，应该把两次更改合并，先加 20 再减 20，也就是说 `balance` 应该还是 100。有关这点，评论区有另外两位读者也提出了相似的质疑。 + +> @Jacob Wright: +> +> your example with modifying balance shows how weak LWW is. If 2 clients change a balance by +20 and -20, you would *want* the result to be a net zero change. The most naive approach is to let the server decide the value by who arrived last. Your approach by adding a timestamp is slightly better. For a balance, you'd want a PN-Counter that captures increments and decrements so they can merge together. + +> @dries: +> +> This strategy doesn't take into account that peers will propose changes with different local states. Not only that, but some changes might be accumulative, i.e. add both changes (+20, -20), resulting in zero change. The balance example is not the best one. + +作者似乎也没能把 HLCs 的原理讲明白，因为从作者举的例子来看，多台设备依然需要互相通信才能确定操作的先后顺序。评论区有人指出对于这种需求，应该使用基于区块链技术的方法来确定改动顺序。 + +简而言之，作者在这边文章里追求「简单有效」，但似乎有些简单过头，导致有些不可靠的地方。 + +### 算工智能 + +> [!note] 📜 +> 文章链接： [Abundant Intelligence - Sam Altman](https://blog.samaltman.com/abundant-intelligence) + +Sam Altman 在 9 月 23 日发布的博客文章，标题是对 AI 这个缩略词的重新定义，把 Artificial（人工的）换成了 Abundant（资源丰富的），这里的资源指代算力资源。Sam Altman 在这篇文章里表达的观点很简单，他认为人工智能的发展速度不应该被基础设施限制住，所以他们接下来的几个月会计划构建能够快速生产大量 AI 基础设施（AI infrastructure）的工厂。 + +另外，Sam Altman 在开头提到使用 AI 在未来可能会成为一项基本人权，我不知道该如何评价。 + +### 总是邀请安娜 + +> [!note] 📜 +> 文章链接： [Always invite Anna](https://sharif.io/anna-alexei) + +作者写道自己在大学的第一个学期经常在周五晚上和同学出去聚会，但有一个叫做 Anna 的女生总是拒绝参加，因为她把大多数时间都花在学习上了。最后，大家都不再想着去邀请她了，只有 Alexei 依然坚持。Alexei 解释说他知道 Anna 会拒绝，但他一直这样做是为了让 Anna 感觉自己是团体的一份子。几年之后，作者又遇见了 Anna，说起那段经历时，她说那个时候她非常想念家人，而朋友们每周五晚上都来敲她的门让她感到自己在远离家乡的地方也有了归属。 + +作者说有时候那些最需要收到邀请的人反而是那些总是会拒绝的人。 + +### 个性化隐私的广告边界 + +> [!note] 📜 +> 文章链接：[个性化广告的隐私边界（上） - 少数派](https://sspai.com/post/102268) + +文章解释了信息时代有关「隐私」的三个误区，区分了隐私、安全和匿名这三个容易被混淆的概念。文章写得很清晰，值得一读。 --- @@ -52,4 +116,15 @@ toc: true  {{</ gallery >}} -访问：[Helium Browser](https://helium.computer)
\ No newline at end of file +访问：[Helium Browser](https://helium.computer) + +### Messenger + + + + +访问： [Messenger](https://messenger.abeto.co/) + +[^1]: 不过我个人觉得有待商榷，因为同步数据时也需要在网络中传输数据，最保护隐私的做法是完全断开网络连接，但这显然不现实。 + +[^2]: 即把离线的更改都保存起来，等有网络连接时再逐个请求云端提交改动。 |