先看看 deploy 或者 sts 版本有没有滚完，哪里出错，先保证业务稳定性，剩下的 ci/cd 问题可以慢慢修

{a} 与 {b} 相比，仍然存在差距

昨天晚上一个问题，使用 {a} 进行修复，修了 A bug ，出现了 B bug ，修了 B ，出现 A 。反反复复实在受不了，尝试 {b} ，一次性完美解决。


可在模板填入任何模型/客户端 ，适用于任何上下文（

主题好康，star 啦

btw 我参考了主题和设计给 Gitea 做了个 pr , 但感觉色系搭配有点怪（? 没有什么艺术细菌 www

https://github.com/lutinglt/gitea-github-theme/pull/35

RN 的可用性和隔壁的 kotlin compose-multiplatform 一个级别的，没法用，ai 可帮你简单解决不了各种诡异的 ffi 跨平台调用

云原生确实是非常值得了解深入的一方面，不是说有哪些项目，而是指相关的细节和考量，例如为什么在此处用 xx 而不是 xx ， 很多都是实际生产环境的经验总结

用 {1} 写出来的程序 用 {2} 审计出来了 {3} 多个 bug

其中 {1} / {2} 可替换为任何模型，{3} 可替换为任意正整数

> 玩家向管理员申诉，管理员就能封禁那个恶意节点

那如果管理员有坏人或者玩小团体有偏向呢

现在 pro 5x 额度掉的比之前快多了

> “ 6 个相信你的人” , “初期一个 pro 账号廉价账号加廉价账号甚至日抛,” “余量还能往外卖” , “掺水血赚一波”

这就是不要相信任何中转站的很小部分原因

A ➗ 都已经这样子了就不要给他当狗了 ...

中转站没有安全的，没给你响应内容替换为病毒脚本算良心的

顺便贴一下使用 chatgpt pro 的结果 , 无法跳步或 SIMD 就没继续看了 （：

这段原始代码不能直接用“常数快速幂”或“矩阵快速幂”跳过 1e14 轮。关键原因是：x ^= x >> 32 不是高低 32 位交换，而是把高 32 位异或进低 32 位；它虽然可逆，但和普通整数乘法的进位混在一起后，整体既不是模 2^64 乘法，也不是 GF(2) 线性变换。

设 B = 2^32 ，C = 0xD1342543DE82EF95 = aB + b ，x = hB + l 。一轮乘法后：

```
L = b*l mod B
H = b*h + a*l + floor(b*l / B) mod B
```

随后：

```
T(h, l) = (H, L xor H)
```

问题就在这里：H 里有整数乘法进位 floor(b*l / B)，而低位又用了 xor 。这会把“模加/乘”的结构和“GF(2) 异或线性”的结构打碎。

一个很小的反例就能排除快速幂假设：

T(1) = 0xd13425430fb6cad6
T(2) = 0xa2684a871f6d95ad

如果它等价于某个常数乘法 T(x)=Kx mod 2^64 ，那么应有：

```
2*T(1) mod 2^64 = 0xa2684a861f6d95ac
```

但实际 T(2) 多了 0x100000001 。这就是进位和异或混合造成的偏差。

同样，它也不是 GF(2) 线性的：

```
T(1 xor 2) != T(1) xor T(2)
```

所以这类写法都不成立：


```
// 错：只能用于纯乘法状态转移
x *= pow_mod(C, n, 2^64);

// 错：只能用于真正的 GF(2) 线性 xorshift
matrix_pow(M, n) * x;
```

这个常数本身确实是常见的 64 位 LCG/LXM 乘子； OpenJDK 相关实现也把 0xd1342543de82ef95 用作 LCG 乘子并说明其谱测试分数。也就是说，如果状态转移只是 LCG 乘法/加法，它能快进；但你这里把 mix 结果反馈回状态了，结构就变了。

@iqoo #29 所以这是打算利用 wasm 嵌入到浏览器做 PoW 来对抗爬虫或者其他自动化工具 ?

我去，初音未来！

看了下 bun 已经合并了 rust pr 了 hhhh ，这种项目还是在小圈子自萌去吧，架构/语言说变就变，旧的 pr / issue 完全不管，藐视贡献者玩独裁主义

https://github.com/oven-sh/bun/pull/30412

根本不需要分辨 , 大部分都是假的