Posts

curl command curl [kɜrl] options --version, print version -s, --silent, 不显示下载进度, 不显示 error message -S, --show-error 在使用 -s 时, 打印 curl error message -C, --continue-at, 断点续传 -o, --output <file>, write output to <file> instead of stdout --connect-timeout <fractional seconds>, 建连接超时, 比如 tcp 三次握手 -m, --max-time <fractional seconds>, 单位: 秒, 可以用小数 0.5 代表 500ms, 传输超时, 比如 http 请求发送之后长时间没有响应, tcp 的 ack 收到了, 但是长时间没收到 http response. -G/--get 以 get 的方式来发送数据 -i, --include 输出时包括 protocol 头信息, 显示 response header, 例如: HTTP/1.0 200, Content-Type: text/plain -v, verbos -N, Disables the buffering of the output stream -I, --head 只返回头信息, 比如 FTP 服务器只返回文件大小. -H, --header LINE Custom header to pass to server (H) -d, --data # DATA HTTP POST data, 如果使用 -d 命令，curl 会以 application/x-www-url-encoded 格式上传参数。 从文件中读取数据 -d @/path/to/foo.json -b, --cookie <data|filename>, 发送请求时附带 cookie。可以直接传入 cookie 字符串，或从文件中读取 cookie --retry, 重试次数 -F curl 会以 multipart/form-data 的方式发送 POST 请求。-F 以 key=value 的形式指定要上传的参数，如果是文件，则需要使用 key=@file 的形式。 -k, --insecure flag to skip certificate validation. -L, --location: 追踪重定向, 如果服务器报告请求的页面已移动到其他位置（用 location: header 和 3xx 响应代码），此选项将使 curl 在新位置上重新执行请求。 -x, 参数指定 HTTP 请求的代理 -X, --request <method> Specify request method to use, -X POST, -X PUT -w, 完成请求传输后，使 curl 在 stdout 上显示自定义信息 --cacert, curl 用来验证对端的 CA 证书 -E, --cert, 客户端证书 --key, 客户端私钥 --pass, 客户端私钥的密码 --trace-ascii /tmp/curl.log, 把交互的数据打印到日志里, https 协议也能把明文打在日志里 -tlsv1.x 这个参数并不是说客户端按你指定的tls版本去跟服务端匹配，不是==的关系，是在≥的关系里面desc降序匹配, 比如支持tls1.0/1.1/1.2的Server，客户端分别以--sslv3、--tlsv1.0、--tlsv1.1、--tlsv1.2这些参数去请求，最终的结果都是以--tlsv1.2去建联，这就是我说的“在≥的关系里面desc降序匹配” --tls-max 1.x 这个参数则是限定死了，最大按哪个来, 比如说服务端最大支持到tlsv1.2，客户端限定最大按tlsv1.3来，那最终肯定就是以tlsv1.2建联了；如果服务端不变，我指定客户端以--tls-max 1.1请求，那最终肯定是以tlsv1.1建联了 -f, --fail 快速失败, 在服务器出错时不显示HTTP错误信息, 直接返回 error 22 -w -w 的作用 完成请求传输后，使 curl 在 stdout 上显示自定义信息 格式是一个字符串，可以包含纯文本和任意数量的变量 ...

Inotify 概述 Inotify 是 Linux 内核提供的一个文件系统事件监控机制，从 Linux 2.6.13 版本开始引入。它允许应用程序监控文件系统的变化，如文件的创建、修改、删除、移动等操作。 核心特性 实时监控：基于事件驱动，当文件系统发生变化时立即通知应用程序 高效性：相比轮询方式，inotify 不需要不断检查文件状态，大大降低了系统开销 灵活性：可以监控单个文件或整个目录树 多事件支持：支持多种文件系统事件类型 工作原理 初始化：应用程序创建一个 inotify 实例（通过 inotify_init() 系统调用），返回一个文件描述符（fd） 添加监控：为需要监控的文件或目录添加 watch（通过 inotify_add_watch()），将 watch 与 inotify 实例关联 事件通知：当被 watch 的文件系统发生变化时，内核会将事件放入该 inotify 实例的事件队列 读取事件：应用程序从 inotify 文件描述符读取事件信息（通过 read() 系统调用） 简单来说： inotify 实例就像一个"邮箱"（用文件描述符标识） 添加 watch 就是告诉内核：“这些文件有变化就往我的邮箱里放消息” 文件变化时，内核自动把事件"投递"到这个邮箱 应用程序通过读取这个文件描述符来"收取邮件"（获取事件） 代码示例： #include <sys/inotify.h> #include <unistd.h> #include <stdio.h> int main() { // 1. 创建 inotify 实例，得到文件描述符 int fd = inotify_init(); // 2. 添加 watch，监控文件的修改事件 int wd = inotify_add_watch(fd, "/path/to/file", IN_MODIFY); // 3. 当文件被修改时，内核会把事件放入 fd 对应的队列 // 4. 应用程序从 fd 读取事件 char buffer[1024]; int length = read(fd, buffer, sizeof(buffer)); // 阻塞等待事件 // 5. 处理事件... struct inotify_event *event = (struct inotify_event *)buffer; printf("文件被修改了！\n"); // 清理 close(fd); return 0; } 关键点： ...

kafka basic, command kafka_2.13-3.4.0.tgz scala 版本 2.13 kafka 版本 3.4.0 TLS kafka todo commands # list topic bin/kafka-topics.sh --list --bootstrap-server 127.0.0.1:9092 # create topic bin/kafka-topics.sh --create --partitions 1 --replication-factor 1 --topic topic_0 --bootstrap-server 127.0.0.1:9092 # consumer bin/kafka-console-consumer.sh --topic topic_0 --bootstrap-server 127.0.0.1:9092 # producer bin/kafka-console-producer.sh --bootstrap-server 127.0.0.1:9092 --topic topic_0 # list group name bin/kafka-consumer-groups.sh --bootstrap-server 127.0.0.1:9092 --list # 查看 consumer group offset bin/kafka-consumer-groups.sh --bootstrap-server 127.0.0.1:9092 --describe --group group0 # tls ./kafka-topics.sh --list --bootstrap-server 127.0.0.1:9093 --command-config /tmp/kafka.conf content of kafka.conf ...

HTTP status, HTTP code 204 No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 300 Multiple Choices 多重选择。链接列表。用户可以选择某链接到达目的地。最多允许五个地址。 301 Moved Permanently， 301 redirect: 301 代表永久性转移(Permanently Moved)。 302 redirect: 302 代表暂时性转移(Temporarily Moved )。 499 客户端主动断开连接。 504 Gateway Timeout 301 (永久移动) Permanently Moved 请求的网页已永久移动到新位置。服务器返回此响应 (对 GET 或 HEAD 请求的响应) 时，会自动将请求者转到新位置。您应使用此代码告诉 Googlebot 某个网页或网站已永久移动到新位置。 302 (临时移动) redirect, Temporarily Moved 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来响应以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置，但您不应使用此代码来告诉 Googlebot 某个网页或网站已经移动，因为 Googlebot 会继续抓取原有位置并编制索引。 304 Not Modified (未修改) 未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求 (一般是提供 If-Modified-Since 头表示客户只想比指定日期更新的文档) 。 服务器告诉客户，原来缓冲的文档还可以继续使用。 ...

Ollama 简介 Ollama 是一个开源的本地大语言模型运行工具，可以让你在本地轻松运行 Llama 2、Mistral、Qwen 等多种开源大语言模型。 安装 Ollama Linux 安装 # 使用官方安装脚本 curl -fsSL https://ollama.com/install.sh | sh 安装记录 (2025-11-14)： 安装版本：v0.12.11 安装位置：/usr/local/bin/ollama 服务配置：已创建 systemd 服务 ollama.service 默认监听：127.0.0.1:11434 GPU 支持：检测到 AMD GPU，安装了 ROCm 支持 用户组：创建了 ollama 用户，并加入 render 和 video 组 自动启动：服务已启用并自动运行 手动安装 # 下载二进制文件 curl -L https://ollama.com/download/ollama-linux-amd64 -o ollama chmod +x ollama sudo mv ollama /usr/local/bin/ 验证安装 # 检查版本 ollama --version # 输出: ollama version is 0.12.11 # 检查服务状态 systemctl status ollama # 测试 API 是否可用 curl http://127.0.0.1:11434/api/version # 输出: {"version":"0.12.11"} 基本使用 启动 Ollama 服务 # 启动服务 ollama serve 拉取模型 # 拉取 Llama 2 模型（7B 参数版本） ollama pull llama2 # 拉取 Mistral 模型 ollama pull mistral # 拉取 Qwen 模型 ollama pull qwen # 拉取 Phi 模型（推荐入门） ollama pull phi 本地已安装模型 (2025-11-14)： ...

Ubuntu 24.04 音频问题修复记录 日期: 2025-11-04 系统: Ubuntu 24.04 硬件: Beelink SER8 音频芯片: Realtek ALC897 问题描述 在系统设置中测试音频时,音箱接入耳机接口(3.5mm)没有声音输出。 排查过程 1. 检查音频设备状态 # 查看可用的音频输出设备 pactl list sinks short 结果: 发现主板音频设备: alsa_output.pci-0000_65_00.6.analog-stereo (Family 17h/19h HD Audio Controller) HDMI音频设备也存在 2. 检查混音器配置 # 查看声卡列表 cat /proc/asound/cards # 检查混音器设置 amixer -c 1 scontents 发现: 音频设备被正确识别 Master, Headphone, Line Out 通道配置正常 Speaker 通道初始被关闭(音量0%, 状态off) 3. 检查系统日志 journalctl -b | grep -i 'audio\|sound\|alsa' | tail -50 发现: ALSA控制器初始化时有多个 “failed to obtain info for control” 警告 PipeWire和PulseAudio服务正常启动 硬件被正确识别: Realtek ALC897 4. 分析硬件Pin配置 cat /proc/asound/card1/codec#0 | grep -A 10 "Node 0x1b\|Node 0x14\|Node 0x15" 关键发现: ...

macos container Apple 官方的容器化工具，专为 Apple Silicon Mac 设计，使用轻量级虚拟机运行 Linux 容器。 系统要求 Apple Silicon Mac (M 系列芯片) macOS 26 或更高版本 Xcode (从 App Store 安装) 安装 # 使用 Homebrew Cask 安装 brew install --cask container # 启动 container 系统服务 container system start # 检查系统状态 container system status # 运行测试容器 container run --rm -it docker.io/library/hello-world:latest # 列出容器 (注意: 使用 ls 而不是 ps) container ls # 查看所有可用命令 container --help 从源码编译 git clone https://github.com/apple/container.git cd container swift build sudo cp .build/debug/container /usr/local/bin/container

tcp_syn_retries http://www.chengweiyang.cn/2017/02/18/linux-connect-timeout/ tcp_syn_retries tcp_synack_retries # ubuntu 24.04 ➜ ~ sysctl net.ipv4.tcp_syn_retries net.ipv4.tcp_syn_retries = 6 ➜ ~ sysctl net.ipv4.tcp_synack_retries net.ipv4.tcp_synack_retries = 5 ➜ ~ # 对于主动连接（客户端主动发起连接），每次SYN重试的间隔会逐步递增（不是固定值），由内核写死，不能通过 sysctl 直接调整。 t0 第一次请求 超时时间 1s t1 第一次重试 超时时间 2s t2 第二次重试 超时时间 4s t3 第三次重试 超时时间 8s t4 第四次重试 超时时间 16s t5 第五次重试 超时时间 32s t6 第六次重试 超时时间 64s 总计 1+2+4+8+16+32+64 = 127s http://www.cnitblog.com/Scripts/archive/2009/05/20/57350.html tcp_syn_retries等参数详解(转帖) tcp_syn_retries : INTEGER 默认值是5 对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255,默认值是5,对应于180秒左右时间。(对于大负载而物理通信良好的网络而言,这个值偏高,可修改为2.这个值仅仅是针对对外的连接,对进来的连接,是由tcp_retries1 决定的) tcp_synack_retries : INTEGER ...

wireguard wireguard default port: 51820 install archlinux archlinux 新版本的内核已经集成了 wireguard，不需要单独安装. archlinux 集成了 wireguard 但是默认没加载, 需要配置一下启动的时候加载 wireguard 内核模块. # 查看 wireguard 内核模块是不是已经加载了 lsmod | grep wireguard # 手动加载内核模块 sudo modprobe wireguard # 再看一下应该已经加载了 lsmod | grep wireguard # load kernel module at boot vim /etc/modules-load.d/wireguard.conf # content of wireguard.conf # load wireguard module at boot wireguard # 安装 wireguard 管理工具, wireguard 集成进内核了, 但是管理工具 (wg) 还是要手动安装的 pacman -Sy wireguard-tools Ubuntu, Debian sudo apt install wireguard macos brew install wireguard-tools 在 App Store 安装 wireguard ...

linux 目录, Filesystem Hierarchy Standard (FHS) / 根目录，一般根目录下只存放目录，不要存放文件，/etc、/bin、/dev、/lib、/sbin 应该和根目录放置在一个分区中 /bin In Arch Linux the /bin is a symlink to /usr/bin /mnt 这个目录一般是用于存放挂载储存设备的挂载目录的，比如有 cdrom 等目录。可以参看 /etc/fstab 的定义。有时我们可以把让系统开机自动挂载文件系统，把挂载点放在这里也是可以的。主要看/etc/fstab中怎么定义了；比如光驱可以挂载到/mnt/cdrom 。 /opt /opt 目录的主要用途是 存放第三方应用软件包（optional software packages），也就是那些不是由系统默认的包管理器（如 apt, yum, pacman 等）安装的程序。 /opt 的设计目的： “Optional” 的缩写：/opt = optional，表示这些软件是“可选”的，不属于系统核心组件。 保持系统整洁：与系统自带的程序（一般安装在 /usr/bin, /usr/lib 等）分开，避免混淆。 便于管理与卸载：每个软件通常会在 /opt 下有一个独立的子目录，比如 /opt/google, /opt/kong，便于手动安装与清理。 表示的是可选择的意思，有些软件包也会被安装在这里，也就是自定义软件包，比如在 Fedora Core 5.0 中，OpenOffice 就是安装在这里。有些我们自己编译的软件包，就可以安装在这个目录中； 通过源码包安装的软件，可以通过 ./configure -prefix=/opt/目录 。 /opt 目录用来安装附加软件包，是用户级的程序目录，可以理解为 D:/Software。安装到 /opt 目录下的程序，它所有的数据、库文件等等都是放在同个目录下面。opt 有可选的意思，这里可以用于放置第三方大型软件（或游戏），当你不需要时，直接 rm -rf 掉即可。在硬盘容量不够时，也可将 /opt 单独挂载到其他磁盘上使用。 ...

python set 线上的某一个业务模块常规的执行时间大概是这样的 📊 总体统计: 完成的 xxx 总数: 379 最短耗时: 0.190 秒 最长耗时: 2815.415 秒 平均耗时: 67.626 秒 中位数耗时: 9.585 秒 标准差: 258.304 秒 ⏱️ 耗时分布: < 1秒: 33 次 ( 8.7%) 1-5秒: 101 次 ( 26.6%) 5-10秒: 64 次 ( 16.9%) 10-30秒: 99 次 ( 26.1%) 30-60秒: 9 次 ( 2.4%) 1-5分钟: 62 次 ( 16.4%) 5-10分钟: 2 次 ( 0.5%) 10-30分钟: 6 次 ( 1.6%) > 30分钟: 3 次 ( 0.8%) ...

python signal.pause() vs time.sleep() signal.pause() 系统调用实现, 直接向内核发起系统调用, 让当前线程进入休眠状态, 直到接收到信号为止. 内核将进程状态从 RUNNING → INTERRUPTIBLE_SLEEP 进程从CPU运行队列(CPU Run Queue)中移除 time.sleep() 是一个非阻塞函数, 它会在指定的时间内暂停当前线程的执行. 用户空间循环实现, 用户空间循环：完全在用户模式下运行 进程状态：持续保持 RUNNING 状态 CPU调度：获得常规CPU时间片 系统调用：重复调用 nanosleep() 或 select() CPU运行队列 (Run Queue) CPU运行队列是一个数据结构（通常是链表或红黑树），包含所有准备执行但正在等待CPU时间的进程/线程。 CPU运行队列是包含所有准备执行的进程/线程的数据结构，这些进程已经准备好使用CPU，只是在等待CPU时间片。 状态：进程处于 READY 状态 CPU占用：这些进程会消耗CPU时间 调度：调度器从这里选择下一个执行的进程 负载计算：运行队列长度影响系统负载平均值 等待队列 (Wait Queue) 等待队列包含不能立即执行的进程，它们在等待某些事件发生（如I/O完成、信号到达、锁释放等）。 状态：进程处于 WAITING/BLOCKED 状态 CPU占用：不消耗CPU时间, 0%（进程不被调度） 上下文切换：最少（仅当信号到达时） 事件驱动：等待特定事件唤醒 负载计算：不计入系统负载 INTERRUPTIBLE_SLEEP INTERRUPTIBLE_SLEEP 是一种进程状态。在 Linux 操作系统中，进程会经历多种状态，而可中断睡眠（Interruptible Sleep，通常用 ‘S’ 表示）就是其中之一。 进程不会占用 CPU 资源，而是自愿放弃 CPU，以便系统可以更有效地管理资源。 与 INTERRUPTIBLE_SLEEP 相对的是不可中断睡眠（Uninterruptible Sleep，通常用 ‘D’ 表示），处于此状态的进程通常正在执行关键的 I/O 操作，并且不能被信号中断，直到操作完成。 ...

MCP https://code.visualstudio.com/docs/copilot/chat/mcp-servers https://modelcontextprotocol.io/introduction https://code.visualstudio.com/mcp vscode> extension>search @mcp install memory mcp

stat command stat 命令，查看某个文件的 inode 信息, 除了文件名以外的所有文件信息，都存在inode之中。 stat, linux 查看文件创建时间, 修改时间 stat file_0.txt atime, mtime, ctime 简名 全名 中文名 含义 atime access time 访问时间 文件中的数据库最后被访问的时间 mtime modify time 修改时间 文件内容被修改的最后时间 ctime change time 变化时间 文件的元数据发生变化。比如权限,所有者等 另外一种格式 Access: 2021-07-05 19:47:15.5638661078 +0800 Modify: 2021-07-04 19:29:15.563861472 +0800 Change: 2021-07-04 19:29:15.563861468 +0800 Birth: 2021-07-04 19:29:15.563861472 +0800 Access: 最近一次读取文件内容的时间, 不一定意味着文件被修改，仅表示被读取过，例如用 cat file_0.txt。 Modify: 最近一次修改文件内容的时间, 如使用 echo something » file_0.txt 会更新这个时间。 Change: 最近一次修改文件inode 元数据（如权限、所有者）最后一次被更改的时间, 如使用 chmod 755 file_0.txt 会更新这个时间。只修改文件内容可能也会更新, 比如更新 inode(block分配等)。 Birth: 文件创建时间, 不是所有文件系统都支持这个字段。系统返回了它，说明使用的文件系统支持（如 btrfs, ext4（带特定挂载选项）或 xfs 带 crtime 补丁等）。 本示例的创建时间可能不是真的, 有可能底层文件系统不支持. # 输出创建时间（epoch 格式，-1 表示不支持） # -c：自定义输出格式（即只显示我们想看的字段）。 # '%W'：表示输出文件的 创建时间（Birth time） # 如果 文件系统不支持创建时间，则输出：-1 stat -c '%W' file_0.txt 在windows下,一个文件有: 创建时间、修改时间、访问时间。 ...

wsl native docker windows vscode hack wsl archlinux install containerd nerdctl nerdctl 和 containerd 使用 Unix socket一般在 /run/containerd/containerd.sock 在 WSL 里启动 socat 监听 containerd.socket，转发到 Windows 命名管道 sudo mkdir -p /mnt/wsl/shared-containerd sudo ln -sf /run/containerd/containerd.sock /mnt/wsl/shared-containerd/containerd.sock socat UNIX-LISTEN:/mnt/wsl/shared-containerd/containerd.sock,fork EXEC:"/mnt/c/workspace/apps/npiperelay.exe -ei -ep -s //./pipe/containerd_engine"

ca-certificates 导入 CA 证书, 安装 CA 证书 macos 导入自签名证书 在 Spotlight 里搜索 “钥匙串访问” 或者 Keychain Access, 在左侧栏里选择 System, 点击菜单栏 File> import items, 导入 自签名的 ca 证书 然后在 系统证书里面找名字是 *.wiloon.com 的证书, 双击打开, 展开 trust, when using this certificate: always trust archlinux ca-certificates update, 导入证书/安装证书 https://www.archlinux.org/news/ca-certificates-update/ # .pem rename to .crt # xxx.crt should export from sub ca sudo cp certs/ca-cert.pem /etc/ca-certificates/trust-source/anchors/wangyue-ca.crt sudo trust extract-compat # 验证是否安装成功 trust list|grep wiloon.com -A 5 -B 5 # 如果连接成功，它会输出服务器的证书链（包括自签名证书）、握手细节、证书的主题、颁发者等信息。 # s_client 工具在不指定验证选项时，只会“显示”证书信息，而不强制验证链条。 openssl s_client -connect hello.wiloon.com:443 openssl s_client -connect calibre.wiloon.com:443 -CApath /etc/ssl/certs -verify_return_error archlinux + chrome 但 Chrome（包括 Chromium）在 Linux 上使用独立的 NSS（Network Security Services）证书数据库，默认不直接读取系统 CA。它有自己的信任存储，通常位于 ~/.pki/nssdb/ ...

自签名证书, self-signed cert sudo pacman -S openssl # 查看默认的 OpenSSL 配置目录 openssl version -d # Create two directories for all certs and root private key that you will generate su - wiloon mkdir -p /home/wiloon/apps/self-signed-cert mkdir certs private # list all available curves openssl ecparam -list_curves # 使用 ECDSA 私钥 # 生成 ECDSA （椭圆曲线数字签名算法）密钥对, CA 密钥, root private key # 参数: -noout - 抑制输出椭圆曲线参数, 如果不加这个参数，命令会同时输出曲线参数和私钥,加上后只输出私钥部分 # -genkey：生成密钥对 # prime256v1 secp256r1 / NIST P-256 256 默认、安全性好、广泛兼容（TLS 默认） # ecparam 子命令, 专门处理椭圆曲线参数（EC Parameters） # -name prime256v1 指定曲线名称 openssl ecparam -name prime256v1 -genkey -out private/ca-key.pem # 使用 rsa 密钥 # genrsa 子命令默认就是生成 RSA 私钥, genrsa子命令没有-genkey参数 openssl genrsa -out private/ca-key.pem 4096 # read ca key openssl ec -in private/ca-key.pem -text -noout 准备一个生成 CA 证书的 配置文件 ca-cert.cnf, the value in the basicConstrains is CA:true ...

ldd 查看程序依赖 动态链接库 ldd(List Dynamic Dependencies) 命令可以用于分析可执行文件所依赖的共享库（动态链接库） # 检测 动态链接 # 查看 libcups 是否真的链接到了 avahi ldd /usr/lib/libcups.so | grep avahi ldd /proc/737543/exe # 输出 libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0x00007f4d777c4000) libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0x00007f4d777b2000) 我们使用 file 命令来分析一个可执行文件的时候，有时候可以看到输出中有 dynamically linked 这样的字眼。这个是啥意思呢？ 大部分程序，都会使用到第三方库，这样就可以不用重复造轮子，节约大量时间。最简单的，我们写C程序代码的话，肯定会使用到 libc 或者 glibc 库。当然，除此之外，还可能使用其它的库。 那我们在什么情况下需要分析程序的依赖库呢？有一个场景大家肯定经历过。你去你同事那边拷备他写好的程序放到自己的环境下运行，有时候可能会跑不起来。当然跑不起来的原因可能很多，但其中一个原因可能就是缺少对应的依赖库。 这时候，ldd 就派上用场了。它可以分析程序需要一些什么依赖库，你只要把对应的库放在对应的位置就可以了。 ldd /bin/pwd linux-vdso.so.1 => (0x00007ffeb73e5000) libc.so.6 => /lib64/libc.so.6 (0x00007f908b321000) /lib64/ld-linux-x86-64.so.2 (0x00007f908b6ef000) 作用: 用来查看程式运行所需的共享库,常用来解决程式因缺少某个库文件而不能运行的一些问题。 示例: 查看test程序运行所依赖的库: /opt/app/todeav1/test$ldd test libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000039a7e00000) libm.so.6 => /lib64/libm.so.6 (0x0000003996400000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000039a5600000) ...

AI AI IDE Microsoft Copilot Cursor Windsurf augment code AI 编程 之前有一种想法，有些小的修改， 比如只有几行代码的修改不需要用 AI, 因为构思提示词的时间往往比直接写代码的时间要长，但是最近这种想法有了一丝松动，AI 写代码出的问题更少一些， 手工改代码很有可能一不小心拷错了，或者敲错字符，AI写码不会有这些小问题，另外 AI 去改的时候会发现一些本来我认为不需要修改的逻辑分支，如果手动修改的话，这些分支只能是等到测试阶段才被发现。

加密分区缩容, LVM on LUKS https://linux-blog.anracom.com/2018/11/09/shrinking-an-encrypted-partition-with-lvm-on-luks/ https://wiki.archlinux.org/title/Resizing_LVM-on-LUKS https://wiki.archlinux.org/title/LVM#Resizing_the_logical_volume_and_file_system_in_one_go https://starbeamrainbowlabs.com/blog/article.php?article=posts%2F441-resize-luks-lvm.html Step 1: Get an overview over your block devices lsblk 加密分区在 /dev/nvme0n1p3 上 Step 2: Open the encrypted partition cryptsetup open /dev/nvme0n1p3 cr-ext # 打开过程中会要求输入密码 # 检查一下设备映射 ls -la /dev/mapper 能看到 PV: /dev/mapper/cr-ext 还有 LVM-volumes: /dev/mapper/ubuntu–vg-ubuntu–lv Step 3: Get an overview on LVM structure pvdisplay vgdisplay lvdisplay # 查看 lv 是否激活 lvs -o lv_name,lv_attr 输出 # 第五位 a 表示 LV 是 active（已激活） LV Attr ubuntu-lv -wi-ao---- 一般情况打开 luks 加密的设备之后 lvm 的 vg, lv 会自动 激活 如果没有激活的话, 手动激活 vg ...