C:\Users\XX\AppData\Local\Microsoft\WindowsApps下放了两个0kb的python.exe以及python3.exe用于弹 Windows Store，并把这个路径加到了个人的环境变量。而且这个环境变量优先级高所以会优先运行。
傻逼微软。
资源管理器里似乎删不掉，要命令行删
这个叫应用执行别名，可以在设置里关闭。并且没有任何命令行关闭的方式
]]>严格意义上的静态聚合（手工聚合）
典型场景：旧设备或不支持LACP的环境。
厂商实现中的“静态LACP”模式 部分厂商（如华为、H3C）支持静态LACP（理论意义上，静态聚合里"没有也不跑" LACP
协议；这两者是互斥的,通常属于国内厂商误用）：
在配置中，静态聚合可能分为两种模式：
特点：
两端设备需手动绑定相同端口到聚合组，但LACP协议会参与链路状态检测（如检查对端是否属于同一聚合组）。
若对端未启用LACP或配置不匹配，链路可能无法正常工作。
LACP（Link Aggregation Control Protocol，链路聚合控制协议）是IEEE 802.3ad（后纳入802.1ax）标准中定义的一种协议，用于动态管理和维护以太网链路聚合组（LAG）。通过LACP，网络设备可以自动协商链路聚合的成员端口，实现带宽叠加、负载均衡和冗余备份。
LACP协议本身是动态的，但其具体实现可以结合静态配置（如手动指定成员）。
LACP 是一个开放标准，旨在确保不同厂商设备之间的互操作性，并且提供了更强的配置校验和故障检测能力，更加健壮和可靠。
NIC Teaming 是 Windows Server（从 Windows Server 2012
开始）的一个内置功能，可以通过服务器管理器 (Server Manager) 图形界面或
PowerShell (New-NetLbfoTeam cmdlet) 轻松配置。
注意需要固定 IP 地址的时候需要配置 Bond 的 mac
地址固定，否则接反线会导致 Mac 地址变化，再 nm-connection-editor
中需要对 bond 的两个 port 都配置同一个 永久的 Mac 地址
对于 GUI，需要先创建网桥再创建 bond/带 vlan 的 bond
注意事项
1 | nmcli connection add type vlan con-name bond.4 ifname bond.4 dev bond id 4 master bridge.4 |
https://learn.microsoft.com/zh-cn/windows-hardware/design/device-experiences/modern-standby-states
powercfg /a 可查reg add "HKLM\System\CurrentControlSet\Control\Power" /v PlatformAoAcOverride /t REG_DWORD /d 0 /f笔记本合上盖子，在部分情况下，无法重新开机，开机后完全电源键闪几下后完全全新启动。
尝试关闭睡眠，设置不进入睡眠，开启休眠都无效。
日志里可以看到电脑进入 S0。
按前面的彻底关闭 S0 (由于笔记本不支持 S3)，导致睡眠完全消失，作为替代，只使用休眠。
实际上笔记本睡眠后起不来是一个长期以来的问题，同型号，同硬件，有的有有的没有。从 Win7 时代就开始了。
只是目前没法判断是硬件问题还是微软的锅。
]]>1 | HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.ps1 |
下面的 UserChoice 删掉
选择 Vscode 打开会不显示，默认打开是记事本的话会显示。
]]>1 | git config --global http.proxy socks5://127.0.0.1:7890 |
1 | git config --global --unset http.proxy |
1 | git config --global --get http.proxy |
吐槽下git的升级连续用了3个裸IP
https那个没用
似乎可能Win下cmd里用就是会解析成IP丢到代理里(
另外需要注意，git 协议走 ssh,需要 ssh 代理以及 ssh key
Github Desktop 对 ssh key 的支持并不好，它的官方教程让设置 passphrase,因此每次使用都要输入，但它自己的客户端不支持并且会每次都报错 -
下面是 Win 的配置,config 文件需要自己新建出来，key 的话，放在那里不用特意写配置
1 | ProxyCommand connect -S 127.0.0.1:7890 -a none %h %p |
注意哈，这里没有写错
1 | git clone -c http.proxy=socks5h://127.0.0.1:13222 <url> |
另外注意是-c是全局的，其他命令要直接放在git后面
https://docs.aws.amazon.com/efs/latest/ug/mounting-fs-nfs-mount-settings.html
后台挂载(Redhat7系列已经不再推荐使用，因为系统底层换成了 systemd，这个参数存在问题)
如果第一次挂载失败，转入后台继续尝试，不阻塞前台启动过程。这个涉及到有时候网络没那么快好，不使用的情况下，一定情况下可能出现启动完后没挂载的情况或者直接就起不来。
本地缓存，需要另一个软件支持，使用中有点问题。最后没用了
行为：当 NFS 服务器不可达时，客户端会无限期不断重试 I/O 请求，直到服务器恢复正常为止。程序会“停住”不动，等待恢复后继续正常运行。
常与 intr 或其替代选项一起使用，使挂载操作可中断（尤其在老内核中），避免客户端彻底卡死。(但是 intr 在 内核 2.6.25 开始废弃，2008 年，RHEL6 开始)
通常 如果 nfs 挂载的是重要数据盘，一般是 hard。硬挂载将保持数据一致性
客户端在发起 I/O 请求后，如果在一定重试次数或超时时间内未收到服务器响应，就会返回错误给应用程序，而不是一直等下去。
可设置 timeo（超时时间），retrans（最大重发次数），让挂载更具灵活性
一般建议是只读挂载才使用软挂载。
async 会先进内存，有比较好的性能，但是断电会有问题，sync 不进内存，但是性能会有比较严重的问题。Gemini 是说 zfs 有写缓存的情况下强烈建议使用 sync。
这个参数同时在客户端和服务端都可以配置，且只影响被配置的机子，async 在客户端配置则只影响客户端是否落盘
硬挂载一般使用默认值就可以，软挂载特别是 timeo 可能需要设短一点，否则会产生超长时间的卡顿后才报错。
而硬挂载，因为会不断重试，本身就会一直卡顿。
另外需要注意的是，早期 NFS 是使用 UDP 的，很多教程会与混淆，而在 NFSv4 中，只是用 TCP，需要考虑 TCP 自身的 timeout 情况。
exportfs -ra nfs server 刷新配置而不用重启exportfs -v 查看客户端挂载参数配置 async 的时候没法使用 no_wdelay，高并发写入时不建议开 wdelay，no_wdelay建议配合 sync 使用
]]>CSI 是目前 Kubernetes 和其他容器编排系统（如 Mesos, Docker Swarm）推荐和事实上的标准接口，用于实现存储的动态供给。
这些插件是 Kubernetes 核心代码的一部分，例如 awsElasticBlockStore、gcePersistentDisk、azureDisk、cephfs、nfs、iscsi 等。
PVC 并引用一个支持动态供给的 StorageClass 时，Kubernetes 的 kube-controller-manager 会调用对应的内联卷插件去创建后端存储资源。k8s 里通过 helm 部署
CSI 就是为了解决内联插件的这些问题而诞生的。它提供了一个标准接口，将存储插件的开发从 Kubernetes 核心中剥离出来。
PVC 和 StorageClass 时，Kubernetes 会调用 CSI 驱动的 CreateVolume RPC 方法去创建后端存储资源。动态供给允许存储卷按需创建。系统根据用户的 PVC 请求，自动在存储端创建物理卷，并自动生成对应的 PV 对象。先有请求，后有卷。
动态供给通常只能生成机器生成的、具有唯一性的名字（通常包含 UUID），用户无法完全自定义后端存储的卷名。
预先在存储端创建好物理卷，并手动在 Kubernetes 中创建对应的 PV 对象。先有卷，后有请求。管理员手动创建 PV
PVC，并手动写配置文件进行挂载。
SCSI (Small Computer System Interface，小型计算机系统接口) 是一种用于计算机及其外围设备（如硬盘、磁带驱动器、扫描仪等）之间进行数据传输的协议标准和命令集。它定义了一套标准的命令（称为 SCSI 命令集）、协议（如何交换这些命令和数据）以及电气和光学接口。
iSCSI (Internet Small Computer System Interface) 是一种存储网络协议。它的核心功能是将 SCSI 命令封装在 TCP/IP 数据包中，并通过标准的以太网进行传输。本质上，iSCSI 允许两台主机通过 IP 网络交换 SCSI 命令，从而实现块级存储的远程访问，就像设备是本地连接的一样。
iSCSI 的架构是 C/S 架构（客户端/服务器）
initiator (发起端)
Target (目标端)是 iSCSI 协议架构中的服务端端点 (Server Endpoint)。
LUN (逻辑单元号)
LUN（逻辑单元） 与 Target（目标） 之间的内部映射关系（LUN Mapping）。
一个 Target 可以包含（映射）多个 LUN (LUN 0, LUN 1, ...)。
LUN 逻辑单元 (Logical Unit, LU) 是一个通过 SCSI 协议标准进行寻址的块存储设备。
LUN 是存储网络环境中，从物理存储资源中抽象出来的、可被服务器独立寻址和使用的块存储单元的数字标识符。
LUN 可以由截然不同的技术和对象构成。
Target 是存储设备上运行的一个逻辑实体，负责监听 TCP/IP 端口（默认 3260），接收并解析来自 Initiator（客户端，即 K8s 节点）的 SCSI 指令。
每个 Target 都有一个全球唯一的标识符，称为 IQN (iSCSI Qualified Name)。initiator 通过 IQN 唯一定位要连接的目标。
权限控制通常在 Target 级别进行配置。
]]>以下所有说明基于标准的域环境。
RSAT 主要涉及到使用 IPC (进程间通信) Inter-Process Communication
IPC$ (Inter-Process Communication)：这是 Windows 的一个隐藏共享，专门用于进程间通信。
RPC 是老协议，但是域控到普通机子仍然一直在走 RPC
远程过程调用。它是 Windows NT 时代就存在的基石技术。它的核心思想是：让在一台电脑上运行的程序，能够像调用本地函数一样，去调用另一台电脑上的函数。
走 RPC (Remote Procedure Call) / SMB 的命令：
quser / qwinsta（查询用户）logoff（注销用户）sc（服务控制）services.msc（远程连接服务控制台）PsExec（虽然它利用 SMB 管道，但本质依赖 RPC/DCOM 机制）注意 SMB 是 RPC 的“载体”，也负责 组策略 (Group Policy) 的分发。
示例命令（远程注销用户登录，用于桌面卡死，无法远程）
1 | qwinsta /server:<pcname> |
Windows 远程管理。它是微软对 WS-Management 协议的实现。这是一种基于 Web 标准（SOAP/XML）的协议。
WinRM 并不是为了完全替代 RPC 而生的，它只是为了“替代 RPC 在远程管理领域的角色”。(协议开销更大，历史包袱与生态)
WinRM 只使用两个端口: TCP 5985 (HTTP), TCP 5986 (HTTPS)
虽然默认端口叫 HTTP，但在域环境中，WinRM 的 Payload（负载数据）是经过 Kerberos 密钥加密的。它不是明文传输。
如果需要更高安全性（如通过互联网管理），可以配置 SSL 证书开启 HTTPS。
WinRM 可以通过配置（JEA - Just Enough Administration）限制远程用户只能运行特定的几条命令，而 RPC 这种控制很难实现。
走 WinRM (Windows Remote Management) 的命令：
Invoke-CommandEnter-PSSession-ComputerName 参数且非 WMI/DCOM 实现的 PowerShell Cmdlet。示例命令(重启服务)
1 | Invoke-Command -ComputerName <pcname> -ScriptBlock { Restart-Service TermService -Force } |
在 CMD 时代，微软专门提供了一个基于 WinRM 协议的命令行工具，叫做 winrs (Windows Remote Shell)。但是因为返回值以及其他一些功能深度上的问题，一般还是建议 Powershell
]]>WSL 是微软推出的兼容层工具，允许用户在 Windows 系统上原生运行 Linux 二进制文件，无需传统虚拟机或双系统。
无缝的 Windows 与 Linux 集成
/mnt 下。例如，访问 C 盘用户目录：1 | /mnt/c/Users/YourName |
<发行版名称> 需替换为实际名称，如 Ubuntu-22.04）：1 | \\wsl$\<发行版名称>\ |
1 | wsl ls -l /home # 调用 Linux 的 `ls` 命令 |
.exe，例如 explorer.exe .。在管理员模式下的 PowerShell 或 CMD 中执行：
1 | # 初始化安装（默认安装 Ubuntu） |
| 功能 | 命令 |
|---|---|
| 列出所有发行版 | wsl -l -v |
| 设置默认发行版 | wsl --set-default <名称> |
| 直接运行命令 | wsl <命令> (如 wsl ls /) |
| 版本更新 | wsl --update |
导出（备份）：
将现有系统打包成 tar 文件。
1 | wsl --export <名称> <备份文件名>.tar |
导入（恢复/迁移）：
将备份文件导入为新的发行版。
1 | wsl --import <新名称> <安装路径> <备份文件名>.tar |
⚠️ 注意事项：
wsl --unregister <名称> 会注销发行版并永久删除其对应的虚拟磁盘文件（ext4.vhdx），请务必先备份。export 和 import 流程，这能最大程度避免跨机器兼容性问题。.vhdx 硬盘文件，然后 unregister 原系统，再在新位置执行 import（指向移动后的文件）。HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss，理论上修改 BasePath 可行，但风险较大，不建议操作。推荐直接使用在线安装。如果需要使用社区镜像（如 openSUSE），可以手动下载并导入。
假设镜像文件位于 _images 目录：
1 | # 语法：wsl --import <系统名> <安装目录> <镜像tar包路径> |
wslconfig 是较旧但依然有效的全局配置工具：
1 | # 列出当前已安装系统（包含详细信息） |
长期存在的问题，到现在都没解决。连不上你倒是给个提示啊，我又不打印。不知道什么脑抽回路还不修。
MDZZ
]]>https://github.com/bleachbit/bleachbit
首先 CCleaner 是垃圾。
最近 cleanmgr 莫名其妙的 bug ,扫完清了，然后再打开是一点没清掉。
界面看久了，眼睛直接不舒服了可还行，加上不太好的操作，没法自定义，直接送走。
]]>Warning: 这个方法主要以开发手段来确认问题，比较复杂。
Spy++ 来源于 Visual Studio，社区版本也都包含。
安装后找到 spyxx_amd64.exe 并运行。该进程只会抓到同架构的程序的信息，所以理论如果有32位进程设了全局快捷键，只能用32位那个抓（未确认）。
之后输入问题快捷键，然后看哪个进程有反应，我的情况是发现是 autolyrics, 就很 emmmm，也不好说作者。
]]>1 | ps auxw | grep $(docker container ls | grep <containername> | awk '{print $1}') |
随后手动结束进程即可
]]>Kubernetes v1.24+ 移除了 dockershim，不再直接依赖 Docker Engine 来作为容器运行时，并且推荐使用像 containerd 这样的 CRI 运行时。同时安装 Docker Engine 和独立的 containerd (被 Kubernetes 使用) 确实可能会导致一些混淆或潜在的冲突，但这并不意味着完全不能安装 Docker，或者某些教程推荐安装 Docker 就是完全错误的。
这里需要澄清几个关键点，解释为什么有些教程可能仍然会提到安装 docker.io (或 docker-ce)：
历史原因和习惯延续：
在 Kubernetes v1.23 及更早版本，Docker Engine 是最主流的容器运行时。大量的旧教程和很多人的经验都是基于 Docker 的。
即使 dockershim 被移除，Docker Engine 本身的核心运行时就是 containerd。所以，安装 Docker Engine 实际上也会安装和运行 containerd。
Docker CLI 的便利性：
很多人习惯使用 docker命令行工具 (docker ps, docker images, docker build 等) 来进行本地镜像构建、容器调试等操作。
即使 Kubernetes 使用独立的 containerd 实例，管理员或开发者可能仍然希望在节点上拥有 docker CLI 以便进行一些辅助操作。
crictl 是与 CRI 运行时（如 containerd）交互的标准工具，但其命令和用户体验与 docker CLI 不同，后者更为用户熟知。
误解或简化教程：
有些教程可能没有完全更新到最新的 Kubernetes 架构变化，或者为了简化步骤，直接让用户安装 Docker，因为 Docker 安装后，其内部的 containerd 可以被配置为 Kubernetes 的 CRI 运行时。
关键点在于如何配置 kubelet： 如果安装了 Docker Engine，kubelet 必须被配置为不使用已废弃的 dockershim，而是直接与 Docker Engine 内部的 containerd 的 CRI socket (/run/containerd/containerd.sock，如果 Docker 将其暴露出来并与 Kubernetes 期望的一致) 通信。
Docker 仍然是构建镜像的主流工具：
虽然 Kubernetes 运行容器不直接依赖 Docker Engine，但构建容器镜像的生态系统仍然以 Dockerfile 和 docker build (或兼容工具如 buildah, kaniko) 为主。(可以看下最下面的命令)
因此，在开发环境或CI/CD流程中，Docker Engine 仍然扮演重要角色。有些教程可能会将节点准备和镜像构建环境的准备步骤混合在一起。
Helm 是 Kubernetes 的包管理器，目前唯一安装 Kubernetes Dashboard 的方式(然后它 Archive 了)，目前应该是推荐用headlamp
Charts (Helm 包)： Helm 使用一种称为 "Charts" 的打包格式。一个 Chart 就是一个描述了一组相关 Kubernetes 资源的文件集合。它可以包含 Deployment, Service, ConfigMap, Secret, Ingress 等等，以及这些资源的配置模板。Charts 通常允许用户通过一个 values.yaml 文件或命令行参数来定制安装，而无需直接修改 Chart 的模板文件。Helm 会跟踪应用的版本，并允许你轻松地将应用回滚到之前的版本。
仓库 (Repositories)： Helm Charts 可以存储在称为 "仓库" 的地方，你可以添加这些仓库来访问社区或组织维护的 Charts。
如 nfs-csi 的镜像代理
1 | helm upgrade --install nfs-csi csi-driver-nfs/csi-driver-nfs --namespace kube-system \ |
打印官方提供的配置
1 | helm show values grafana/alloy |
注意事项
首先注意主节点不能用delete node，移除可能需要kubectl drain(维护模式)。错误操作或者主节点意外失效，主节点的相关信息仍然会保存在 etcd 里。
需要进入 etcd pod 操作
1 | ETCDCTL_API=3 etcdctl -w table endpoint --cluster status |
列出 default 下的所有 pods
1 | kubectl get pods -n default -o wide |
删除一个 pod (通常会自己重启)
1 | kubectl delete pod <podname> -n default |
批量删pods的命令
1 | kubectl get pods -n default |grep "Error" |awk '{print $1}' |xargs kubectl delete pod |
不过如果机器对 grep 用 alias 显示行号，会需要unalias grep
crictl 是为 Kubernetes 设计的，通过 CRI (Container Runtime Interface) 标准与任何兼容的容器运行时（如 containerd, CRI-O）交互。它是跨运行时的调试工具。
列出所有 pods
1 | sudo crictl pods |
列出镜像
1 | sudo crictl images |
下载镜像
1 | sudo crictl pull <image-name> |
crictl 只支持下载删除镜像，但不支持 tag、build 等功能
查看容器 log
下面是 containerid ，不是名字，也不是pod id
1 | sudo crictl logs <containerid> |
runtime-endpoint 是容器运行时（如 containerd, CRI-O）暴露其 CRI 服务的通信地址，--runtime-endpoint用于指定 crictl 工具需要连接的、实现了容器运行时接口（CRI）的 gRPC 服务的监听地址。目前不写也没事
1 | containerd: unix:///run/containerd/containerd.sock |
1 | sudo crictl --runtime-endpoint unix:///run/containerd/containerd.sock ps -a |
ctr 是 containerd 项目自带的原生客户端，直接与 containerd 的 API 交互，绕过了 CRI 层。它只适用于 containerd，并且功能更底层。
在 Kubernetes 环境中，containerd 会为 Kubelet 创建一个名为 k8s.io 的命名空间。因此，使用 ctr 查看 K8s管理的资源时，必须指定该命名空间。
1 | sudo ctr -n k8s.io images ls |
其他还包括 images tag
1 | zcat harbor.v2.14.1.tar.gz | sudo ctr -n k8s.io images import - |
(docker 支持tgz,ctr只支持tar)
这些用来替代docker的命令
是 containerd 的另一个客户端工具。它的目标是提供一个与 Docker CLI 完全兼容的体验。
未测试
看了下，目前是需要自己下 bin 文件使用，还涉及到 docker-buildx, debian 目前还不建议用。其它系统自行调研下好了
查看报错，通常用于确认节点的异常。
1 | sudo journalctl -u kubelet -f --no-pager |
helm ctr 命令说明更新 -
]]>这是一个集成包
10GiB 网卡 X540 因为是比较型号老的，最后的驱动日期是2020年的，其只能手动安装。不支持 2.5 GiB 模式。
只建议在 Linux 下使用，Windows 下驱动已经不更新了
Intel(R) Serial IO GPIO 控制器驱动在 Intel 官网没有提供，且 Windows Update 通常不推送
该驱动分发依赖 OEM 厂商定制，而非 Intel 直接提供
一方面是OEM 定制化主导
Intel 将此类驱动（如 GPIO/I2C 主机控制器）视为芯片组配套组件，授权给设备制造商（如 Dell、Lenovo、ASUS）进行适配和分发。用户需通过电脑品牌的官方支持页面获取驱动，例如：
另一方面硬件 ID 绑定严格，硬件 ID（如 ACPI\INT345D）深度关联，不同主板型号（如 100 系列与 300 系列芯片组）需匹配不同驱动版本。若用户未按硬件 ID 精确搜索，在 Intel 官网难以定位正确驱动。
DDR5内存将传统的64位位宽拆分为两个独立的32位子通道（称为双子通道），因此单条DDR5即可实现类似双通道的带宽效果。例如，单条DDR5 4800MHz的理论带宽为38.4 GB/s（32位×2通道），而DDR4单通道仅25.6 GB/s（64位单通道）。
插满四根DDR5可能导致频率下降（如4800MHz降至4000MHz），带宽反而比双条降低15%~20%，延迟增加25%。
目前绝大多数消费级的DDR5主板都采用一种叫做“菊花链”（Daisy Chain）的布线方式。CPU的内存控制器设计时，通常会对两根内存插槽的信号线路做专门优化，以实现最高的频率和最稳定的运行。当插上四根内存时，相当于内存控制器需要同时管理四条“通道”的信号。这会大大增加控制器的负载和电气压力，导致信号衰减和干扰（Crosstalk）变得更严重。离CPU最近的两个内存插槽（通常是A2和B2）是“主要出口”，信号路径最短，最干净。另外两个插槽（A1和B1），信号需要绕更远的路，质量会下降。在高频情况下不稳定，为了保证四条路都能同步稳定，整个系统的速度就必须被拉低到最差的水平。
所有DDR5 DRAM芯片都具备 On-Die ECC，仅用于内部，不是传统的系统级ECC（不会将错误报告给CPU或操作系统）。
Unbuffered ECC （非缓冲ECC）和 Registered ECC（注册式ECC）
Unbuffered ECC内存指的是不带缓冲（unbuffered）的纠错码（Error-Correcting Code）内存模块。它在标准内存基础上添加了额外的位（通常是1/8的额外容量）来检测和纠正单比特错误，从而提高数据完整性和可靠性，但没有额外的缓冲芯片来管理信号。 与registered（或buffered）ECC相比，unbuffered ECC的命令直接从内存控制器传输到模块，没有中间寄存器延迟，因此速度更快，但通常支持的内存通道或模块数量较少，适用于桌面、工作站或小型服务器，而非大规模企业级系统。
]]>删除这个文件夹下的/var/lib/dpkg/info/相关文件
1 | sudo dpkg --remove --force-all <包名> |
其实建议再仔细看下包的源码，然后尝试还原下里面修改的配置，避免潜在影响。
]]>renderer: networkd，才能dhcp-identifier: mac