@lxdlam 没写完发出去了。补充一下特性第一条：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑可以读写分离的架构，使用一些缓存、分片的技术难度会大幅下降，且能在合理资源量内得到一个不错的效果。

日志需要持久化，尤其是有跨天 case 的可能性。使用 MySQL 或者其他 OLTP DB 是一种方案，但是不是最好的方案。

将日志当作事件流，思考日志的使用场景：
- 问题定位：最常见的 case ，通过请求、用户、设备等等维度抽取一个特定的事件流分析，哪一步出现了问题，这种 case 通常需要对一些特定的 field 当作 key ，抽取查询相关联的事件。
- 数据分析：通过对特定事件进行聚合，计算出来一些业务或者技术指标，诸如平均响应时间、订单完成延迟等。这种场景一定程度上会被 metric 所替代，但是在错误日志聚合上仍然有价值。

同时，日志有一些自己的特性：
- Append only：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑
- 丢失冗余：根据日志量的关系，其实允许一定程度的日志丢失和冗余，也就是没有严格事务要求。
- 量级和查询需求：很多日志都是大海捞针，允许一定的查询延迟和一定延长的运行时间

从上面的角度，其实使用一个 OLAP 系统或者更加专门的系统更好。OLAP 常规的选型可以选择诸如 ELK 、ClickHouse 这样的系统，搭配 Kafka 之类将日志落进去；而比较完善的日志系统现在比较流行的就是 Loki + Promtail/Grafana Agent ；如果量小，使用 fluentd 采集并发送到 S3 使用一些脚本去分析也是 OK 的。

本科阶段用了很久的 Manjaro ，现在主力开发两台机器还是 macOS + Fedora ，不太追求 Cutting Edge 的滚动更新，Fedora 用着正好。

之前用过一段时间 NixOS ，但是 NixOS 会有一些 dirty hack 的工作要做，会有一定量级的时间定期调配置文件，后面就放弃日常使用了，下一步打算在 CI 场景用一下。

Redis 这次换其实是比较强盗逻辑的。

背景是 Redis 之前开发了很多附加组件，如时序数据扩展 Timeseries ，JSON 扩展 RedisJSON ，然后这一系列扩展统称为 Redis Stack ，所有 RedisStack 就是按 SSPL 分发的，同时保持原有的代码为 3-Clause BSD 。

> In fact, more than 50% of redis.io downloads – from Redis 6 and beyond – come from Redis Stack. We now believe that extending this licensing to Redis itself will enable us to continue to evolve the most holistic set of data models, processing engines, and developer capabilities for our users.

根据原文，他们觉得既然有超过 50% 的用户下载 Redis 都是从 Redis Stack 过来的，那为什么不把这俩合一呢？是否合理、怎么合并暂且不提，单纯因为这个原因把 core Redis 的 License 换成 RSAL+SSPL ，就纯粹是在绑架那一批完全用不到 Redis Stack 的用户了。而显然，这虽然看起来是 Redis 跟托管云的斗争，但是实际上这部分成本总会以各种形式转嫁到 end user 上。

我的桌面是 Windows ，用一对 PreSouns Eris 3.5 ，但是接了个外置声卡走的平衡输出。

XKCD 538.

https://imgs.xkcd.com/comics/security.png

介绍一下另一种形式，并非由一个 committee 来决定的形式：[终身仁慈独裁者]( https://en.wikipedia.org/wiki/Benevolent_dictator_for_life)，从 Python 之父开始的一个特定名称，被他毙掉的 PEP 不计其数。一个非常著名的提案是 PEP-572 ，就是 Python 3.8 引入的赋值（海象）操作符 `:=`，社区对这个提案一直比较两极化，但是 Guido 下场了，最终通过这个提案。

Disclaimer：我并没有说这个提案通过跟 Guido 下场有直接关系，现象如此，而且我也经常使用海象操作符。

将一个接口 wrap 进一个 db transaction 本身只保证了 db 操作的“原子性”，这还建立在本身 db 的 txn 处于正确的 isolation level 下。

所谓的接口原子性要考虑的问题远比这个复杂，如果使用了其他的后端服务，诸如 Redis 写入、第三方系统 API 调用，当非原子操作产生时，这些服务是否均支持回滚？是否保证回滚时的一致性？这样就需要从业务逻辑去考虑，然后落实到技术层面去解决，比如 Redis 是否需要 transaction 去配合？对于不支持原子的操作技术上如何取消？无法取消的事务如何在业务跟技术层面去做补偿？

我可能是极少数买了 Mathematica for Home&Hobby 的，今年他把 Cloud access 整合之后估计就继续按年续 Service plan 了

目前主用 rye ，只能说非常舒服

@lxdlam 当然，进阶还有更多话题，比如备份经常还有可能备份错，所以多天 snapshot 之类做回滚也是常见需求；根据 321 原则，是否在合理价格内支持两地、多地同步 etc ，这些大部分也都会算在成本点里面

感觉很多东西楼主没考虑到：

- 流量费用如何计算？ Ingress 跟 Egress 各自怎么计算？
- SLA 如何保证？数据取回是否会有延迟？全球上传和下载平均速度如何？
- 安全和合规如何保证？不是所有人、所有存储方案都适合用 borg ，如果直接使用 S3 跟 WebDAV etc ，平台怎么保证安全性？如果有监管部门审计需求会如何响应？

在加密备份领域业界最好的方案应该是 Tarsnap ，当然也不便宜；跟你这个方案类似的是 rsync.net ，他们提供的安全性和方式支持非常完善，供参考。

并没有找工作，只是很好奇一件事：你们对 Elixir 的态度如何？

非常好看，用了下也挺轻量级的，支持了一波。提一个功能建议，可以增加 intergrate db shell 的支持，类似于 mongo compass 和 redis insight 下面的 integrated shell

用 Windows 10 专业电竞战斗版 1.5 。

https://www.v2ex.com/i/z8Tz1085.jpeg

图源来自网络。

我一向觉得游戏的目的是找到快乐，如果找不到快乐了，就可以不玩。

一方面我同意 #3 ，更像是编译器的 bug ，另一方面我本地似乎复现不了这个差距如此巨大的结果，估计可以看下 1.21rc 到现在（ go 1.21.6 ） 的差异。

而对于一定程度上的差异（ 100000ns per op ），单纯从生成代码上来看，f 生成的函数直接对 r 做了修改，所以需要一次对 r 的 load ，而 g 是对一个临时变量做修改，虽然二者都是一次 load 跟一次 store ，但是 r 毕竟不好说分配在哪儿（也许在 heap 上，也许在 register ，看编译器优化），那么 r 确实可能比起临时变量（ go 倾向于分配在 register 上）的读写要更慢。至于为什么会有如此差异，实际上应该是因为编译器识别出来了这个累加 pattern ，而在 f 里因为没有额外操作，所以直接对 r 进行操作，把加数这些都当 immediate value 优化成单次 INCQ 了；而在 g 中，由于又读到了 r + 0 ，编译器首先优化成了将其写入中间变量的操作，又在后续 pass 中发现其实对 r 基本无操作，去掉了这里面所有 r 的主动 reference ，将其完全优化到了完全只读写中间变量，所以生成了这个样子的代码。

以上仅抛砖引玉，我不是 plan9 和 go compiler 专家，只能看个大概，这里面同样可能会有很多说不清的其他因素影响。但是我仍然同意，这种 case 应该 report 给官方去修改，而不是当新时代的语言律师模拟考题，同样，如果在乎这个粒度的性能差距，可能我们会选择更精细的语言和优化方式了，而不是在这继续抄写茴字剩下的写法。

日区 Spotify 已经两年+。

从体验上来说，AM 跟 Spotify 的算法都很不错，冷启动到符合我的喜好学习速度很快，也不会跟 Youtube 一样，播放列表只会循环推完全特定的歌，基本零探索性（比如推一些可能会喜欢可能不喜欢的）。

但是 AM 缺了一些关键功能，比如必须苹果全家桶才能用上比较好的远程控制，但也仅限是手机/电脑 -> HomePod ，诸如 Spotify 的所有端都可以跨端控制有很大距离。同时，除了苹果之外，Android 上的体验也不尽如人意，最终放弃。

从音质上来说，流媒体我完全不在意音质，确实非常喜欢的歌我都会去 mora ，ototoy 买 Hi-Res 或者直接收实体 CD 抓一份，我对流媒体的核心要求还是方便+曲库+算法。

特别补一个，Apple 的 iTunes Match ，就是所谓的“云盘”，其实非常难用。iTunes 的标签修复有非常大的苹果延迟，就是你并不能完全知道到底这个 tag 修复有没有被正常推到音乐库里面，有可能在 mac 上看起来修了，换个设备发现压根没变化。同时，上传音乐的时候苹果会去自己的音乐库 match ，如果有就会用自己的替代，这样如果你抓了 44.1khz 16bit 的 flac ，但是苹果并没有这个音质的版权，他会给你 match 回 aac 版本，音质倒退。