使用 vim 进行中文输入，遇到的最大困难是要频繁的切换中英文，这个操作是比较繁琐的，往往会打断创作思路。我们的想法是，在 insert 模式下，使用中文输入；但是在 normal 模式下，则自动切换到英文输入，如此可以方便各种键位的操作。

在网上找了一会，发现有一个 im-select 的插件可以实现这个目的，使用起来非常的丝滑。

这几天发现有一个 crontab 没有启动，一开始以为是脚本有问题，所以添加了日志重定向。可是还是没有任何输出，所以怀疑是 crontab 没有执行，然后查看系统日志 /var/log/cron 发现有报错

1

crond[81985]: (infra) FAILED to authorize user with PAM (Module is unknown)

在网上搜索发现是 PAM 密钥过期了，需要重新设置

1
2
3
4

chage -M 99999 root
chage -M 99999 infra
chage -M 99999 spd
chage -M 99999 ops

重新查看就可以了

1
2
3
4
5
6
7
8

chage -l infra
Last password change                                    : Jul 12, 2024
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

这两天在使用 hhkb 键盘，并通过配置 xremap 进行键位映射，以更加舒服的姿势写代码。由于在 hhkb 键盘中，Ctrl 和 Shift 都处于左手小拇指的位置，这导致我在输入 shift+; 的时候，有可能此时的小拇指还停留在 Ctrl 键，进而触发来 Ctrl+;。然后诡异的是，这时候会跳出一个列表，显示 Select to paste，上面保留了系统粘贴板的信息。其实，这个是为了快速的输入最近的粘贴缓存，但是在这个情况下，我误触发键盘，极容易导致不停的跳出列表，非常影响效率。

周末的时候，我们组对一台 CentOS7 的机器进行了升级，原因是需要部分软件要求至少是 glibc2.18 及以上版本。整个升级流程还算顺利，程序也都能正常运行

1
2
3
4
5
6

$ locate libc.so
/usr/lib64/libc.so
/usr/lib64/libc.so.6

$ strings /lib64/libc.so.6  |grep GLIBC    |grep 2.28
GLIBC_2.28

但是周一交易盘前，我们发现一个奇怪的现象：shm 相关的操作，对于 /dev/shm 根目录下面的共享内存操作是正常的，但是对于带有子目录，如 /dev/shm/spdm/spdx_param，会出现程序崩溃。然后我把这个现象跟领导沟通了一下，由他编译一个 debug 版本，进入 gdb 调试看看。

他确实发现，一旦遇到带有目录路径的 shm_open 就会出问题，返回的 fd 是 -1，这说明操作系统无法打开文件句柄。他经过一番 ChatGPT 之后，给出的结论是

今天发现了一个情况，在某一台服务器上不能通过shmv命令来访问或者创建带字目录的共享内存文件，比如/dev/shm/abc/xyz，根源上是shm_open不接受"abc/xyz"作为参数，查了相关文档，发现这台机器虽然centos 版本不一样，但是对比发现比这个版本更老或者更新的其他版本是支持abc/xyz这样的共享内存文件名的，现在怀疑是glibc版本导致的，因为这台机器的glic版本相对高一些（2.28)，我们其他服务器绝大多数都是2.17，目前没有定位具体glic哪个版本什么样的改动导致了这个，但是POSIX规范确实要求传给shm_open的文件名除了第一个字符以为不能为/

当时全组震惊，这意味着我们的技术将被「锁死」在 glibc2.18，无法再继续升级；这也意味着后面有新的程序需要依赖 glibc 更高本版（比如 npm、neovim）将无法使用。

kanagawa 一款柔和色调的主题，相比 tokyo.night 没有那么的刺眼。主要特别注意的是，这款插件采用了 jit 编译技术，一旦修改配置，还需要执行 KanagawaCompile 才能生效。

I’m writting code on a rather outdated Linux CentoOS7, with glibc of version up to ‘2.18’. And for a meanwhile, there is no hope to upgrade it, since we’ve deployed quite a lot of services, meaning updating may cause some unanticipated crashes.

I’ve also learned that starting from v0.10.0, neovim would support buildin inlay, which definitely enhance our code reading. It’s gonna to be the main reason I need to upgrade nvim. The sad part of this story is that, the official release of nvim require at lease glibc of version 2.29.

However, there is on repo provide unsupported release version of nvim for some legacy systems. And it only require glibc of version 2.17. What a great job!

In case anyone would need this

Now I’m happy with it.