由于我的 pi 里的 python 版本还是 3.5，一些功能无法使用，但是 arm 架构又没有现成的源，只好本地编译安装。
先安装基础的编译工具
sudo apt-get install -y make build-essential libssl-dev zlib1g-dev
sudo apt-get install -y libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm
sudo apt-get install -y libncurses5-dev libncursesw5-dev xz-utils tk-dev
到 python 的官方库里取下载源码，例如：
https://www.python.org/ftp/python/3.9.13/Python-3.9.13.tgz
cd /tmp
tar zxvf Python-3.9.13.tgz
cd Python-3.9.13
sudo ./configure && sudo make -j4 && sudo make install
需要注意的是，在解压缩时，可能会报错，可以尝试移除 z 参数，改用 xvf 来解压缩。反正衣服自己洗是放弃了，直接在 windows 平台上用 7z 重新打包，然后上传到 pi 里解压缩来解决的。
最后，通过 python3 -V 来检查版本号是否符合预期。
昨天在 WSL 里安装 nodejs，按照官方文档，对于 WSL 系统，不能安装常规的版本，需要通过库管理工具例如 nvm 来安装。
nvm 安装完成以后，运行 nvm ls 可以获取到 nodejs 的版本列表，运行 nvm install –lts 可以安装最新长久支持版本的 nodejs，可是问题就在于这个下载速度实在太慢，一直都失败了，简直让人崩溃。
突然想起来，既然 npm 有国内源，是不是 nvm 也可以使用国内源。原本是想查找其配置文件，检索了一番，费时间，放弃了，和我没有缘分。
搜索了下，发现了一个更合适的方法，如下：
NVM_NODEJS_ORG_MIRROR=https://npm.taobao.org/mirrors/node nvm install 16.16.0
直接使用淘宝源来下载安装 16.16.0 的版本，临时性地修改了环境变量，很是方便。
老实来说，这个问题困扰我的时间简直是以年为单位，在很久以前，我是用音箱直接连接的香蕉派，所以平时用来播放音频是没有问题的。
后来切换到 Firefly 后，木有多的音箱了，但是好消息是显示器自带的有音频输出，所以就想着是否可以直接拿过来用，同时又不改变其默认的输出设备，也就是说默认还是使用电路板上的音频设备，以规避设备切换或者移动带来的问题。
一直以来，都是使用 sox 来播放音频文件，占用资源少，命令行运行，非常完美。
就是这个选择默认音频输出设备，简直要崩溃，查看了其帮助文档，也没有说清楚具体是要如何操作。
直到有一天，无意间发现了命令，简直不要太好用。说起来也很简单，就是环境变量的设置。放在这里，方便像我一样的小白。
AUDIODEV=hw:0 play test.wav
这里的 0 就是音频设备编号，想要查看具体有哪些音频设备，以及其编号，可以输入：
aplay -l
大家请一定要根据自己机器的实际情况来设置上面的数字顺序哈。
一直以来，衣服自己洗都意味升级 MongoDB 的升级，就是从官网下载最新的 zip 包，然后解压缩覆盖同名文件即可。
这次发现官网上已经有 5.x 的版本了，替换后报错，检查日志发现了下面的提示信息：
Invalid value for featureCompatibilityVersiondocument in admin.system.version, found 4.2, expected ‘4.4’ or ‘4.9’ or ‘5.0
经过搜索发现了官网的帮助文档，还需要修改配置。
在升级前，先连接和访问 admin 数据库，在 shell 里运行下面的命令
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
检查其返回值里是否包含和 MongoDB 实际版本号一致，我这里当前的版本是 4.4，如果不一致，那么需要运行下面的命令修改
db.adminCommand( { setFeatureCompatibilityVersion: "4.4" } )
接下来，再用最新的版本来覆盖。等待 MongoDB 启动后，再次运行上面的设置命令为实际版本号，本次最新的版本号是5.0，所以就需要设置为 “5.0”，方便下一次升级。
需要注意的是：
1、尽量逐版本升级上来，不要跨越太大的版本区间。
2、操作前请及时备份数据。
最近的项目在计划切换到使用 .net6 来编译，虽然微软官网有提供转换工具，但是作为强迫症人群，还是选择了从0开始创建项目，在创建后，再拷贝相关代码。
很显然的，有一些函数或者命名空间在 .net6里并无法找到对应的，官方也提及，可以先试一试 Microsoft.Windows.Compatibility 这个 NuGet 包。VS2022 的右键菜单里还提供了一个很实用的功能，就是移除未使用的引用，所以大家可以放心地先引用。
如果你的项目使用了注册表，那么就需要添加 Microsoft.Win32.Registry 这个 NuGet 包。
很可惜，我的代码里使用了 System.Windows.Forms 的API去判断电源是 DC 还是 AC 模式，上述都没有很好地解决问题。
经过一番搜索，发现下面的解决方式，
1、右键卸载项目
2、编辑项目的 csproj 文件，在 PropertyGroup 节点下添加 true和true 这两个配置。
3、设置 .net6.0属性，替换为 .net6.0-windows，如果有其它的编译需求，例如 net461也可以加进去，以英文分号分割。
4、重新加载项目
当然，这么做也意味着编译后的二进制文件并不能在 Linux 平台上运行，仅仅意味着使用 .net6编译而已，不过这个对于衣服自己洗来说已经足够了，本身项目就是跑在 windows 平台上的。
在前面的文档中，我提及了在Firefly里编译后，但是无法成功加载权重文件来预测，只好转到 windows 平台上琢磨其使用，因为我有个机器是使用了英伟达的 2080Ti 的显卡，内心还是想验证看看速度到底有多快。
按照网上的说法，从这里把源码下载回来，然后配置 OpenCV和CUDNN。说到这个CUDNN的配置，是个麻烦事，好在以前已经安装了，这次没有做任何变动就可以了。
对于如何配置 OpenCV，可以参考我的另外一个帖子。
然后就可以正常地编译 x86和x64位的了，编译后就可以按照说明，去做预测了。确实速度非常的快，如我前文所述，毫秒级的，还是有钱好的，显卡牛批，节省时间。
在 Github 原文里，还提及了使用另外一种编译方式，就是微软推出的一种新的工具：vcpkg。
这个工具好在哪里呢，它会自动查找依赖项，并且下载了放到项目的目录里，以解决各种缺少配置的问题，看起来下载回来的那些包有点像绿色版的。下载好后，按照说明，运行命令，就可以开始编译了。
在我的2台电脑上都可以正确地编译，然后验证了下，使用和不使用GPU所消耗的时间差异很大。毫秒级的识别和十几秒的识别。
不过再重新编译就失败了，可能是我修改了什么东西出错。先不管了，不管如何，我现在有了可以编译成功的二进制的 dll 了，后面就可以共享给 C++ 和 C# 调用了。我看了下，python 调用还是怪麻烦的，就不考虑了。
在最后，给出一些当初参考的文档：
这里，这里，还有这里 和这里
在衣服自己洗前面的文章中的，大家都有看到提及FireFly这个东西，它到底是什么呢？
其实在更久远一点，衣服自己洗用的是香蕉派，其实包括树莓派，它们都是一类性质的东西，低功耗单板电脑。
让我从官司上复制几张图片，让大家看看。
这么多年来，一直稳定地运行着，比香蕉派什么的稳定多了。
安装：pip install pipreqs
在项目根目录下，打开控制台，输入：
pipreqs ./ –encoding=utf8
加–encoding=utf8为了避免编码错误
在以前 .net core 出来的时候，我没有上车，现在MS又释放了新的 .Net 6，是时候看看具体怎么玩的了。
以前在香蕉派上都是通过 mono-complete 来安装完整的 mono 运行时的，现在就给卸载了。
首先可以通过访问 https://dotnet.microsoft.com/en-us/download/dotnet 来查看最新的版本，以及下载地址。好在MS官网提供了 arm32 的版本。
下载完成后，运行下面的命令：
创建目标文件夹
sudo mkdir /usr/local/dotnet
解压缩文件
sudo tar zxf dotnet-sdk-6.0.101-linux-arm.tar.gz -C /usr/local/dotnet
创建软链接
sudo ln -s /usr/local/dotnet/dotnet /usr/bin/dotnet
增加环境变量
sudo nano /etc/profile
export DOTNET_ROOT=/usr/local/dotnet
export PATH=$PATH:/usr/local/dotnet
验证结果
dotnet --info
是不是很简单，像 golang 的安装方式一样。
想要使用 bamboo 自动生成 changelog 文件，检索了下发现已经有现成的方式，即大家约定 git commit message 的格式。
<type>(<scope>): <subject>// 空一行<body>// 空一行<footer>
其中，Header 是必需的，body 和 footer 可以省略。任何一个部分建议长度不要太长避免自动换行。
Header 是必需的，只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）
（1）type
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
如果type为 feat 和 fix，则该 commit 将肯定出现在 Change log 之中。其它类型（docs、chore、style、refactor、test）可以不用放。
（2）scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
（3）subject
subject是 commit 目的的简短描述，不超过50个字符。以动词开头，使用第一人称现在时，比如change，而不是changed或changes；第一个字母小写；结尾不加句号（.）
Body 部分是对本次 commit 的详细描述，可以分成多行。
Footer 部分只用于两种情况。一：不兼容变动，如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。二：关闭 Issue，如果当前 commit 针对某个issue，那么可以在 Footer 部分标记关闭这个 issue 。
来源