- 博客(1785)
- 收藏
- 关注
RSS订阅原创 管道输入怎样消费？用2字节缓冲区读取一次写入，先忘掉消息边界
控制进程把任务输入写进管道，工作进程读到一块数据后就开始解析。这种实现如果默认“一次读取就是一条完整请求”，就把业务消息边界交给了一个没有提供这种保证的接口。本文用一个非常小的C程序验证消费循环：父进程写入四个字节，子进程每次最多读取两个字节，累计处理直到输入结束。不接真实诊断工具，不使用业务日志。
2026-11-05 14:31:06
118
原创 Linux服务内存限制怎么验？把MemoryHigh、MemoryMax和事件计数对齐
给服务设置内存上限以后，看到当前用量低于上限，就能说配置没有影响吗？不一定。进程可能经历过回收压力，也可能有工作进程已经结束，采样时用量才降下来。内存限制要同时看配置范围、当前状态和过去发生的事件。本文针对systemd与cgroup v2讨论观测设计，不在当前机器修改配置，不制造内存耗尽。
2026-11-05 14:29:46
61
原创 诊断命令白名单别只列程序名：动作、参数和资源范围要一起定义
给诊断工具接入外部命令时，最容易想到的办法是列几个允许执行的程序名。请求里的第一个词在名单里，就放行。问题在于，同一个程序可能有读取、写入、导出甚至执行其他内容的选项。允许程序名，不等于允许它的全部能力。更清楚的入口是业务动作：用户请求“查看设备摘要”，系统把它映射为已经评审过的固定调用。日志内容或模型建议只作为材料，不直接变成一段命令文本。
2026-11-05 14:28:35
152
原创 Linux工具运行状态怎样探测？进程存在、功能就绪和证据过期要分开
本地诊断工具可以把就绪定义为：当前配置已经加载，必要组件初始化完成，能够接收指定类型的新任务。这是示例合同，不是所有服务都适用的标准。若工具有多项能力，还可以分别报告采集、分析、导出是否可用。不要因为主进程存在，就让界面把全部能力标为正常；也不要在某个可选组件失败时把所有功能都算成不可用。Linux服务管理本身也区分不同启动语义。systemd.service官方手册说明，需要服务在完成启动后主动发送就绪通知。这要求程序显式支持，不能只改配置就假定应用初始化已被准确识别。本文没有实现或执行该通知协议。
2026-11-05 14:27:20
52
原创 fflush之后数据到哪了？用全缓冲小实验分清写入、刷新和持久化
诊断工具写报告或保存状态时，程序可能先把内容交给C库缓冲，再由底层写入文件。如果只检查fwrite返回成功，就立刻告诉用户“已经安全保存”，这个承诺可能超过接口实际完成的工作。本文用一个三字节临时文件实验观察刷新前后的文件长度，再回读校验。它帮助理解缓冲层次，不测试断电持久性，也不测存储性能。
2026-11-05 14:26:04
151
原创 用最小C程序收集子进程结果：waitpid拿到的不是业务答案
诊断服务启动一个工作进程，等它结束，再把状态交给上层。逻辑听起来只有一句话，但实现时有两个容易混淆的对象：操作系统提供的退出状态，以及业务约定的任务结果。本文先用一个只会返回固定退出码的子进程，把结果收集过程缩到最小。不启动真实诊断工具，不运行模型，也不操作其他任务的进程。
2026-11-04 20:56:23
191
原创 Linux服务设置TasksMax前，先算清线程和控制组范围
一份能复核的记录应同时保留配置值、有效限制、当前任务数、控制组路径、采样时刻和当时的服务阶段。再加上应用自身的工作进程与线程观测，才能解释差异来自哪里。本文完成的是官方语义核对与合成计数验证，未声称在Linux真实部署成功。对产品交付来说，数量限制不只是一个保护参数；达到边界后任务是否结束清楚、失败是否能被发现，同样决定这个服务能否独立维护。
2026-11-04 20:55:11
178
原创 诊断工具只读访问日志：先列资源，再区分句柄与服务权限
诊断工具只读日志”是一句很有用的边界声明，但要把它变成可维护的实现，还需要继续问：读哪些日志？结果写在哪里？用什么身份运行？所谓只读，约束的是一次打开操作，还是整个服务能做的事情？如果这些问题没有区分，代码里出现一个只读标志，文档就可能写成“工具不会修改日志”。这比实际验证跨了很大一步。
2026-11-04 20:54:01
104
原创 Linux工具配置升级：写一个保留原文件的迁移器，比自动改完更可靠
工具更新后，旧配置不再符合新格式，用户常遇到两种糟糕体验：程序直接启动失败，却没说怎么改；或者启动时自动迁移，等出问题才发现原文件已经被覆盖。配置迁移值得成为独立、可检查的操作。它负责解释旧格式并生成候选，是否启用候选则是另一项决定。本文用一个很小的版本变更演示这条边界，不修改任何实际工具配置。
2026-11-04 20:52:49
146
原创 连读两遍文件，就证明页缓存命中了？先把内容、驻留和I/O证据分开
测试日志读取性能时，一个常见实验是连续读取两遍同一个文件。若第二遍更快，就解释为“页缓存命中”。这个解释可能合理，但只凭两次时间还不够。文件可能在创建时就已经进入缓存，设备本身也可能有缓存；第二遍的程序状态、调度和后台负载也未必相同。要让实验能被复核，先写清每个观测量回答什么问题，再决定结论能走到哪一步。
2026-11-04 20:51:33
50
原创 收到 SIGTERM 就写日志、释放内存？先把信号处理器的边界划出来
诊断进程准备退出，最直觉的写法是在信号处理器里打印日志、清理模型、删除临时文件。问题是信号可能打断程序正在执行的库函数，处理器里的调用未必能安全重入。更小的起点是：处理器只设置标志，主流程在合适位置停止任务并清理。下面用程序向自身触发 SIGTERM 验证标志交接，没有向其他进程发送信号，也没有运行真实诊断服务。
2026-11-03 23:46:53
70
原创 配置文件设成只读就够了？还要看父目录和更新入口
诊断服务只需要读取配置，维护程序负责更新。如果服务还能写父目录，就不能只看配置文件本身的模式来判断边界；路径也可能经过软链接，指向预期之外的位置。这篇从资源职责和路径反例出发，不修改任何权限。实际验证只在自建目录中解析路径，没有创建系统账号，也没有测试操作系统是否拒绝写入。
2026-11-03 23:45:39
42
原创 给服务一个私有临时目录，为什么还可能把空间用光？
诊断服务有独立运行目录，也能在退出时清理。一次大输入却产生了多份中间结果，暂存空间迅速增长。目录归属与生命周期解决了部分问题，容量还需要单独约束。本文分清文件系统限制、应用预留和失败恢复，给出预算演示。没有挂载 tmpfs、修改服务或填满磁盘；实际只执行内存中的预算断言。
2026-11-03 23:44:29
75
原创 Linux 工具安装失败，为什么不把检查提前到写文件之前？
安装程序复制了一半文件，才发现目标架构不支持；或者替换了入口，随后才报告空间不足。使用者面对的是半成品状态，恢复成本比一句明确的不兼容提示高得多。安装前检查可以先完成只读判断，保留不通过原因，再进入受控安装。本文使用合成包清单和目标记录验证判定，没有安装软件、修改权限或探测真实二进制兼容性。
2026-11-03 23:43:17
142
原创 文件描述符关了，映射还能读吗？用一个小实验分清 mmap 的生命周期
做本地诊断工具时，读取日志或索引文件可能会用到文件映射。这里容易出现一个直觉：文件是通过描述符打开的，关闭描述符，之前拿到的地址应该也不能用了。这个直觉把两种资源绑在了一起。描述符是进程访问打开文件的入口，映射则是一段虚拟地址区域。它们建立联系以后，释放动作并不相同。先弄清这个边界，比一上来讨论映射能快多少更有用，否则很容易把资源释放写错。
2026-11-03 23:41:58
113
原创 诊断包怎样导出，才能让维护者知道里面究竟是什么？
工具报错，使用者点击“导出诊断包”，拿到一个压缩文件。里面若只有一堆没有来源说明的文本，维护者还是不知道哪些材料属于这次任务；若直接压缩临时目录，又可能混入不该交付的内容。诊断包是一个交付接口：先选内容，再说明来源和限制，最后检查实际打包字节。本文用内存中的合成文件演示，没有收集本机真实日志、凭据或任何用户数据。
2026-11-02 12:42:07
1368
原创 close 以后资源还在？用 dup 实验分清描述符和打开文件描述
Linuxclose(2)说明描述符关闭后可以被复用；当它是相关打开文件描述的最后引用时，才涉及对应资源的释放。不同资源还有自己的生命周期，不能把关闭一个整数编号理解为“内核里所有相关内容已经清空”。这也解释了日志工具的常见边界：包装模块复制了描述符，采集模块只关闭自己的那份，副本仍需要有明确归还责任。如果把描述符交给第三方库，应说明所有权是转移还是借用，避免两边都关闭或两边都不关。成功关闭也不等于写入已经持久化。数据落盘要求属于另一个问题，需要按文件系统和持久化协议设计。
2026-11-02 12:40:54
1531
原创 Linux 服务的文件句柄上限，为什么不能只看终端里的 ulimit？
在终端查到文件描述符上限很高，服务仍然报“打开文件过多”。终端与服务可能由不同父进程启动，继承的限制也不同。排查应落到实际进程，而不是拿当前 shell 的读数替它作证。本文给出配置核对顺序，并在本任务自建子进程中演练描述符耗尽。实际实验运行于 macOS，没有部署或修改 Linux 服务，也没有改变当前会话的限制。
2026-11-02 12:39:43
1568
原创 给诊断工具换个服务账号，就算完成隔离了吗？
诊断工具需要读日志、写暂存结果，并不需要修改自己的程序包。若它与维护流程共用一个可写发行目录的账号，一次解析缺陷可能扩大成程序被替换。服务账号设计应从职责出发，而不是只给进程换个名字。本文给出静态资源清单与 systemd 配置示例，没有创建账号、修改权限或切换身份。实际执行的检查只核对清单自洽，不代表操作系统已经拒绝越权访问。
2026-11-02 12:38:30
1467
原创 calloc 返回以后，内存都准备好了吗？逐页写入前后看缺页增量
端侧工具启动时先申请一块工作区，界面很快显示“准备完成”；第一次处理日志时却出现额外开销。只测分配函数返回，可能没有覆盖后续首次访问的工作。这篇用一个小型 C 程序观察两轮逐页写入前后的计数。实际运行环境是 macOS，本机页大小与输出都如实记录；Linux 机制依据官方手册核对，没有把当前结果冒充 Linux 实测。
2026-11-02 12:37:20
1639
原创 日志轮转后为什么还在读旧内容？用最小 C 程序分清路径和描述符
一个日志读取器只在启动时打开app.log，随后持续读取。轮转程序把它改名为app.log.1，又创建新的app.log。目录看上去已经更新，读取器却可能继续停在旧文件末尾。这不一定是缓存问题。需要先分清两件事：路径现在指向什么，以及已经打开的文件描述符引用什么。本文复现“改名旧文件，再创建新文件”的轮转方式。实验在当前 macOS 环境中用现有 C 编译器运行通过；Linux 行为依据官方 man-pages 核对，没有在本环境运行 Linuxstrace。不涉及真实生产日志。
2026-11-01 19:50:55
1364
原创 Linux 工具升级失败后，只把软链接改回去够吗？
工具升级后起不来，维护说明写着“把 current 改回旧版本”。使用者照做，界面仍然打不开。可能是旧进程没有重启，也可能是配置已经被新版本改过。文件入口恢复，只完成了回退的一部分。这篇讨论独立目录交付的小工具，目标是让使用者知道失败发生在哪一步、如何恢复、恢复后检查什么。受包管理器管理的软件应优先遵循对应管理机制，不要用自写脚本随意覆盖它的文件。下面只在临时目录演练入口切换与模拟探针，没有升级任何系统软件，没有重启服务。
2026-11-01 19:49:40
1678
原创 管道里没数据，read 为什么不结束？把等待和 EOF 拆开观察
诊断工具启动子进程收集信息，读标准输出时一直等不到结束。子进程可能已经没有新内容，但某处仍持有管道写端。只要这个条件没有处理，“暂时没数据”就不能被当成“以后不会有数据”。本文用本地匿名管道区分这几种状态。实验在 macOS 运行，Linux 语义依据 man-pages 核对；没有启动真实诊断命令，也没有修改其他任务进程。
2026-11-01 19:48:32
1597
原创 诊断工具把日志放进 /tmp 就安全了吗？先列临时文件的访问清单
端侧诊断工具导入日志、提取片段、生成报告，中间往往会落几份文件。它们叫“临时文件”，并不代表内容不敏感，也不代表退出后一定消失。比“统一放到 /tmp”更有用的设计，是逐项写清谁创建、谁读取、何时清理、是否交给使用者。这样才能判断工具究竟需要什么权限，以及失败后可能留下什么。本文只在自建临时目录中创建合成文件并检查模式，没有修改系统权限，没有进行跨账号访问测试。
2026-11-01 19:47:18
1862
原创 CPUQuota=50% 限的是半台机器吗？把服务配置和节流证据对齐
给端侧诊断服务加上，然后看任务管理器，读数似乎对不上。问题可能出在口径：这个百分比参照的是一个 CPU 的时间，不是整台多核机器算力的一半。对产品交付而言，配额能限制资源使用，却不能直接承诺“别的应用不会卡”或“诊断一定在某个时间内完成”。先把配置、实际限额和工作负载对应起来，再谈合适的值。本文依据 systemd 与 Linux cgroup v2 官方文档给出检查方案。当前环境是 macOS，没有执行 Linux 控制组配置；本地仅验证了示例预算换算，没有节流实测曲线。
2026-11-01 19:46:03
1778
原创 Agent 自动修复到哪一步该停：重试预算与待评审结果
自动修复如果只有“失败就重试”，很容易把网络暂时失败、权限拒绝、配置错误和结果未知都丢进同一个循环。对Agent来说，能识别什么时候停，比多跑一次更重要。2026-10-15的介绍了探索代码、提出修复、重跑CodeQL并打开PR供审阅的流程。官方产品行为不能替我的工具链作保证，但“候选结果仍要验证并交审”的边界值得保留。访问日2026-10-24，本文未调用GitHub或创建PR。
2026-10-31 23:06:48
1677
原创 Rust 的 wgpu 回读为什么还没好：提交、映射与 buffer 生命周期
拿到adapter名字，只说明枚举或设备选择走到了一步，不能证明矩阵已经算过。即使命令已经提交，CPU也不能立刻把结果buffer当作可读切片。对Rust端来说，最容易漏掉的是提交、映射完成和视图释放之间的顺序。标记30.0.1：map_async立即返回，成功回调后才能访问映射范围；使用结束时先释放视图再unmap。说明原生端推进清理与回调的方式，WebGPU端由其环境驱动。本文没有安装或运行wgpu。
2026-10-31 23:05:38
1704
原创 学 Rust 时纠正的三条误解：编译、FFI 与 Wasm 各缺什么证据
我刚学Rust时，容易把一个局部保证记成一句全局口号。绿色编译输出很让人安心，反而需要停一下：编译器具体检查了什么，外部代码承诺了什么，运行时又替我隔离了什么？这篇只纠正三条误解，不统计产量，也不把尚未发生的月底经历写成总结。
2026-10-31 23:04:30
1647
原创 llama.cpp、Candle、Burn 怎么选：先列我的模型与后端条件
如果需求还没写清，直接问“Rust推理选哪一个最快”，我很容易得到一个看似明确、其实无从验证的答案。我的起点更小：要跑哪个模型、什么格式、在哪个设备、是否需要训练，以及愿意维护哪些原生依赖。本轮2026-10-24重新查看和。仓库master会变，README不是具体模型在我的设备上已跑通的证明。
2026-10-31 23:03:24
1854
原创 同一份 Rust 组件为什么连不上：给 WIT 版本做张兼容表
文件扩展名都叫.wasm，接口名字也差不多，却在宿主里链接失败。我现在先核对产物种类与完整接口标识，而不是反复换运行时试运气。Rust源代码相同，不代表生成的组件接口和宿主需求相同。区分了WASI版本和产物路径。2026-10-24读取的页面还明确指出wasm32-wasip3工具链的Tier 3及构建限制，0.3示例采用特定reactor路径。不能把页面中某个示例简化成“任何Rust main都能直接切到0.3”。
2026-10-31 23:02:14
1653
原创 VNNI 算的是 u8×i8：别把 INT8 矩阵直接塞进去
都叫INT8，两个输入也不一定同为i8。看VNNI内核前，我先查具体指令的乘数类型；把负数缓冲原样当无符号读取，会改变它代表的数。说明：a中相邻四个u8与b中对应i8相乘，再与i32累加器合并；接口要求AVX-512 VNNI目标特性，文档标记自Rust 1.89.0稳定。本机aarch64没有执行该指令。
2026-10-30 13:18:05
1731
原创 Wasmtime 沙箱能防什么：权限配置挡不住运行时漏洞
不向Wasm模块提供文件系统导入，是在限制它能请求什么；运行时正确维护边界，是另一件事。前者配置得再少，也不能把后者的漏洞修好。2026-10-02发布的涉及组件异步回调结果校验缺陷。本文不构造攻击组件、不复现逃逸，只按公告检查版本与控制措施。不能把旧公告说成当天新发现。
2026-10-30 13:15:44
1712
原创 跨 Rust 和 C++ 查内存错误：Miri、ASan 各自能看到哪一段
Rust包装层通过测试，不能说明C++内部也被检查过。跨语言排错时，我会先确认检测链能否看见目标代码，再讨论“没有报错”意味着什么。介绍对Rust执行路径中未定义行为的检查及FFI限制；介绍原生插桩及其运行要求。Miri和ASan都提供有限证据，不是完整正确性证明。本轮访问日2026-10-24。
2026-10-30 13:13:42
1720
原创 Agent 工具令牌别自己发明签名：先验 audience 与资源范围
用DefaultHasher把消息算成一个数字，再把这个数字叫“签名”，不会得到可验证主体身份的令牌。普通哈希表散列器没有替应用定义密钥、算法、验证方或信任来源；这不是缺一条注释能补齐的问题。要求服务确认token确实发给自己，并明确禁止token passthrough。这个规范版本是七月资料，不把它包装成十月新发布。
2026-10-30 13:11:08
1627
原创 AI 短剧素材带了来源凭据，就能证明画面真实吗？
短剧本来就可以是虚构故事。给一段生成画面加上来源凭据，解决的是“谁声明了哪些制作和编辑信息、这些信息是否与素材绑定”等问题，不会把剧情变成真实事件。反过来，没有凭据的素材也不能直接判为造假。提供C2PA读写和验证相关能力。未安装SDK、没有签名任何媒体，也没有核验这批文章配图的C2PA凭据。
2026-10-30 13:09:38
1777
原创 Rust 的生命周期不是分布式租约：Agent 状态安全的四个边界
借用的生命周期是编译器对引用可用范围的约束；租约是运行系统在时间和故障条件下授予的权利。它们都谈“多久”，但含义不同。把两者叫作同构，既没有给出严格映射，也容易让读者误以为编译器替远端协议背书。2026-10-07的强调工具执行边界与模型执行是不同关注点。这可以作为Agent工程背景，不能据此推导所有状态问题都已解决。访问日2026-10-24。
2026-10-29 22:26:04
1761
原创 Wasm 冷启动从哪里计时？先拆开下载、编译和实例化
同一份Wasm，在新进程里首次运行，和复用Engine后新建一个实例，测到的不是同一种启动。如果一边计入编译，另一边拿预编译产物直接实例化，最后的微秒表再整齐也没有公平含义。于2026-10-20发布，适合作为固定实验对象。说明了预编译、池、COW和InstancePre等机制；不把滚动示例当成已在固定版本跑通的代码。
2026-10-29 22:24:33
1771
原创 把 64 字节对齐改回来之前，先看这条 AVX 加载要求
AVX加载必须64字节对齐”这句话太宽了。对哪一条指令、哪种宽度、哪个地址？如果连要求都写错，后面的缓存调优就会把正确性和性能混成一件事。明确要求32字节边界，并要求相应AVX目标特性。256位是32字节；这条对齐加载的条件不是64字节。文档事实不等于本机执行结果。
2026-10-29 22:22:53
1746
原创 先别叫开源复盘：给 llama.cpp 的 Rust 封装做一张契约清单
一份extern声明加一个Drop，还不能证明绑定库是安全的。我现在更愿意先写契约表：声明来自哪个头文件，返回的指针归谁，什么操作会让它失效，哪些调用允许并发。没有公开仓库、tag和验证记录，就不把学习片段叫作开源项目战绩。2026-10-15的修复了特定x86_64 FFI bool返回问题，提醒我同时核对语言类型和目标ABI。这里不复述该回归实验，重点放在绑定的证据链。
2026-10-29 22:21:31
1672
原创 10 月手账先核账：255 份稿件，不等于 255 次可复现实验
如果把目录里的稿件数量写成“完成多少个项目”，我会先把自己的手账退回来。文件存在、示例能编译、运行有日志、文章已发布，是不同状态。技术学习需要进度，但进度应该对应能检查的东西。本轮对陈一铭账号10月目录的本地核对，共有255份Markdown稿件：1–20日每天10篇，21–31日每天5篇。这是工作区稿件数量，包含尚未到来的排期，不是255篇已发布文章，更不是255次实验或个人手写代码量。
2026-10-29 22:19:45
1509
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人