昨晚整理完nas阶段性测试的资料准备关机前，想到19年底nas系统还有一个基于传统freenas分支的nas4free。当时它更FreeNas官方公司走高端化路线不同，延续了原Freenas的低配高效的路线。
上网查了一下相关资料，nas4free也已经更名为Xigmanas，只看安装镜像大小，就知道他只是更名而没有改变发展理念。
Xigmanas相关的技术资料不多，多的是其与群晖、威联通的优劣比较的文章。
这nas本来是隐于幕后，为机器服务的，只是随着这些年网络的高速发展，特别是视频文件翻番又翻番的体积增长，才让nas从机房转战到办公室，最后落户家庭。现在流行热议的nas，可以说工作室或个人的网盘而已。
其实，就连nas本身也是一个低成本的平民版存储系统，真正高端或者商用的，用的是与intel、oracle齐名的EMC。这应该也是Freenas的东家一度要发展硬件的原因之一，只是高不成低不就拓展不利后，又转回到软件为主的集成应用系统上来。
这个策略也不能说不对，至少可以看做是一个前置机与nas的组合，性能够用，数据也有一定保障。
至于重要数据管理，还是需要稳定运行低调的nas。
19年底安装公司业务用nas的时候，选用的是基于Freebsd的Freenas，机器CPU是双核赛扬，运行正常。但也没正常用几天，疫情就来了。
前几天重新安装nas，freenas除了更名truenas，还分为两个版本，core版延用原先版本，算是熟门熟路了，便选用了基于Debian系统的scale版本。
安装完系统，创建pool，开始应用时，第一反应就是，这还是nas系统吗？
再后来按照网上介绍安装docker时，才明白，还装什么装，这应用系统整个就是一个k8s，nas成附属的了。
不止如此，这系统默认自带虚拟机管理，而且是能安装windows和Freebsd的，也就是说还超越docker。
运行测试一番后，今天关机，重新搬回储藏室。
因为不止硬盘容量大大落后于时代，这cpu根本就带不动啊。
下一步，升级！
早上早早醒了，等送走早八的，却也睡不着了，于是将储藏室里老nas机器搬出来，重新安装测试。
四年半过去了，系统已经从freenas更名为truenas。变化更大的还是是硬件，当年在机箱里塞了4个2T硬盘，觉得够使了，现在安装完系统，看看那不到6T的可用空间，还不如上周买的威联通一个硬盘的一半。
忙了一上午，除了安装时，因为老系统硬件识别遇到点麻烦，还算顺利。
顺带根据系统提供的APP，学习了一下相应知识，原来软件应用与硬件一样发展迅速，要用要学的，还是那么多。
近来学习使用媳妇推荐的zotero作为管理软件，搜集归档相关资料。一般都是浏览到感觉有用的，就先收藏起来，留作后用。
原先测试网络资料中程序，流程都是逐步测试，发现问题，以资料为准，进行修改，解决问题。
但最近学的太新太杂，越来越发现网上相关资料并不靠谱，如此一来，太多次被带到沟里，费时费力。
于是不得不改变策略，开始使用排除法。也就是找资料的问题，如果资料运行有问题，那就不再认为自己设置有问题，直接pass掉了。
如此一来，资料验证精简后，效率反而提高了。
还是那句话，网文不能全信。
这一个多星期，主要在学习测试个人知识库，折腾一番还是挺失望的。
现在以大模型为主，辅以内嵌模型加向量数据库的RAG系统炙手可热，相关文章甚至可以说是甚嚣尘上。
但验证完那么多文章，还是那个熟悉的疑问困扰着我：“这些作者真的用过，运行过代码吗？”
归根结底，RAG还是离不开大模型的，就像测试的三国演义，第一回还凑付，一旦扩展到全部章节，就开始胡说八道，不说是关公战秦琼，但也要跟姜维过过招，骂骂皓首老贼的。
这就像看着自动驾驶车有前景，于是就想把车、智能系统加导航鼓捣到一起一样。且不说车与系统的兼容性问题，那各国交通规则和各地路况还不一样呢。
这样还不如直接买一辆成品车。
或者就是踏踏实实手工操作，智能辅助，也挺好的。
不过，也不是没有收获，至少发现网上现成资料比想象中要多的多。
昨天在制作docker镜像编写Dockerfile文件时，为了提高效率，便使用vscode编辑。
谁知刚打了几个字符，编辑器上就出了一大堆代码。这才想起，前段时间在vscode上安装了continue插件，连接到了公司的ollama服务器上了。
害得我手忙脚乱找关闭连接的开关，这就像开车出门就近买个菜，自动驾驶直接奔着城市那头最大的农贸市场了。
这简直就是倒逼人进步啊。
今天忙了半天，把报告查询系统也容器化了。
因为是基于python的，原先计划是使用虚拟环境转移而非docker，但部署的时候发现涉及到自启动，无论是gunicorn还是uwsgi，都无法实现多个应用同时启动，于是决定还是转用docker容器化。
而今天大部分时间也是花费在gunicorn自启动设置上。由于alpine系统资料欠缺，解决无果后，决定转向通过Dockerfile设置CMD来解决，这也算是乱序学习docker的一部分。
过程异常顺利，结局出奇顺利。
看来我学习docker的思路是没有问题的。
昨天下班点接到通知，12点前上报某报告。
最为头疼的就是带截止点的工作，就是早早完成，也得等到时间点才放心。
报告早早完成，为打发时间，便试着将前几天的word转PDF工作批量自动化。
网上关于此转换的方法中，Linux下使用abiword库是最为简单的，默认只需一行命令就把同名文件转化保存到同一路径下。但同样，兼容性最差的也是它，试了一下，果然如此，本来在左下角的二维码，转换后都跑到页面左中部了。
失望之余，就将abiword一删了之。
熬到12点平安无事就睡了。早上起来复盘昨天工作，想到：这转换后的PDF格式不好，未必是转换的问题，有可能是word文件格式就有问题，因为原文件是在Windows下编辑生成的。
开机后重新安装abiword，好在文件小速度快，打开那个Word文档，果然估计是字体、行距等原因，原先那个二维码的位置，就在生成后PDF文件中的那个位置。将图像调整到合适位置，重新生成，完全符合预期要求。
如此一来，只要文档转换前，使用abiword进行排版调整就可以了。
最近又开始邪门，说什么来什么。刚说完把virtualbox打入冷宫，昨天就遇到麻烦了。
因为决算报表全局审核bug，昨天晚上在家里想就把问题解决，结果从官网下载的同一个程序，单位运行的好好的，家里机器安装正常，就是没法任务初始化，换了一台机器同样如此。
折腾一晚上，早上早早赶到单位，系统正常，继续折腾报表。完成任务后，开始找问题，发现不出所料，是家里机器安装的时候，未能将初始数据生成在默认的C盘路径下。
于是跟外甥一起，痛骂Windows那该千刀权限设置。
这个权限问题由来已久，早些年在原单位，只要是Java系统的程序，必然要因为权限导致各类莫名其妙的问题。
后来在系统Mac上安装运行Win10，同样如此，Java的程序无法在生成默认输出到C盘的文件。
可恶的是，现在它能用了，标准的win10系统又不行了。
想来这个决算报表系统，最早是XP下开发的。
如此一来，virtualbox还得继续用啊。
昨天在抖音看到一段docker的技术视频，从实战应用讲起，浅简易懂，跟我理清的思路相同。
评论区有得到播主赞同的评论，说视频好，但不适合初学者。估计这也是受传统学习方式的受害者。
视频中还对比讲解docker与virtualbox等虚拟机的区别。结合视频开端先讲的是我之前略过的Makefile，也算是有新的收获。
我感觉virtualbox的初始安装相当于docker的镜像，Makefile相当于虚拟机快照。
原先忽视docker，主要原因是virtualbox用习惯了，现在看来，只要不涉及到操作系统，virtualbox基本可以束之高阁了。