https://mmm.page/
https://workshop.cjpais.com/projects/dumpster #design #tool

https://themackabu.dev/blog/js-in-one-month #dalao #ce 兽圈聚聚多啊

花了10分钟看文，看完后才发现他是从parser开始写的（BDWGC+libuv+computed goto for FFI/动态链接），最初通过jszoo suite 用了一个月2MB，现在已经能完整支持npm平台要求的API 9MB

> The manual free-list GC was disabled and enabled hundreds of times, each attempt breaking another core part... everything was breaking when I added JSON support.

他甚至手写了一个Trie关键词高亮.. https://github.com/theMackabu/ant/blob/master/src/highlight/iter.c#L33

新一代真是Lua.so都能随便写出来了

IT 界经久不衰的都市传说：永远不要轻易质疑头像带兽耳的开发者的代码能力。

😱
https://yuk1i.github.io/os-next-docs/lab/lab2/ 这个又是手搓内核的

#py https://moelove.info/2017/10/21/当执行-python-xxx-py-时-CPython-到底做了什么/

#rust
#selected 这个大哥的博客真不错，写了很多科普的文章。
https://luoyuxia.github.io/archives/
https://luoyuxia.github.io/posts/rust用链表理解所有权借用与-unsafe/

#win https://blog.batkiz.com/posts/talk-about-scoop/ winget !
https://blog.batkiz.com/posts/software-on-my-computer/

HeHeDa: jandan.net/t/6180784
OO: 104 XX: 4
墨丘利: 几年前有一次，要一大早开车去一个地址在海边的公司开会，要高速开60多公里。当时路上车极少，纯大脑放空的行驶着突然注意到蓝天中正飘着和一大片极其壮观的白云，和此图很像。那一刻的绝景，让我感觉一股无比的自由畅快，仿佛只要开着爱车，我就哪里都能去，顺着路继续开，我就能飞上天空，没入那块云，而穿过这片云，会到达一个梦境般的世界
OO: 62, XX: 1

#tool https://www.morphicons.com/#how #cg

最简单的lerp一下 path[d].xy 就行了，这个还做了形态学/启发式，可以看到分析出的morph策略

如果是 Anime.js / Snap.svg 或许就只支持一笔画的morph

节点补全（Point Padding）： 若 A 有 4 个点，B 有 8 个点，计算引擎需在 A 上自动插入额外的插值点（或将直线转换为控制点重合的贝塞尔曲线），使两者的点数和命令类型完全对齐（Resampling / Sub-division）： 利用 B-spline 或贝塞尔曲线弧长重采样（Arc-length Resampling），在点数较少的路径上补全虚设点

顺序重合与寻优（Shape Matching Algorithm）： 计算两形状上点的最佳映射关系，避免旋转翻转过程中的路径相交或不自然扭曲（如采用最小位移代价算法）。
旋转与方向翻转： 没有启发式匹配时，直接 lerp 会导致图形在形变过程中出现自我纠缠（Self-intersection）、折叠或顺逆时针翻转。

没错，同款算法也被应用在Zbrush的物理笔刷、SDF大号字体、div layout 剪裁缓动里，不过Live2D这样更有价值的反而不需要这般数学了，要手K
Voronoi 图（泰森多边形） 或 Delaunay 三角剖分，将复杂的矢量路径转化为多边形网格或隐式场（Implicit Fields / Distance Fields）。
这使得引擎能够轻松实现“一变多”或“多变一”：例如把一个水滴图标（1 个连通域）瞬间融化分裂成 5 个离散的小圆点（5 个连通域），过程如同液体溅射般自然。

#tool https://shangchenzhou.com/projects/ProPainter/

基于运动模糊（小脑/光流）的不透明马赛克去除模型

在将前后帧的真实像素/特征对齐回当前帧后，如果视频全程某个角度从未暴露过真实面貌，光流传播也救不了时，这个 Transformer 就会充当“大脑”：只针对马赛克掩码区域（Masked Tokens）进行高效的自注意力计算（Sparse Attention），生成语义合理且帧与帧之间绝不闪烁的新内容，补齐最后的缺失角。

HeHeDa: jandan.net/t/6191287
OO: 91 XX: 4
蛋友e63b64bec06ee: 博大精深
OO: 15, XX: 0

#ai探讨 #cg https://fixupx.com/virushuo/status/2086978049115861104
https://share.gemini.google/qI3hnXxriJox
AIGC 与“小虎队解谜卡”——纯文字、短篇小说如何隐写

> 这么一说，替换和slice都不能影响隐写的99%识别，那直接1千人里选一个人写500字就能判定是谁写的了

区分 1,000 个人需要多少信息量？只需要 log2​(1000)≈10 bits 的信息熵。数百 bits 的容量远超区分 1,000 人（甚至全地球 80 亿人）所需的 10~33 bits。

图片 LSB 隐写 (RGB 1-bit)LLM 概率水印 (Green-Red Rule)，其实并不是硬阈值vs logprob 的区别，仅仅是后者有一个混淆口令(RNG salt)，并且需要传达的信息量低的离谱。 对中国读者来说《小虎队》的那种解谜卡片就很像后者，只不过A\ 用许多卡片来读水印

这就好像把全人类蒸馏成一个Collective，然后用speakerID来理解也完全和当下的世界一模一样

为纪念全党全军全国各族人民公认的享有崇高威望的卓越领导人，伟大的马克思主义者，伟大的无产阶级革命家、政治家、军事家、外交家，久经考验的共产主义战士，中国特色社会主义伟大事业的杰出领导者，党的第三代中央领导集体的核心，“三个代表”重要思想的主要创立者江泽民主席诞辰一百周年，中央电视台将从今日起，连续六天播出文献纪录片《江泽民》。

#rust #os
#rust 递归的href失效链接列举器
https://share.gemini.google/7nZmDVJC9hdF

5 年！5 年！lychee 最初被设计为一个单向无环流水线（DAG Pipeline）

强行增加“从 Response 回传到 Input”的反馈环时，遭受了 5 年的架构折磨。
🦀

需求：每次开发者提交 PR 时，CI 必须确保这几万个文档页面里的所有超链接（包括内部锚点和外部网址）都不是 404。
需求：扫描一个拥有 100 万个 URL 的大型电商网站，分析网站的拓扑结构、找出“孤立页面（Orphan Pages）”、301 重定向循环以及死链。

如果你只需要结果：在 CI/CD 自动化流水线里，开发者只需要知道“我的文档今天有没有产生死链”，这时 lychee 丢弃 Body、秒级跑完、只输出 Report。

#go muffet 等工具从诞生第一天起就是标准的网络爬虫架构（Cycle Graph） broken-link-checker

sync.WaitGroup、并发 Set 以及轻量级 Goroutine，让它在无需设计复杂框架的情况下自然避开了 Rust tokio Arc<RwLock<...>> 的毛病
入队 CAS 去重、并发限制器、Abort Signal / 零拷贝流式丢弃

1. 主线程只需要调用 waitGroup.Wait() 即可安全地等待所有并发任务归零。如果仅靠“队列为空”就判定退出，程序就会提前终止。纯粹的 true / false 在真实复杂的链接检查器中很快就会不够用（null=正在处理）
1. 为了在成千上万个并发 Task 之间共享 Visited Set（去重集合）、Rate Limiter（限速器）：复杂的多端 Channel。Goroutine 成本极低（轻量级 M:N 协程 + GC 管理内存）
1. 并发限制器(-j N)和pipe的重叠。 LinkChecker（Python 版）甚至在源码注释中明确写道：“不要给 URL 队列设置最大长度（max size），否则当所有 worker 线程同时调用 put() 时会导致死锁。”

🦀听起来不像我在编程，反而是Rust在写我。那么，hyperfine跑分怎么样？

网络检查一个 URL：DNS 解析 + TCP 三次握手 + TLS 协商 + 服务器响应，延迟在 数百毫秒级,比SSD性能直接相差了 100 倍以上。

muffet（Go）作者第一天利用 Go 标准库敲出来的代码，跑分已经达到了 Rust 版 lychee 80%~90% 的性能。更快几秒钟、省了几十兆内存。 💭

这个朋友用 LLM 批量写了好多这类的文章，但是写的很好。
说实话我不知道是好是坏，觉得有点悲伤，曾经想研究透一个东西学习一个东西需要几天甚至几个月一点一点的学习，一个问题一个问题的解决，而现在可能只需要设定好一个风格，一个 /goal.
曾经写一篇这么好的东西，需要花非常多的精力，未来有人读到这篇博客还可能在下面评论交流，发邮件感谢，甚至交流过程中成为朋友（我就有几个朋友是这么交的），现在呢？大概率不会了，未来的自己会看么？我也不确定。。。

https://ursb.me/notes/

#pingback #design NZ,JP,KR 都去过这个大佬

https://liuaaron.com/ 可以作为demo了

#tool https://t.me/im_RORIRI/34385 CJK align-center

https://amruth.ai/ 这个不比JB官方牛逼多了，不是 webgl 胜过gl

Spotify把Claude、Gemini和Codex塞进一个总控台，1300名工程师已在用

Spotify 把内部使用的多 Agent 工作台 Xirp 开放给外部开发者。Claude Code、Gemini CLI 和 Codex 都能接入。开发者可以同时跑多个 Agent，也能中途换工具，原来的工作状态继续保留。

Xirp 会给每个会话单独开一个 Git worktree。多个 Agent 可以同时改一个项目，互不干扰。Spotify 称，Xirp 最多能协调 50 多个并行会话。内部已经跑过 3.6 万多次，1300 名工程师在用。

Xirp 还能接 Spotify 的企业开发者平台 Portal。企业可以把自己的服务、API、技术文档和团队信息集中到 Portal。Agent 开工前可以直接读取这些信息。做完后，会话记录也会存回 Portal，其他人或 Agent 可以接着做。

Databricks 今年 6 月开源的 Omnigent 跟它属于同一类工具。两者都在现有 Coding Agent 上再加一层统一管理。Omnigent 更强调权限、成本、沙箱和多人协作；Xirp 更强调多 Agent 并行、工具切换，以及通过 Portal 接入公司内部知识。

Spotify

#dalao https://magcius.github.io/xplain/article/index.html x11 API #cg #selected
https://haqr.eu/tinycompiler/ #ce 这个也是很好的，原理剖析

最近读到一些文章认为Wayland的集成度太低了， wl-clipboard、Ctrl+O/+S 文件选择器和OBS支持都很差，破坏了既有的 xdo/xclip 工具，甚至 AppImage 的开发者都这样认为
https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277

不过一位KDE开发者也为2026年的wayland+XDG(DBus, Portal..) 解释 https://pointieststick.com/2023/12/26/does-wayland-really-break-everything/

Nate Graham 的核心逻辑在于：Wayland Pipewire 和 XDG Portal 不是为了打破而打破，而是在为未来二十年的 Linux 桌面搭建能持续维护的“骨架”。 X11 时代许多看似“爽快”的功能，背后全是不计后果的架构借债；而 KDE 的态度非常务实

不过，wl再差也不太可能突破安卓11【容器化】的底线了，那个性能和开发难度真是有巨大问题，SAI安个apk都遭殃 🥱

#bash Linux桌面的架构变迁 🖥

老协议就不能用吗？FTP依然被用于SSH文件分享，ELF也万年不变。 我们通常认为Xwin的失败之处在于socket的“过度网络化/浪费拷贝”、安全问题和积重难返

其实，现代基于GPU对象id，并没有性能问题，至于.ssh都能乱读的发行版就更别说啥点击劫持和keylogger了。X不如wl那样面向事件，并且给予xywh（无装饰的窗口）混合器的编程自由度较低，在一些细枝末节（比如HDR/VRR/触摸板手势）上没有更新，它不受 Waydroid; Omarchy(Hypr.land) 和 Niri （推广一种横向平铺的GNOME动态工作区）支持

X11体系里KWin这些东西更像是xywh上画一个标题边框的外挂，一个旁听生（当然，这不影响XFCE高级的透明混成、KDE和Compiz的GL果冻窗口），比如systray的实现，就是硬塞一个32x32窗口到任务栏

但是wl里，以牺牲兼容性的方式，KDE和GTK4获得了xywh摆放的主导权，然而实际上，wl并不比X快多少，甚至有许多功能（如不可变色温和整数倍缩放）也是近年才改掉的。wl也没有在发展中规避错误，比如，面向事件到以为wm比mpv/ffmpeg更懂rAF帧回调和解码

按理说wl不该犯这样蠢的错误（比如Ctrl+C/V/O/S的基本功能性统一、截屏录屏、动画布局和av解码调度器的区分），再如systray被简化为 SNI API 的icon和目录树（如同浏览器插件右键菜单），明显是GNOME中心的设计，很可能要像Android那样，等加了Calendar和Clock，番茄钟什么的，架构又腐烂了呢？当然， notify-send 确实很方便

总而言之，KDE的决策是不错的（包括他们最近在SteamDeck开箱即用的亮眼表现），wl仍有坑要踩

KDE社区的兼容性一贯是非常好的，包括不歧视Win快捷键、兼容微软/谷歌/OSX的设计风格（MD3的颜色设计、klassy、liquid glass 都有AUR特效插件）

在SteamOS上的gamescope利用了wlroots的嵌套合成器特性，让游戏窗口1920x1080 60 FPS超分辨率执行，这个就真是和Sunshine或Proton一样神的图形应用了。设想一下，还没有任何一个消费级OS能实现在截屏时提升视频/网页/App分辨率的效果，但是wl能零摩擦的做到 👍 🎮

Wayland相对于X11有什么技术架构上的优势？
--
https://www.dedoimedo.com/computers/xlibre.html 认为X11没有造成实质性问题且性能更好

Peek，是一款用户体验堪称巅峰的GIF录屏应用。它超级直观，只有一个透明窗体和按钮。如果不使用快捷键来启动录屏，大概没有录屏集成能做到这样零摩擦。它的后端就是 ffmpeg grab 但窗口化选区的可拖动设计可称绝唱

因为wl的“用户不需要”杀死了Peek

--
套一层UNIX socket真的有很大问题吗？ client会把pixmap拷贝一次？

X11和wl实现的都只是 wdiv2bmp (roots和xwyh) 与pointer事件这样的简单功能
--
没错，相对于普通div和窗口装饰器，roots 还包括IME、menu等特殊类型窗口(surface)、显卡UMat和dirtyRects/VRR/DPI等性能要求。wl基本上就是把skia/svg的职务交给GTK4/Qt6去办了，至于截图什么的就开始碎片化了

在OBS和RPA的支持上，跳过了Pipewire的Sunshine显著快于wl的远控。wlroots; wev; kdotool 很明确的展示了桌面ClientRect的特性，但它们的完成度相对于成本和代码行数并不高

wl的架构用一个UMat+面向事件和最小权限就能说清，但它的考量呢？ 截图录屏远控（性能），甚至剪贴板DnD输入法，这些都是显然预见的到，兼容性会出问题的。直接撕裂成GTK/QML/wlr三派，又不让用root桌面。
--
值得注意的是，全局热键、全局菜单栏、屏幕色温和skipTaskbar也是和剪贴板、sysTray、MIME打开或发送同级的桌面协议问题

如果KiCAD和Krita这些“原生”应用都认为Wayland授权弹框的缺位让旧功能的兼容（例如简单的记住窗口位置）都不可能，是否说明wl必须把XWayland作为ABI保障来维护？
--

Linux的容器化使任何一个curl|bash都能访问.ssh和浏览器cookie，又让Telegram.AppImage/Flatpak无法默认写入Downloads文件夹（需要手动剪贴），居然有人在说【安全可靠的窗口系统】。

wl没有的协议很大程度上都在D-Bus的通用服务（如Pipewire）里实现了，但这些服务并非在GTK/QML/wlr下都可用

mpv开发者表示，对于任何跨平台运行的程序来说，wl逼我们不能“浪费”帧，但却忽略了你可以把交换间隔设为 0 然后直接把帧扔掉。

#ai探讨 #bash 上文，感觉这些人还挺严肃的讨厌wl