博客

  • nvim使用踩坑1

    nvim相比我目前使用的spacemacs,感觉好轻量,headless 配合neovide, 高级感立马上来了。 真希望emacs也可以如此,为此我认真的体验了接近3周使用nvim进行开发, 甚至我的nas的系统镜像 移除了vi, 引入了nvim+fzf+rg+yazi+tmux等

    我大都是远程编辑的,因此远程主机开上nvim headless, 然后windows主机远程连接上去, 最长使用时长大约一周都没关过nvim,期间也没有用过spacemacs.算是深度体验。

    格式化的坑

    我使用的是lazyvim,代码文件保存的时候,默认会格式化,这样每次提交,变动可能会比较大, 初始我大致扫描了一眼,感觉没太大问题,直到后来我觉得系统不太正常了,发现自动格式化之后, 程序执行与想要的不一样了。最简单的,在js文件中,比如下面的方式:

    const cmd=`node script/test.js --op=test --test=1`;
    

    格式化完之后,可能变成了如下:

    const cmd=`node script / test.js --op = test--test = 1`;
    

    命令组合失败。因此,最好关闭这个,我知道自己写的代码是什么样子的。

    文件管理不方便

    我很喜欢spacemacs的文件管理(包括打开),默认是当前文件目录,快速切换到目录,分栏等等, nvim默认在cwd等root目录,新建文件,默认的就在这个目录下,导致我经常找不到。另外,虽然使用了 类似fzf, rg等快速查找的外部工具,但架不住我文件数量多啊,再高的效率在错误的目录中也白搭。 而侧边栏(space e), 选择文件不方便,我也很少使用侧边栏。更不用提远程文件了。AI建议我使用sshfs 了。yazi虽然实现了类似tramp的方式,但远程目录还是不太方便。

    org模式vs markdown

    我太喜欢org模式了,blog的几乎所有文件都是org模式写的,相同类型放在同一个文件中,因此,只用 维护几个org文件就行了。写blog, 发blog, 全在org-mode.为了在nvim中更好的写记录,我只能使用 markdown了,甚至将blog由wordpress导出到hugo,然后发现每篇文章要写一个markdown,要维护几千个 md文件,还要想着文件名,天,放弃吧。我还是使用emacs+org-mode,虽然emacs很烂,wordpress很烂, 但没有替代方案。

    输入法

    对我这种经常在中文/英文之间切换的,nvim可以使用本地输入法真的太方便了,对于emacs而言,反而 要依赖x11+emacs体系的输入法(我用的是rime),实在无法比较。emacs慢,rime慢,x11慢, 动不动还经常剪切板之类的无法使用,对于emacs真的无力吐槽了。我甚至向ai询问,重写emacs的显示 框架调整为nvim的模式,难度几何,工作量如何。

    git管理

    虽然我使用mgit很顺手的,但也仅仅因为我基本都是简单使用,不涉及很复杂的比如多分支,多worktree 频繁的切换等等。但lazygit确实不错(除了我还是难以习惯,经常乱按键),这一点上,nvim集成的 其实还不错。

  • Openclaw 配置踩坑

    sandboxing

    关于agent.id=main

    我喜欢使用docker来部署,防止失控, 默认的openclaw.json配置中关于agent.defaults.sandbox.mode默认为”non-main”, 如果同时设置了sandbox.workspaceRoot目录,然后在agent.id=”main”中同时设置了workspace目录位置。 我的本意是,agent为main的,都使用这个指定的workspace目录。如果使用docker部署,同时在不同的聊天渠道下,有时候会 把sandbox.workspaceRoot/session 下的目录作为workspace目录,从而整个错乱了。

    openclaw给出的解释:

    根据 OpenClaw 文档和 schema 设计:
    sandbox.mode: "non-main" 表示:非 main agent 的会话默认启用沙箱,main agent 默认不启用。
    这是一个全局默认值(fallback),不是强制规则。
    矛盾点:为什么 main agent 在沙箱里?
    因为 OpenClaw 的运行时逻辑是:
    sandbox.mode: "non-main" = 除了 main 以外的 agent 默认进沙箱。但 Gateway 本身是否把 main 也放进沙箱,取决于 agents.defaults.sandbox 的其他字段(如 workspaceRoot、docker.image 等)是否存在。
    当 defaults.sandbox 块完整存在(有 workspaceRoot、browser.allowHostControl 等),Gateway 会把它当作一个有效的沙箱配置模板,即使 mode 是 "non-main",main agent 如果也被 Docker 包装了,就会继承这个模板。
    

    因此,对于agent.id=”main”的配置,如果不使用sandbox的话(即使它真的运行在docker中), 依然要配置”sandbox”: { “mode”: “off” } 来覆盖默认值。

    关于sandbox.backend=ssh

    我的两个agent(test1, test2), 两个配置基本一致,通过backend=ssh连接到其他的服务器(也是docker构建的,主要是因为默认的docker沙箱无法打开端口和高权限操作),然后我在同一个matrix房间中,分别询问这两个agent 的workspace的全路径, 然后,一个告诉我在/workspace,一个告诉我在/workspace/<session-id>/workspace, 最后让openclaw查询官方文档才找出区别:

    字段 test1 test2
    sandbox.workspaceAccess “rw” “none”(默认)
    工作区挂载点 /workspace /workspace/<session-id>/workspace

    完全是workspaceAccess模式的不同

  • docker 容器禁止生成core文件

    这个生成真的很烦,除特定之外,基本无太大用途。还占用空间,我自动备份每次都要备份这种无用的垃圾。

    1. docker-compose 方式:

    services:
      your_service:
        image: xxx
        ulimits:
          core: 0
    
    1. docker run 方式:

    docker run --ulimit core=0 ...
    
    1. 主机全局关闭: /etc/security/limits.conf 文件加入

    #+begin_example

  • sas3008 读取HBA温度

    ./storcli64 /c0 show all
    

    其中有一段: ROC temperature(Degree Celsius) = 59

    这个为芯片温度。就是不知道是背板的温度还是HBA的温度

  • bcachefs 关于reconcile pengding的消除

    先说故障过程:

    1. 我将bcachefs(EC) 由 replicas=2 更改为replicas=3, 这样相当于从raid5升级到raid6.
    2. 升级非常的慢,然后我删除了所有的文件,重新从备份系统复制回来,这样会比直接升级快很多
    3. 我的SSD由256G(NVME)+128G(SATA)+(80G PART)组成的cache。因为我要将80G的分区做他用,因此移除了它.然后reconcile就显示大约有65G的meta属于pending状态
    4. 我将meta_replicas更改为了2, 依然如此。
    5. 接下来发现,每次加载的时候,都会有一个大约4-5分钟的检查
    6. 接下来的重点是:随着使用的时间越来越长,ssd中need_discard会越来越多,从不减少,如果cache部分满了之后,速度会暴降。重新挂载后need_discard部分就会消失。

    原因: 移除80G分区后,文件系统的meta数据无法满足meta_replicas=3的分布,因此就只能在pending状态了。即使修改了meta_replicas=2, bcachefs依然尝试从不存在的地方先读取再减少。

    解决方式: 添加一个临时的设备到cache组,然后等着reconcile完成meta_replicas=3降级到meta_replicas=2的操作,完成后,再移除临时设备。 接下来 need_discard 就不会发生之前从不减少的问题了。