Discourse 的升级变得越来越频繁后，现提供了一个升级功能预览的选项。 通过对这些功能和特性预览，能够了解 Discourse 开发团队对下一步软件开发的计划和侧重点。 https://www.isharkfly.com/t/discourse/1733
根据多年使用 Discourse 的经验，在栏目分类上尽量不要进行细分而应该使用 Tag。 Discourse 的设计理念应该是希望用户更多地用 Tag 进行扁平化分类，所以分类的目的其实在Discourse的社区中被弱化了很多。 这个与早期的 Discuz 设计理念完全不同。 我的感觉就是在 Discourse 中分类越多越麻烦，还不如就只使用简单的几个分类即可。 给人的感觉 Tag 在 Discourse 中的使用更加多。 在考虑如果 Tag 被大量使用，到时候查找又是个麻烦事。 https://www.isharkfly.com/t/discourse-tag/2955
如果内容没有被 AI 终总结过的话，Discourse 会提供 AI 总结功能。 这个 AI 总结工具将会把内容的所有数据发给 AI 让 AI 对内容进行总结。 如果内容不多，读一下就行。 如果内容的回复比较多，那么这个总结功能挺很实用，能够把这个主题中的内容加上回复给总结出来。 总结的结果会存在数据表中，不是每次调用的时候都会调用 API 接口。 在总结的信息界面中，可以看到系统是调用那个 LLM 模型进行总结的。 当主题没有改变的时候，应该不会重新调用 API 了。 貌似有 2 个触发条件。 当主题数超过一定程度的时候进行触发，或者手动进行触发。 当主题中有新的回复的时候，系统会被识别到。 然后提示可以手动进行再次触发。 可以通过这个配置来平衡 AI 的调用。 貌似在后端没有找到自动总结的功能。 现在的主题总结，多用手动触发。 https://www.isharkfly.com/t/discourse-ai/2959/2
提示的错误信息请参考下图： 问题和解决 出现上面提示的问题是移动的分类和上级分配的权限不一致。 简单来说，如果把 【分类A】 移动到 【分类B】 下面，那么分类A就是分类B的子分类。 但是如果【分类 B】 限制了访问权限，也会 Level3 以上的人才能可以访问，但是 【分类A】的权限为比【分类 B】还要松的话就会出现上面的情况。 找到分类下的安全，删除上面设置过宽的权限即可。 https://www.isharkfly.com/t/discourse/2956
就说这光模块吧，大部分的时候都时候好好的。 但用了个把月，就开始出现下面的问题。 大部分的时候数据访问都比较正常，但会不确定性的出现超时的现象。 总感觉上面的问题是光模块自己因为什么原因重启了？ 温度原因？感觉不像是这个原因，因为已经用了多一个多月了，而且好像是每次 1 个多月后多会发生下。 我感觉更多的像是模块本身的质量问题。 https://www.isharkfly.com/t/topic/2953
我觉得 AI 域名本身它不是顶级域名，是一个国家域名。 这就有点和我们国家的 CN 域名以及一段时间炒的比较火的 IO 域名是一个意思。 一个国家域名在管理中一个最大的问题，就是很多域名的注册修改以及使用都跟国家政策相关。 .ai域名自1995年就已存在，最初是作为加勒比海岛国安圭拉的[国家代码顶级域名（ccTLD）而创建的。 由于“AI”是人工智能（Artificial Intelligence）的缩写，这一域名逐渐受到科技和IT公司的青睐，被视为通用顶级域名（gTLD），如今已成为最受欢迎的域名后缀之一。 部分国家代码域名要求注册者在该国拥有实体存在，过去.ai域名也曾有此限制。 但自2009年起，无论身处何地，任何人都可以注册 .ai 域名。 还记得以前我们国家 cn 域名出过一个限制的时候，把一夜之间把 cn 域名全部干翻了。 我觉得这类域名的最大风险就是在于域名持有国家的政策。 且这类域名的总体持有价格并不便宜，通常一年都会要好几十美元以上。 我记得 IO 域名价格上也不便宜。 我个人更倾向于还是使用国际顶级域名下到 com 和 net 这种的，通常这类域名会很稳定，而且不会怎么会被回收。 除非有特别好的 AI 域名，否则我不觉得这一类域名的投资价值有多高，可能当这个风口过了以后，这个域名就变得不再那么重要了。 就网站和应用来讲，更多的还应该是内容。 和 com 域名一年10美元左右的持有价格相比，这一类域名的持有成本更高，可能再砸了一些钱进去以后，也没有人追捧了。 https://www.isharkfly.com/t/ai/18751/2
在开源软件领域，并行版本系统（CVS）一直使版本控制的选择。 恰如其分的是，CVS本身是一个自由软件，它的非限制性的技法和对网络操作的支持（允许大量的不同地域分散的程序员可以共享他们工作的特性）非常符合开源软件领域合作的精神，CVS和它半混乱状态的开发模型成为了开源文化的基石。 但是像许多其他工具一样，CVS开始显露出衰老的迹象。 Subversion是一个被设计成为CVS继任者的新版本控制系统。设计者通过两个办法来争取现有的CVS用户：使用它构建一个开源软件系统的版本控制过程，从感觉和体验上与CVS类似，同时Subversion努力弥补CVS许多明显的缺陷。 Subversion 可以在多种不同的操作系统上运行，它的主要用户操作界面是基于命令行的，但现在已经开发出很多可以运行在不同操作系统上的客户端以及多种开发工具的集成套件。 CollabNet 这个公司早在 2020 年和 XebiaLabs 进行了合并。 CVS 这个软件版本控制一直在 2010 的一个项目中还在使用。 后来好不容易让那个项目把版本控制从 CVS 转换到 SVN，谁知道没有过多久又需要从 SVN 转换到了 GIT。 不管怎么样，在大学毕业后的那几年，软件版本的控制一直用的是 CVS，也算是代表了青春的一段回忆。 还记得 CVS 那时候使用的logo是这条小鱼，不过很多年已经没有看到过这条小鱼了。 客户端那个时候使用的是这只小乌龟，现在软件开发的时候还是会安装这个小乌龟，只是这个小乌龟从 CVS 变成 SVN，然后变成了git。 不管软件行业的开发怎么变，当一个产品被市场慢慢淘汰的时候，可能连一个招呼都不会打。 https://www.isharkfly.com/t/cvs-subversion/10626/2
警告的信息为： error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left. 原因和解决 这主要发生在 pnpm 版本与 Node.js 版本不兼容 时（特别是 Node.js 20+），常见于运行 pnpm install 或构建项目时。 解决方法也很简单，运行下 pnpm 的更新命令。 npm install -g pnpm@latest 然后检查下版本。 PS D:\WorkDir\Repository\Stonex\Stonex-Isharkfly-Ui> pnpm -v 7.29.1 PS D:\WorkDir\Repository\Stonex\Stonex-Isharkfly-Ui> npm install -g pnpm@latest changed 1 package in 9s 1 package is looking for funding run `npm fund` for details PS D:\WorkDir\Repository\Stonex\Stonex-Isharkfly-Ui> pnpm -v 10.33.0 可以看到 pnpm 的版本升级到了 10.33.0 再次运行安装程序，使用升级后的版本，通常问题都可以完全解决。 https://www.isharkfly.com/t/npmp-error-err-invalid-this/9801
构建 VUE 项目时，提示错误信息： Build VUE ... [Pipeline] sh (hide) + pnpm install --frozen-lockfile This project is configured to use yarn because /var/lib/jenkins/workspace/Stonex/Stonex-Mdm-Ui/package.json has a "packageManager" field 但实际上源代码的包文件中没有packageManager 这个配置。 登录 DeveOps 服务器，发现确实添加有：packageManager 这个参数。 有点奇怪这个参数是从哪里来的。 原因和解决 因为源代码中没有这个配置，但在构建的时候添加上去了。 猜测有可能是 Jenkinsfile 配置文件的问题。 因为在配置文件中，我们添加了： sh 'yarn set version berry' 猜测是这个配置导致的问题。 删掉这句话后再次尝试构建。 https://www.isharkfly.com/t/jenkins-pipeline-packagemanager/10623
+ yarn add -D wrangler@latest This project is configured to use pnpm because /var/lib/jenkins/workspace/Stonex/Stonex-Mdm- Ui/package.json has a "packageManager" field 上面的错误原因非常明确，是因为使用的包不同。 原因和解决 修改使用 pnmp 来进行部署。 原来的配置为： stage('Deploy to Cloudflare') { steps { // Install Wrangler locally for the project sh 'yarn add -D wrangler@latest' // Deploy sh "yarn wrangler pages deploy ./dist --project-name=${PRJ_NAME} --branch=main" } } 修改为： stage('Deploy to Cloudflare') { steps { // Install Wrangler locally for the project sh 'pnpm add -D wrangler@latest' // Deploy sh "pnpm wrangler pages deploy ./dist --project-name=${PRJ_NAME} --branch=main" } } 再次尝试部署。 https://www.isharkfly.com/t/jenkins-cloudflare/9316