Gogs是很优秀的git托管，之所以想迁移到gitea最大的痛点是代码搜索，这个确实很有必要。当然带价就是会费不少服务器资源。

迁移流程大概是：

1. 进入gogs环境执行gogs backup --database-only
2. 备份git库，比如我是zip打个包
3. 把数据库版本切换到13UPDATE version SET version=13;
4. 用docker跑gitea:1.1.4，指定好gogs的mysql数据库
5. 这里一定要根据gitea手册检查对应的几个文件夹，比如avatas等，目录结构跟gogs是不一样的
6. 确定使用正常后docker升级到1.6.4，最后升级到最新版

然而我在升级的时候不知道是不是文件夹关系，最后打开的库都是404，研究中发现，gitea会用git库提交的name和邮箱来对应网站上的用户。所以另一个避坑建议就是请再gitea中保持原有的用户名和邮箱不变。

每个玩过dns的都会碰到这个问题，当修改了/etc/resolv.conf后马上就生效了，然后重启后就都丢失了。其实在这个文件的开头就有明确的提示，此文件为链接文件，每次都会重新生成。并且你修改了原文件后也还是会被覆盖，不知道提出这个建议的人为什么没有被还原。 正确的做法应该是修改systemd的配置文件/etc/systemd/resolved.conf，修改其中dns配置项，不知道是不是生效特别慢还是怎么的，我的还是ping不通，所有linux手册都是推荐这个，实在不行再用后面的终极大法。

终极大法

1
2

systemctl stop systemd-resolved.service
systemctl disable systemd-resolved.service

其实systemd之所以接管dns，好像是到目前为止没有人做过一个像样的管理器，所以他才勉为其难接管，然后做的也太难用。既然就是/etc/resolv.conf他的问题，那么让systemd放弃dns接管，改为手动设置即可，毕竟dns服务器万年不变的。 这里需要注意的是linux只支持三个namserver哦，多了也没用。 对了，我是docker中没有生效，如果也是docker的问题可以用这个办法，同时docker支持手动在damon配置中配置dns：

1
2
3
4
5
6

{
  "dns" : [
    "114.114.114.114",
    "8.8.8.8"
  ]
}

常用命令

dig @xxx.xxx.xxx.xxx www.domain.com 指定ip地址解析域名，我最喜欢用了

nslookup www.domain.com 最常用的，信息量丰富

1
2
3
4
5
6
7
8
9

resolvectl query domain | ip address
用於 DNS 的正向或反向查詢，取決於輸入資料。
裡面也會寫查詢的協議、回應時間等等資料。
resolvectl status
查詢目前 systemd-resolved 的設定。
resolvectl statistics
查詢 systemd-resolved 的統計資料，像是快取數量及命中率。
resolvectl flush-caches
清除本機 DNS 快取，一般來說應該用不到，除非 DNS 被污染而快取錯誤的資料吧。

云服务器注意点

在配置腾讯云服务器时发现他居然单独给网卡设置了dns，所以实际解析都是靠这个地址，比如内网系统更新源镜像、docker镜像等。所以linux的三个nameserver依次就是

1. 我们的dnsmasq
2. 云厂商nameserver
3. 公网nameserver比如114.114.114.114

阿里云内网地址

1
2
3
4
5

nameserver 100.100.2.136
nameserver 100.100.2.138
nameserver 223.5.5.5
nameserver 223.6.6.6
options timeout:2 attempts:3 rotate single-request-reopen

第一次接触是在给k8s实验集群架设ELK时才知道这个东西的，第一印象就是它的哲学非常符合k8s的调调，之所以考虑将nginx迁移过来，主要的考虑还是服务发现。

下面是使用的感受和坑以及建议

• 它不够轻量，虽然是go编写的，实际使用内存在40MB左右，所以很抠的个人服务器要注意下；
• 它不是传统意义上的webserver，所以它不能像nginx一样代理fastcgi，通常还是要交给nginx来做，“纯”这个东西对有的人来说是好东西；
• 它的配置分为静态配置和动态配置，动态配置就是支持服务发现的部分，这里有意思的是比如有一个file，初始时是静态配置，中间你更改了，更改的部分就是动态的了，当然最好别这么干；
• 静态配置是互斥的，狗日的没人说，找了很久在v2 的一个issue中看到的，静态分为docker file cli ，不知道是哪个版本开始的，至少2.8中互斥；
• 配置最佳实践是，不变的，精简的，初始化导向的放在cli中，其他都用docker的label做动态配置；
• 别跟nginx比性能，虽然差的不多，但是不应该作为对比的存在；
• traefik的service中除了初始化的静态配置外应该包含：entrypoint，middleware，default route
• 可以设置providers.docker.constraints，这样只会监控需要路由的服务；
• dashboard是个好东西，但是最好不要暴露，哪怕是用密码登录，最好的方式是是用openvpn访问，我怀疑traefik之所以吃内存也是这个dashboard的关系
• acme支持泛域名，我喜欢tls challenge，比较简洁吧，这里需要注意的是，因为免费服务，到期前如果脸黑反复失败，会造成let’s encrypted 限流，导致无法更新证书

先说三遍：垃圾小程序垃圾小程序垃圾小程序~ 系统api中systemInfo什么都给了，就是不直接给你这两个高度，可能是涉及组件的实现吧，搭建在安卓和ios上的hybird渲染就是麻烦。

直接上答案：navBarHeight = systemInfo.statusBarHeight + 44; 有人会问44哪里来的，44就是所有ios导航栏的高度 tabbarHeight=systemInfo.screenHeight-systemInfo.safeArea.bottom + 50

height: calc(100vh - 96rpx（自定义的tabbar组件高度） - env(safe-area-inset-bottom)（适配苹果）);

首先是框架组件的选择

目前主流框架是uni-UI和taro，可能拼错了，不想再去打开，虽然两者都支持react和vue，说说的而已，前者主要支持vue，后者主要支持taro，前者很接地气跟vue一个德行，后者很react，了解他们的都懂我说的啥。自以为清高跳过源生直接来了个taro+taro UI。大概玩了几天，莫名奇妙的坑无数，最烦的是无法适配“微信开发者工具”，无奈放弃react的写法（确实很爽，之前没用react写过东西）。再接触源生后发现，狗日的，taro这些其实是大坑，那么多小程序平台，只有微信的吸引我，不跨平台千万别用这些垃圾框架，bug多，机器人回复issue，全是kpi的产物。最后源生只要看好微信不得不趟过去的坑即可，加上有赞的vant组件即可满足大部分需求。

再说说垃圾微信

你弄个小程序平台就好好弄，自己跟自己搞得很矛盾，比如引入component，写tabbar时又不需要，还得把路径名都写死，惊呼大撒币。毫无疑问，这个平台的设计者根本不关心逻辑的一致，也不关心开发者是不是乐意好好开发。也是就是个流量入口而已，完整的功能肯定放在源生app上，小程序只要简单完成闭环和引流即可。

结论：虽然国内互联网发展很猛，但是土壤决定了出一个好框架可信赖的组件基本不太可能

默认UG使用的是1位小数，但是在机加工领域最常用的是2位小数，每次新建模型修改特别麻烦，最好的办法就是把母模板文件改了一劳永逸。下面是UG12和1980两个版本的模板文件路径。修改方法很简单，用一个已经修改好的prt文件替换下面路径中的model-plain-1-mm-template.prt即可。 UG12的路径地址：C:\Program Files\Siemens\NX 12.0\LOCALIZATION\prc\simpl_chinese\startup\model-plain-1-mm-template.prt UG1980的路径地址：C:\Program Files\Siemens\NX1980\LOCALIZATION\prc\simpl_chinese\startup\model-plain-1-mm-template.prt

使用wtform时populate_obj一直是一个非常方便的方法，不同于其他语言，python的这种方式显得理所当然。它的作用很简单，就是将表单中同名的属性赋值给对象。 TypeError: populate_obj: cannot find a value to populate from the provided obj or input data/defaults 只要使用这个方法，上面错误可谓是常见，debug也没有告知到底是哪一个的值出现问题。这里给一个能覆盖99%问题的思路，就是它在赋值时要么是名字不对应找不到，要么是赋值的对象为空。今天一个表单之前还工作正常加了一个属性后就挂了，偏偏是一个‘FieldList’，关于这个字段类型，需要在初始化中告知它赋值的对象类型，比如：FieldList(FormField(InvoiceForm,default=Invoicedetail), min_entries=1)

简单记录如下：

1. 开启不明来源安装，毕竟来路不正；
2. 卸载之前的版本，对不起我只知道remove 应用程序文件夹，这里很坑，你可能在六个位置找到adobe相关的文件夹，这里建议删除的方式适用于安装adobe全套工具，否则会破坏adobe其他已经安装的程序；
3. 下载官方的安装包安装，因为如果没有卸载干净还是会报错，嗯，我就碰到了。可是安装包巨大，下载久的话下一个办法；
4. 安装Creative Cloud ，2.9MB，记住不要安装提示的防恶意软件app，装好后就可以卸载了。这个东西极其恶心，用完就可以卸载了，然后你就可以愉快地安装了，因为它会帮你清理所有路径下adobe的文件夹。

典型的错误信息如下：

ERROR exporting to image
error: failed to solve: server message: insufficient_scope: authorization failed

这个问题卡了我好久，也正好理了一下xbuild的原理，首先buildx只是个壳干活的叫buildkit，xbuild在目标容器中进行build构建，而目标容器中使用 QEMU这个东西模拟了不同架构下的指令，构建好了以后还有一个输出的过程，因为它支持非常非常多的格式，OCI兼容的只是其中一种，所以真的非常强大。 说了那么多废话，实际使用中要注意的就是build成功后如果出现上面的错误，说明导出配置有问题，一般打tag会直接指向目标repo地址，如果打的是本地的，那么加上–push就是错误的配置，可以改为-o type=docker,但是这很奇怪，docker文档中就说明了一般直接使用目标repo。因为使用docker driver导出后只适用于本地，没有实际意义，我能想到的就是测试的时候可能会方便一些。

最近在试着学UG，突发奇想自己的mbp能不能跑，一搜有youtube大神装过了，可惜没有太多细节，这里列一下我在安装时碰到的坑。

首先的首先，windows11 必须安装arm版本，这个版本的windows还处于inside阶段，所以经常崩溃，我不得不重启来应对，所以主力觉得不适合拿来用太影响效率了。 目前mbp M1芯片全线不支持bootcamp所以不得不跑在虚拟机上，这也是为什么我用“突发奇想”来形容了，这就意味着不能发挥出100%的硬件效率。而虚拟机的选择有两种，vmware和parallels desktop17（16版本据说对11arm兼容有问题）。 能很明显的感觉到vmware比PD17更流畅说明核心技术vmware更强，但是在各种适配上vmware完败，因为分区的问题无法在vmware上测试UG NX。 UG NX油管上大神用的是1980版本，我安装的是最新的2023，请尽量用最新的 版本。 安装UG 之前请先行安装jvm和.net framework,目前jvm没有找到特供win arm的版本，.net framework可以找到请将5.0+和6.0+都装好，这样可以绕开UG安装包默认装的组件。默认的组件只支持x86。 运行效率：UG入门的草图速度一般般不算太慢，因为是x86转译加上虚拟机所以可以相像如果适配了arm版本的ug那么效率值得期待。