「殷 - 中国最古の王朝」

中国最古の王朝である殷について、史記などの後代の文献資料ではなく殷代の甲骨文字をもとに解き明かした本です。限られた情報をもとに当時の様子を推測するさまがとてもよかったです。ここに書いている説がどれだけ真実なのか、過去を旅したくなりました。

[宣伝] 既刊同人技術書をDL販売することになりました&技術書典5に新刊を出す予定です

既刊のDL販売について

これまで筆者はフリーの編集者である風穴江さんと一緒に技術書典において"windhole"名義で同人技術書を販売してきました。その際、毎回のように「行き損ねた/買い損ねたのでDL販売をしてほしい」という声をたくさんいただいてきました。これを受けて、このたびDLMarketにおいて既刊4冊の電子版(後述の「おしながき」を参照)をDL販売することになりました。興味のあるかたは是非お買い求めください。DL販売の利点を活かして、適宜読者のみなさまのご意見の反映を含めた加筆修正をした上で再DLできるようにする見込みです。

今後は技術書典とDLMarketを以下のように使い分けていく予定です。

  • 技術書典: 新刊の紙版および電子書籍を先行販売。既刊についても販売。購入時の割引やノベルティのプレゼントも検討中
  • 本記事で紹介する既刊、および技術書典で販売してからある程度経過した新刊の電子版を販売

おしながき*1

図解でわかるMeltdown

ebook2.dlmarket.jp

2018年の年明け早々世間を騒がせたMeltdownという脆弱性についての解説書です。この脆弱性は前提知識さえあれば理解は決して難しくありません。しかし必要な前提知識の数が多い、かつそれぞれOSカーネル以下あたりの低レイヤのものが中心なため、一般的なソフトウェア開発者にとってはなかなか敷居が高いのが実情です。

本書はレイヤを問わずあらゆるソフトウェア開発者のためにMeltdownおよびその理解に必要な前提知識をひっくるめて図解しています。「この脆弱性について興味はあったもののなんだか難しそうなので手付かずだった。最短距離で手っ取り早く理解したい!」というかたにおすすめです。

Btrfsの薄い本

ebook2.dlmarket.jp

BtrfsというLinuxファイルシステムについての解説書です。Linuxファイルシステムといえばext4やXFSが有名です。Btrfsはこれら2つと同様の使い方もできますが、通常「Linuxファイルシステム」と言われて普通の人が思いつくものとは大きく異なる豊富な機能を備えています。Btrfsはまた多くのLinuxディストリビューションで実際にサポートされています。

本書はこのファイルシステムが一体どういうものなのかという概要を書くと共に、それを読んでさらに興味が出たかたむけに使い方、トラブルシューティングから歴史までを説明しています。ファイルシステムについて新しい知識を得たいかた、刺激が欲しいかたにお勧めです。きっと「こんなことができるの?」と思うはずです。

近いうちに対象カーネルバージョンを更新すると共に新圧縮アルゴリズムzstd、および一般ユーザによるスナップショット操作についての記述を追加予定です。

カーネルモジュール作成で学ぶLinuxカーネル開発の基礎

ebook2.dlmarket.jp

Linuxカーネルを自分で改変するためには覚えておかなければならない作法があります。これらの作法は一旦わかってしまえば大したことはないのですが、やたらと数が多いので参入障壁が高いです。本書ではそのお作法をカーネルモジュールの作成という方法を通して学びます。まずは単純な機能を追加してから次第に複雑な機能を作り込んでゆくというインクリメンタルな説明方法になっているので、カーネルになじみのないかたにもとっつきやすくなっています。お作法のうちの大して重要ではないところについては自動化して飛ばすツールを紹介しているのもポイントです。

Linuxカーネルをいじってみたいけど、何をすればいいのかさっぱりわからない」というかたにおすすめです。

近いうちに対象OSをUbuntu 16.04からUbuntu 18.04に更新予定です。

Linuxカーネルで学ぶC言語マクロテクニック(既刊。電子のみ)

ebook2.dlmarket.jp

Linuxカーネルのソースを読むにあたっての大きな障壁のひとつがトリッキーなC言語マクロたちです。本書はこれらのうちの多く使われていて、かつ初見殺しなものを抜粋して解説しています。これからLinuxカーネルソースを見てみたいというかた、およびC言語マクロ黒魔術の世界をのぞいてみたいかたにおすすめです。

近いうちに内容を追加する予定です。

技術書典5の新刊

10/8に開催される技術書典において新刊を出す予定です。

techbookfest.org

タイトルは「Ryzen SEGV Battle」です。この本は2017年に発売されたAMDのプロセッサRyzenの一部に存在した問題を、筆者を含む同問題に遭遇した人たちが一丸となって解決した話について物語調にまとめた本です。純粋に読み物として楽しんでいただいてもいいですし、トラブルシューティングの参考に使っていただくこともできるかと思います。カーネルやハードウェアなどの低レイヤの用語がたくさん出てきますが、適宜解説をつける予定です。乞うご期待。

おわりに

DL販売の諸手続きについては私は何もやっていなくて風穴さんがすべてやってくれました。この場を借りて御礼申し上げます。

*1:

「リーダブルコード」を読んだ

読みやすいコードを書くにはどうすればよいかというテーマを扱った本です。奇をてらったものはなく、順当なことが書いてありました。人に見られることを前提としたコードを書いたことがないかたは読んでみるとよいかもしれません。

本書は一度ざっと読んだ上でコーディング経験を積んでしらばくしてからまた読み返して…というのを繰り返して自分なりのスタイルを身につけるという使い方がよさそうです。なぜかというと、サンプルコードが非常に短いものばかりなこともあってコーディング経験が浅い人が本書をいきなり読んでも多分ピンと来ないからです。もう一つ言うと、人によって「リーダブル」の定義は違うので、単に本書の内容をうのみにするのではなく、筆者の考えかたをもとに自分のスタイルを身につけるとよいと思います。自分以外の誰かが書いたコードを読みながら、それがこの本、あるいは自分から見て「リーダブル」かどうか、そうでないとしたらどうすれば「リーダブル」になるのかを考えてみるのも面白いかもしれません。

最後に、本書そのものの内容ではないのですが、「これから書くコードは全部リーダブルにせねばならない」などという考えにとらわれるとプログラミングがつまらなくなってしまうので、楽しくプログラミングをしつつ徐々によいコードを書けるようにしていけばいいと思います。

「OSSライセンスの教科書」を読んだ

タイトル通りオープンソースソフトウェア(Open Source Software, OSS)のライセンスについて扱った本です。難解なことを筆者の経験を踏まえて平易に解説してくれているので、この手のことを知りたいと相談された場合は「これを読んでみてください」と勧められる本でした。

OSSのライセンスについての知識は近年のソフトウェア開発者には避けては通れません。しかしこれを十分に理解している開発者は多くはありませんし、(とくに「コードだけ書いていたい」というタイプの人には)それほど興味をひく題材ではないというのが実情ではないでしょうか。この状況をなんとかしようと長年OSSに関わってこられた筆者が一石を投じたのが本書です(多分)。筆者が技術者の目線だけ解説するだけではなく、弁護士のかたの監修を受けることによって法律家の目線からも解説しているという点で本書は貴重です。私はこのような本を少なくとも日本語では見たことがありません。

筆者のバックグラウンドが組み込みソフトウェア業界ということもあり、本書を読んで一番嬉しいのはおそらく組み込みソフトウェアエンジニアでしょう。組み込みソフトウェア(が入ったハードウェア)は不特定多数のユーザに大量に頒布されるという特徴があるため、OSSライセンスにまつわる問題にもっとも遭遇しやすいもののひとつと言えるため、OSSあるいはそのライセンスに不慣れな開発者には本書が大きな助けになるでしょう。その他の業界の開発者にとっても適宜内容を読みかえれば十分役に立つ内容ですし、本書を読み終えた後にはその読みかえができる材料がそろっていることでしょう。それに加えて開発者にとっては「ライブラリ」のような当たり前の用語についても平易に解説しているため、ソフトウェア開発者から相談を受けた法律家にとっても有用だと思います。

本書は各種OSSライセンスについて無味乾燥に解説するだけではありません。第一に、各種ライセンスを「どういう価値観を持った人々が」「どういう意図で作ったのか」という文面だけからは読み取れない前提知識を提供してくれています。第二に、ライセンスについて学んだ上で「どうすればライセンスにまつわる問題を防げるのか」「どうすればOSS、およびOSSコミュニティとうまくやっていけるのか」ということも解説してくれています。ソースコードのforkにまつわる話やソフトウェアのサプライチェーンをすべて考慮しなければいけないという生々しい話は現場のことを知らなければ書けない内容なので、一読の価値があります((と同時に筆者のこれまでの苦労がしのばれます:-)))。

読者が判断に迷うであろう要所要所について「これについては法律家に相談してください」「これについては著作者の確認をとってください」という次の一手を示してくれているのもよいと思いました。一見すると「相談してじゃなくて答えを書いてよ、頼りないなあ」と思うかもしれませんが、一口では言えないものを「これはこうです」と筆者が勝手な判断で書いてしまうと後で困るのは読者なので、これはこういう書き方にするよりないと私は思います。

細かいところでは次のようにひっかかるところもありましたが、全体的にはとてもよい本だったと思います。

  • OSI認定OSSライセンスの下で頒布されるOSSと本書が定めるOSSを区別している理由(JSONライセンスの解釈のくだり)がわかりにくかった
  • 第III部あたりはOSS(とくにバザール型開発のもの)がそれ以外のものに比べて好ましいものとする筆者の熱のこもった考え方が強く前に出ており、若干話が飛躍しているように見えた

「エンジニアの知的生産術」を読んだ

もともとなんとなく気になっていたのと読後感がついったに沢山流れてきたのをきっかけに読んでみました。

全体としてなるほどと思う新規の知識がいくつか得られたので満足できました。「著者の場合はこうしたらうまくいきました。以上」ではなく、著者自身による調査、および、誰かが調査した結果をまとめた書籍や学術論文を明記した上で自分の見解も述べているのが気に入りました*1。まったく新規の知識を得られただけではなく、自分がもやもや「こうではないか」と思っていた物事に、ある程度理由付けをしてくれていたのもよかったです。

細かいところで若干ひっかかったのは「エンジニアの」というタイトルです。私がこれを見た際の印象は「エンジニア"のための"本なんだな」でした。しかし実際そうではなくもっと一般的な内容を扱っていました。もし私と同じ解釈をした人がいて、かつ、「自分はエンジニアではないから対象読者ではないんだ」と考える人がいるならもったいない話だと思いました。本当のところは筆者に効いてみないとわかりませんが、「エンジニア"による"知的生産術」のほうがしっくりきました。

*1:当たり前と言えば当たり前なのですが、こういう本はそれほどないです

WSLのファイルシステムアクセス速度をマシにしようとしたが失敗した話

背景

WSLはファイルシステムアクセス速度がめちゃくちゃ遅い((わたしのマシンでは数 [MB/s]くらい)のをなんとかしたかった。

やったこと

WSLにおいて通常のファイルシステム上、tmpfs上、およびWindows上で作ったメモリ上に構築したファイルシステム上でlinux-4.18.5.tar.xzの展開したときの所要時間をとった。

結論

残念ながらどれも通常のファイルシステムを使う場合と大して変わらず。

測定環境

  • OS: WIndows 10 Home, version 1803, build 17134.228
  • WSL: Ubuntu 16.04

測定コマンド

$ time tar xf linux-4.18.5.tar.xz

測定結果と考察

まずは通常のファイルシステムとtmpfsについて。

real    10m59.151s
user    0m19.984s
sys 1m28.875s
  • tmpfs
real    10m37.472s
user    0m21.031s
sys     1m22.344s

処理中にWindowsのリソースモニタを見ると、どちらももwriteは5 [MB/s]くらいだったので、WSLのtmpfsは、実は裏側にはメモリではなく何らかのファイルがいる、および、そいつへの書き込み速度はWSL上の通常のファイルと同等なためtmpfsを使っても何も嬉しくない、という推測ができる。WSLはLinuxのエミュレーションに過ぎないので文句は言えないんだけど、かなしい。

続いてWindowsの機能でメモリ上にファイルシステムを作って、その上で上記のソースを展開することにした。WIndowsにはメモリ上に仮想ディスクを作れるImDiskというツールがあるので、これを利用した。管理者権限でこのツールを使えば、たとえば次のように2GBのサイズを持つ仮想ディスクをRドライブとして作成できる。

C:\WINDOWS\system32>imdisk -a -m r: -s 2G
Creating device...
Created device 2: R: -> Image in memory
Notifying applications...
Done.

C:\WINDOWS\system32>

後はこいつをNTFSでフォーマットしてWSLから/mnt/rからアクセスすればよい。

Rドライブ上でソースを展開した場合の所要時間は次の通り。

real    8m12.778s
user    0m18.859s
sys     0m52.031s

ちょっとは速くなったけど大して変わらない。処理中のwrite I/Oは200 [KB/s]くらいだったことより、Rへのアクセス時にはストレージへのアクセスはほとんどしていないようだ。つまりファイルシステムの裏にあるものがストレージデバイスだろうとメモリだろうと、そいつらにアクセスする以前のファイルシステムエミュレーションレイヤがめちゃくちゃ遅いということだろうか。かなしい(2回目)。

最後にImDIskで作った仮想ディスクを削除して終わり。

C:\WINDOWS\system32>imdisk -d -m r:
Notifying applications...
Flushing file buffers...
Locking volume...
Dismounting filesystem...
Removing device...
Removing mountpoint...
Done.

C:\WINDOWS\system32>