杂谈学习笔记系列
杂谈学习笔记系列 1. AS5600 12 位可编程非接触式电位器 (个人博客链接) (CSDN链接) 2. C++ virtual 关键字的沉思：为何“万物皆虚”是反模式？ (个人博客链接) (CSDN链接) 3. Chrome书签图标“失踪”了？一招“同步大法”让它们全部回来！ (个人博客链接) (CSDN链接) 4. Multi-Pass Review 还不够：为什么还需要专项 Profile 和 Fresh Diff Scope (个人博客链接) (CSDN链接) 5. NVIDIA驱动更新“翻车”？解决RTX 2060在Bilibili客户端无法加载4K视频的终极指南 (个人博客链接) (CSDN链接) 6. PotPlayer采集结束后崩溃？罪魁祸首竟是你的安装路径！ (个人博客链接) (CSDN链接) 7. Rime输入法跨平台配置与同步教程：以雾凇拼音方案为例 (个人博客链接) (CSDN链接) 8. WIN11如何可以安装ISO (个人博客链接) (CSDN链接) 9. Win11新版“Apple设备”应用无法识别iPhone？终极解决方案来了！ (个人博客链接...
虚拟机学习笔记系列
虚拟机学习笔记系列 1. Ubuntu 虚拟机根文件系统损坏故障的深度分析与修复 (个人博客链接) (CSDN链接) 2. VMware Ubuntu 24 (个人博客链接) 3. 安全移除VMware虚拟机数据磁盘的终极指南 (个人博客链接) (CSDN链接) 4. 解决因取消VMware快照删除导致的虚拟机磁盘损坏问题 (个人博客链接) (CSDN链接)
VMware Ubuntu 24
VMware Ubuntu 24.04 虚拟机从 124 GB 压缩到 33 GB：快照合并、VMDK 占用与 disk shrink 实战 摘要：记录 Ubuntu 24.04 在 VMware Workstation 中从约 124 GB 收缩到约 33 GB 的过程，解释快照合并、VMDK 分片、Guest 空闲块与 VMware Tools disk shrink 的关系。 @[toc]在 VMware Workstation 中长期使用 Ubuntu 后，很容易遇到一个看起来矛盾的问题：Ubuntu 内部明明只用了三十多 GB，Windows 上保存虚拟机的目录却已经膨胀到一百多 GB；即使在 Ubuntu 中删除了大量文件，宿主机上的 VMDK 也不会同步缩小。 这次实际环境就是这样：Windows 上的虚拟机目录一度约 124 GB，而 Ubuntu 根文件系统实际只使用约 29～32 GB。处理中还出现了一个很容易误判的阶段：删除快照，并在 VMware 中执行压缩和碎片整理后，虚拟磁盘的“当前大小”反而变成了 88.4 GB。 最终，在确认快照链已经合并...
lely-canopen-rtt：为什么推荐在 RT-Thread 上使用 Lely CANopen 构建主站
lely-canopen-rtt：为什么推荐在 RT-Thread 上使用 Lely CANopen 构建主站 摘要：面向 RT-Thread MCU 的 CANopen 主站选型，比较 Lely、CANopenNode、CanFestival 与商业栈，并说明本软件包的架构、静态对象字典生成和使用流程。 仓库地址：https://github.com/wdfk-prog/lely-canopen-rtt @[toc] 推荐判断如果项目的目标是在 RT-Thread MCU 上实现一个真正承担网络管理职责的 CANopen 主站，而不是只做几条 NMT 命令和简单 SDO 读写，我更推荐以 Lely CANopen 为协议栈核心，再通过 lely-canopen-rtt 这一层完成 RT-Thread 适配。 推荐它的原因并不是“Lely 支持 CANopen，所以可以用”，而是它的设计方式和主站需求比较匹配：Lely 本身把 NMT Master、远端节点 boot、配置请求、SDO Client、PDO、SYNC、EMCY、TIME 等能力组织成完整的 CANop...
docker学习笔记系列
docker学习笔记系列 1. 01-Docker开发环境容器化：从基本概念到Ubuntu20 (个人博客链接) 2. 02-大型SDK开发镜像工程化：BuildKit、Buildx与项目脚本 (个人博客链接) (CSDN链接) 3. 03-交叉编译开发容器故障排查：从CMakeCache到目标库链接 (个人博客链接) (CSDN链接) 4. 04-Docker常用语法与命令：CLI、Dockerfile与Compose速查 (个人博客链接) (CSDN链接) 5. 05-Docker开发镜像跨主机迁移：从Ubuntu20 (个人博客链接) 6. 06-Docker开发环境到底要交付什么：镜像、源码与运行脚本 (个人博客链接) (CSDN链接) 7. 07-大型Docker镜像导出导入工程化：可靠性、磁盘与压缩 (个人博客链接) 8. 08-Docker29与containerd-image-store：镜像为什么会保存两种形态 (个人博客链接) 9. 09-大型Docker开发镜像磁盘排查：containerd、缓存与容量规划 (个人博客链接)
05-Docker开发镜像跨主机迁移：从Ubuntu20
Docker 开发镜像跨主机迁移：从 Ubuntu 20.04 到 24.04 摘要：说明如何把已验证的 Ubuntu 20.04 开发镜像迁移到 Ubuntu 24.04，并逐层验证 Docker、镜像、源码挂载和真实构建。 @[toc]旧开发机长期使用 Ubuntu 20.04，交叉编译 SDK、CMake 和各种依赖已经调通；新机器升级到 Ubuntu 24.04 后，最稳妥的做法往往不是重装整套依赖，而是继续运行已经验证过的开发镜像。 1. 宿主机升级，不等于容器也升级假设我们已经有一张镜像： 1cross-dev:20.04 它内部包含： 123456Ubuntu 20.04 用户空间Yocto SDK交叉编译器CMake / Make / Python代码生成工具entrypoint 把它迁移到 Ubuntu 24.04 后，结构是： 123456flowchart TB Host["Ubuntu 24.04 宿主机"] --> Engine["Docker Engine"] Engine --&g...
06-Docker开发环境到底要交付什么：镜像、源码与运行脚本
Docker 开发环境到底要交付什么：镜像、源码与运行脚本 摘要：从团队交付角度区分 Docker 镜像、bind mount 源码、entrypoint、Compose 和 dev.sh，明确哪些需要随镜像一起交给使用者。 @[toc]开发镜像自己能运行以后，下一个问题往往不是“怎么构建”，而是： 我要把这套环境给另一个开发者，他到底需要拿到哪些文件？ 最容易产生误解的是 entrypoint.sh、compose.yaml 和 dev.sh。 它们看起来都和“启动容器”有关，但所处层次完全不同。 1. 先把开发环境分成三层可以先用一张图建立边界： 123456flowchart TB User["开发者"] --> Dev["dev.sh"] Dev --> Compose["compose.yaml / docker run 参数"] Compose --> Image["Docker Image"] Image --> Entry[&...
07-大型Docker镜像导出导入工程化：可靠性、磁盘与压缩
大型 Docker 镜像导出导入工程化：可靠性、磁盘与压缩 摘要：分析二十多 GiB Docker 镜像在 save/load、临时 TAR、流式压缩、SHA256 和 zstd 之间的工程取舍，并给出更省磁盘的脚本结构。 @[toc]普通镜像只有几百 MB 时，docker save 和 docker load 很少让人关心磁盘峰值。 但开发镜像如果包含完整 Yocto SDK，规模达到二十多 GiB，导出本身就会变成一个值得设计的流程。 真正的问题不再只是： 1怎么导出？ 而是： 12345失败时会不会留下假成功文件？Ctrl+C 会不会留下几十 GiB 垃圾？临时 TAR 会占多少磁盘？压缩包是否需要先解压才能 docker load？如何校验传输完整性？ 1. save/load 的基本数据流导出： 1docker save -o cross-dev.tar cross-dev:20.04 导入： 1docker load -i cross-dev.tar 可以理解成： 12345Docker image ↓ docker save...
09-大型Docker开发镜像磁盘排查：containerd、缓存与容量规划
大型 Docker 开发镜像磁盘排查：containerd、缓存与容量规划 摘要：给出大型开发镜像的磁盘排查顺序，区分 containerd 镜像数据、snapshot、BuildKit cache、导出归档和源码构建输出。 @[toc] 当一个二十多 GiB 的开发镜像运行在 Docker Engine 29+ 新主机上时，磁盘问题往往比容器运行问题更早出现。 例如根分区只有约 80 GiB，却同时存在： 123456大型开发镜像containerd contentunpacked snapshotBuildKit cache源码 build 输出镜像导出归档 这时如果只看到： 1/dev/sdaX 90% 然后立刻运行 docker system prune -a，很容易删掉重新构建代价很高的开发镜像。 更好的方式是先回答： 空间到底被哪一类数据占用了？ 1. 第一层先看文件系统1df -h / 它回答的是： 1整个根文件系统还剩多少空间？ 它不会告诉你 Docker 哪个对象在占空间。 如果镜像归档放在其他分区，还要分别看： 1df -h /path/t...
08-Docker29与containerd-image-store：镜像为什么会保存两种形态
Docker 29 与 containerd image store：镜像为什么会保存两种形态 摘要：从 content store 与 snapshotter 两个角色解释 Docker Engine 29 的 containerd image store，以及大型镜像为什么比传统 overlay2 更占磁盘。 @[toc] 把一个大型开发镜像迁移到新的 Ubuntu 主机后，有时会看到一个很反直觉的结果： 12镜像内容大约 27 GiBDocker 相关磁盘却接近 50 GiB 如果新机器使用 Docker Engine 29+ 的全新安装，这个现象很可能与 containerd image store 有关。 Docker 官方当前文档明确说明：Docker Engine 29.0 及以后版本的全新安装，默认使用 containerd image store；从较早版本升级的系统则可能继续使用传统 graph driver。 1. 先确认当前后端Docker 官方提供的检查命令是： 1docker info -f '{{ .Drive...
