2025-10

Alpine Linux

原计划在国庆假期把 Python 相关的包努力做一做，setup.py install 相关函数将要在月底废弃，但是经过努力决定开摆，原因有下：

当前在不测试的情况下完全无法分辨是否依赖有缺失
很多上游不着急，构建系统的切换还是上游做合适
缺少项目经验，不明白 nox、pytest、uv 等的工作原理
使用的 py3-gpep517 脚本协议错误，提了修改没人管

这个月 pmos 的人引入了 systemd 子包功能到 abuild，也算是对社区的又一次冲击（摊手），不知道 WHLUG 能不能做个闪电分享讲讲这些事：

Wless & Wayland

隔了一整个 8 月和 9 月没写，之前写的代码有点看不懂了，于是也重新看。

在 sway 中 layer-shell 是挂在 output 下，渲染时 reparent 到 server
在 dwl 中 border 是挂在 client 下，对于我的场景应该适合挂在 output 里
wlr_scene_node_set_size 需要考虑到 pending 状态（tinywl 的 resize 没考虑）

之前拆多文件是为了使用 AI 写代码理解方便，但是体验了 VSCode + cline + DeepSeek，小几千行的情况下，单文件对 AI 和对我的原生 Vim 来说都更方便，我就改回去了。

协议 wlr output management 是为了客户端 Read 或者 Write 服务端的显示器设置

zwlr_output_manager_v1
- request create_configuration >> zwlr_output_configuration_v1
- request stop
- event head >> zwlr_output_head_v1 只读的广播，没什么逻辑
- event done
- event finished
zwlr_output_configuration_v1
- request enable_head >> zwlr_output_configuration_head_v1 + zwlr_output_head_v1
- request disable_head >> zwlr_output_head_v1
- request apply
- request test
- request destroy
zwlr_output_configuration_head_v1
- request set_{mode,position,etc.}
https://wayland.app/protocols/wlr-output-management-unstable-v1

10 月用两个周末的时间完全重写了之前的配置文件（主要是快捷键）的逻辑，大幅度依赖 getopt、getsubopt、wordexp 这三个标准库函数。修改之后实现了两个目标：

决定把部分复杂功能从 WM 本体中丢出去，降低配置的复杂度
命令行与配置文件使用同一套解析函数

认真学习了 wlr_output_layout_output 相关内容（并不认真）：显示器的 enable 在非原生后端时可能会修改，但是如果 output 不在整个 layout 中，我们也应该认为这个显示器是 disable 的。应用到具体场景就是用户的笔记本显示器熄屏，此时物理上显示器连接，但是显示器没有真正投入使用，用户可能扣着盖子用外接屏幕。

Bushi & Git

重新审视了这个项目的整体架构，思考下一步真的要做什么。项目已有的“祖先跳表”设计令人兴奋，但是内部数据的生成还是依赖 git-fast-export，这不优雅：

很难控制 git-cli 本体的内存占用，据测算需要 800 Mb（使用 aports.git 仓库）
命令行输出的解析是用的手抠字符串，虽然能跑但相当原始
初始化更新和后续更新可能逻辑不一致，写两套函数无法接受

所以最好这里再细节一点。

先尝试的是字符串解析，尝试使用 nom 但阅读文档后发现，这个库必须先把字符串读取为 &str，这就很不合适，因为管道重定向是 Stream 流：数据量大、输出时间长、不保证字符编码。目前也没有什么其他库做这件事很合适，所以搁置。

用原版 git-cli 和 libgit2 各做 1000 次提交差异对比，发现原版速度就是快一个数量级

export GIT_PAGER=cat
git diff --no-color --name-only "$commit_old" "$commit_new"

看了会儿 libgit2 的源码思考为什么如此慢。发现它读取 object-tree 这里可以改一下，用 data 的 size 除以 oid_t + mode + 6，然后拿这个数值去初始化数组，避免很多次 realloc。修改后对比测试，略有提升，效果微乎其微，平均百万次读取超大 object-tree 调用提升 10s（口算）。

读取有 object 后的 diff 运算没有可以优化的地方，就是简单的双指针单向遍历。

所以还没什么其他加速思路。

从 git-sizer 程序的解析结果看，把仓库中所有的 object-tree 事先解析并塞到 SQLite 的方法会导致程序体积占用很大，预计有 20 倍的膨胀，所以不可取。理想预期：

【内存占用小】全程不超过 200 Mb，而且缓存大小可控
【硬盘占用小】因为必须保留原生 git-objects 做兼容，所以尽可能产物小于同期 fossil
【CPU 消耗低】初始化不作要求，查询时单线程可运行
【解析时间短】初始化时间低于 git-fast-export 耗时的三倍，查询时间低于 git-cli

下一步计划：当前的性能瓶颈有两个，object-tree 的 read 和 diff，它们被广泛压缩在 packfile 中，不仅 IO 紧张而且 CPU 紧张。但是逆转过来想，压缩本身也是一种信息？可能需要写一点优化后的读取方法，在读取时抓取更多信息。

备用计划：手动封装 git

找个支持流式解析库，优化现在的 fast-import
魔改 fast-export 输出 json，然后接 serde::json
封装原版 git-diff-stat 用 nom

QT

发现一个 Bug，右键弹出菜单中，分隔线上的点击事件无效但会导致弹出菜单消失。使用 AI 写了个复现小 demo，提交问题到了 QT 上游。

# 感谢子冲帮忙修复 LSP 爆红
sudo apt install libstdc++-13-dev

不知道下一步会不会学习 QT 做点小工具。

论文

导师喊我改论文，这让我非常难过，尽管我知道这件事情只要完成就再也不会有烦恼了。但我还是很难过，无法诉说的压力和恐惧，让我没有失去了对生活 60% 的注意力和快乐。有以下几个方面需要改：

标点符号、文字、句子之间的连贯性
图表、公式、大小写

好像没了。我尽量去做吧。祝我开心。

Vim

学到了 Vim 自带的 grep 命令，非常好用，再也不需要终端里查询复制到 Vim 中再打开了。

现在是接入了 ripgrep 日常使用，配置文件略微修改：

if executable("rg")
        set grepprg=rg\ --vimgrep\ --smart-case
        set grepformat+=%f:%l:%c:%m
endif

把之前在 Vim 上修的小补丁 cherry-pick 到了 NeoVim 上

ssh [-L|-R] [FROM_IP:]FROM_PORT:DESTINATION:DESTINATION_PORT [USER@]SSH_SERVER

对于 -L 本地端口转发来说，流量从本地端口进入，转发到 DESTINATION，所以是 LOCAL

1024

本来想搭配“麒麟”这首歌做个混剪小视频，但是和 xingji 交流后发现代码提交截图不适合做素材，远远不如画画、徒步等，所以还是算了。

Donations

这次选择了 asciinema 项目，恰好新版本发布。

捐款上也有一些小想法：

参与代码贡献的项目不捐：出力不出钱，比如 Alpine Linux
账面还有很多钱的不捐：钱不能解决这种维护问题，比如 libgit2
没用过 or 不好用的不捐：特指希望倒闭的 matrix

没事可以去 https://opencollective.com/search 逛逛，想想以后自己的项目怎么搞钱

如果 11 月没想好给谁就去订阅一下 LWN，或者给服务器加点钱什么的。

qaqland - hash

2025-10

Alpine Linux

Wless & Wayland

Bushi & Git

QT

论文

Vim

Misc

博客 or 主页

FetchSrc

LSP

SSH

1024

Donations