#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

我大概一生也成不了这样精彩的人，但是看着他们的生活，从中找到几本想看的好书，想玩的游戏，也非常开心了。

https://tangdh.life/posts/interesting/ncdu/ #dalao #dev #db 还会优化向量搜索 BPF 🤔 感觉很牛逼
#rust
#cpp https://tangdh.life/posts/c/rvo/

我们的实验结果表明，io_uring 显著提升了性能。这主要归功于 io_uring 的异步特性。fsync我们无需等待每个调用返回结果，而是可以提交 I/O 请求，并在没有其他任务需要处理时一次性全部处理。

好家伙，最后还是批量操作文件保存提速…… 太合直觉了

#game #dalao https://wszqkzqk.github.io/2026/02/20/PvZ-Portable-Zombotany-Image-Fix/

访问 浏览器免安装体验页面，导入你的 main.pak 和 properties/ 目录，点击 Start Game 即可开始。存档自动保存在浏览器的 IndexedDB 中

笔者在大一时曾经尝试写过 Python 版植物大战僵尸。那时候笔者还在起步阶段，用 Python 和 Pygame 做了一个简单的练习，主要目的是学习 Python 和面向对象编程。那个项目虽然能玩，但在还原度上和功能完成度上存在不少局限。
时隔几年，随着技术栈的深入，在开源社区前人大量代码1 2的基础上，笔者带来了一个强大得多的新项目 —— PvZ-Portable。

几乎 100% 复刻原版所有特性 支持 Linux, Windows, macOS, Android, iOS/iPadOS, WebAssembly, Switch… 基于 OpenGL & SDL

且可移植存档相互兼容，支持 MO3 音乐格式。支持各种语言的官方年度版资源包

#tg 最近支持：右键一键转发！

原本功能：
HistoryView::ContextMenu::fillElementMenu()
https://github.com/telegramdesktop/tdesktop/blob/8e18cb71103d83d7d98994ff27f0a2bca55c489c/Telegram/SourceFiles/history/view/history_view_context_menu.cpp#L1123

HistoryView::Message::drawRightAction()
https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/history/view/history_view_message.cpp#L5769
https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/history/view/history_view_message.cpp#L5896

是真没想到这玩意还要加几百行，和快速reaction有冲突 ❤️

吐槽：高性能， 这个所谓的自动layout追加不就是Tk pack()、平铺式布局管理，加几条用户权限的if线么，一个小角标写几百行cpp

嫌运行时ui树慢可以做comptime编程啊，弄的widget()都返回bool或QRect，我都不敢想设计有多困难

“用巨大的开发维护成本”，在我看来就是反直觉，没有工程策略。树框架依然是要的，你不喜欢可以写个协议把QRect缓存下来，而不是像cpp不用iostream而sizeof+init 写两遍一样。

我会那样写吗？我直接在js用Proxy bind到数组union的offset。

他要是稍微有点设计感，就直接把CSS伪状态重新发明出来了。 右键菜单分过Type后能有几个case，不就是owner、group、新老消息什么的，到处accessor item->allowsForward() 和fn() { if 开头 } 算什么呢，还不如QWidget树

面向什么就面向什么，一开始就知道有十几种菜单，可穷举的就在.md里就想好，然后把datatype打包好

https://blog.est.im/2026/stdout-26 #tencent #dev

有人测试出来 Polar+AES 在性能和体积上都非常平衡，而且支持单行实现grep

FTS5建立索引是最快的，但是体积翻了3倍

vx的聊天功能，还是 时间戳排序+串读串写（离线或多人），列数据库确实适合 append-only ，只是那个时代RDBMS非常通用了

为了一个grep速查索引放弃整个文件树模型…… 这大概是文件系统本身的问题了，想起了Everything。 大概没人真的因为【调试方便】 而用fs管理消息，电邮都不