wikiと掲示板を閉鎖します

テーマ:
サーバ見直しを行っているのですが,以下のページがほとんど利用されていないので閉鎖しようかと思っています.
1週間くらいで閉鎖しますので,必要コンテンツなどあるかたはダウンロードしておいてください.

KOZOSのwikiのページ
http://wiki.kozos.jp/

「熱血!アセンブラ入門」の掲示板
http://bbs.kozos.jp/

AD
OSC東京2015春のLTで話した「ハロー・ワールド入門」ですが,「ハロー "Hello, World"」というタイトルで本日発刊されました.

Amazonのサイト
秀和システムのサイト
書籍サポートページ





内容はLTでしゃべったとおりで,以下のようなわずか7行のハロー・ワールドのプログラムをとことん解析する,というものです.

#include <stdio.h>

int main(int argc, char *argv[])
{
printf("Hello World! %d %s\n", argc, argv[0]);
return 0;
}

■ 表紙について

タイトルも表紙もなんだか爽やかな感じで,技術書とは思えない.笑
旅行のガイドブックか何かのようだ.

電車の中とかでフツーに読んでても違和感無い!?

■ 対象とする読者

対象読者は以下のようなかたです.

入門書でハロー・ワールドを説明されたとき,printf()の先はどうなっているのか? とかmain()が呼び出される前には何が行われているのか? とかmain()からreturnしたらどこに返るのか? といった疑問を持ったが,それらの疑問はそのまま棚上げにされ,放置されている.改めて知りたい,というひと.

動的解析や静的解析,Linuxカーネルやライブラリなどのコードリーディングというものに興味があるしやってみたいが,どこから手をつけたらいいかわからない,最初の一歩がいまいち踏み出せない,というかた.
(とにかく手を動かす系の本なので,初心者もとりあえず手を動かして,解析作業やコードリーディングを体験することができます)

プログラムがどのように動いているのか,OSは何をしているのか,といったことを知りたい人.とくに,机上の理論や図を使った抽象的な説明でなく,実際の現物ベースで知りたい人./usr/includeにあるヘッダファイルや/usr/libにあるライブラリが,誰によって提供されどのようにしてシステムが構築されているのかなどを知りたい人.

大学や専門学校でのOS系・解析系の授業の教科書として.
技術的な内容もいろいろ含んでいますし,OSの全体構成(カーネルとライブラリとアプリケーションの関係)について理解できるので,OSの授業とかにいいんじゃないかと思います.
大学等の講義で使うことを意識して,全12章にしてあります.(1回の講義で1章のペースで,半期で終わる感じ)

■ 書いた経緯

上のようなハロー・ワールドについてA4用紙で5枚のレポートを書け,という課題が大学かどこかで出たことがあるという話を聞いたことがあります.

要するに,単なる7行のプログラムだとしても,それくらい奥が深いということなのですが,だったら1冊の本が書けるんじゃないかなあと思って書いてみたものです.

■ 内容について

内容ですが,まずハロー・ワールドの実行ファイルを動的解析することでprintf()の処理の先を追い,文字出力が行われる瞬間(システムコール命令の発行)をとらえます.
次にLinuxカーネルのソースコードを見て,writeシステムコールがどのように処理されるのかを探ります.
さらに標準Cライブラリのソースコードを見て,システムコール命令の発行がどのように行われているのかを確認します.

さらにmain()が呼び出される前のスタートアップの処理を探って,main()からreturnする先の処理を探ります.exit()で何が行われているのかなどを探ります.
「main()の前にはスタートアップという処理がある」という話を漠然と聞いたことがある,という人はいるかと思います.しかしそのスタートアップを実際に見たことがあるという人は少ないですし,説明してある書籍もあまり無いです.このあたり,詳しく調べて説明しています.

あとはstdio.hなどのヘッダファイルがどこにあって誰によって提供されているのかとか,OSの仕事は何なのかとか,標準Cライブラリは誰によって提供されていて,いわゆるLinuxディストリビューションと呼ばれているシステムはどのように構築されているのかとか(GNU/Linuxの話とか),実行ファイルを解析してみるとか,最適化についてとか可変長引数の実現方法などについても説明しています.

ハロー・ワールドについて,かなりお腹いっぱいになる感じだと思います.

他にもシステムコール処理をLinuxカーネルとFreeBSDカーネルで比較したり,x86とARMで比較したりといったクロスプラットホームの話題もあります.(このあたりが私らしいところか)

秀和システムの書籍のサイトで,目次を確認することができます.
興味のあるかたは,ぜひ目次を見てみてください.

■ 発刊されて

内容的にはなかなかコアな内容で,類書の無い面白い感じに仕上ったかと思います.

理論だけの説明でなく実際に手を動かしてみて,現物を見てみた後で理論的な説明をする,調べた結果だけを見せるのではなく調べかたをちゃんと見せる,というのがだいたい私が書きたい書き方なのですが,バッチリそういう感じに仕上りました.

あと私の書き方の特徴なのですが,同じことを何箇所かで説明していたりします.(本書の場合は,システムコールラッパーの役割とかFreeBSDのソースコード配置などがそう)
これはまず一度説明して,いろいろ理解が進んだところでさらにもう一度説明することで理解を深める,というように書きたいからです.
この手の勉強は義務教育のようにカリキュラムがバッチリ決まっていて順番通りに進めていけばいい,というものではなく,Aを説明するためにはBの知識が必要で,でもBを説明するためにはAの知識が必要,ということはよくあります.なので,同じことを何度も説明するというのは,個人的には悪いことだとは思わないので,そういうふうに私は本を書いています.
なので読む人によっては「くどい」と感じられたりしますが,逆に「何度も説明してくれてありがたい」という意見をいただくこともあります.

あと表紙は爽やかでお気に入りですね.

AD
来週の週末に開催されるオープンソースカンファレンスに出展します.
場所は多摩の明星大学です.

http://ospn.jp/

セミナーは金曜に,熱血アセンブラ入門を題材にしてアセンブラ関連のものをやります.
ちなみに各種アーキのアセンブラなので,x86特定ではありません.

ライトニングトークはハロー・ワールド入門という新ネタでやらさせていただく予定です.

AD
今年はずいぶん本を出すことができたなーと思う.技術書を10冊書くことがとりあえずの目標だったのだけど,今年になんとか達成できた.

とはいっても共著もあるし(共著者のかたがた,ありがとうございました),たまっていたものが一気に出たというところもあるので,まあそれほど山のように書いた,というわけでも無い.いや書いたか.笑

とくに今年出した本は,ちょっと斜め上を行っている内容のものというか,自分ならではの内容のものを出せたなーとも思うところがあって,まあよかったかなあと.

僕自身は面白い技術書をもっと書きたいと思っていて,これは誰も書かないだろうと自分が思えるような技術書を書きたい.せっかく書くならば,似たような本を増やしてもつまんないし,今までに無いような本を書きたい,という感じだ.

「面白い技術書」(笑いとして面白い,というのではなく,興味深く読める,という意味で)というのがもっとあったほうがいいし,ぜひそういう「他に類がない,面白い技術書」がもっと増えるといいと思う.(なので,自分も書く)

例えば熱血!アセンブラ入門とかは,アセンブラの本は他にもあるけれど,あのような「データシートとか無視して,とにかく手を動かして有りものベースでパッと読んでみる」という方向性で書いてある本は少ないだろう.

アセンブラの本ってたいていは,命令一覧やCPUのデータシートとにらめっこするような方向性になるし,アセンブラ学ぶならきちんとデータシート読むべきであって,それをやらずにアセンブラ読むなんて信じられん!という人もいることだろう.

でも別にそれでいいと思うんです.それが良いのか悪いのかは読者のかたが判断して選ぶことであって僕が決めることではないし,勉強のしかたなんて人それぞれで押しつけるようなものではないので,「良いか悪いか」ではなく「その人に向くか向かないか」の問題だ.少なくともああいう方向性のアセンブラ本があれば,それはそれで学習しやすいという人もいることだろう.
(少なくとも10年前にあの本があれば自分はとびついていたし,10年前の自分が喉から手が出るほど切望していた本を書くというのが,自分が本を書くときのひとつの基準ではある)

なのでいろんな方向性の本が増えることは,読者の選択肢が広がるという点で有益かなあと思う.本屋の書棚が似たような本ばっかりになってもしょうがないようにも思うし.

バイナリで遊ぼう!やアセンブラ短歌とかも,そんな感じだ.

まーこういうちょっとズレた感じの本(笑)は賛否両論あることだろうけど,それが自分に向かないならばそれは読まなければいいだけであって,どんな本でも「本が有る」というだけで,それは非常に有益なことだと個人的には思っている.

新しいことを勉強しようとしたときに,「そもそもその分野の本が無い」ということはよくあることだ.だから自分的には,本が有るだけでもありがたいと痛切に思うことがよくある.とくにその分野に関して唯一の本とかであればなおさらで,たとえその本が読みづらいものだとしても,有るだけでもありがたいものだ.

まーそんな感じで今年はバイナリ系の本を多く出したわけなのだけど,なんでぼく自身が最近こんなにバイナリ系の本ばっかし出しているかというと,自分が勉強したいから,というのが大きい.本を出すことで,実は一番勉強になるのは,筆者自身だ.

まあ勉強っていうのは,技術者である限り一生続くものだよね.(別に技術者に限らないかもしれないけど)

「すぐに役に立つ勉強は何か?」的な話を聞くことがあるが,今後技術者としてずっとやっていくことを考えるならば,自分でやる勉強というのは,1年とか3年とかいう短いレンジではなく,10年とか20年とかいうレンジで考えたほうがいいように思う.
(仕事としてやる勉強は短いレンジでいいと思うが,逆に言えばそういう勉強は仕事としてやればいいので,自分でやる勉強は違ったレンジで考えたほうがいい)

なので「10年,20年後に役に立つ知識は何か?」という視点で考えたほうがいいと思っているのだが,ところが経験上,「10年後にはこれが来る」と広く言われている技術が実際には全然来ない,ということはよくある(笑).

なのでぼく自身は,そういう「この先はこれが来る」という話はあまり意識していなくて,それよりも基礎技術としてのコンピュータ・アーキテクチャとか,そういうのに興味が有る.解析とかも,便利なツールに頼らずにバイナリエディタ開いて自力で手を動かしての解析とか,そういうのに興味が有るわけだ.

いまさらアセンブラやコンピュータ・アーキテクチャを勉強したって意味は無い,と言われることはよくあるが,自分でやる勉強が役に立つかどうかを1年とかの短いレンジで考えるのは,ちょっと危険かなあとも思う.技術者人生は何十年も続くわけなのに,1年とかで結果を求めるような勉強方法になってしまうからだ.
(でもまあそれをべつに否定するわけではないです.勉強はモチベーションが一番大切と思うので,本人がそれを勉強したいならばそれをやるのが一番いいと思うので)

そんなわけで僕自身はそういう「10年後にはこれが来る」とか言われている流行りモノをことを勉強するのではなく,やっぱり基礎技術をきちんと学んでおくことが一番つぶしが効いて10年後にも役立つことだと思っている.10年後に何が流行ってるかなんてわからないから,結局のところ基礎知識があって地力があるのが一番強い,ということだ.
アセンブラ短歌本とかバイナリで遊ぼうとか熱血アセンブラとかは,そんな考えで書きました.

まーとはいってもこれは僕自身はそう思うからそうしているというだけで,別にそうしたほうがいいよとかおすすめするようなわけではないです.

しかし,書きたい本はまだ山ほどあるんだよなあ.書く速度よりも,こんな本書きたいなーと思って書きたい本のストックが増える速度のほうが速いのが悩みどころではある.

来年も可能な限り書いて,書きたい本のストックを極力減らしていきたいところだ.

ちょっと時間ができたので,たまには最近思うことでも書こう.

低レイヤーが好きで勉強してきて,良かったなーと思うことが最近いろいろある.

まあ要するにアセンブラとかCPUアーキテクチャとか勉強してきてよかったなーという話なのだけど,このあたりのレイヤーは,そんなところ勉強しても役に立たないとか,なんでそんなのいまさらやるの,とか言われがちな分野ではある.笑

が,自分自身はそんなことは微塵にも感じていなくて,むしろ勉強してきてよかったなーと思うし,そしてこれからも勉強し続けていくと思う.(まあでも別に,他人に対して「低レイヤーを勉強したほうがいいぞ!」とか言うわけではないです.僕自身はそうだと思う,というだけ)

とくに思うのが,最近セキュリティ関係とかで,勉強会の資料や演習のサンプルを作ったりするときだ.

たとえばバッファオーバーランの脆弱性の実演みたいなものとか,そういうのを勉強会とかで出したいときだ.

こういう演習サンプルって,説明のときには「適当に作ったサンプルですが」とか口では言ったりはするのだけど,実際にはほんとに適当に作ったものを使っているわけではなくて,僕の場合は,カリカリにチューニングして作成していたりする.

見た目は数十行のシンプルなサンプルでも,実際にはいろんな細かい配慮がされていたりするわけです.
(まあそれでも凡ミスがあって,いかにも雑に作ったみたいに見えてしまうことも多いのだが.笑)

例えばコンパイルオプションとかをチューニングして所望の出力が得られるようにしていたり,コンパイラが出力するアセンブラを意識しながら元のC言語ソースをコーディングしていたり,場合によっては所々をアセンブラや機械語コードで直接書くことで細かくチューニングしていたり,そんなことをしている.

そしてこの手の細かいチューニングは,そもそもの原理をちゃんと知っていないとピンポイントで行えないものが多い.本当に適当に作ったとしたら,なかなか思い通りにはならないものだったりする.

こういうのは,低レイヤーをいろいろ勉強していればこそのものだと思う.やってると結構楽しくて,CPUやコンパイラに直接触れているような面白さがある.

しかし,別にそうしたチューニングができるようになることを目指して低レイヤーを勉強してきたわけでは,実はなかったりもするんだよなあ.

好きでやってきたら,気がついたらそういう感じになっていたというぐあいだ.

ぼくは基礎技術というのを非常に大切にしているのだけど,そういう基礎技術というのは,新しいことやあまり誰もやっていないこと,あまり資料が無いようなことをやろうとするときに,すごく役に立つ.

そういうことをするときには,なにせ参考にできるサンプルや資料が無いので,自分で試したり考えたりして,自力でなんとかするしかないというところが多々ある.

基礎技術というのは,そういうときの地力になる.
スポーツマンにとっての基礎体力みたいなものなのかな.

ググッて出てくるようなことっていうのは,そもそも誰でも知っているような情報であるわけで,本当に知りたいことというのは,ネット検索では得られないものだと思う.

結局のところ,役に立つか立たないかというのは,いかに自分が役立てるかによるわけで,役に立たないと自分で決めつけたらそりゃ役に立たないだろうし,そうではなくて役に立てようと自分なりにいろいろ考えて工夫することが大切なわけだ.

なので低レイヤーを勉強してきてよかったなーと今自分が思えているということは,自分はかろうじてそういうふうになんとかやってこれてるのかなあ,よかったなあ,なんて思う.