技術書典4に出す本の宣伝

はじめに

明日開催される技術書典4に参加いたします。第二回に初めて参加してから連続して3回目の参加です。

techbookfest.org

以前はサイボウズのご厚意でサイボウズブースを間借りしていましたが、今回は独立してwindholeブースです*1。場所は「け51」です。

techbookfest.org

今回は次の5冊を頒布いたします。

上から4冊は同人誌で、いまのところ一般販売はしていません*2。一番下は同人誌ではなく技術評論社から出て書店に並んでいる本ですが、ついでに売ります。本エントリではそれぞれについてコメントを付けて宣伝しておきます。

図解でわかるMeltdown(新刊。紙&電子)

f:id:satoru_takeuchi:20180422071409j:plain

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

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

Btrfsの薄い本(既刊。紙&電子)

f:id:satoru_takeuchi:20180422071406j:plain

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

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

カーネルモジュール作成で学ぶLinuxカーネル開発の基礎(既刊。電子のみ)

f:id:satoru_takeuchi:20180422071359j:plain

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

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

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

f:id:satoru_takeuchi:20180422071402j:plain

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

Linuxのしくみ

これについては技術評論社のWebサイトにある紹介ページをごらんください。

gihyo.jp

おわりに

いかがでしたでしょうか。1冊でも興味のあるかたはお手数ですが当日ブースに来ていただければと思います。試読もできるようになっていますのでお気軽にお立ち寄りください。紙の本は数に限りがあるので「絶対に電子版は嫌」というかたは早めにお越しください。

*1:私だけでなく@uchan_nosさんも3冊出します

*2:そのうちWebで電子版を売るかもしれません

Ubuntu 16.04のVagrantでpublic Vagrant boxにアクセスできなくなった問題(解決編)

下記の過去記事の解決編です。

satoru-takeuchi.hatenablog.com

現状を確認したくて久しぶりにこの問題の再現試験をしたところ、なにもworkaroundを使わずに期待した動作をしました。しかしupstreamのissueはcloseしていませんでした。

vagrant box update - Fails with 404 Not Found error · Issue #9442 · hashicorp/vagrant · GitHub

ではdistroで修正したのかなと思い、Ubuntu 16.04のvagrantパッケージのchangelogを見ると、次のような項目を見つけました。

...
vagrant (1.8.1+dfsg-1ubuntu0.1) xenial; urgency=medium

  * debian/patches/0013-Switch-to-vagrantcloud.patch: Switch from Atlas
    to Vagrant Cloud.  Closes LP: #1747426.

 -- Daniel Watkins <daniel.watkins@canonical.com>  Mon, 05 Feb 2018 18:00:06 -0500
...

これに対応するUbuntuのissueは次の通り。

Bug #1747426 “Vagrant <2.x can no longer fetch box metadata from...” : Bugs : cloud-images

Ubuntuのひとたち、ありがとう。

出版物の原稿の管理方法について

わたしは自分が作成したソフトウェアのソースコードをすべてgithubにおいてOSSとして公開しています。これは自分がプログラマとして生きていられるのは先人が作ったOSSのおかげという思いがあるから、自分も先人と同じようにしようという考えからです1ソースコード以外にもいくつかのドキュメントもgithubやqiita上で公開しています。

qiita.com

これらは利害関係者が自分しかいない、無償で見てもらって誰も困らない記事や同人誌の原稿です。

最近は書店で売る書籍も書くようになったので、githubに課金して($7/month)、本の原稿をプライベートリポジトリとして管理するようにしました。ソースコードと同様に原稿を公開するという手もあるのですが2、色々考えた結果、プライベートリポジトリで管理することにしました。

  • できれば一人で書きたい。執筆方針は執筆開始時点のものから変えたくないし、それを貢献してくれる意図がある人に逐次わかってもらうコストをかけられない
  • ソースコードと違って、公開したいという強いこだわりが無い
  • なるべく多くの人に読んでもらいたいという思いはあるが、これまで溜めてきた知見を導入して膨大な手間をかけて書いたものなので、対価は得たい
  • 原稿を公開することが売り上げに良い影響をもたらすのか否かという判断材料を持っていない。売れなくなると自分だけではなくて出版社を含めた利害関係者すべてが困る

では読者の意見は無視するのかというとそうではなくて、たとえば最近書いた本ですと、twitterなどから直接いただいたりエゴサしたりして集めたりしたご意見をまとめて共有のgoogle spreadsheetとして公開しています。公式サイトのフォームからもご意見を受け付けています。

とりあえずこのように運用して、困ったことがあればやりかたを変えていきます。


  1. と、偉そうなことを言っているものの、今のところ世界中で使われているような大物は無いですが…

  2. 最近だと江添さんが書かれた江添亮の詳説C++17が有名です

拙著"[試して理解]Linuxのしくみ "が発売されました

わたしの初めての著書が本日出版されました。

gihyo.jp

副題の通り、実験と図解によってOSとハードウェアの基礎知識について学ぶのが本書の目的です。難解な理論の話やカーネルソースコードは一切出てこないこと、および、サンプルソースの中身を見なくても読み進められることによって、プログラマ以外のかたがたにも理解できるようにしています。

本書を執筆しようとした動機は次のようなものです。

  • あまねくITエンジニアはOSやハードウェアについて少しばかりの知識があるだけでコンピュータシステム全体への理解が一気に高まると思っている
  • OSについての既存の書籍は開発者向けの理論や実装詳細の解説を主としているものがほとんどなため、OS開発者以外にとってはしきいが高い
  • わかった気にさせて終わるのではなく、実際に読者自身が実験によって知識を体得できるようなものがいい
  • 無いなら自分で書こう

このコンセプトを実現できたかどうかは読者の審判をあおぎたいと思います。もしよろしければ書店で本書を手にとって、一瞥してみて、よさそうだと思えば買っていただけたらなと思います。

最後になりましたが、本書の編集を担当してくれた風穴江さんと技術評論社の細谷謙吾さんに深く感謝いたします。おふたりの協力がなければこの本の完成はありえなかったでしょう。それに加えて推薦文を書いていただいた小崎資広さん、発売前に本書をレビューしていただいた皆さまにも感謝いたします。

Ubuntu 16.04のVagrantでpublic Vagrant boxにアクセスできなくなった問題

本日、普段使っているpublic Vagrant boxに対してvagrant box addを実行したところ、404 not foundになってしまいました。

$ vagrant --version
Vagrant 1.8.1
$ vagrant box add --provider libvirt elastic/ubuntu-16.04-x86_64
The box 'elastic/ubuntu-16.04-x86_64' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:

URL: ["https://atlas.hashicorp.com/elastic/ubuntu-16.04-x86_64"]
Error: The requested URL returned error: 404 Not Found
$ 

比較的マイナーなboxだったので、作者が提供を辞めてしまったのかなと思ったものの、ちゃんとサイトはありました。

Vagrant box elastic/ubuntu-16.04-x86_64 - Vagrant Cloud

もっとメジャーなUbuntu公式イメージをaddしようとしても同じ問題が発生しました。

$ vagrant box add --provider libvirt ubuntu/trusty64
The box 'ubuntu/trusty64' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:

URL: ["https://atlas.hashicorp.com/ubuntu/trusty64"]
Error: The requested URL returned error: 404 Not Found
$ 

先月同じコマンドを実行したときには動いていたはずなので、なんかおかしいなあと思って色々調べていたら、Vagrantgithubに、つい二日前に登録された怪しいissueを見つけました。

vagrant box update - Fails with 404 Not Found error · Issue #9442 · hashicorp/vagrant · GitHub

issueはvagrant box updateに関するものでしたが、わたしのケースとすごく似ています。斜め読みしたところ、問題はpublic Vagrant BoxのURLとしてatlas.hashicorp.comを受け付けなくなって、vagrantcloud.comを指定しなくてはならなくなった、ということのようです。どうやら、すくなくともUbuntu16.04は全部影響を受けるらしい。

issueの中に、次のようなworkarundを見つけたので、試してみることにしました。

vagrant box update - Fails with 404 Not Found error · Issue #9442 · hashicorp/vagrant · GitHub

とりあえず、自分の環境でこれと同じ問題が出るか、および、workaroundを使って問題が解決するかを確かめました。Vagrantfileの変更が必要なので、とりあえずは当該ファイルを使わないvagrant box addではなく、`vagrant initを使いました。

  • workaround適用前
$ vagrant init elastic/ubuntu-16.04-x86_64
$ vagrant up --provider=libvirt
Bringing machine 'default' up with 'libvirt' provider...
==> default: Box 'elastic/ubuntu-16.04-x86_64' could not be found. Attempting to find and install...
    default: Box Provider: libvirt
    default: Box Version: >= 0
The box 'elastic/ubuntu-16.04-x86_64' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:

URL: ["https://atlas.hashicorp.com/elastic/ubuntu-16.04-x86_64"]
Error: The requested URL returned error: 404 Not Found
$

期待通り(?)失敗しました。

  • workaround適用後(initの後にVagrantfileを編集)
$ vagrant up --provider=libvirt
Bringing machine 'default' up with 'libvirt' provider...
==> default: Box 'elastic/ubuntu-16.04-x86_64' could not be found. Attempting to find and install...
    default: Box Provider: libvirt
    default: Box Version: >= 0
==> default: Loading metadata for box 'elastic/ubuntu-16.04-x86_64'
    default: URL: https://vagrantcloud.com/elastic/ubuntu-16.04-x86_64
==> default: Adding box 'elastic/ubuntu-16.04-x86_64' (v20171130.0.0) for provider: libvirt
    default: Downloading: https://vagrantcloud.com/elastic/boxes/ubuntu-16.04-x86_64/versions/20171130.0.0/providers/libvirt.box
...
$ 

成功しました。続いて、上記コマンドの実行結果から得たboxファイルをもとにvagrant box addが成功するかを試しました。

$ vagrant box add elastic/ubuntu-16.04-x86_64 https://vagrantcloud.com/elastic/boxes/ubuntu-16.04-x86_64/versions/201711
30.0.0/providers/libvirt.box
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'elastic/ubuntu-16.04-x86_64' (v0) for provider:
    box: Downloading: https://vagrantcloud.com/elastic/boxes/ubuntu-16.04-x86_64/versions/20171130.0.0/providers/libvirt.box
...
$ 

こちらも成功しました。私が遭遇した問題は上記issueと同根と見てよさそうです。

ここから最終的にはvagrant box add --provider libvirt elastic/ubuntu-16.04-x86_64を正しく動くようにしたいのですが、上記の方法が今のわたしにとってはworkaroundとして十分なので、とりあえずはこれで放置。後はUbuntuで修正されるのを待ちます。

防水音楽プレイヤーを買った

スポーツクラブで使う防水音楽プレイヤーを探していたところ、友人に教えてもらったウォークマンを買いました。

欲しかった理由は運動、とくにプールにおいて飽きるのを防ぎたかったこと、および、スタジオの音や人の話し声を遮断することです。今のところ、その目的は見事に果たせています。素晴らしいです。買ったのは去年なのですが、去年で一番良い買い物だったと思います。

もともとはスポーツクラブでのみ使う予定だったのですが、今では、どこでもこれしか使わなくなってしまいました。一番大きな理由は、これまではイヤホンとプレイヤー本体を別々に用意しなくてはいけなかったのが、これだと小型軽量な一台で2つの役割を果たしてくれることです。それに加えて外出中ずっと使っていられるほどバッテリの持ちが良いこと、および、BTじゃないので音楽プレイヤーとしてのスマホのバッテリを消費しないことも評価できます。

改めて、買ってよかった。

Ryzenを積んだマシンで発生した新たな問題とその解決

Ryzenを積んだマシンでgccのビルド負荷をかけるとランダムにSIGSEGVが発生して失敗するという問題に去年ハマりました。これについては問題ない石に取り替えてもらって、解決しました。

satoru-takeuchi.hatenablog.com

ところがその後、マシンが2,3日に一度ハングするという事象が新たに発生して、悩まされておりました。不思議なことに、この事象はSEGVが発生していた石では起きていませんでした。

実はこの事象は上記の記事においては言及していなかったのですが、そこかしこで似たような報告がされていました。報告されている対策はいろいろあって、詳細は下記meihongさんの調査結果が詳しいです。

damelog.com

私の場合は、ここで紹介されていたスクリプトを使ってC6 stateをdisableにしたところ、問題が発生しなくなりました。カーネルのRCUの設定は変更していません。

github.com

これについてはハードウェアが悪いのかLinuxが悪いのか全然わかりませんが、あまり気にしないことにします。理由は次の通り。

  • 大きな影響なしに回避できる
  • SEGV現象に比べると調査しづらい。発生確率が低い上に発生するとマシンがハングする
  • 去年ほど時間に余裕が無いし、もう疲れた

色々とトラブルが耐えない石ですが*1、安価でビルドが速いので、これからも数年は頑張ってもらう予定です。

*1:また、今回発生した問題においては犯人が全く不明ですが