tl; dr:

近年のLinuxはそれほどファ●ックではない。最大の"F値"は25で、単一のファイルに集中していた。

もくてき

ファッ●クと言えばLinuxの風物詩と言える時期もあったが、最近は落ちついてきた印象はある。それでも fuck コマンドやメーリングリスト等では言及は有る。

では、それを印象付けるような出来事としては何があったのだろうか。今回、コミットログおよびそのソースコードdiffにおけるF-wordの登場回数を F 値 (F value) と定義し、最もF値の高いコミット(the most F-valued commit)を探してみることにした。

(ソースコードdiffにおける登場回数であるため、F-wordを削除したコミットも高いF値が与えられることに注意する)

全てのコミットを `git show` する

最近シェルスクリプト代わりにCMakeを使っているので今回もCMakeで書いた。

https://github.com/okuoku/cmtask-gitexplode/tree/a88b50a45d5030cc17eb4072b296806636dcf603

基本的には git rev-list HEAD でコミットのリストを出力し、それをcommit hash先頭の3文字 000 - fff に分類して(= 16**3 = 4096分割)ビルドターゲットとし、 ninja に並列実行させている。

Linuxのリポジトリ( https://github.com/torvalds/linux )では、

$ git rev-list HEAD | wc -l
897506

HEADに繋がるコミットは約90万コミットあるようだ。ただし、 このリポジトリにはGit以前のコミットが含まれない事に注意する 。

コミットのF値を求める

コミットのF値は普通にgrepで求められる。

$ git show -p -w HEAD | grep -ci fuck
0

HEAD のF値は当然のごとくゼロ、F-wordを含むソースコードの周辺行を編集したコミット https://github.com/torvalds/linux/commit/4b550488f894c899aa54dc935c8fee47bca2b7df では1となる。

$ git show -p -w 4b550488f894c899aa54dc935c8fee47bca2b7df | grep -ci fuck
1

流石にgrepをそのまま使うと時間が掛かるので、ripgrep( https://github.com/BurntSushi/ripgrep )のような高速grepツールで纏めて求めるのが良い。

$ rg -ci fuck
fa/76/fa7662aad7dc033a61ff2f705c33cbb301d0552d.diff:1
f4/db/f4dbc4c20f05ccf6986b0de429f7552b21a1b362.diff:1
51/53/51533b615e605d86154ec1b4e585c8ca1b0b15b7.diff:1
29/57/2957c9e61ee9c37e7ebf2c8acab03e073fe942fd.diff:2
36/5b/365bff806e9faba000fb4956c7486fbf3a746d96.diff:1
5b/5f/5b5f9560354dc5a3a27ce57a86aec6b98531ee21.diff:1
96/39/963945bf93e46b9bf71a07bf9c78183e0f57733a.diff:1
b2/e1/b2e1b30290539b344cbaff0d9da38012e03aa347.diff:2

F値の高いコミット

LinuxのgitリポジトリでもっともF値が高いコミットは 最初のコミット 、つまり、gitに移行したタイミングのLinuxソースコード自体で、その値は 堂々の56 となった。

https://github.com/torvalds/linux/commit/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2

$ git show -p -w 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | grep -ci fuck
56

流石にこのコミットは殿堂入りとしても良いだろう。

そうでないコミットのtop3は、

何と全部同じファイル arch/mips/pci/ops-bridge.c に対する処理 となっている。このファイルはLinuxの歴史における F-キング と言っても差し支えないだろう。

このファイルはF値24のコミットでファイル pci-ip27.c から分割されて作られた。元のファイルを見ると、このファイルはLinuxがgitで管理され始めた当初からかなりFだったことがわかる。

https://github.com/torvalds/linux/blob/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2/arch/mips/pci/pci-ip27.c#L90 - Gitの最初のコミット時点で既に多くのF-wordを含む

逆に言えば、このように突出したF値を持つファイルはgit移行後には作られていないということになるわけで、少くともソースコードの面ではあまりLinuxはFでは無いと言えるだろう。

ちなみに現時点のLinuxカーネルソースコードで最大のF値を持つコードは drivers/net/ethernet/sun/sunhme.c で、その値は たったの2 となっている。先に挙げた ops-bridge.c の現在のF値はゼロであり、F値 12 のコミットで一掃されている。

https://github.com/torvalds/linux/commit/a44d924c81d43ddffc985aca14aeeaf1abd6dd22

cleaned up language in arch/mips/pci/ops-bridge.c

このコミット自体は2019年に行われているが、2018年にはわかりづらい表現のパッチ提案 https://lkml.org/lkml/2018/12/1/105 が存在し、F値25のコミットでも多少の文法改善を試みている https://github.com/torvalds/linux/commit/686957e71d34beffe2b29cf5fb2e05025972020b 。

かんそう

少くともGit移行後に限れば、ソフトウェアとしてのLinuxカーネルはあまり高いF値を持っていないことがわかった。Git移行以前については調査の余地はあると見られるが、フ●ァックの印象は人間活動によるものと言ってよさそうだ。

F値よりも良い指標が必要かもしれない。例えば、F値をコミット毎に定義するよりも、F-wordの生存期間といった別の指標が考えられる。