共 4 篇相关文章
这篇讲的是作者从一个已停更的“the linux kernel fuck count”项目获得灵感，对Linux内核的C、H及汇编源代码进行了一次系统的脏话统计分析。作者按版本号，分别从脏话的绝对数量和代码行的脏话密度两个维度绘制了图表。 数据呈现了一个有趣的趋势：从2.4版本开始，脏话的绝对数量显著攀升。然而，考虑到同期内核代码总量也在激增，折算下来，平均每行代码的“脏话密度”反而是在下降的。文章坦诚地分享了统计方法的局限，比如会将词中包含的词也计入，以及受FreeBSD正则引擎内存泄漏的影响未能优化。 作者最终开源了统计脚本，但也自嘲其代码质量混乱。这本质上是一次用独特视角审视开源社区文化的趣味实践，既看到了开发者情绪的外露，也反映了代码库膨胀带来的稀释效应。
这篇讲的是MySQL 5.6.7-rc版本中Index Condition Pushdown（ICP）特性的源码探索之旅。作者对ICP很感兴趣，于是决定跟踪代码，一探究竟。 文章首先通过对比不同索引结构下的`EXPLAIN`执行计划，直观展示了ICP的效果。在单一字段索引下，查询需要先通过索引找到主键，回表取完整数据，再用其他条件过滤。而创建了`(name, info)`联合索引后，像`info like '%1'`这样的条件，能在索引层就先被过滤掉，从而减少了回表次数，执行计划里也不再出现“Using where”。 最关键的“真相”在代码里。作者一路跟下去，找到了存储引擎层比较WHERE条件的位置，并直接给出了函数调用栈：从`row_search_for_mysql`开始，通过`row_search_idx_cond_check`，最终调用到`innobase_index_cond`执行条件判断。这个调用链清晰地揭示了ICP是如何在InnoDB引擎内部、在通过二级索引读取记录时，提前将不满足条件的数据过滤掉的，避免了不必要的回表操作，这正是该特性的巧妙之处。
这篇讲的是作者从多年正则使用经验出发，提炼出在PHP Web开发（尤其数据抓取与代码分析场景）中极具实战价值的两个关键技巧。文章并非泛泛而谈基础语法，而是直接切入实战痛点。 作者指出，正则表达式在处理复杂文本匹配时，往往需要超越基础模式匹配的思维。例如，在提取HTML片段或分析嵌套代码结构时，常规的贪婪匹配可能失效，而调整为懒惰匹配或巧妙使用“前瞻”与“后顾”断言，则能精准定位目标内容而不破坏上下文。这两个技巧的核心差异在于对“匹配边界”的控制方式，前者处理包含关系的文本更稳健，后者在验证上下文条件时更高效。 文章通过具体场景（如从网页中抓取特定区块的链接）演示了这两个技巧的运用，清晰地展示了不同正则写法带来的效果对比。对于经常需要处理非结构化数据、进行代码静态分析或构建爬虫的开发者而言，掌握这类精细的控制方法，能显著提升正则表达的准确性和健壮性。
这个略带挑衅的问题，其实触及了自由软件世界一段有趣的公案。一位葡萄牙学生没有停留在理论争论，而是直接对 Ubuntu Natty 发行版的软件包动了“手术刀”，试图用数据说话。 他的分析方法很直观：统计整个系统中的代码行数，并绘制了两个饼图来展示占比。结果发现，如果纯粹按代码行数衡量，GNU 核心组件（如 glibc、GCC）加上庞大的用户空间软件（例如桌面环境、办公套件）构成了绝大部分，而 Linux 内核本身的代码占比远低于许多人的直觉预期。这篇分析跳出了“是否应该叫 GNU/Linux”的命名之争，提供了一个具体的、量化的视角。 它让我们看到，在一个典型的 Linux 发行版里，内核虽然是基石，但围绕它的“用户世界”才是代码量的主体。这对于理解 GNU 项目的长期目标——构建一个完全自由的操作系统——以及开源生态中不同组件的实际分量，都提供了非常具象的参考。下次再看到“GNU/Linux”这个名称时，或许能多一分对其背后庞大工程与协作生态的体会。
