让服务器响应整个网段中的请求
这篇讲的是如何让一台服务器响应整个网段的所有IP地址请求。作者从实际需求出发，发现这个看似复杂的网络配置，核心方案其实异常简洁，仅需两步关键操作。 第一步是在路由器上为目标网段（如 172.16.0.0/16）添加静态路由，将其网关指向服务器的物理地址。第二步则是在服务器本机，使用一条 `ip route add local` 命令，将该网段绑定到本地回环接口（lo）上。作者特别指出，这样能确保服务器正确接收并回复所有来自该网段的数据包，且比使用 ARP 代理（如 tarpd、ndppd）的传统方式性能更优，不会导致网关和服务器的邻居表爆炸。 此外，作者还补充了该方法对 IPv6 同样有效，并提示路由应配置在 lo 而非 eth0 接口上以避免潜在问题。整体来看，这是一个高效、干净的解决方案，通过巧妙的路由表配置，用最小的改动实现了复杂需求，尤其适合开发测试或需要模拟多服务端点的场景。
编译 RenderDoc 的安卓 apk(带interceptor-lib)
作者以亲身经历开篇：之前编译过安卓版的RenderDoc，但因未留笔记，再次需要时只能重头再来。这次他想为需要强Hook能力的版本做详细记录，因为核心的interceptor-lib组件依赖一个非常古老的LLVM版本，编译过程颇为繁琐。 文章的核心价值在于点出了一个官方文档中未明说的关键陷阱。尽管流程大体可循——先按指南配置好JDK/SDK/NDK，再克隆interceptor-lib并修改其构建脚本——但在实际使用CMake生成工程时，新版本CMake与Android NDK工具链的交互方式已经变化。直接使用常见的`-DANDROID_TOOLCHAIN=clang`参数实际上无效，导致构建会默认选用无法工作的GCC工具链。 作者给出的解决方法是使用正确的CMake参数：`-DCMAKE_ANDROID_NDK_TOOLCHAIN_VERSION=clang`，并指明了可参考的具体CMake模块文件路径。这个细微的修正，正是避免编译功亏一篑的关键。文章最终明确，遵循此调整后的步骤，即可成功编译出具备强Hook能力的RenderDoc安卓APK。
Linux下解决同一硬盘因为连接设备不一样导致扇区大小不一致的问题
作者最近遇到了一个令人头疼的硬件兼容性问题：将一块硬盘从
Golang socket 里面奇怪的 pipe 使用
这篇讲的是一个Go语言代理服务器在排查文件描述符时遇到的蹊跷事。 作者日常监控发现，一个TCP连接数两万多的服务，在系统的`/proc/pid/fd`目录下却有五万多个pipe文件描述符，数量远超socket本身。这不符合直觉，于是开始深挖源码。 根因最终指向了Go在Linux下对`net.Conn.readFrom`方法的优化。为了减少用户态内存拷贝，Go会尝试使用`splice`系统调用在内核态直接完成数据传输。而`splice`要求一方必须是管道，因此其实现略显“绕”：每次`readFrom`操作都会先通过`pipe2`创建一对临时管道，再分别进行`splice`操作，用完即关。这完美解释了那些额外pipe的来源。 作者也指出，尽管这种“管道中转”的实现看起来不甚优雅，但在像代理这样`readFrom`生命周期较长的场景中，其性能收益依然可观，因此通常无需优化。文章通过一次具体的生产现象，清晰揭示了Go网络库中一个精巧但隐蔽的内核级优化机制。
CentOS 在线升级 Oracle Linux 的方法
这篇文章讲的是如何将正在运行的 CentOS 系统在线、平滑地升级为 Oracle Linux，尤其适合因 CentOS 停止维护而寻找迁移路径的运维人员。作者从实际操作出发，详细拆解了六个关键步骤：先用 rpm 强制安装 Oracle Linux 的核心发布包与红帽发布包，接着移除原有的 CentOS 相关包与 epel 源，再安装 Oracle Linux 专属的 release 包以完成源切换。随后，系统便可通过 yum 正常更新。对于需要高性能内核的场景，文章最后还提供了可选方案——安装 Oracle 打造的 UEK 内核。整个流程的核心在于巧妙利用 rpm 与 yum 工具，在不重装系统的前提下，将软件仓库彻底切换至 Oracle Linux，从而实现平滑过渡并持续获得安全更新与技术支持。