https://www.phoronix.com/news/Wayland-X11-Performance-PorteuX
https://github.com/fulalas/wmbench/blob/main/lib/win_wl.c 人家手搓的BENCH_BACKEND，没有RPA..

@ AMD Ryzen 7 32GB of RAM

#bash #performance Wayland, xfwm4-gl 项目做的测评

"KDE Plasma on Wayland along with the likes of Labwc and COSMIC not being far off"

#PLT #design 还有VIM的吐槽（现在好些了）

默认非local、非public不会觉得自己很蠢吗？该不会还觉得做了什么了不起的虚拟机优化。

约定优于配置。声明式到底有多难？！

是什么让90%编程语言的作者像java的public那样到处拉屎。到处Local写的真的烦死了，ES6的箭头函数好点但也脑残

最后kt还是默认pub,Bun还是提供write， 所谓的防呆全都是自欺欺人。像bash那样 echo>file cat>>conf 到底有多难？！ 非要 mkdir, create, 甚至encode.. 有这点功夫不如实现json lodump

以至于python可以只因为不给人添麻烦而成功，和性能或设备移植性一点关系没有

几乎没有tui编辑器支持选区和复制粘贴吧？vim不支持Shift选区？

NVim按ctrlc 仍然无法工作

在vim因为cli而区分V-mod时，正常编辑器已经有minimap了

这等于要重新学一遍盲打。 有什么好处？真不懂visual和默认模式有什么用。

表面上Vim们是结构化，实际上minimap和悬停、Ctrl点击早就决定胜负。如果多标签和工作区都不自带，怎么编程。它有双空格yazi预览，但VSCode也只是有预览没做平铺，IDEA更是比vim好太多

真是匪夷所思，所有编辑框都支持的nvim反而不支持，还拿来做什么窗口分配调宽度。hjkl甚至在物理上都与意义不对称，别说好不好记，每次你都要翻译一下再跳词 😅

从vi开始就是设计弊病，不知所谓的单字符快捷键，就好比编程里的 code.golf ，直到现在Kate都支持文件夹和工作区了，nvim还是只有配色改了
有configUI，但只能预览，太蠢了。bash的set可以把状态变成字符串。如果做不到，把eval记录到文件都行。

r2用完全相同的交互，你看不到这样大的学习曲线

r2 完全可以在效率和易用上做到平衡，用REPL语言来做scriping和r2pipe，因为它的作者自己有能力包许多插件和h5界面，而Vimscript是 dirty hack，和TeX一样是外行碰运气

而且r2支持qt,h5。r2 的 s, 0x, / 跳转绝对让人立刻理解CLI编辑器的优势，而不是nvim这样，在VISUAL,NORMAL和莫名其妙的V-mode矩形选区里蹦跶

这个智能混搜没有命令搜索功能，也不能在 @或> 前缀时切换搜索，让人觉得莫名其妙

Snack自己完全没有这种omnibox吗？ 非要手写。Lazy本身也有一个which-key，却没有这种路由处理，简直就是加了一点 i 的蠢货命令行而已

看到gelguy/wilder.nvim的README里只有一张gif，下面每段代码都是折叠VimScript+Lua，我就明白乔布斯的Bozo是什么意思了。 简直和Linux没有Docker理念时一模一样，到处是没有性功能的样板

现在的 Neovim 生态给人一种“现代化”的错觉，完全是因为folke换上了 Lua、iconfonts、Catppuccin 主题、无边框浮窗和平滑滚动，精力还是在没有flow的地方。

r2、Blender 的按键/hint UI 很明确的告诉“高效编程者”什么是真正省键位—— 把能用的 action list 和快捷键写出来，统一可编程API，而不是拿键位和古怪的DSL糊弄人

这才是Hacker的【用户中心】，不是教人作事的Bozo。

Vim就需要只读和读写两个模态，默认读写。拿那些修饰键临时切换。 Normal模态下的键位真应该<5个， Lazy默认的<C-o>SPC不就只有一个，还带UI。

Vim和Kate的矩形选区也是反人类的功能点。 除了写文档注释 asciiflow.com （意味着不该由编辑器支持），我不明白矩形选区有什么意义，它既不酷也不hack，还不如加多光标和视口内重构。

这让我想到各种 cmd|awk {print $2}，一整个沙盒只为一个Tab split。AWK到今天还不如jq和ruby ARGF有用了。 😅

👍 folke（也是 LazyVim 的作者）将整个发行版设计为极度模块化、高性能且“开箱即用”的现代 IDE。snacks和which-key非常友好，而且像MT管理器那样强大

让我想到那个典中典的微内核与Linus之争了， 还“如果Linux是作业我给你零分”，我可去你的，对语义和场景无知到什么程度，

还真是和Gates说的那样， 真以为自己做了API和算法就有人用了，谁理你，这心智模型是什么碎片垃圾

#js #web React direct GPU

https://github.com/remorses/gpuix

GPUI is an immediate-mode UI framework — it rebuilds the entire element tree every frame. Instead of fighting this, GPUIX embraces it:
React reconciler detects a state change and queues host mutations (createElement, setStyle, appendChild, etc.)
applyBatch() validates and applies the complete commit to the Rust RetainedTree

值得注意的是，实现了一组基本的CSS https://github.com/remorses/gpuix#supported-styles

但文档一眼AI，甚至有点管理不住模块化的感觉（毕竟GPUI套娃），感觉最近看AI文档都有点ptsd了

你说不好吧，也不行，因为许多人写不到这么细，但是还是感觉很草蛋

#ai探讨

GPUI 的本质：
GPUI（Zed 编辑器用的底层）是 Rust 下受 Flutter/SwiftUI 启发的声明式渲染器。所谓 immediate-mode element tree，是它每帧通过 render closure 重新生成一套极其轻量的 Rust struct 视图树，依赖 Rust 零成本抽象、编译期静态检查与紧凑内存布局来保证极致的高帧率（60~120fps）。

React Reconciler 的本质： React 的 react-reconciler 是彻头彻尾的保留模式（Retained-mode）增量对比器。它做 Fiber diff、生成 patch mutation 操作指令流（appendChild, commitUpdate 等）。

所以他不得不在 Rust 侧人肉实现一个微型的 DOM 树（RetainedTree）作为中介缓存。 整个流程变成了：这是在 Rust 内存里造了一层 Shadow DOM，然后每次重新把这颗 DOM 树转译成 GPUI 的元素。

每次 React 提交 setStyle，Rust 端得把 CSS 解析成 GPUI 具体的样式属性。 而不是 Tailwind/SwiftUI：.flex().gap_2().text_color(...)

一旦把事件（onClick, onHover）暴露给 React，就意味着要跨 FFI 往 JS 引擎派发事件

--
哦，我大概理解为Rust是直接把 Gtk/Qt式的 children 放在func body里的，通过一个loop unroll做的ImGui，其实是真正的0开销
div()
.flex()
.child(text("hello"))
.child(button("click"))
不过， 不使用dirtyRect节省重绘在一些屏幕上没问题吗？

在现代硬件架构下，很多时候全屏重绘（Full Redraw）反而比 CPU 精细计算 Dirty Rect 跑得更快、吞吐更稳。
新时代（Metal / Vulkan / WebGPU / Apple Silicon）： 在 4K/5K 屏幕上，哪怕 60/120Hz，统一内存（Unified Memory）或现代独立显卡每秒几百 GB/s 的带宽根本不在乎你多填几个色块。

GPUI 是 Tile-based / Batching 渲染，不是纯暴力贴图

很多人对 Immediate UI 有个误解，以为它像 3D 游戏一样只要开着就在疯狂死循环 120fps 刷 GPU。 实际上 GPUI 是事件驱动的即时模式（Event-driven Immediate）：
屏幕静止、没有鼠标移动、没有光标闪烁、没有数据更新时：0 fps，完全休眠，GPU 功耗为 0。

听起来很有趣。虽然ImGui被许多人认为是现代、高完成度快速响应复杂UI的模式，优化上面也是有些区别的吧，比如文字渲染和dpi的问题、性能耗电，以及是否对前沿App普遍更好

底层直接接入系统的原生排版或工业级 HarfBuzz / FreeType / CoreText。动态 LRU 纹理图集： 只有屏幕上真正出现的文字字形（Glyph）才会被光栅化并写入 GPU Atlas。动态 LRU 纹理图集： 只有屏幕上真正出现的文字字形（Glyph）才会被光栅化并写入 GPU Atlas。

你需要手动写 ImGuiListClipper，在代码层人肉告诉引擎：“当前视口只看得到第 50 到第 80 行，请只执行这 30 次循环”。 GPUI 虚拟化滚动内置（Virtualization）： 深度结合视口，虽然外观像 Immediate，但其内部对长列表和富文本实现了类似 Retained 的分块测量缓存

ImGui 证明了“单向流与消除复杂状态树”的可行性，而现代 Rust 应用框架则是把排版、渲染管线、色彩管理和矢量栅格化的工业标准

看来还是不要陷入Rust狂热，reflow和复杂外语的渲染确实是大问题，不过GUI毕竟不是浏览器，这方面可以做两套运行时按页换。 onDPIchange 这个我是没见过，毕竟电脑屏幕不是游戏，每天有人场上换装备接着打
我说的按页换是指实现层，不是节点图层……

感觉dpi的问题被夸大了。 我是完全没有遇到，即便有两个屏幕时。感觉用两个屏幕像是差生文具多，为什么不搞个截图糊弄一下，状态管理问题才值得解决
好了，现在BeOS时代的矢量图又回来了，只不过以一种侵入式的方法，把本来重绘bitmap的问题变成了编程问题

🤔 叽里咕噜说什么呢？ 我看，我终于找到为啥读起来一眼AI了

这tm是拿人人手搓Office或Renderer的标准要求一个微信计算器小程序啊

（Event-driven Immediate）：
屏幕静止、没有鼠标移动、没有光标闪烁、没有数据更新时：0 fps，完全休眠，GPU 功耗为 0。

学到一个新知识： ImGui只是不做子区更新，不是60fps烧电池，但也不要以为显卡程序更先进了，文本+reflow上游戏UI没法看

Rust通过<T>单态嵌入和DSL直接把HTML弄成字节码的模式也很有趣, Container<Tuple<Text, Button>>，看起来那样比ts2c成功多了，如果用于常用App的话会跟手不少。过去很多人幻想“把 TypeScript 静态编译成 C/C++ 来替代 Electron”。

#vibe 感觉现在真是每个星期都能找到值得学习的项目，但是又没有在做什么。

这两天写了个Vim #lua 配置

正好把之前的 https://t.me/dsuse/22874 说法 实现了一下…… 我的天，还真是 iframe in Vim 😅

虽然整体设计不方便交流，但小细节确实非常搞笑（高效）。 唉，我是否也该变成楼上那种monorepo干三年的大佬呢？

还是要保持码场自由人的传统呢？ ……

#code init.lua 120行， 实现了KDE下往vim里内嵌窗口

象征性开源一下，没有什么功能。 有些感叹， 4天前说的概念，这不就用上了……

做了个C/C++窗体热重载功能， 对GTK挺好的（简直良心，比Web世界快多了），Qt的话官方IDE编译性能也不咋地，没有QML重载就做不出效果

当然也支持pyqt/gobj的，只是要写cpp exec()。

我觉得Vim应该也就拿来写个c系，py js 应该不搭的吧…… 但反过来，哪怕是G/Q的官方IDE也不如LazyVim

#ai探讨 https://chat.librechat.ai/share/gM26LMXRmBmB1MOtYI02Q

聊了关于此Vim配置（真的只是配置？？） 和vibe带来的问题。 AIGC的毛病不止影响“业余狂吹”，也会影响我们……

——他们都在说AI取代古法编程，可是我这一和你说，就发现有很多误会，根本做不到免费升IQ。 当然，Moonbit的张宏波认为AIGC对系统编程也是有帮助的（虽然他实际上没有多用）。 理解一门编程语言，和说它，是两回事

#linux #ai

托瓦兹表示，最终修复只涉及把错误的 round_up () 改为 round_down () 😅😅😅。不过，定位过程远比修复代码复杂：他累计添加 24 个补丁，用于逐步增加调试信息，并启动内核 18 次，才锁定内存破坏的具体原因。

托瓦兹表示在本次调试过程中，AI 承担添加调试代码和分析输出结果等大量重复工作。在调用处理过程中，AI 多次得出该问题无法解决的结论，不过在托瓦兹的多次协调指导下，不断推进让 AI 生成新的调试工具

https://t.me/im_RORIRI/34538

所以，比起有些人热爱 Code Agents ，我坚定不移的跟随 Alan Kay ，交互介质才是未来。我认为 User Interaction 和 Dev. Common Sense 的问题仍然没有得到解决

UX可不是一个节点/图层/事件入口而已，它就像typec和全面屏一样， 很多人误以为【即时连接】就是简单肤浅的，这种想法让它们认为更强大和复杂的 Agent 才是人机接口的未来。

💭 Bret Victor 所展示的那种【反AI】，不是因为他不知道老虎机能以多快的速度，实现哪些【网上早有，你没发现】的practice：比如仿照《植物大战僵尸》什么的

而是一种对【语言之死】的无视。 智能是有【载体】的，就像编程语言有高亮和Tab键，就像一本小说有【目录】和【主线人物】，一部视频游戏有【玩法/操作】和【数百个脚本】，而这些差异经常被力大砖飞派完全忽视， 就像F12常常被当作是Web世界的【常理】和空气

你不是在用Codex用LLM，而是在用【老极客的文字和行号】，这才是真正的模态，而且这不是最好的用法。

再过五年，我们看今天的Agent，可能就像看罗马数字或诺基亚上的26键一样，会觉得它fancy的动画和高度集成只是在掩盖罗马数字的晦涩。

SataEric
Claude 定价里那个“20x”真的很误导人。

$100 方案说是 Pro 额度的 5 倍，$200 方案说是 Pro 额度的 20 倍。听起来你好像能获得 4 倍用量。

但那个 20x 只适用于 5 小时使用窗口。每周限额其实基本只是 $100 方案的 2 倍。

我花了太多时间在互联网和 Reddit 上翻找才搞清楚。他们本来可以直接写明限额，而不是拿“20x”来宣传。

光是这点就能省下我几个小时的一头雾水。

推特上一群所谓KOL一样的大佬们的大脑一直都在升级，从mac升级到加密货币再升级到AI，就好比装在他们大脑位置里的是一个跟着潮流走，可拆卸的模块，今天拿出来一个新的把旧的换掉，就获得了新的姿势。

可惜了，他们唯独缺乏一个属于自己的大脑。

很多人讨论 MiniMax H3 Max

可以称之为 faster than real time 的视频生成模型：5 秒视频 3 秒出片，声音画面同一次生成。视频被创作出来的速度，超过了它被观看的速度，这意味着视频内容的「制作」和「实时性」被AI完成了双重平价化。

目前AI视频的内容还更多的在制作网剧， Startup宣发小视频领域发光发热。
刚好看到他提供免费使用接口了，不用注册每天可以生成五段5秒768p视频

#ai 感觉这个在中推的讨论度还不够高，但下一个全新产品形态的机会确实出现了。
https://x.com/whereisvivien/status/2093946583125803329?s=46