Nicksxs's Blog

What hurts more, the pain of hard work or the pain of regret?

这题的题目介绍有一定的误导性,没有把字典序说明白,虽然的确是常规意义的字典序,但是题目介绍给的序列顺序反而会让人觉得那样不对
这里我们逐步深入地来讲这个题,也类似于找规律
注意:这里的递减递增序列都是从前往后看的
字典序可以就当查字典,或者默认的字符串排序方式,就是对于一个序列,逐个字符对比,同一位的相同再对比下一位的,例如 11在12前面,12在13前面,
那对于同一组字符或者像题中的数字,以最简单的12来分析,因为这个就两种排列,12跟21,按字典序排列,12在前,21在后
通过这个仔细点也能发现,或者再举个例子123,这个排列就会多一些了

1
2
3
4
5
6
123
132
213
231
312
321

一共有这么几种,不过举这个例子是为了更具体的发现规律,对于第一个数字相同的情况,比如123跟132,是132在后,发现规律没,递增序列是最小的,递减序列是最大的,因为2个数字 只有两种排列,扩展到3个数字,也可以把它拆分开,同样是第一个数字是1,后面两个数字就又回到了前面12序列的情况,
所以就可以把问题分成两部分来解决,首先从后往前找到递减序列
通过例子来讲

1
1 4 6 5 3 2

为什么要找到递减序列,因为递减序列已经是最大的了,要做调整要在这个之前调整,并且要找的是下一个序列,所以要是最接近的那个,否则我找到的可能就是下N个了,这个有点类似于数学里进位的意思,比如十九,九已经是个位里最大的了,找下一个比它大的只能是前面一位加一,但是加一以后需要九变到这一位的最小,也就是零。
对于上面的例子,递减序列就是6532,第一个非递减的是4,我要找下一个就是要比当前这个大,那我就去后面找比4大的,至于为什么能找到,因为这是递减序列边界之外的,说明肯定有比它大的,那要找哪个呢,要找比4大的数字里最小的,这样才是最近的下一个序列,并且因为后面是递减序列,所以可以直接从后往前找第一个
也就是会找到 5
找到 5 之后就做交换

1
1 5 6 4 3 2

这样是不是就行了呢,不行,因为这不是下一个,而是下N个,当4变成5之后,这个序列不管5后面的数字怎么变都是比 146532 大的,但是要找的是下一个,最接近的那个,则需要后面的序列变成最小,也就是变成递增序列,也就是

1
1 5 2 3 4 6

这里有两种例外情况,或者严格来说是一种
第一种是本身整个就是递减序列了,这在题中说了,下一个就是从头再开始,那就也很简单整个排序成递增的就行了
第二种是本身就是个完全递增的,那其实就交换末两位,但这种跟上面的可以糅合在一起,比如就是

1
1 2 3 4 5 6

单个6构不成递增或递减,找到的第一个非递减的数字就是 5 ,那就是在 5 后面找一个比它大的做交换,这时只有 6 ,所以就 5 跟 6 交换下,然后单个 5 做排序也等于不用做
再结合代码来看

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public void nextPermutation(int[] nums) {
int n = nums.length, i = n - 2, j = n - 1;
// 这个while循环是为了从后往前找到递减序列的分界点
// 循环完成后i就是递减序列左边的第一个数字位置
while (i >= 0 && nums[i] >= nums[i + 1]) --i;
if (i >= 0) {
// 表示有找到分界点,然后就从后往前找到第一个比nums[i]大的做交换
while (nums[j] <= nums[i]) --j;
// 这个while循环在找到第一个nums[j] > nums[i]时退出
// 下面就是做交换
int temp = nums[i];
nums[i] = nums[j];
nums[j] = temp;
}
// 因为前面已经保证了逆序,这里只要排成正序就是最小的了
Arrays.sort(nums, i+1, nums.length);
}

很早之前就有用过iptables,那时候是早期版本的Ubuntu系统,配置防火墙的时候,是挺复杂的,就是在reject之前添加accept规则,并且当时很多网上资料都是在后续添加就行,这个其实在当时是有问题的,所以比较印象深刻。
这次碰到的问题是对iptables的概念不熟悉有关,因为iptables的逻辑其实也有一定问题我觉得,比如最基本的命令,iptables -L
这里help显示的是会展示所有chain的rules

但是这样完全把table概念给忽略了,如果不注明理论上应该把所有table的展示出来,或者把包含这个参数并且是默认给出filter这个table的写清楚
所以这次要补一下这部分概念
iptables里首先就是有四种table,分别是 Filter, NAT, Mangle, Raw四种内建表
并且层次结构是 iptables -> Tables -> Chains -> Rules.
filter:
This is the default table (if no -t option is passed). It contains the built-in chains INPUT (for packets destined to local sockets), FORWARD (for packets being routed through the box), and OUTPUT (for locally-generated packets).
包含 INPUT,FORWORD和OUPUT三个chain,默认就是展示这个,所以就会导致用iptables -L 显示不了mangle table的规则
nat:
This table is consulted when a packet that creates a new connection is encountered. It consists of three built-ins: PREROUTING (for altering packets as soon as they come in), OUTPUT (for altering locally-generated packets before routing), and POSTROUTING (for altering packets as they are about to go out).
nat包含 PREROUTING,OUTPUT,POSTROUTING三个chain
mangle:
This table is used for specialized packet alteration. Until kernel 2.4.17 it had two built-in chains: PREROUTING (for altering incoming packets before routing) and OUTPUT (for altering locally-generated packets before routing). Since kernel 2.4.18, three other built-in chains are also supported: INPUT (for packets coming into the box itself), FORWARD (for altering packets being routed through the box), and POSTROUTING (for altering packets as they are about to go out).
mangle主要用于专门的数据包更改,包含 PREROUTING,INPUT,OUTPUT,FORWARD,POSTROUTING 五个chain,注意有内核版本区别,只是现在基本没那么老的内核了
raw:
This table is used mainly for configuring exemptions from connection tracking in combination with the NOTRACK target. It registers at the netfilter hooks with higher priority and is thus called before ip_conntrack, or any other IP tables. It provides the following built-in chains: PREROUTING (for packets arriving via any network interface) OUTPUT (for packets generated by local processes)
包含 PREROUTING和OUTPUT,主要用来配置例外
chain内部会有实际的rule规则,这个具体后面可以介绍

玩客云 casaos

玩客云这样的小机器现在也有一些自己的生态了,感谢开源大佬们的贡献,这个casaos就是个颜值颇高的轻nas方案,casaos虽然叫做os,但其实一套轻nas组件,并且有一个好看的webui,然后通过docker来作为内部的软件市场安装形式,我们沿着上一篇接下来尝试下安装轻度试用下这个casaos,首先安装

1
2
3

curl -fsSL https://get.casaos.io | sudo bash

安装会提示空间不够大,可以先忽略,如果想更保险的话就可以通过加一张SD卡或者USB插外接硬盘

安装中主要是执行了casaos的一些安装shell,以及启动rclone服务,完成后给出了登录地址,默认是80端口,可以在后面UI界面里更改端口


也可以设置自动挂载usb

安装完以后打开地址

创建账户

进入系统后的UI长这样


还是挺赏心悦目的,默认会展示系统的状态,cpu,内存和存储网络这些,预装了syncthing作为同步工具,还有个App Store

有挺多应用在商店

只是这里就会发现个问题,只是玩客云是32为的ArmV7系统

有很多组件不支持,包括jellyfin这些,不过它提供了自定义安装功能,可以自定义安装docker镜像

不过这里有个小bug,拷贝镜像名进入第一个输入框以后会提示不能为空,这边需要带上tag一起复制进去

第二个问题是我安装的0.4.8是没办法安装latest以外的tag的,不然会提示 store app not found

在dockerhub上是有armv7版本的jellyfin的,只是没有latest这个tag的,如果实在想体验下就考虑安装casaos的0.4.7或更早先版本的或者可以自己在Armbian里拉取镜像再安装下Portainer来管理docker,不过玩客云的性能是真的很羸弱,所以不要抱什么期望,低负载的任务可以跑跑,jellyfin显然不是很合适的,只是作为一个示例

逻辑复杂负载比较高的就算了,考虑N1或者其他性能更好的机器

LlamaIndex 是目前比较新的大模型RAG框架,RAG是指 检索增强生成 (Retrieval-Augmented Generation, RAG)是指在利用大语言模型回答问题之前,先从外部知识库检索相关信息。RAG 被证明能显著提升答案的准确性,并特别是在知识密集型任务上减少模型的错误输出。通过引用信息来源,用户可以核实答案的准确性,从而增强对模型输出的信任。
此外,RAG 有助于快速更新知识并引入特定领域的专业知识。
RAG 有效结合了大语言模型的参数化知识和非参数化的外部知识库,成为实施大语言模型的关键方法之一。本文概述了 RAG 在大语言模型时代的发展模式,总结了三种模式:初级 RAG、高级 RAG 和模块化 RAG。
首先我们可以了解下LlamaIndex的几大模块,
使用大型语言模型(LLMs):无论是OpenAI还是任何托管的LLM,亦或是您自己本地运行的模型,LLM都被用于从索引和存储到查询和解析数据的每一个步骤。LlamaIndex提供了大量可靠经过测试的提示,我们也将向您展示如何自定义您自己的提示。
LlamaIndex 主要有这五大块能力

  • Data connectors
  • Data indexes
  • Engines
  • Data agents
  • Application integrations

其中加载部分可以认为是初始的部分,我们可以从各个数据源去获取信息,比如各种文档,或者confluence,甚至api接口,只需要合适的数据加载器,我们就能将其转化为我们要的数据
比如我想要将我博客里的Markdown文件作为知识库加载

1
2
3
4
5
6
reader = SimpleDirectoryReader(
input_dir="./somedir/source/_posts/",
required_exts=[".md"],
recursive=True
)
docs = reader.load_data()

然后由文档来就构建我们的索引

1
index = VectorStoreIndex.from_documents(docs)

但是这里我们需要提前设置好对应的 embedding 模型,这个很重要,如果有条件推荐使用OpenAI的,如果想用本地的可以考虑使用BAAI智源出品的,只是要注意是否支持多语言,如果要使用本地embedding的话需要安装

1
pip install llama-index-embeddings-huggingface

这里我选了BAAI也就是智源研究所的bge-m3模型,因为这个是支持多语言的,如果是纯英文的可以用他们 BAAI/bge-small-en-v1.5

1
2
3
4
5
6
7
8
9
10
from llama_index.core import Settings
from llama_index.embeddings.huggingface import HuggingFaceEmbedding
Settings.llm = Ollama(model="gemma:7b", request_timeout=60.0)
Settings.embed_model = HuggingFaceEmbedding(
model_name="BAAI/bge-m3"
)
index = VectorStoreIndex.from_documents(docs)
query_engine = index.as_query_engine(llm=gemma_7b)
response = query_engine.query("数据库主从延迟")
print(response)

另外LLM 我使用了本地部署的 gemma:7b,因为想尝试下本地的链路,需要注意的是一些文档还是用的原来的service_context,在新版本中这个已经被改掉了,都是通过 Settings 来设置,此外还有诸如 SimpleDirectoryReader 这些包也被挪到了 llama_index.core 中,需要注意下
然后我们就能使用这种方式来增强LLM,把我们的本地文档作为知识库来搜索,结合了大模型的能力。

derper是 tailscale 已经开源的 tailscale 中转服务,可以进行自己搭建,不然就是使用 tailscale 提供的 derper 节点,我的体验是在晚上高峰期会比较卡,所以有能力可以自建的话也是比较推荐的,不过相对比前面的设置会麻烦点

第一个就是默认这个是需要 https 的,所以需要给 derper 服务申请个域名,或者有了域名就加个解析,比如 dp.hello.com,申请完域名就需要申请证书了,这个刚好就学习下使用 acme.sh这个工具,还是非常不错的,我用的是腾讯云的域名解析服务,其实是收购的 dnspod 的服务,acme.sh 安装就很简单,一条命令

`

1
curl  https://get.acme.sh | sh

然后成功了之后就要把.zshrc 生效下,默认会把脚本路径加入到当前的 shell 的 rc 文件里,然后就是申请证书,但是有两种方式,一种就是在域名指定的 ip 机器对应的访问路径下放置验证的文件

1
acme.sh  --issue  -d domain.tld -d www.domain.tld  --webroot  /home/wwwroot/domain.tld/

比如这样指定 webroot,另一个中更方便的方式就是通过 dns 认证的方式,我这边以 dnspod 举例,这边要特别注意的是 dnspod 虽然被腾讯云收购,但是这个方式还是需要用 dnspod 原来自己的 api token 验证的

然后拿到生成的 id 跟 token 设置到环境变量里,需要保存好这个 token,后面是看不到了的

1
2
export DP_Id=123456
export DP_Key=xxxxxx

然后就可以用命令进行验证了

1
acme.sh --issue --dns dns_dp -d xxx.hello.com

这个是 dnspod 家的,其他的也可以在这里找到验证方式

申请完成后会把证书放在用户目录下的.acme.sh 目录中,记得把cer文件改成 crt,并且文件名只能是域名 xxx.hello.com.crt,我没试过其他的行不行,从别的文章里看到需要一致,然后就是启动 derper 了

我们通过 docker 的方式,

1
2
3
4
5
6
7
8
9
sudo docker run --restart always \
--name derper -p 12345:12345 -p 3478:3478/udp \
-v /$dir/.acme.sh/xxxxx.hello.com_ecc/:/app/certs \
-v /run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock \
-e DERP_CERT_MODE=manual \
-e DERP_ADDR=:12345 \
-e DERP_DOMAIN=xxxxx.hello.com \
-e DERP_VERIFY_CLIENTS=true \
-d ghcr.io/yangchuansheng/derper:latest

 前一个端口 12345可以自己随意定,后面$dir改成自己的.acme.sh目录所在的路径,然后

-v /run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock \ 这一行 和-e DERP_VERIFY_CLIENTS=true \ 是为了能够让 derper 能够安全一些,就是在本机开一个 tailscale 客户端,连接接到 headscale 服务,可以参考前面的添加节点,然后把这个启动客户端的进程映射进docker里面,因为本身 derper 就没有特别的认证逻辑,所以就让同一个headscale服务的客户端进程来验证是属于同一个headscale服务的节点才允许加入中转,实际这样就跑起来了一个 derper 服务这样可以用 docker 命令查看日志

sudo docker logs -f derper 查看是不是有问题,然后如果没有问题的话还不一定代表 derper 起来了,比较直接的方法就是直接打开域名加上端口的地址,比如 xxxx.hello.com:12345 这个,

image

显示这个就代表服务已经正常启动运行了,然后就是需要修改 headscale 的配置文件了,首先要设置 derper 的配置文件,类似这样

1
2
3
4
5
6
7
8
9
10
11
12
13
regions:
100:
regionid: 100
regioncode: ahk
regionname: Aliyun Hongkong
nodes:
- name: 100a
regionid: 100
hostname: xxxxx.hello.com
ipv4:
stunport: 3478
stunonly: false
derpport: 12345

regionid表示区域 id,一个区域下可以后多个 node,node的 name 是节点的唯一识别码,ipv4 可以不填,有 hostname 就可以,然后stunonly 是 false 表示不只使用 stun还可以使用 derp

然后就是修改 headscale 自身的配置文件,把共用的 derper 配置改成

image

上面的 urls 注释掉,后面的 paths 添加刚才的配置文件路径,这样就可以了,至于连接是不是走的这个

可以用 tailscale netcheck 查看最近的 derper 节点已经延迟,看到使用了自己的 derper 就对了

0%