之前观察 crazygames 的发展： https://github.com/CrazyGamesCom/unity-optimizations-package
感觉技术层面 webGL 完全和传统前端没关系，倒是适合游戏领域的人 转型 web 。
现有的一些原生 webGL 的框架或库，要么预期用户学过 图形学 CG 能手撸 OpenGL ，要么假设你从事过游戏引擎的开发。
反而和前端的 HTML/SVG/CSS/JS 渐行渐远。

前年把基于 aws 的配置中心拆掉了，鸡肋。
发布中心也改成了基于 github action 的插件，只要合并到特定的分支就会自动 tag 并 deploy 。

@god7d 打击黑煤窑的原因 更多的是其利润不上缴 XX ，计划外生产的煤炭 影响 XX 对能源的垄断。甚至利益输送保护伞造成 XX 的统治效率降低。
考虑到 XX 内部复杂的用工方式(编制，合同工，临时工...)，以及华为与 XX 的关系。恐怕他们还比较乐见这种降低人矿使用成本的方式。

@jeffwcx 但只有华为倒闭才能证明这种 用工方式 是错误的，否则效仿者众

做成接口，然后 k8s CronJob 去调用

我选择 fx
https://pkg.go.dev/go.uber.org/fx#section-readme

劳动力资源 不如 劳动力所需生存资源 和 生产资料 稀缺而已。
土地，水源，能源这些都以 全民 的名义 被少数几个家族暗箱控制，可以让它们的价格长期保持你的工资刚刚够消费，却又无法积蓄的程度。

高铁动车组就是这样"师傅带徒弟"搞出来的，只要甲方肯给钱，不是事。

https://www.infoq.cn/article/4lDxHRoqXbSw6zl29AEo
这篇通稿也能解释一些。

2015 年的树莓派 1B+ 至今仍在运行。
3 年前 新添加了 树莓派 400 服役至今。

1. gorm 不是精品，至少是鸡肋。无论其 api 风格还是库的实现，都能看出作者 与 go 本身的设计思想 以及其标准库实现 的对抗，但又不得不迁就的无奈(比如配置连接池，raw sql ，自定义 colum 类型的接口设计)
2. 既然是集成第三方库，必然需要封装，无论是出于统一业务逻辑(比如报错方式)，还是可维护性(仅就 go-redis 库，难道直接在业务代码里写 redis cmd ？为啥不封装一个面向业务的方法，将 key, ttl 等细节屏蔽)。
3. 如果是纯写业务，对性能，自定义底层行为，以及 第三方依赖管理 没有需求。应该是选择主流的框架或项目模版，按其文档进行开发。而非仅靠 stars 挑选第三方库并集成

"Then, our product failed to generate revenue. Our 500k developers would not pay to use it."

https://github.com/excalidraw/excalidraw
https://github.com/tldraw/tldraw
http://natto.dev/
最近 canvas 类的新项目挺多的，更不用说还有 figjam

@swhhaa 但是 AI 的 软硬件平台 迭代进化速度 比 人 更快。

@tool2d 我理解这里的 server 指的是 需要 auth 的网站。而不是苹果的 icloud 。而且这篇文档的下方，就是它在吹嘘通过 icloud 同步这些密钥多么靠谱。

@tool2d 使用这个 passkeys ，要开启钥匙串，且打开 icloud 。我自己本地搭建过 webauthn 的网站，用不同的苹果设备登陆，它提交的都是相同的公钥，那说明各设备间的私钥是通过网络互相同步的，而不是仅存在本地。

@GaryLz 如果按苹果现在的实现，本质上是 密钥托管服务。passKeys 是服务具体实现所用的协议及格式，而且数据会上云，对于中国用户来说是云上贵州。而且目前用户实际上无法直接得到密钥数据文件，但是托管设施的监管者却可以。

其实还是有局限性的，或者有待发展的。比如单账户多设备登陆，因为信任的是公钥，所以要么像苹果那样，iCloud 跨端同步 credential ，要么类似 github 有一个公钥管理界面。