多买几个机器不就好了，小主机也不占地啊，可以用 kvm 切换或者直接远程控制

ai 的迁移能力超乎你的想象（）
只要别太离谱，基本上你想到的小众语言 ai 都可以很快胜任
而且移植库也更方便了，以前还要纯苦力移植，现在 ai 翻译移植库非常容易（）

其实主要问题是
https://laike9m.com/blog/avoid-mini-frameworks,171/
引入了太多不属于库的新概念，虽然你可以解释说是大家最后都会这么做，然而最后会这么做和一开始就要这样做还是不一样的（）

6202 年还在依赖实验性装饰器这点就已经输了（）
zustand 里想用 class 其实可以直接做一个中间件来做，以下是 ai 一秒生成的代码，可能有误，但大体思路明确

https://grok.com/share/c2hhcmQtMi1jb3B5_424db85c-b856-4a85-a83e-d185fca2c8b7

zustand 的核心就是那个 selector 机制，避免了 context 的牵一发动全身问题
其他的一切都只是为了一个简单好用的 api ，包括那个 set get 的设计，做成这样是为了能方便被中间件扩展，某种意义上说，相比于函数式或者面向对象，zustand 的 middleware 设计更偏向于 aop 也就是面向切面编程

主要是就算你想在外面直接调用 set 也可以使用那个 selector 函数的 setState 方法，所以我完全不知道为啥你有导出 set 的想法（）

@jaydenWang zustand 的派生不是直接在 selector 里写的吗，我倒好奇你是怎么用的
语法上确实没阻止你直接导出 set 但一般人也不会这么写啊

zustand 里唯一看上去是函数式相关的，大概只有不可变数据和纯函数更新这两点了，但完全不能和真正意义上的函数式打等号，一些资料里这样写单纯是因为他们没搞清楚概念，真正重要的是那个 flux 模型，它看似与函数式紧密联系，但实际上是完全不同层次的抽象，只能说有一定的相似性

Flux 的核心原则包括：
单向数据流：数据流动是单向的，避免双向绑定带来的复杂性和不可预测性。典型流程是：View 触发 Action → Dispatcher 分发 → Store 更新状态 → View 重新渲染。
单一真相来源：应用状态集中在 Store 中，而不是散布在各个组件。
动作驱动更新：状态变化通过明确的 Action 来驱动，便于追踪和调试。

zustand 只是在这个基础上把开发体验做了一定的提升，简化了使用：
不需要 Dispatcher 或严格的 Action/Reducer 分离。
直接在 store 中定义状态和更新函数（这些函数类似于 Action Creators ），通过 set 函数不可变地更新状态。

至于为啥不用 class ，还不是因为 js 本身局限性，无法高效跟踪深度嵌套类型的变动，只能采取创建新对象的方式来触发更新——例如 zustand 同一家出的那个 valtio ，就是使用 proxy 做的状态跟踪，为了解决 js 的局限性，其实不仅带来了很多损耗，也需要遵循很多规则（ this 使用规则，还有 proxyMap proxySet 等原生对象包装）写才不会出事

我翻遍了资料也没看 zustand 说它是函数式啊？能不能先别立一个稻草人呢

打字延迟这些你需要优化的可能是用 startTransition 等功能来降低更新重要性，但前提是你的代码支持这样的操作，不然可能会导致意外的问题（主要是由于全局状态管理的问题，大部分全局状态管理库所用的机制和并行渲染有本质上的不兼容，用 startTransition 并没有作用或者会导致数据出错）

catppuccin 的 latte 配色（

为什么这种 1 秒钟就能搜索到的内容要放在这里问。。。
https://wiki.postgresql.org/wiki/Multithreading

@sagnitude 这套方案不是很行，你一个约束可能要写好几遍（考虑嵌套对象数组），因为 ts 没对 decorator 做任何类型检查，lint 也没有，自己写容易写错不一致，decorator 只存在于运行时基本上还是缺点，毕竟你定义数据库结构，还需要一个运行环境，运行前还得跑 transpiler （毕竟也没 runtime 支持 decorator ），那为何不一开始就直接 compile 解决呢（）
别跟我说 decorator 更成熟，现在摆着的就是两个互相不兼容的实现，运行时表现完全不一致，根本不能说是成熟

@james122333 这有啥办法，其他 ipc 工具没第三方支持你自己搞等于没用
wayland 自己的那几个 protocol 根本不够用，官方全在搞真空中的球形鸡

wayland 做的安全也是完全伪命题，因为大部分协议跑 dbus 上，但 dbus 的安全性基本纸糊的——你的 keychain 一旦解锁，实际上任何 app 都能读取其他 app 的 secret ，那个验证完全防君子不防小人
dbus 本身也一大堆问题，实现宽松，不强制约束序列化格式——你发个不良输入可以随意崩服务端,官方还十分鼓励厂商特定的扩展，而且那些扩展还几乎都没啥文档，不说扩展，本身 dbus 的标准也混乱无章文档和没有一样，导致实际实施标准的人也瞎写，你真按标准去读反而各种缺失字段
之所以 wayland 的 portal 搞得一地鸡毛，就是 dbus 本身的坑，各家实现看似相似，实际完全不一样，没有一个统一能用的实现
x11 之所以看上去比 wayland 好，是因为起码很多基础功能不依赖于 dbus 实现，现在 wayland 不做基础功能了，全依赖 dbus ，底裤就暴露出来了

有影响的，即使是国内的模型也建议全英文 prompt （特指编程任务），并且源代码里也最好不要含有任何非英文注释

本地模型上下文你能开多少呢，64k ？ agent 起码 128k 起跳才有价值

有一点要注意的就是 amd 显卡 HDMI 输出在 linux 下被限制到最高 4k60 ，因为专利的那些破事，但 DP 接口没有问题，DP1.4 4K160 输出是没有问题的（当然 1.4 的肯定有 DSC 压缩）

谷歌的日常 feature gate 测试，新功能都是按一定百分比推广的，这样有问题了也可以立刻停止推广甚至回滚，你要有几个亿的用户量你也不会一次性把新特性全部推给所有用户