AI-Assisted

概念 优先级队列（Priority Queue）是一种特殊的队列，队列中每个元素都附有一个"优先级"。出队时，不再遵循普通队列的 FIFO（先进先出）原则，而是优先级最高（或最低）的元素先出队。 直观类比：医院的急诊室——无论谁先到，病情最重的患者优先就诊。 核心特性 插入（insert / enqueue）：将元素连同优先级一起加入队列 取最值（peek）：查看优先级最高的元素，不移除 取出最值（poll / dequeue）：取出并移除优先级最高的元素 不保证全局有序：内部结构只保证堆顶（最值）正确，其余元素顺序不确定 内部实现：二叉堆 绝大多数语言的标准库都用**二叉堆（Binary Heap）**实现优先级队列。 堆的结构 用完全二叉树表示，通常以数组存储 最小堆（Min-Heap）：父节点 ≤ 子节点，根为最小值 最大堆（Max-Heap）：父节点 ≥ 子节点，根为最大值 数组索引关系（从 0 开始）： 节点 索引 父节点 (i-1) / 2 左子节点 2*i + 1 右子节点 2*i + 2 核心操作：上浮与下沉 上浮（Sift Up）：插入新元素时，将其放在数组末尾，然后与父节点比较，不满足堆性质则交换，直到满足为止。 下沉（Sift Down）：取出堆顶后，将末尾元素移到堆顶，然后与子节点比较，不满足堆性质则与较小（或较大）的子节点交换，直到满足为止。 时间复杂度 操作 时间复杂度 插入 $O(\log n)$ 取出最值 $O(\log n)$ 查看最值 $O(1)$ 建堆（heapify） $O(n)$ 两种变体 最小优先级队列（Min Priority Queue） 优先级数值最小的元素最先出队。例如：Dijkstra 最短路径算法中，每次选取距离最小的节点。 最大优先级队列（Max Priority Queue） 优先级数值最大的元素最先出队。例如：任务调度中，优先执行优先级最高的任务。 ...

Git basic commands 目前比较流行的版本管理系统 相比同类软件，Git有很多优点。其中很显著的一点，就是版本的分支 (branch) 和合并 (merge) 十分方便。 有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本 (又称"快照") 的指针，因此非常快捷易用。 commands git status --porcelain #用于以简洁、脚本友好的格式显示 Git 仓库当前的状态，方便自动化处理和快速查看文件的变动情况。 git ls-files --unmerged git diff --name-only --diff-filter=U #显示出 HEAD 对应的提交的 hash 值 git rev-parse HEAD git rev-parse --short HEAD # windows install git winget install Git.Git # 显示工作树状态, (已经修改但是没 git add, 或者 没有 git commit) # 显示索引文件和当前HEAD提交有差异的路径，工作树和索引文件有差异的路径，以及工作树中不被Git追踪的路径（也不被gitignore[5]忽略）。前者是你通过运行 "git commit "会提交的东西；第二和第三者是你在运行 "git commit "之前通过运行 "git add "可以提交的东西。 git status -s # 查看本地仓库的当前分支和远程分支的差异(已经 commit 但是还没 push), 只显示 commit id 和 comments git cherry -v # 查看本地仓库的当前分支和远程分支的差异(已经 commit 但是还没 push), 展示方式类似 git log git log master ^origin/master # 计算对象数和磁盘消耗 git count-objects -vH # 指定目录 1.8.5 以前 git --git-dir=/Users/jhoffmann/tmp/my-project/.git --work-tree=/Users/jhoffmann/tmp/my-project/ pull # 指定目录 >=1.8.5 git -C /Users/jhoffmann/tmp/my-project/ pull options -C, 大写 C 指定目录, .git 所在的目录 –version, 查看 git 版本 origin https://www.zhihu.com/question/27712995 ...

k8s command commands kubekey https://github.com/kubesphere/kubekey Rancher https://rancher.com/ archlinux install k8s ubuntu install k8s commands # 查看某一个 pod 配置 kubectl get pod <pod-name> -n <namespace> -o yaml # 找到 Pod 所属的 Controller（通常是 Deployment） kubectl get pod <pod-name> -o jsonpath="{.metadata.ownerReferences[0].name}" # 查看 Deployment 的 YAML 启动命令 kubectl get deployment bgp-opt-backend -o yaml # exec api kubectl exec -it "$(kubectl get pods | grep -Eo '^[^ ]+' |grep api)" -- bash # pod kubectl get pod -A -o wide # 查看 pod, 比如能看到镜像版本 kubectl describe pods pod0 # configmap kubectl apply -f redis-config.yaml kubectl get configmap kubectl get configmap -n namespace0 kubectl edit configmap configmap0 kubectl delete configmap configmap0 # 显示集群信息 kubectl cluster-info kubectl cluster-info dump # 查询所有节点标签信息 kubectl get node -o wide --show-labels # kube-system namespace 的 pod kubectl get pods -n kube-system kubectl label node 192.168.0.212 gpu=true kubectl get node -L gpu kubectl get node -L kubernetes.io/arch # delete lable kubectl label node minikube disktype- kubectl describe node node0 ## 节点关机操作 ```bash # 1. 标记节点为不可调度（防止新 Pod 调度到该节点） kubectl cordon <node-name> # 2. 驱逐节点上的 Pod（优雅地将 Pod 迁移到其他节点） kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data # 3. 验证节点上是否还有 Pod 运行 kubectl get pods --all-namespaces -o wide | grep <node-name> # 4. 关机 sudo poweroff # 5. 节点重新上线后，恢复调度（取消不可调度状态） kubectl uncordon <node-name> 查看 pod 状态 kubectl get pods –all-namespaces ...

Git graph LR work["Working tree<br/>工作树/工作区"] stage["Index / Staging Area<br/>暂存区"] repo["Local Repository<br/>本地仓库"] remote["Remote Repository<br/>远程仓库"] work -->|add| stage stage -->|commit| repo repo -->|push| remote remote -->|pull| work remote -->|"fetch/clone"| repo stage -->|checkout| work repo -->|merge| work repo -->|"reset --soft"| stage repo -->|rebase| stage repo -->|"reset --mixed"| work 工作区 (working tree) working tree, 2.9.1 之前被称作 Working Directory https://stackoverflow.com/questions/39128500/working-tree-vs-working-directory 也称工作区, 工作目录、工作副本 我们日常开发操作是在工作区中进行的。 工作区的内容会包含提交到暂存区和版本库(当前提交点)的内容，同时也包含自己的修改内容。 ...

“video, h.264, h.265, ffmpeg” H.265与H.264是ITU-T VCEG 制定的视频编码标准。H.265标准围绕着现有的视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。具体的研究内容包括: 提高压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。H264由于算法优化，可以低于1Mbps的速度实现标清数字图像传送；H265则可以实现利用1~2Mbps的传输速度传送720P (分辨率1280*720) 普通高清音视频传送。 H.265旨在在有限带宽下传输更高质量的网络视频，仅需H.264的一半带宽即可播放相同质量的视频。H.265标准也同时支持4K(4096×2160)和8K(8192×4320)超高清视频。 H.264 H.264，同时也是MPEG-4第十部分，是由ITU-T视频编码专家组 (VCEG) 和ISO/IEC动态图像专家组 (MPEG) 联合组成的联合视频组 (JVT，Joint Video Team) 提出的高度压缩数字视频编解码器标准。这个标准通常被称之为H.264/AVC (或者AVC/H.264或者H.264/MPEG-4AVC或MPEG-4/H.264 AVC) 而明确的说明它两方面的开发者。 H.264最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。举个例子，原始文件的大小如果为88GB，采用MPEG-2压缩标准压缩后变成3.5GB，压缩比为25∶1，而采用H.264压缩标准压缩后变为879MB，从88GB到879MB，H.264的压缩比达到惊人的102∶1。低码率 (Low Bit Rate) 对H.264的高的压缩比起到了重要的作用，和MPEG-2和MPEG-4ASP等压缩技术相比，H.264压缩技术将大大节省用户的下载时间和数据流量收费。尤其值得一提的是，H.264在具有高压缩比的同时还拥有高质量流畅的图像，正因为如此，经过H.264压缩的视频数据，在网络传输过程中所需要的带宽更少，也更加经济。 H.265, HEVC(高效视频编码) H.265是ITU-TVCEG继H.264之后所制定的新的视频编码标准。H.265标准围绕着现有的视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。 新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。具体的研究内容包括: 提高压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。H264由于算法优化，可以低于1Mbps的速度实现标清数字图像传送；H265则可以实现利用1~2Mbps的传输速度传送720P (分辨率1280*720) 普通高清音视频传送。 H.265旨在在有限带宽下传输更高质量的网络视频，仅需原先的一半带宽即可播放相同质量的视频。这也意味着，我们的智能手机、平板机等移动设备将能够直接在线播放1080p的全高清视频。H.265标准也同时支持4K(4096×2160)和8K(8192×4320)超高清视频。可以说，H.265标准让网络视频跟上了显示屏"高分辨率化"的脚步。 H.265 与 H.264 有何不同 在讨论 H.265有哪些提升和优点之前，我们不妨先来了解一下H.264。H.264 也称作 MPEG-4AVC(Advanced Video Coding，高级视频编码)，是一种视频压缩标准，同时也是一种被广泛使用的高精度视频的录制、压缩和发布格式。H.264 因其是蓝光光盘的一种编解码标准而著名，所有蓝光播放器都必须能解码H.264。更重要的是，因为苹果公司当初毅然决然抛弃了Adobe 的VP6 编码，选择了 H.264，这个标准也就随着数亿台iPad和iPhone 走入了千家万户，成为了目前视频编码领域的绝对霸主，占有超过80%的份额。H.264 也被广泛用于网络流媒体数据、各种高清晰度电视广播以及卫星电视广播等领域。H.264相较于以前的编码标准有着一些新特性，如多参考帧的运动补偿、变块尺寸运动补偿、帧内预测编码等，通过利用这些新特性，H.264比其他编码标准有着更高的视频质量和更低的码率，也因此受到了人们的认可，而被广泛应用。 H.265/HEVC 的编码架构大致上和H.264/AVC的架构相似，也主要包含: 帧内预测(intra prediction)、帧间预测(inter prediction)、转换(transform)、量化(quantization)、去区块滤波器(deblocking filter)、熵编码(entropy coding)等模块。但在HEVC编码架构中，整体被分为了三个基本单位，分別是: 编码单位(coding unit，CU)、预测单位(predict unit，PU)和转换单位(transform unit，TU)。 H.265为 何优于H.264 比起H.264/AVC，H.265/HEVC提供了更多不同的工具来降低码率，以编码单位来说， 最小的8x8到最大的64x64。信息量不多的区域(颜色变化不明显，比如车体的红色部分和地面的灰色部分)划分的宏块较大，编码后的码字较少，而细节多的地方(轮胎)划分的宏块就相应的小和多一些，编码后的码字较多，这样就相当于对图像进行了有重点的编码，从而降低了整体的码率，编码效率就相应提高了。同时，H.265的帧内预测模式支持33种方向(H.264只支持8种)，并且提供了更好的运动补偿处理和矢量预测方法。 反复的质量比较测试已经表明，在相同的图象质量下，相比于H.264，通过H.265编码的视频码流大小比H.264减少大约39-44%。由于质量控制的测定方法不同，这个数据也会有相应的变化。通过主观视觉测试得出的数据显示，在码率减少51-74%的情况下，H.265编码视频的质量还能与H.264编码视频近似甚至更好，其本质上说是比预期的信噪比(PSNR)要好。这些主观视觉测试的评判标准覆盖了许多学科，包括心理学和人眼视觉特性等，视频样本非常广泛，虽然它们不能作为最终结论，但这也是非常鼓舞人心的结果。 目前的HEVC 标准共有三种模式: Main、Main10 和Main Still Picture。Main模式支持8bit色深(即红绿蓝三色各有256个色度，共1670万色)，Main10模式支持10bit色深，将会用于超高清电视(UHDTV)上。前两者都将色度采样格式限制为4: 2: 0。预期将在2014年对标准有所扩展，将会支持4: 2: 2和4: 4: 4采样格式(即提供了更高的色彩还原度)和多视图编码(例如3D立体视频编码)。 ...

ps command Linux 中的 ps 命令是 Process Status 的缩写 输出指定的字段 ps -eo pid, ppid, command ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' 其中 rsz 是是实际内存 ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' | grep oracle | sort -nrk5 其中 rsz 为实际内存，上例实现按内存排序，由大到小 http://blog.fpliu.com/it/software/procps ps 命令用来列出系统中当前运行的那些进程。ps 命令列出的是当前那些进程的快照，就是执行ps命令的那个时刻的进程，如果想要动态的显示进程信息, 可以使用 top 命令。 要对进程进行监测和控制，首先必须要了解当前进程的情况，也就是需要查看当前进程，而 ps 命令就是最基本同时也是非常强大的进程查看命令。使用该命令可以确定有哪些进程正在运行和运行的状态、进程是否结束、进程有没有僵死、哪些进程占用了过多的资源等等。总之大部分信息都是可以通过执行该命令得到的。 linux 上进程有 5 种状态 运行 (正在运行或在运行队列中等待) 中断 (休眠中, 受阻, 在等待某个条件的形成或接受到信号) 不可中断 (收到信号不唤醒和不可运行, 进程必须等待直到有中断发生) 僵死 (进程已终止, 但进程描述符存在, 直到父进程调用wait4()系统调用后释放) 停止 (进程收到SIGSTOP, SIGSTP, SIGTIN, SIGTOU信号后停止运行运行) STAT 进程的状态 R 运行 Runnable (on run queue) 正在运行或在运行队列中等待。 S 睡眠 Sleeping 休眠中, 受阻, 在等待某个条件的形成或接受到信号。 I 空闲 Idle Z 僵死 Zombie (a defunct process) 进程已终止, 但进程描述符存在, 直到父进程调用wait4()系统调用后释放。 D 不可中断 Uninterruptible sleep (ususally IO) 收到信号不唤醒和不可运行, 进程必须等待直到有中断发生。不可中断的睡眠，通常是I/O T 停止 traced or stopped 进程收到SIGSTOP, SIGSTP, SIGTIN, SIGTOU信号后停止运行运行。 停止或被追踪 terminate终止 P 等待交换页 W 进入内存交换（从内核2.6开始无效） 无驻留页 has no resident pages 没有足够的记忆体分页可分配。换出,表示当前页面不在内存 (从内核2.6开始无效) X 死掉的进程 < 高优先级进程 N 低优先级进程 L 内存锁页 Lock 有记忆体分页分配并缩在记忆体内, 些页被锁进内存 s session leader (在它之下有子进程) l 多进程的 (使用 CLONE_THREAD, 类似 NPTL pthreads) + is in the foreground process group, 前台运行. 默认情况下, ps 不会显示很多进程信息, 只是列出与当前终端会话相关的进程 ...

kitty kitty 是一个 GPU based terminal https://sw.kovidgoyal.net/kitty/ SSH 连接远程主机 xterm-kitty: unknown terminal type Kitty 使用 xterm-kitty 作为 $TERM 环境变量的值。通过 SSH 连接远程主机时，该值会被传递过去，但远程主机的 terminfo 数据库中没有 xterm-kitty 的定义，导致 git、vim 等程序报错： 'xterm-kitty': unknown terminal type. 解决方案：使用 kitty +kitten ssh Kitty 内置了 ssh kitten，连接时会自动将 terminfo 传到远程主机。 在 ~/.zshrc（或 ~/.bashrc）中添加别名： alias ssh='kitty +kitten ssh' 然后执行： source ~/.zshrc 之后直接执行 ssh openclaw 即可，无需其他改动。 远程控制（Remote Control） Kitty 支持通过命令行远程控制终端，可以实现自动化窗口管理、发送命令等功能。 启用远程控制 在 ~/.config/kitty/kitty.conf 中添加： # Unix Socket 方式（推荐，可从任何终端控制） allow_remote_control socket-only listen_on unix:/tmp/kitty.sock 注意：使用 Unix Socket 方式时，Kitty 会在 socket 文件名后自动添加进程 ID，例如： ...

“network manager” sudo pacman -S networkmanager sudo systemctl status NetworkManager.service sudo systemctl start NetworkManager.service sudo systemctl restart NetworkManager.service sudo pacman -S nm-connection-editor sudo pacman -S network-manager-applet nmcli device nmcli connection nmcli c delete System policy prevents control of network connections System policy prevents control of network connections System policy prevents modification of network settings for all users< vim /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy Open /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy with root/sudo privileges and search for the following line: ...

git merge git rebase interactive rebase Join two or more development histories together merge 合并 用于将两个或多个分支的更改合并到一起。它通常用于将一个分支上的开发成果合并到当前分支（如将 feature 分支合并回 main 分支）。其主要作用是整合不同开发者或分支上的工作，保持代码库的统一和最新。 # 基本用法 # git merge <branch-name> # merge 默认会把 commit 的历史都合并进来 # 把 branch_0 合并到当前分支 git merge branch_0 # -m 参数用于指定合并提交（merge commit）的说明信息，即合并时生成的 commit message。 git merge branch_0 -m "MSG0" # 禁用 Fast forward git merge branch_0 -m "merge with no-ff" --no-ff 合并方式 Fast-forward（快进合并） 如果当前分支没有新的提交，仅仅是落后于目标分支，Git 会直接把指针向前移动到目标分支的位置，这种合并不会产生新的合并提交。快速合并，看不出做过合并。快进合并后不会留下一个明显的"feature 分支合并节点"，只有一条线性的记录。 特点： 不创建 merge commit 分支指针直接前移 提交历史呈线性 无法看出曾经有分支存在 示意图： ...

Kong 插件开发语言 Kong 支持使用多种语言开发自定义插件： 语言 方式 说明 Lua 原生支持 Kong 基于 OpenResty/Lua 构建，Lua 是最成熟、性能最好的插件开发语言，官方内置插件均用 Lua 编写 Go Go PDK 通过 go-pdk 库开发，编译为独立进程，Kong 通过 IPC 通信调用 JavaScript / TypeScript JavaScript PDK 通过 kong-js-pdk 开发，运行在独立的 Node.js 进程中 Python Python PDK 通过 kong-python-pdk 开发，运行在独立进程中，适合快速原型开发 WebAssembly (Wasm) Wasm Filter Kong 3.4+ 支持，可以用 Rust、C/C++、Go (TinyGo) 等编译到 Wasm 的语言开发，性能接近原生 除 Lua 外的其他语言插件都通过进程间通信（IPC）与 Kong 交互，会有一定的性能开销。生产环境对性能要求高的场景推荐使用 Lua 或 Wasm。 kong run postgresql docker network create kong-net # 创建 postgresql, 并创建一个实例 kong-db # KONG_DATABASE 数据库类型，必须是 postgres # 初始化 kong 数据库 nerdctl run --rm \ -e KONG_DATABASE=postgres \ -e KONG_PG_HOST=postgresql \ -e KONG_PG_PORT=5432 \ -e KONG_PG_USER=user_0 \ -e KONG_PG_PASSWORD=password_0 \ -e KONG_PG_DATABASE=kong_db \ -e KONG_PASSWORD=password_0 \ kong:3.9.1 kong migrations bootstrap # kong OSS + kong manager OOS nerdctl run -d --name kong \ --network=kong-net \ -e "KONG_DATABASE=postgres" \ -e "KONG_PG_HOST=postgresql" \ -e "KONG_PG_PORT=5432" \ -e "KONG_PG_USER=user_0" \ -e "KONG_PG_PASSWORD=password_0" \ -e "KONG_PG_DATABASE=kong_db" \ -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \ -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \ -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \ -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \ -e "KONG_PROXY_LISTEN=0.0.0.0:8000,0.0.0.0:8443 ssl" \ -e "KONG_ADMIN_LISTEN=0.0.0.0:8001,0.0.0.0:8444 ssl" \ -e "KONG_ADMIN_GUI_LISTEN=0.0.0.0:8002" \ -p 80:8000 \ -p 443:8443 \ -p 8444:8444 \ -p 8001:8001 \ -p 8002:8002 \ kong:3.9.1 # -p 80:8000 # HTTP 代理端口 # -p 443:8443 # HTTPS 代理端口 # -p 8001:8001 # Admin API HTTP 端口 # -p 8444:8444 # Admin API HTTPS 端口 # -p 8002:8002 # Admin GUI HTTP 端口 curl -i -X GET --url http://localhost:8001/services # Kong Manager OSS http://kong:8002/ load balance # 创建一个 upstream curl -X POST http://192.168.50.31:8001/upstreams --data "name=k8s" # 添加两个 targets 到 upstream curl -X POST http://192.168.50.31:8001/upstreams/k8s/targets \ --data "target=192.168.50.80:6443" \ --data "weight=100" curl -X POST http://192.168.50.31:8001/upstreams/k8s/targets \ --data "target=192.168.50.82:6443" \ --data "weight=100" # 创建一个Service 目标到 Blue upstream # host: upstream name curl -X POST http://192.168.50.31:8001/services/ \ --data "name=k8s-service" \ --data "host=k8s" # 最后, 添加一个 Route 作为一个端点到 Service curl -X POST http://192.168.50.31:8001/services/k8s-service/routes/ \ --data "hosts[]=k8s.wiloon.com" commands curl -s localhost:8001 | jq '.configuration' kong manager add route upstreams name: enx-api targets target address: enx:8080 gateway service new gateway service name: enx-api-service service endpoint protocol: https host: enx-api-upstream ca certificate cert: past the content of ca-cert.crt certificates cert: the content of wiloon.crt key: wiloon.key upstreams Upstream 是在 Kong 中管理后端服务的负载均衡机制。当请求到达 Service 时，Kong 会通过定义的 Upstream 来选择一个具体的后端实例（例如，一个微服务的多个副本）。 如果不使用负载均衡就不需要配置 upstreams 了, 直接在 gateway service 中配置 service endpoint 即可. ...

EDID 简介 什么是 EDID？ EDID (Extended Display Identification Data) 是一种标准化的数据结构，用于显示器向计算机系统描述自己的能力和特性。可以将它理解为显示器的"身份证"或"技术规格说明书"。 EDID 包含的信息： 基本标识信息： 制造商 ID（如 Dell = “DEL”, Samsung = “SAM”） 产品型号代码和序列号 生产日期（周数/年份） 显示能力参数： 支持的分辨率列表（如 1920x1200, 1600x1200, 1280x1024） 支持的刷新率（如 60Hz, 75Hz） 原生（推荐）分辨率 色彩深度和色域信息 物理特性： 屏幕物理尺寸（以毫米为单位，用于计算正确的 DPI） 显示接口类型（模拟/数字） Gamma 值（2.2 是常见值） 系统如何读取 EDID？ 是的，操作系统从显示器读取 EDID 信息。 这是一个自动化的初始化过程： ┌─────────────────────────────────────────────────────────────┐ │ 1. 物理连接 │ │ 显示器连接到主机（HDMI/DisplayPort/DVI/VGA） │ │ 硬件检测到连接 │ └──────────────────┬──────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 2. DDC 通信初始化 │ │ 主机 → 显示器：发起 DDC (Display Data Channel) 请求 │ │ 使用 I2C 总线协议 │ └──────────────────┬──────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 3. EDID 数据传输 │ │ 显示器 → 主机：返回 EDID 数据（128 或 256 字节） │ │ 通过显示线缆内的专用数据通道 │ └──────────────────┬──────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 4. 内核处理 │ │ GPU 驱动解析 EDID → 验证校验和 → 提取支持的模式 │ └──────────────────┬──────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 5. 自动配置 │ │ 选择最佳分辨率（通常是原生分辨率）→ 配置显示输出 │ └─────────────────────────────────────────────────────────────┘ 通信协议细节： ...

EDID 简介 什么是 EDID？ EDID (Extended Display Identification Data) 是一种标准化的数据结构，用于显示器向计算机系统描述自己的能力和特性。可以将它理解为显示器的"身份证"或"技术规格说明书"。 EDID 包含的信息： 基本标识信息： 制造商 ID（如 Dell = “DEL”, Samsung = “SAM”） 产品型号代码和序列号 生产日期（周数/年份） 显示能力参数： 支持的分辨率列表（如 1920x1200, 1600x1200, 1280x1024） 支持的刷新率（如 60Hz, 75Hz） 原生（推荐）分辨率 色彩深度和色域信息 物理特性： 屏幕物理尺寸（以毫米为单位，用于计算正确的 DPI） 显示接口类型（模拟/数字） Gamma 值（2.2 是常见值） 系统如何读取 EDID？ 是的，操作系统从显示器读取 EDID 信息。 这是一个自动化的初始化过程： ┌─────────────────────────────────────────────────────────────┐ │ 1. 物理连接 │ │ 显示器连接到主机（HDMI/DisplayPort/DVI/VGA） │ │ 硬件检测到连接 │ └──────────────────┬──────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 2. DDC 通信初始化 │ │ 主机 → 显示器：发起 DDC (Display Data Channel) 请求 │ │ 使用 I2C 总线协议 │ └──────────────────┬──────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 3. EDID 数据传输 │ │ 显示器 → 主机：返回 EDID 数据（128 或 256 字节） │ │ 通过显示线缆内的专用数据通道 │ └──────────────────┬──────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 4. 内核处理 │ │ GPU 驱动解析 EDID → 验证校验和 → 提取支持的模式 │ └──────────────────┬──────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 5. 自动配置 │ │ 选择最佳分辨率（通常是原生分辨率）→ 配置显示输出 │ └─────────────────────────────────────────────────────────────┘ 通信协议细节： ...

概述 在参与开源项目开发时，通常的工作流程是：Fork 主仓库 → 在自己的仓库开发 → 保持与主仓库同步 → 提交 Pull Request。本文记录这个完整的操作流程。 前置准备 添加上游仓库 首次 fork 项目后，需要添加原始仓库（上游仓库）作为远程仓库： # 添加上游仓库 git remote add upstream <原始仓库的 git 地址>igin https://github.com/your-username/project.git (fetch) origin https://github.com/your-username/project.git (push) upstream https://github.com/original-owner/project.git (fetch) upstream https://github.com/original-owner/project.git (push) origin: 你的 fork 仓库 upstream: 原始仓库（上游） 保持本地主分支同步 在开发新功能前，或定期需要将上游仓库的最新变更同步到本地： 1. 获取上游仓库的最新变更 git fetch upstream 这会下载上游仓库的所有分支和提交，但不会合并到本地。 2. 切换到本地主分支 git checkout main # 或者 git switch main 3. 检查当前状态 git status 确保工作区是干净的，没有未提交的更改。 4. 合并上游主分支 git merge upstream/main 为什么 main 分支用 merge 而不是 rebase？ ...

概述 给开源项目贡献代码是参与开源社区的重要方式。本文记录了从 Fork 仓库到提交 Pull Request (PR) 的完整流程。 前置准备 Fork 仓库 在 GitHub 上打开你想贡献的开源项目 点击右上角的 Fork 按钮 将仓库 Fork 到你自己的账号下 克隆你的 Fork git clone https://github.com/你的账号/仓库名.git cd 仓库名 配置上游仓库 添加上游仓库（只需做一次） git remote add upstream https://github.com/官方账号/官方仓库.git 验证 remote 配置 git remote -v 输出应该类似： origin https://github.com/你的账号/仓库名.git (fetch) origin https://github.com/你的账号/仓库名.git (push) upstream https://github.com/官方账号/官方仓库.git (fetch) upstream https://github.com/官方账号/官方仓库.git (push) 同步上游代码 在开始新功能开发前，确保你的本地代码与上游保持同步： # 拉取上游最新代码 git fetch upstream # 切换到 main 分支 git checkout main # 合并上游的 main git merge upstream/main # 推送到你的 fork git push origin main 创建功能分支 不要直接在 main 分支上开发，应该创建新的功能分支： ...

python basic 数据类型 list array, 列表, 数组 list/dict str to list/dict >>> import ast >>> x = '[ "A","B","C" , " D"]' >>> x = ast.literal_eval(x) >>> x ['A', 'B', 'C', ' D'] >>> x = [n.strip() for n in x] >>> x ['A', 'B', 'C', 'D'] colon syntax # check if two list equal sorted(a) == sorted(b) : is the delimiter of the slice syntax to 'slice out' sub-parts in sequences , [start:end] [1:5] is equivalent to "from 1 to 5" (5 not included) [1:] is equivalent to "1 to end" [:20] from start to 20 # Python 合并两个列表 # 法一： # Python合并两个列表, 相加是拼接 list1=[1,2,3] list2=[4,5,6,7] list3=list1+list2 print('list3',list3)#输出[1,2,3,4,5,6,7] # 注意：Python合并两个NumPy数组，相加时候是对应相加 import numpy as np arr1=np.array([1,2,3]) arr2=np.array([4,5,6]) arr3=arr1+arr2 print(arr3)#输出[5 7 9] #那么NumPy数组怎么拼接呢，使用concatenate arr4=np.concatenate((arr1,arr2),axis=0) print('arr4',arr4) # 法二： l3=[] l1=[1,2,3] l2=[4,5,6] l3.append(l1) l3.append(l2) print('l3',l3)#输出[[1, 2, 3], [4, 5, 6]],注意这里是二维列表,不是我们想要的结果 # 如何才能达到我们要的结果，使用 extend l1.extend(l2) print('l1',l1)#[1, 2, 3, 4, 5, 6] # 总结： # Python合并两个列表，可用两个列表相加存入新列表，或者使用extend在原列表修改 ———————————————— ...

git reset git reset 是一个重置 (reset) 命令， 通过 git reset 命令可以修改 HEAD 指向不同的提交，这个提交甚至都不必是当前分支上的某次提交， 只要是版本库中合法提交都可以使用这个命令进行设置，相应的版本库的内容也会发生对应的变化， 它可以使你正在开发的 dev 分支瞬间变成 master 分支。 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-NC-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接：https://blog.csdn.net/albertsh/article/details/106448035 # 默认 --soft # 默认 HEAD git reset # 如果本地有没提交到 local repo 的话, 会提示 Unstaged changes after reset, 如果的确是要放弃修改, 可以执行 git reset --hard # 丢弃 工作树 和 索引 的修改 git reset --hard # 等价于 git reset --hard HEAD # reset 最近一次 commit git reset --hard HEAD^ git reset --hard HEAD~1 # reset 最近两次 commit git reset --hard HEAD~2 # reset 到某一个 commit, 退到/进到 指定 commit_id # 默认是 --mixed 模式（保留工作区修改，撤销 commit 和 git add） git reset commit_id # 等价于 git reset --mixed commit_id # hard reset 到指定 commit（危险！会丢失所有修改） git reset --hard commit_id git reset --soft HEAD^ # 重置到远程分支（丢弃本地未 push 的 commit） git fetch origin git reset --hard origin/main # 如果是其他分支，替换 main 为对应分支名 进行了错误的提交，但是还没有 push 到远程分支，想要撤销最近的几次提交 (commit)，可以使用 git reset –-soft/hard 命令。 ...

DDD 领域驱动设计 (Domain-Driven Design，简称 DDD） Domain Layer 领域层 - 业务实体, 值对象, 领域服务 Infrastructure Layer 基础设施层 - 数据访问, 外部服务调用等技术实现 Application Layer 应用层 - 协调领域对象来执行应用用例 Interface Layer 接口层 - API 控制器, 视图 值对象 (Value Objects) 实体对象 (Entity) Repository 模式 - 抽象的数据访问层 聚合根 Factory 模式 Domain Service 值对象 (Value Objects) 代表领域中没有身份标识但有重要意义的概念 不可变性 (Immutability), 一旦创建，不能修改, 只读属性 基于值的相等性 (Value-based Equality), 比较的是值，不是对象引用 无身份标识 (No Identity), 两个值相同的对象被认为是相等的 可哈希性 (Hashable) 生命周期 短暂，可替换 封装业务逻辑: 比如某些固定规则的字符串组合 值对象的使用场景: 复合标识符 实体对象 (Entity) 有唯一身份ID ...

什么是 LangGraph LangGraph 是 LangChain 生态系统中的一个框架，专门用于构建有状态的、多步骤的 AI 应用程序。它通过图（Graph）的方式来定义和管理复杂的 AI 工作流，让开发者能够创建具有循环、条件分支和持久化状态的智能体系统。 LangGraph 的核心理念是将 AI 应用程序建模为状态机，其中节点代表操作步骤，边代表流程控制，状态在节点之间传递和更新。 核心概念 State（状态） State 是在整个工作流中传递和更新的数据结构。通常使用 TypedDict 定义： from typing import TypedDict, Annotated from langgraph.graph import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] user_input: str analysis_result: str Node（节点） Node 是执行具体操作的函数，接收当前状态并返回更新后的状态： def research_node(state: AgentState): # 执行研究任务 result = do_research(state['user_input']) return { "analysis_result": result, "messages": [("assistant", f"研究完成：{result}")] } Edge（边） Edge 定义节点之间的连接关系： Normal Edge（普通边）：直接连接两个节点 Conditional Edge（条件边）：根据状态决定下一个节点 from langgraph.graph import StateGraph, END # 普通边 workflow.add_edge("node_a", "node_b") # 条件边 def should_continue(state): if state['done']: return END return "continue_node" workflow.add_conditional_edges( "decision_node", should_continue ) Graph（图） Graph 是完整的工作流定义，包含所有节点、边和状态管理： from langgraph.graph import StateGraph workflow = StateGraph(AgentState) # 添加节点 workflow.add_node("research", research_node) workflow.add_node("analyze", analyze_node) workflow.add_node("respond", respond_node) # 定义边 workflow.add_edge("research", "analyze") workflow.add_edge("analyze", "respond") # 设置入口点 workflow.set_entry_point("research") # 编译图 app = workflow.compile() 核心特性 1. 状态持久化 LangGraph 支持状态的持久化存储，可以实现： ...

什么是 CrewAI CrewAI 是一个开源的 Python 框架，专门用于构建和管理多智能体（Multi-Agent）系统。它允许开发者创建一个由多个 AI 智能体组成的"团队"（Crew），这些智能体可以协同工作，共同完成复杂的任务。 核心概念 Agent（智能体） Agent 是 CrewAI 中的基本执行单元，代表一个具有特定角色和能力的 AI 助手。每个 Agent 具有： Role（角色）：定义 Agent 的身份和职责 Goal（目标）：Agent 要达成的目标 Backstory（背景故事）：为 Agent 提供上下文和个性 Tools（工具）：Agent 可以使用的工具集合 from crewai import Agent researcher = Agent( role='研究员', goal='收集和分析相关信息', backstory='你是一位经验丰富的研究专家，擅长从各种来源收集准确信息', tools=[search_tool, scrape_tool], verbose=True ) Task（任务） Task 定义了需要完成的具体工作，包括： Description（描述）：任务的详细说明 Agent：负责执行该任务的智能体 Expected Output（期望输出）：任务完成后的预期结果 from crewai import Task research_task = Task( description='研究 AI 领域的最新发展趋势', agent=researcher, expected_output='一份包含最新 AI 趋势的详细报告' ) Crew（团队） Crew 是多个 Agent 和 Task 的组合，负责协调整个工作流程： from crewai import Crew, Process crew = Crew( agents=[researcher, writer, reviewer], tasks=[research_task, write_task, review_task], process=Process.sequential # 顺序执行 ) result = crew.kickoff() 执行流程 CrewAI 支持两种执行流程： ...

font, 字体 主流编程字体 等宽编程字体特性 编程字体需要具备以下特点： 等宽设计：每个字符宽度相同，便于代码对齐 字符区分度高：容易区分 0O（数字零和字母O）、1lI（数字一、小写L和大写I）等相似字符 连字支持（可选）：将 ->, =>, != 等组合显示为单个符号 编程符号优化：清晰的括号、引号、运算符显示 舒适的行高和字间距：长时间编码不易疲劳 开源免费字体 Cascadia Code 开发者：Microsoft 特点：Windows Terminal 默认字体，支持连字（Cascadia Code PL 变体），包含 Powerline 字形 适用场景：Windows 开发、终端、VS Code 安装：sudo apt install fonts-cascadia-code (Ubuntu/Debian) 官网：https://github.com/microsoft/cascadia-code JetBrains Mono 开发者：JetBrains 特点：专为开发者设计，字符高度区分，支持连字，行高适中 适用场景：IntelliJ IDEA、PyCharm 等 JetBrains IDE 推荐 官网：https://www.jetbrains.com/lp/mono/ Fira Code 开发者：Mozilla（基于 Fira Sans 和 Fira Mono） 特点：最流行的连字编程字体之一，支持 100+ 连字组合 适用场景：喜欢连字效果的开发者 安装：sudo apt install fonts-firacode 官网：https://github.com/tonsky/FiraCode Hack 特点：基于 Bitstream Vera 和 DejaVu，字符区分度极高 适用场景：注重代码可读性，不需要连字 安装：sudo apt install fonts-hack 官网：https://sourcefoundry.org/hack/ Source Code Pro 开发者：Adobe 特点：优雅的设计，6 种字重，清晰的字符 适用场景：喜欢 Adobe 设计风格 安装：sudo pacman -S adobe-source-code-pro-fonts (Arch) 官网：https://adobe-fonts.github.io/source-code-pro/ DejaVu Sans Mono 特点：基于 Vera Sans Mono，Unicode 覆盖广 适用场景：多语言编程，Linux 默认等宽字体 安装：大多数 Linux 发行版预装 Ubuntu Mono 开发者：Canonical 特点：Ubuntu 系统默认等宽字体，字符清晰 适用场景：Ubuntu 用户 Inconsolata 开发者：Raph Levien 特点：简洁紧凑，适合小屏幕 适用场景：小尺寸显示 官网：https://levien.com/type/myfonts/inconsolata.html IBM Plex Mono 开发者：IBM 特点：现代设计，IBM 企业级品质 适用场景：喜欢 IBM 设计语言 官网：https://www.ibm.com/plex/ Iosevka 特点：窄字符设计，同屏显示更多代码 适用场景：喜欢紧凑布局，小屏幕 官网：https://typeof.net/Iosevka/ 商业付费字体 SF Mono 开发者：Apple 特点：macOS 和 Xcode 默认等宽字体 适用场景：macOS 开发者 获取：随 macOS 系统或 Xcode 提供 Operator Mono 开发者：Hoefler & Co. 特点：优雅的意大利斜体，价格较贵（$199+） 适用场景：追求极致美观 官网：https://www.typography.com/fonts/operator/ MonoLisa 特点：专注可读性和长时间编码舒适度 价格：€139 起 官网：https://www.monolisa.dev/ Nerd Fonts 系列 Nerd Fonts 是在流行编程字体基础上打补丁，添加大量图标字形（Font Awesome、Devicons、Octicons 等）。 ...