欢迎留言、转载请注明出处
最近在配置一台128M内存运行debian 11系统的虚拟机时，遇到了修改systemd服务配置后reload时报错的情况，提示信息如标题所写，排查后发现debian系统安装后默认配置的/run空间大小是和系统内存数成比例的，而默认分配的16M空间，在执行“systemctl daemon-reload”时就会提示上面的错误信息，还会说明类似如下信息：
Currently, XX.XM are free, but a safety buffer of 16.0M is enforced.
解决的方法就是想办法加大这个/run就可以了，修改/etc/fstab，追加如下内容：
none /run tmpfs defaults,size=64M 0 0
这里指定了64M空间用于/run，按网上的说法这样应该可以应付绝大部分情况，之后执行：
mount -o remount /run
重新挂载/run，完成后可以用“df -hT”确认下当前/run的大小，增大后再次daemon-reload即可正常操作了。
最近要用到一个库，依赖boost，于是久违的下载了需求的最低版本1.57的boost拿来build一把，结果已开具就遇到了坑…
目前用的编译器是VS 2022的toolchain，于是打开x64 Native Tools命令行，进到boost源码路径，简单看了下说明，敲了“bootstrap.bat”，提示：
Building Boost.Build engine
cl: 命令行 warning D9035 :“GZ”选项已否决，并将在将来的版本中移除
cl: 命令行 warning D9036 :使用“RTC1”而不使用“GZ”
cl: 命令行 warning D9002 :忽略未知选项“/MLd”
Bootstrapping is done. To build, run:
.\b2
To adjust configuration, edit 'project-config.jam'.
Further information:
- Command line help:
.\b2 --help
- Getting started guide:
http://boost.org/more/getting_started/windows.html
- Boost.Build documentation:
http://www.boost.org/boost-build2/doc/html/index.html
还是继续上一篇stomp的问题，这次是在实际使用中又有了新发现，那就是java后端向前端发送stomp消息时，存在底层异步操作造成的消息顺序不确定性问题，如下：
@Autowired
SimpMessageSendingOperations messagingTemplate;
@MessageMapping("/create")
@SendToUser("/queue/reply")
public ReplyDTO create(@Payload CreateDTO msg, SimpMessageHeaderAccessor accessor) throws Exception {
String userId = getUserId(accessor);
if (userId.isEmpty())
return buildNotLoggedInReply(accessor);
int createId = myService.create(userId, msg.getTypeName());
CreateInfo ci = myService.info(createId);
String infoStr = new ObjectMapper().writeValueAsString(ci);
messagingTemplate.convertAndSendToUser(
Objects.requireNonNull(accessor.getSessionId()),
"/queue/response",
buildOkResp(accessor),
createHeaders(accessor.getSessionId())
);
return buildReply(accessor, infoStr);
}
最近研究spring的stomp协议框架，上到消息订阅、发送时一开始用的普通String，没有任何问题，都可以跑通，后来上DTO数据对象时，遇到了标题上的问题，查了下发现是框架层在调用jackson自动反序列化json为DTO对象时报的错，很久没用java，都忘记了，参考下面链接的说明
https://blog.csdn.net/weixin_39827145/article/details/89314433
意识到jackson反序列化时默认的行为是需要class的无参构造，之后再处理各个属性对应到json key的value，而出问题是的DTO class上用的lombok标记是“@AllArgsConstructor”，只生成了全成员变量参数构造，因此导致了此问题，把接收stomp请求，用于对应@Payload的class换成@NoArgsConstructor（当然，一般还要带上@Getter，用于成员变量的访问）后，问题解决，接收到stomp请求后，成功传递到了controller的对应处理方法中。小问题连带了一个小知识点，记录一下。
关于这俩c库函数的使用方法，百度上一搜能搜到很多，但是实际上用了这么多年的我有时候还是会犯迷糊，分不清哪个是处理0结尾的，哪个是没有的，因此今天趁着放假有时间，再整理记录一下。
#include <cstring>
int main(int argc, char *argv[])
{
char sz_test1[10] = {};
char sz_test2[10] = {};
char sz_source[10] = "123456789";
strncpy(sz_test1, sz_source, 10);
snprintf(sz_test2, 10, "%s", sz_source);
return 0;
}
上面是一段很简单的写在cpp里的c代码，纯c也差不多，主要说的是这俩c函数的区别，可以看到sz_source有9个字符，带1个结尾0凑成10字节的字符串，上面还有两个同样是10字节的char缓冲区用于测试，可以看到strncpy和snprintf的n都给10的时候，sz_test1和sz_test2都是和sz_source一样的结果，包括结尾0。
接下来把两个函数的n都换成9，这时候可以看到如下结果：
Continue reading…之前在使用x264编码时所谓的CBR流控其实是通过abr流控+vbv码率、缓冲参数设置的（vbv-maxrate，vbv-bufsize，也可以是ffmpeg的minrate，maxrate，如“ffmpeg -re -stream_loop -1 -i test.mp4 -c:v libx264 -x264-params “nal-hrd=cbr:force-cfr=1” -b:v 4M -minrate 4M -maxrate 4M -bufsize 1M -f flv rtmp://127.0.0.1/live/test，即控制了波动范围的vbr，而到了x265编码时，发现如法炮制的参数并不好使了，码率还是会有较大范围的波动，最后搜索研究了很久后发现，原来x265有这么个参数：
–[no-]strict-cbr Enable stricter conditions and tolerance for bitrate deviations in CBR mode. Default %s\n”, OPT(param->rc.bStrictCbr));
实测加上这个参数后，编码输出码率几乎就是目标码率很小范围内波动了，ffmpeg命令如下：
ffmpeg -re -stream_loop -1 -i <input> -c:v libx265 -b:v 25M -muxrate 30M -x265-params strict-cbr=1:vbv-bufsize=25000:vbv-maxrate=25000 -c:a aac -ac 2 -b:a 128k -f mpegts udp://239.3.3.3:5000
最近在学习EDA，使用的是开源的KiCad，基本操作还是挺简单的，但是众多的电子元件符号、封装相比起来还是不如立创EDA这种web版生态完善的来的方便，好在网上找到了将立创EDA中PCB元件封装导入KiCad的方法（拿来主义，哈哈），原文在这里：http://www.taodudu.cc/news/show-5505674.html?action=onClick，转过来记录一下：
在使用KiCad软件的时候，有些元器件的封装没用合适的，需要自己画。但是自己画起来比较麻烦，这时候就可以直接去立创EDA软件中下载。
首先登陆立创网页版的EDA，网址：https://pro.lceda.cn/ 进入标准版。
之前曾经写过一篇 魔改国产ST-LINK V2仿真器，增加SWO支持 的博文，记录了给山寨ST-LINK V2增加SWO引脚引出的方法，而今天要说的是，这个方法在合宙的AIR32系列MCU上实测并不不好用，原因在于：https://wiki.luatos.com/chips/air32f103/switchFromSxx.html#debug-sw-jtag ，这里合宙官方的文档上描述了AIR32与STM32的JTAG关断差异，简单说就是SWD和JTAG同气连枝，要开都开，要关都关，而后面又有关于SWO的描述：https://wiki.luatos.com/chips/air32f103/switchFromSxx.html#traceswo-printf，要使用SWO则必须关掉JTAG但保留SWD（这个目前我理解是SWO的printf输出依赖SWD调试），但是尴尬的是：https://wiki.luatos.com/chips/air32f103/switchFromSxx.html#jtag-jtrst，调试状态关JTAG会导致程序复位，这几个情况叠加在一起就造成了我试验时的现象：接上魔改的ST-LINK V2的SWO，一通配置Keil调试设置和代码设置（具体不写了，百度一搜一大堆），然后调试启动后确实能看到SWO的输出，但是过一小会儿，程序就重置了。。。😂于是，我又开始寻找其它方案（其实最后还是换了带串口的DAP-LINK，走UART打log了，这里记录的是研究过程），最终使用Keil的中间件（应该是这么叫吧）Event Recorder实现了既不依赖SWO，也不用串口，就SWD那几根儿线打log的功能：
Continue reading…
这次坏的是公司用的明基鼠标（具体型号不明，海贝A800键盘套装送的，用着还算顺手，也是10多年的了），这个鼠标几年前滚轮编码器坏过，当时更换编码器时还特意检查了下左右键微动，是凯华的，感觉好像还挺耐用的，就没管它，结果最近发现左键开始出现接触不良的情况，拖动窗口按着按键有时自己就松开了，严重影响各种拖拽操作，容易造成意外，于是赶紧换了个之前存货的凯华红微动：
10年前给大概8年前买的G1换了日产欧姆龙微动：给用了快8年的罗技G1换了个新的微动开关 https://blog.k-res.net/archives/996.html，时隔10年之后的今日发现左键再次开始出现连击、拖动时断断续续的情况，差点把重要文件误删了，赶紧拆开再次急救：
