项目发布中，不同客户很多时候是由分支来管理的，但同时也存在很多用标准产品的客户，就会出现同一个分支不同时间的代码出现在不同的客户那边。
但是在发布很久之后可能需要修复某个 bug，这时候是不需要部署最新代码的（避免出现新问题），所以要找到当时发布时那个节点的代码，对应修复部署即可。
之前的做法是在发布的时候，打个 tag，但有时候容易忘记，并且也会导致 tag 太多混乱
找到一款叫做 git-commit-id-maven-plugin 的插件，可以很方便的将当前编译的时间、分支信息加入到文件中，使用方法也很简单。
github 主页：https://github.com/git-commit-id/git-commit-id-maven-plugin
注意，这里的 groupId 和 artifactId 会根据 jdk 版本不同而有不同的写法，下面这种写法是 jdk8 的写法，具体请参考 github 中的使用方法
<plugin>
<groupId>[......]总所周知，Chrome 的地址栏搜索框的历史记录是臭名昭著的存在，但是一直没找到办法去删除或者屏蔽，只要在地址栏搜索过任何信息，打开新标签页，都会自动弹出，让人十分反感。
之前用过一个扩展，叫做 HCOS – Hide Chrome Omnibox Suggestions，但是最近在升级 Chrome 之后，以“此扩展程序未遵循 Chrome 扩展程序的最佳实践，因此已无法再使用。”为理由提示不能再使用，不小心删除了。
找了好久，终于找到一个离线版本的，通过 Chrome 开发者模式加载进来，那清爽的地址栏又回来了。
原扩展地址：
https://chromewebstore.google.com/detail/hcos-hide-chrome-omnibox/aldijnffnfojelcpcfoekkeifffkhldo
HCOS扩展离线下载地址 （需要右键另存为下载）
[……]
项目中需要有 Excel 或者 Word 文档导出功能，但是很多用户希望能在导出前做个预览，想着导出功能本身就做好了，就不想再做个前端预览功能了，而且也不通用，所以就想着直接预览将要导出的文件即可
这个软件本身就是开源的，符合要求，也支持本地文件、远程文件、文件输出流
这里只讲写怎么用 docker 进行部署
我这边用的是 4.3.0的镜像文件，使用 docker load < 镜像文件命令，把镜像导入到系统中
准备字体文件
大部分的情况都会出现预览中文乱码的情况，基本都是字体问题，一下是官方解决方案
大部分Linux系统上并没有预装中文字体或字体不全，需要把常用字体拷贝到Linux服务器上，具体操作如下： 下载如下字体包 https://kkview.cn/resource/fonts.zip 文件解压完整拷贝到Linux下的 /usr/share/fonts目录。然后依次执行mkfontscale 、mkfontdir 、fc-cache使字体生效
docker run -it --name kkfilev[......]docker镜像极致压缩（二）
之前在一篇文章中提到 如何在编译镜像的时候尽量缩小镜像的体积 以用于网络传输，这次在构建另一个镜像的时候，采用了更为激进的办法，直接将原来4G的镜像，缩小到了1G左右，压缩更明显，图片见对比。
为什么不使用 docker-compose ，为什么要把这些软件全部安装到镜像内，这里就不作过多讨论了
总的来说，就是2点，分别是：
这两点都很好理解，阅后即焚，是在之前聊过的减少层数这个基础上，把每一层创建好之后，不需要的东西删掉，因为一层的内容创建好之后，体积就相对固定了，下面一层再去删除，是无法改变原有镜像大小的，例如，通过FROM ubuntu:22.04来使用ubuntu的镜像，然后在接下来编译的过程中，删除镜像的文件，并不会对最[……]
项目中使用了emqx来对硬件进行管理和状态数据的更新，但由于错误的使用姿势，导致在某个项目中，硬件设备超过了500个后，后台服务器接收处理mqtt的消息达到了惊人的2分钟延迟。
而项目甲方的服务器问题，导致无法修改emqx的配置来进行调优，流程特别繁琐，而且在调整过程中需要不断尝试。
所以就尝试在后台服务代码层面解决问题。
当前场景为：
有A、B、C、D 等n个设备，后台服务器订阅了所有设备的所有topic，每台设备在数秒内会上报一条状态消息，由后台服务器处理、存档，并且将设备最新的信息，再发回设备端，另外需要在 A 设备上展示 B、C、D等设备的状态，同时A设备操作B设备的开、关门的业务。
有一天发现，当B设备开关门后，或者A指令B开门后，需要长达2分钟才能响应，在跟踪代码之后，发现了项目中错误的使用姿势，例如mqtt服务不止用来做状态更新上报等，还在请求中加入了大量的数据，又或者过分依赖mqtt的消息来做业务处理。
在查阅文档，以及做了很多测试后，发现一开始对emqx的订阅有一些误解，原以为它的客户端（org.eclipse.paho.clie[……]
在很多企业和高校内做私有化部署的服务的时候，信息中心都会给一台服务器，不管是虚拟机或者是实体机，都会定期做漏洞扫描，每次一扫出来，都是很多漏洞，要求中高风险的漏洞必须修复，否则谁没事去搞这玩意呢。
比较麻烦的是，这些服务器大多都是纯离线，利用VPN、跳板机、远程桌面进行访问的，这无疑给软件升级带来了很多麻烦。
这次需要升级的内容是OpenSSH，为什么有这篇文章，因为我参考了很多文章，内容很多都不一样，有点连版本号也没有，都是拼拼凑凑来实现的，所以在这里做个记录
为了确保在升级过程顺利，最好安装一个Telnet服务，来确保后续可以继续操作，否则一旦服务器失联，一定是一件头皮发麻的事情。
下载以下文件上传到服务器：
参考了文章: https://lblog.net/?p=282 但是此站点现在已经无法访问
telnet-0.17-65.el7_8.x86_64.rpm
telnet-server-0.17-65.el7_8.x86_64.rpm
xinetd-2.3.15-14.el7.x86_64.rpm
安装以上文件
rp[......]在目前网络环境这么好的情况下，大文件传输似乎已经没有什么问题了，动辄上G的文件传起来也不在话下，在这个场景下，再大的镜像体积，看起来也没什么问题。我这个镜像体积也不算过分，但是需要通过微信传输 – SVN推送 – SVN下载 – 镜像推送 – K8S 部署这几个步骤，一整套下来也确实挺浪费时间的，而且都是通过公网传输，在没有办法改变流程的情况下（客户要求，无解），尽量缩小镜像体积，会提高很大的效率。
最早的镜像和最新的镜像体积差别,<none>是不断更新过程中被覆盖的
可以先用 docker history 命令看下镜像的构建步骤，可以简单理解成构建了多少层，这是原来刚开始构建镜像的时候写的Dockerfile，在构建过程中，步骤达到了30+，很多RUN操作虽然不会增加体积，但是无形中增加了很多镜像的 layer ，积少成多，会影响构建的效率。
另外还有几十甚至是几百兆的体积增加，最好都尽量避免掉
早期镜像的history
优化之后的镜像history
由于 Docker 镜像构建，就像它的名字[……]
最为一个新手，最近搞了一台J4125的机器，装了一个iStoreOS，来体验了一下所谓的轻NAS，里面放一些个人网站、Jellyfin、备份和私人ChatGPT服务，感觉还是非常不错，机器性能也还过得去，但是外网访问是个问题，还没有公网IP，所以有诸多不便，单纯Web服务的话，可以考虑FRP内网穿透，但是对于文件和媒体服务，对FRP的带宽要求就显得高了，所以就另寻蹊径了，看看能不能用IPv6。
电信 F450G ZTE的光猫
TP-LINK XDR5430 路由器，升级官方系统到最新版，含防火墙开关
J4125 小主机
一开始比较当心会搞坏网络影响家人上网，所有没有将小主机作为软路由或者旁路由，仅仅作为一个普通的小主机，iStoreOS称为轻NAS
很久之前通过网上的一些方法，搞到了超管密码，但是后来好像被远程关闭了（光猫是可以被远程控制的，尴尬不尴尬），找密码的办法是（仅在网上的那些192.168.1.1后面加各种后缀无效可尝试，谁不想简单点呢）：
准备好你的网络宽带账号、密码、宽带识别码（LOID ）等信息
拔掉光信号线，捅 R[……]
在规划客户需求的时候，看到了一个叫 AIChatWeb 的 开源 软件，为什么有删除线呢，因为我也不知道它到底是不是开源的。我习惯性的看了仓库中的README，这个软件是根据 https://github.com/Yidadaa/ChatGPT-Next-Web 这个项目延伸的，开发出了一个SpringBoot的后台，和一个Vue的前端，来管理页面title、api key以及销售套餐之类的项目。
我大概看了下之后，下意识的认为这个项目前后台都开源，并且在README中也找到了后台地址，但是是一个空仓库，在部署完demo后，发现这个项目功能上还是基本吻合的，准备做二次开发，所以我就加群准备问下如何获得源码以及费用问题（实际上我这是个赚钱的项目，是做好了付费的准备，无非多赚少赚的问题）：“你好，想请问这个项目的后端模块是否开源或者是付费获得”，没想到却得到一些“没有开源计划”、“编外人员开源有什么好处”、“白嫖用户洗洗睡吧”、“先买pro版再提问”之类的傲慢回复，所以然后就没有然后了，我就离开了。
然后一直到现在，在GITHUB仓库中，仍然没有明确表示后台不开源，也仍[……]
近日，百度开了“文心一言”的发布会，这是一款基于自然语言处理技术的语言模型，与其他知名的语言模型产品如OpenAI的GPT系列以及百度自己的ERNIE等相似。但是，与这些产品相比，文心一言受到了很多批评和质疑。在此，我们应该给这个新兴的产品更多的鼓励，让它有机会展示其潜力。
首先，我们需要认识到，人工智能技术是一个复杂和不断发展的领域。一款新的语言模型需要不断地进行迭代和改进才能达到更好的表现。因此，我们不能期望一款新产品能够立刻和已有的产品媲美，需要给予它更多的时间和空间来成长和发展。
其次，我们应该注意到我们和美丽国IT技术之间的差距。虽然我们在人工智能领域的进步十分迅速，但与美丽国的科技巨头相比还有一定的差距。这主要是由于美丽国的科技公司拥有更为先进和成熟的研发和创新体系，以及更为完善的技术生态。因此，我们的科技企业需要更多地进行技术积累和创新投入，以便在全球市场上更好地竞争。
最后，我们需要认识到，IT技术不仅仅是一种商业竞争，更是全球社会的共同进步。作为全球最大的人口国家和第二大经济体，我们在科技创新方面发挥着越来越重要的作用。因此，我们需要给予我们的科技企业更多的支持和鼓励[……]