VirtualBox＋buildrootでLinuxトレーニング

世の中仮想化といえばXenの話が多いのですが、私の日常の課題といえば、いかに楽しみ、いかに学ぶかがテーマだったりします。そこで、LinuxをWindows上で動かして、Windows上で遊びつつ、Linux上で学ぶというのがだらだら休日の理想です。Xenだとどうもこの用途には向いていません。そこで、私はVirtualBoxを使っています。

VirtualBoxはドイツのinnotek社が開発したソフトで、QEMUの技術を一部に利用しています。6/5にメジャーバージョンアップして1.4.0になりました。QEMUでも良かったのですが、目的がLinux上で何かをすることだったので、GUIの手軽さに流れてしまいました。ただ、今のVirtualBoxは弊社のLinuxがすべて動くわけではなく、試した限りではMIRACLE LINUX V3.0 SP3はカーネルがBoot出来ませんでした。今はMIRACLE LINUX V2.1 U3ベースの環境を使っています。(ごくまれにカーネルがBoot出来なくなるので、ブートフロッピーを作っておくことをお勧めします。)

以下の画面ではLinuxでコンパイルしながら空き時間でWindowsで遊んでいるところです。

コンパイルしているのは、uClibcを使用した組み込み系(?)Linux環境のbuildrootです。手持ちの古いモバイルPC用に軽いLinux環境が欲しいなぁと思ったので、作ることにしました。

buildrootは通常のLinux上でさまざまなツールをクロスコンパイルすることを目的とした環境なので、i386用以外の環境も作ることができます。これが終わったら、念願のNuBus Performa用バイナリにも挑戦してみることにします。

それはともかく、buildrootにはstableブランチという概念がありません。そのためREADMEに書いてあるとおりにやってもすべてが順調に進むとは限りません。まぁ、コンパイルが通ればよいだけでしたら最新のsnapshotなら間違いないのですが、たとえばカーネルを2.4系にしたいとかなると、古いbuildrootを使わなければならず、トラブルが頻発します。

私としてはディストリビューション開発者としての腕を錆付かせないためのトレーニング教材として良いです。なにせ最近のLinuxはコンパイルエラーがほとんど発生しないので、これに対処する能力が維持できないのです。が、そんなことしったこっちゃない人にとっては挫折するかもしれません。

古いbuildrootに挑んでいるうちにふと思ったのですが、これは弊社のAsianux開発エンジニアの入社試験項目にいれたらどうでしょうね。トラブル対処能力を測るのにぴったりな気がします。

Comments

[投稿： tmorimoto]

> 弊社のAsianux開発エンジニアの入社試験項目にいれたらどうでしょうね。
(おそらく)私は歴代最低点で入社したのですが、1回でも質疑応答してくれると嬉しいですね。パニクってたらヒントも(-_-#

[投稿： rk]

最近特に思うのですが、ディストリビューション作成人は技術で解決するべきじゃないときもありますね。しかも多く。
1. ディストリビューション本来の役割からいって、オリジナルのソースコードに無闇に手を入れるべきではない。調停のために必要な修正のみが理想。
2. お客様が理解しづらいような、高度な方法で解決することは避けたい。
そういう意味で、今の入社試験は技術によりすぎているかな〜、と思ったりしました。
ここで挙げたbuildrootのmakeに正解はないです。どのように「解決」したかの過程で、プログラマーよりか、コンサルタントよりか、それともディストリビューターなのか、その人のエンジニアとしての属性が分かるように思えます。

[投稿： fumiyas]

純粋に疑問なんですが、「ディストリビューションの本来の役割」って何ですか? ディストリビューションによって異なるものだと思うんですけど (もちろん共通するところもあるでしょうが)、「(Linux?) ディストリビューション」という言葉には特別な意味が込められているものなんでしょうか。

もう一つ、「お客様が理解しづらいような、高度な方法で解決することは避けたい」理由も思いつきません。また、高度かどうかの基準はどこ(誰?)になるんでしょうか。

[投稿： rk]

fumiyasさんご無沙汰してます。

Linuxディストリビューションの一番原始的な役割は、「ユーザーが使いたいアプリケーションソフトウェアを(オリジナルの)ソースからコンパイルすることを肩代りすること」です。これだけはどのLinuxディストリビューションといえども外せません。
ここでは、ソフトウェアを使い易く改良したり、新たなソフトウェアをつくり出す役割は、ディストリビューションには必須では無いわけです。(そうしても良いですが、従属的な機能です。)

# つづきはまた後で。

[投稿： rk]

どう説明するのが適切か悩みますが、「どのように対処したかがわかりづらい」方法は、第三者がシステムをカスタマイズするときに困ります。ディストリビューションはカスタマイズする自由が重要なファクターと思いますので、馬鹿っぽい遠回りな方法で対処するのも時には必要と思います。
基準については正直倫理規範的なものだと考えています。ユーザーに理解できないかもしれない確率の高いコード・コーディングには(シンプルであろうとエレガントであろうと)罪悪感を持つべきだ、でしょうか。
ちょっと言葉足らずで済みません。