duangsuse::Echo pinned «>>大人，时代变了 https://x.com/matthewberman/status/2108245653843509415?s=46&t=rA_7EMcK9LnAsVTcD4VODA 二进制即发布 = 源码即发布 这个等式被坐实了。以前大家默认有一道模糊的墙，现在墙没了。这对靠信息不对称活着的软件是末日 #reveng #ai 软件末日论？ 逆向不能免费创造油猴这样的AOP环境 Neil Wood 和 Matthew Berman 都在拿 Napster 做对比：工具让“复制”变得极容易，行…»
Forwarded from Sukka's Notebook
Make Bilibili Great Than Ever Before 发布 1.9.0 版本，推出「Thread Ripper」功能，无需进行任何手动配置，自动评估 Bilibili 的多个 CDN 节点的质量（TTFB 和带宽）、选出最优的数个 Bilibili CDN 节点、多线程并发并行 缓冲 视频分片。该功能默认关闭，需手动打开。
该功能受 MrTangLuyao/Bilibili-thread-ripper 项目启发，但是仅使用了 不到三分之一的代码量（不包含代码注释）实现了 接近甚至更好的视频播放缓冲速度 和 启播用时。
具体取舍和实现细节参见 https://github.com/SukkaW/Make-Bilibili-Great-Than-Ever-Before/pull/31
该功能受 MrTangLuyao/Bilibili-thread-ripper 项目启发，但是仅使用了 不到三分之一的代码量（不包含代码注释）实现了 接近甚至更好的视频播放缓冲速度 和 启播用时。
具体取舍和实现细节参见 https://github.com/SukkaW/Make-Bilibili-Great-Than-Ever-Before/pull/31
GitHub
GitHub - SukkaW/Make-Bilibili-Great-Than-Ever-Before: A fork of the userscript "Make Bilibili Great Again", but with some experimental…
A fork of the userscript "Make Bilibili Great Again", but with some experimental features - SukkaW/Make-Bilibili-Great-Than-Ever-Before
duangsuse::Echo
但是跳跃能用！场景可复现！无限世界和生物正常生成！时间和天气也能调！
#ai对比
太权威了克总，替换400行代码，直接从白板单页变成这样……
https://codepen.io/duangsuz/pen/yyMvvvK
它手搓了一个DDA光栅+AO，连带hmTex体素量化的部分，另外写了mipmap八叉树剪枝，确保性能在手机上也够用。 这个质量都有光影感了
太权威了克总，替换400行代码，直接从白板单页变成这样……
https://codepen.io/duangsuz/pen/yyMvvvK
它手搓了一个DDA光栅+AO，连带hmTex体素量化的部分，另外写了mipmap八叉树剪枝，确保性能在手机上也够用。 这个质量都有光影感了
duangsuse::Echo
它手搓了一个DDA光栅+AO，连带hmTex体素量化的部分，另外写了mipmap八叉树剪枝，确保性能在手机上也够用。
#game #vibe
图为《迷你世界》2026 DLSS 画质。 许多人可能最初以为AI不能负责深奥的部分（比如向量几何，许多人以WebGL为“前端护城河”），实际上，vLLM最擅长的，反而就是这些部分！何况 shadertoy.com 上类似的训练数据是一大堆了（会者不难）
那么，真正的护城河是什么呢？ 可能是【时尚】，但更多在于那些错误的主流实践。 这些【自以为对】的事情，比想象中多太多了，以至于从0开始足够可以成为一种特殊的【工程师精神】。 取代人的不是vibe和Agent，而是那些理解设计与数据流的主创。（他们依旧是少数）
#algor https://t.me/dsuse/23035
XZP, X2V, Blk.xyzb'mat 这些概念，在做这个端到端无限体素viewer的过程中，仍然有效，只是AI五分钟把 facestrip(X2V) 和区块采样并加载(XZP) 这些过程写完了（就好像不存在这些节点），我负责打磨了下动感和dblcheck，过程中有微妙的加成…… 退一步说，具体的算法网上几乎没有资料，所以人类本来就应该【会念咒】即可，即用即学。
（事实证明prompt准确可以提升A\的智商，哪怕两次它会选择相同路径，明确决策后AIGC仍然会更牛逼）
图为《迷你世界》2026 DLSS 画质。 许多人可能最初以为AI不能负责深奥的部分（比如向量几何，许多人以WebGL为“前端护城河”），实际上，vLLM最擅长的，反而就是这些部分！何况 shadertoy.com 上类似的训练数据是一大堆了（会者不难）
很多人要么直接做完整 3D 体素（内存爆），要么就做纯高度图地形（不是体素感，不含洞穴、悬空建筑、复杂室内），两边都没走到这个折中点。光线步进（DDA raycast）在2010性能完全不够看。 我这里也支持了传统mesh，确实比DDA微分还快30% ，这里是端到端只读，工程复杂度并不高。 现代移动 GPU里，这种准光追平衡性还好
那么，真正的护城河是什么呢？ 可能是【时尚】，但更多在于那些错误的主流实践。 这些【自以为对】的事情，比想象中多太多了，以至于从0开始足够可以成为一种特殊的【工程师精神】。 取代人的不是vibe和Agent，而是那些理解设计与数据流的主创。（他们依旧是少数）
#algor https://t.me/dsuse/23035
XZP, X2V, Blk.xyzb'mat 这些概念，在做这个端到端无限体素viewer的过程中，仍然有效，只是AI五分钟把 facestrip(X2V) 和区块采样并加载(XZP) 这些过程写完了（就好像不存在这些节点），我负责打磨了下动感和dblcheck，过程中有微妙的加成…… 退一步说，具体的算法网上几乎没有资料，所以人类本来就应该【会念咒】即可，即用即学。
（事实证明prompt准确可以提升A\的智商，哪怕两次它会选择相同路径，明确决策后AIGC仍然会更牛逼）
duangsuse::Echo
取代人的不是vibe和Agent，而是那些理解设计与数据流的主创。（他们依旧是少数）
#statement
🤔 许多人会用各种新闻学（比如Jev和果蝇的各种夸大/不实宣传）把LLM们吹的无所不能，IQ至高，【不可战胜】，可实际上，它们仍然只有一份上文，一把探照灯。因为屏幕外边的最终用户是这样的。
软件创作者的本来任务，就是多见识一些东西，哪怕不求甚解，做个深广的'T'型人才。 尽管，Agent比人更擅长活在操作系统里不知疲倦，所以不需要人替它们烧脑、剪枝，但用户，却不是如此。
机器长了轮子，不需要护膝，可是人机界面、人际平台，始终需要人来理解。
总是有人试图用美容药和垄断的“资源堆砌法则”，来夺走每个人天赐的好处，但结果却是被【偶然性】次次打脸。 所谓手搓、工匠精神，与AIGC的关系，也应该如此。 📚
那么，【品味】难道不是可以生成和【一键继续】的吗？ 理论上，未来+1年的AI，可以顶你一辈子ID吧？
答案或许是：我不怕有人当copycat，因为我的“正确”应该是他们忍受不了的风格。
隐藏层的复杂性没有上限，但是，接口是由人来声明的。 我学的编程，更多是一种面向接口、强类型、正交组合的思维的哲学，而不是数学或“Excel的三种写法”（表单 class sql）。
其实，画师商单的弊病，本来就很明确：
- 高度任意性（缝石块），产品可以凑合，一幅画基本就是另外两幅换脸换笔刷，做个风格迁移
- 无个体差异，一个单子让什么人画，只有<5%的人能在不破坏的前提下融入风格
- 小众冷门，本身就（不像动漫原画）受主流待见，商业模式还在70年前
- 绝杀： 人手只能一笔笔画，AI能按图块和风格“绘画”， IO 模态的降维打击。 就像是还没有【以图搜图】【以图荐图】时手打的标签系统，到【谷歌识图】那样的绝杀。
编程里通过声明式框架，AI和人站是在一个模态上继续编程，并且方便压缩。 你很少用过【无法言喻】的软件，但软件逻辑本身，是丰富且开源的，作者和最终用户边界并不明确
通俗的说，IT 知识接受过更多【大众化考验】，所以努力更能看到成果
🤔 许多人会用各种新闻学（比如Jev和果蝇的各种夸大/不实宣传）把LLM们吹的无所不能，IQ至高，【不可战胜】，可实际上，它们仍然只有一份上文，一把探照灯。因为屏幕外边的最终用户是这样的。
软件创作者的本来任务，就是多见识一些东西，哪怕不求甚解，做个深广的'T'型人才。 尽管，Agent比人更擅长活在操作系统里不知疲倦，所以不需要人替它们烧脑、剪枝，但用户，却不是如此。
机器长了轮子，不需要护膝，可是人机界面、人际平台，始终需要人来理解。
总是有人试图用美容药和垄断的“资源堆砌法则”，来夺走每个人天赐的好处，但结果却是被【偶然性】次次打脸。 所谓手搓、工匠精神，与AIGC的关系，也应该如此。 📚
向量几何、着色器、网格遍历，看起来专业，但其实就是【风格迁移】类任务。 与其说是AI足够聪明了，不如说是【反馈循环】、低噪音、高信息交叉的机器学习模式，降维打击了【瞪眼法】的deadfish传统CV/CG领域。
那么，【品味】难道不是可以生成和【一键继续】的吗？ 理论上，未来+1年的AI，可以顶你一辈子ID吧？
答案或许是：我不怕有人当copycat，因为我的“正确”应该是他们忍受不了的风格。
隐藏层的复杂性没有上限，但是，接口是由人来声明的。 我学的编程，更多是一种面向接口、强类型、正交组合的思维的哲学，而不是数学或“Excel的三种写法”（表单 class sql）。
《软件工程》会和“绘画圈”一样出问题吗？
其实，画师商单的弊病，本来就很明确：
- 高度任意性（缝石块），产品可以凑合，一幅画基本就是另外两幅换脸换笔刷，做个风格迁移
- 无个体差异，一个单子让什么人画，只有<5%的人能在不破坏的前提下融入风格
- 小众冷门，本身就（不像动漫原画）受主流待见，商业模式还在70年前
- 绝杀： 人手只能一笔笔画，AI能按图块和风格“绘画”， IO 模态的降维打击。 就像是还没有【以图搜图】【以图荐图】时手打的标签系统，到【谷歌识图】那样的绝杀。
编程里通过声明式框架，AI和人站是在一个模态上继续编程，并且方便压缩。 你很少用过【无法言喻】的软件，但软件逻辑本身，是丰富且开源的，作者和最终用户边界并不明确
通俗的说，IT 知识接受过更多【大众化考验】，所以努力更能看到成果
Forwarded from duangsuse
Daniel Lemire's blog
Parsing JSON at tens of gigabytes per second… in Python
Python used to have limited parallelism, due to its global interpreter lock (GIL). Only one thread could run Python code at a time. Python 3.14 comes in a free-threaded version (python3.14t), without the global interpreter lock. Several threads can now run…
Daniel Lemire's blog
Parsing JSON at tens of gigabytes per second… in Python
source #py #perf
我突然觉得释然了。 为了屎山codebase能“免费”提升它们从来用不到的吞吐量， 许多人真的会给母猪上唇膏并且开始f...它了
JSON，在>80%应用里，是一个连 [{},] 的excel模式和 {_5args: true} 都没有优化的格式，甚至也没有约定 {Duck:} {Cat:{arg:"wtf"}} 的type多态。
在我眼里，这就像一个逆向工程工具看不懂libc，或运维panel不会用 -k v 参数理解bash接口那样， 但是，它偏偏很快。
他们宁愿在端到端上，投入无数奇技淫巧的精力，也不愿意像CBOR（预训练字典）或flatbuf一样，提供一套新的、协议化的，是【对人类有意义】的选择，从一开始就没有这些跳空格 s.indexOf("\"") 的问题， 甚至是让JSON兼容一下csv模式，而不是 [{},] 的无效重复AoS
如果一开始就基于flatbuf+js Proxy 或tg的TL这样的心智模型（从原理上就更好优化）， 这些文章里90%的概念可能根本没必要提出。 以后就连AI也会在JSON这样连Excel CSV 都不会压缩的【最佳兼容性实践】上，继续搭建吧
预训练字典和SoA/AoS变换，可以说是通用性相当好的选择。 就像对于Electron的体积，像./gradlew那样【用到时再下载】是更好的理解。 但是，他们一直在两个极端之间吊着。
这样的软件工程，真的早点毁灭吧。 端到端的优化AI也完全可以生成啊
Parsing JSON at tens of gigabytes per second… in Python
source #py #perf
我突然觉得释然了。 为了屎山codebase能“免费”提升它们从来用不到的吞吐量，
JSON，在>80%应用里，是一个连 [{},] 的excel模式和 {_5args: true} 都没有优化的格式，甚至也没有约定 {Duck:} {Cat:{arg:"wtf"}} 的type多态。
在我眼里，这就像一个逆向工程工具看不懂libc，或运维panel不会用 -k v 参数理解bash接口那样， 但是，它偏偏很快。
他们宁愿在端到端上，投入无数奇技淫巧的精力，也不愿意像CBOR（预训练字典）或flatbuf一样，提供一套新的、协议化的，是【对人类有意义】的选择，从一开始就没有这些跳空格 s.indexOf("\"") 的问题， 甚至是让JSON兼容一下csv模式，而不是 [{},] 的无效重复AoS
如果一开始就基于flatbuf+js Proxy 或tg的TL这样的心智模型（从原理上就更好优化）， 这些文章里90%的概念可能根本没必要提出。 以后就连AI也会在JSON这样连Excel CSV 都不会压缩的【最佳兼容性实践】上，继续搭建吧
预训练字典和SoA/AoS变换，可以说是通用性相当好的选择。 就像对于Electron的体积，像./gradlew那样【用到时再下载】是更好的理解。 但是，他们一直在两个极端之间吊着。
这样的软件工程，真的早点毁灭吧。 端到端的优化AI也完全可以生成啊
"给母猪上唇膏"这个比喻不是针对simdjson，而是在问，为什么RPC问题里最最基本的子部分（比如csv），
想要压缩+提速，需要端到端（人类不可介入）的优化？做在与 TLS 平级的层面不行？ py/js dict 和元编程的层面呢？分出【测试100%覆率期】和高效运行期？ 这些都不需要很大精力，明显比榨干最后一个cycle和L1 cache，少多了，而且更加可控。
但是，他们还是愿意做这样的，无需理解任何新决策、新协议、新flow，未来连AI都可以loop的JSON.parse单函数优化。
对A\ 5.1: 你还是不明白。 我说的是指理论上的，你一直在提Proxy这些实现问题，哪怕我在编译期Proxy又怎么样呢
至于HPACK的问题，分出"测试期"和"高效运行期"，我是指【C/S管道】本身要有字典训练命令。你还是不理解