MINIXの新バージョン3がリリース 74
ストーリー by yoosee
マイクロカーネルはモノリシックカーネルより信頼性が高いのじゃよ 部門より
マイクロカーネルはモノリシックカーネルより信頼性が高いのじゃよ 部門より
flutist曰く、"Linuxカーネルがモノリシックとして誕生するきっかけともなった、タネンバウム教授の教育用OS MINIX のバージョン3 がリリースされた。教授の主張を踏襲して、当然マイクロカーネル。これまでの教育志向に加えて、組み込み用途を視野に入れた「使いやすく信頼性の高い」OSを目指した、とされている。"
Minix3 に関しては slashdot.org にも記事が出ている。
トップページ翻訳 (スコア:5, 参考になる)
もったいないのでここにポストしちゃいます。おかしなとこあったらdiffでもつけてください^^;
MINIX 3 は、高い信頼性とセキュリティを実現するためにデザインされた新しいオープンソース・オペレーティング・システムです。 多少は以前のバージョンのMINIXをベースにしていますが、多くの重要なところで根本的に違っています。 MINIX 1と2は教育用ツールを意図していました。MINIX 3は限られたリソースや組み込み用途のコンピュータ、そして高い信頼性が要求されるアプリケーションに使えることを新しいゴールとして設定しました。
この新しいOSは、カーネルモード部で走るものは4000行未満の実行コードという、極めて小さいものです。ユーザーモードで走る部分は小さなモジュールに分割されており、他のものからきちんと隔離されています。 例えば、めいめいのデバイスドライバは一つのユーザーモードプロセスに切り離されて走っており、(バグのある巨大なソースのOSとは段違いに)ドライバのバグがOS全体を巻き込むことはありません。実際、だいたいドライバがクラッシュしたときは、ユーザーの介入の必要もなく、再起動の必要もなく、走っているプログラムに影響を与えることも無く、それが自動的に置き換わります。これらの機能は、小さなカーネルコードの帰するものであり、他の面でも優れた信頼性を増すシステムです。
MINIX 3 は以下のようなものを初期ターゲットとしてます：
MINIX 3 Features
Re:トップページ翻訳 (スコア:5, 参考になる)
→これらの機能・小さなカーネルコード・その他の点によってシステムの信頼性が大幅に向上しています。
(バグのある巨大なソースのOSとは段違いに)ドライバ
→(OSにおいて断トツで最大のバグ発生源である)ドライバ
きつい制限のかかったGPLのアプリケーション
→GPLでは制限がきつすぎるアプリケーション
Re:トップページ翻訳 (スコア:1)
・・・・いや、OSにその手の機能を組み込む事を考えてないと駄目でしょうけど。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:トップページ翻訳 (スコア:1)
# 実際、付けたり外したりはLinuxでもできるし。
Re:トップページ翻訳 (スコア:2, 参考になる)
ホントに出来るかどうかはさておいて:-)
ユーザーが再起動せずに自分でドライバをデバッグしつつ組み込んだり、外したりできたりとか、ユーザーが動的にファイルシステムを拡張したりできる訳っす。
たとえばzipを直接読み書きできるファイルシステムをカーネル落とさずにユーザーがコンパイルして組み込め、なおかつドライバをデバッガで追っかけられるという変態的な開発が可能になる・・・かも、という話です。
やりたいかどうかはさておいて:-)。
で、これが究極まで行くと、MINIXでMINIXを動かすという変態的な技も可能になると思います・・・というかHurdで可能になる、等と言われていた筈:-)
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:トップページ翻訳 (スコア:2, 参考になる)
/sbin、/usr/sbin にデバイスドライバのバイナリが普通の実行ファイルとして置いてあります。ブートに必要が無いデバイスは /etc/rc で実行していくみたい。
ドライバと普通のプロセスの区別が無いようなんで、割り込みが絡まない場合は、ひとまず普通プログラムとして開発して、完成度が上がったらドライバに仕立て直すのが一般的になるんじゃないでしょうか。
普通に動かすとwgetのようなダウンローダだけど、実行オプションによってはwebdavfsとして動く変態的プログラムもできそうです。
なんちゃってプログラマ?
Re:トップページ翻訳 (スコア:2, 参考になる)
モノリシックでもそれはできるよ。例えばLinuxのドライバ書く時はモジュールで作っておいてinsmodで組み込んで、rmmodで取り外してるし。(大抵は)再起動なしに。
マイクロカーネルとモノリシックの差は、ドライバが腐ってる時にカーネルごと死ぬ確率とか割り込みに対する応答時間とかそういう性能っぽい部分であって、動作中に付けたり外したりできるかどうか、というか可能/不可能という部分じゃないよ。
>MINIXでMINIXを動かすという変態的な技
Linuxの例ばっかでアレだけど、UML(ユーザーモードリナックス)っつーのがあるね。LinuxでLinuxを動かすって奴。
妄想たっぷりで考えると (スコア:1)
FUSE [linux.com] がそれだし、原理的には NFS を使えばいける。
マイクロカーネルの利点って言ったらやっぱり設計なんじゃないかなぁ。
モノリシックカーネル内部での関数の呼び出しが
マイクロカーネルの各ドライバ間でのメッセージ送受信に相当するはず。
OOP のポリモーフィングを、
関数テーブルで実装するか、メッセージの書き換えで実装するかの
違いと言ってもいいのかも知れないな。
メッセージの書き換えで実装するほうが、たいていは
より柔軟にできる可能性があると思われる。（その分遅くなるけど）
# mishimaは本田透先生を熱烈に応援しています
日本語記事 (スコア:4, 参考になる)
Re:日本語記事 (スコア:1)
驚き。
てっきりオランダ人だと思い込んでいました。
だから"Geheim"もオランダ語だろうと思ってましたが、もしかして違うのかな。
Re:日本語記事 (スコア:1)
Andrew S. Tanenbaum, Professor of Computer Science [cs.vu.nl]
フリイエ大学 [www.vu.nl]
#わざわざ「米国人の」と書くのも変な気がするけど．
Re:日本語記事 (スコア:5, 参考になる)
My paternal grandfather was born in Chorostkow, currently in Ukraine, historically in Poland, at the time under Austro-Hungarian management. He came to the U.S. in 1914. I was born in New York and grew up in White Plains, NY. I went to Amsterdam as a postdoc and have sort of hung around ever since.
アメリカの生まれ育ちで、ポスドクからオランダ、だそうです。
Re:日本語記事 (スコア:1)
なるほど，そう言うことですか．これでまた知識が増えた：）
Re:日本語記事 (スコア:1)
"秘密"って言う意味のオランダ語です。
っていうのは1版バイブルの訳注か何かに書いてありませんでしたっけ?
ほかの本だったかな。もう記憶が曖昧…。
from もなか
VMWareイメージも (スコア:3, 参考になる)
LiveCDやVMwareイメージでの提供もされているようですね。
20代の自分にはMINIXというと、名前だけ聞いたことのある
過去のモノ、という印象が強かったのですが、こういう
配布形態を用意してきたということで、それが若干
払拭されたような気がします。
それとも、元々教育用であったことを考えるとこの配布形態は
至極当たり前なのでしょうか。
Re:VMWareイメージも (スコア:4, 興味深い)
だもんで、386化するのに大いに難儀したといういきさつからLinuxが支持を得た、という経緯があったと思います。
それはさておき、デバイスドライバがユーザー空間で走るなど、OSとしても意欲的な構成じゃないですか。
GNU Hurdもこっちに乗り換えて欲しかったり:-)
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:VMWareイメージも (スコア:3, 興味深い)
しかし当時はそれでは性能が出なかった。
というのもLinusがモノリシックカーネルに固執した理由の一つでしょう。
バーチャルマシンブームの今なら、ハードウェアのサポートも期待できるし、また流行するかも知れませんね。
Re:VMWareイメージも (スコア:2, 興味深い)
AVG anti-virus data base out of date
Re:VMWareイメージも (スコア:3, 興味深い)
モノリシック=GPL、マイクロカーネル=BSDな傾向が？
# そういやMonaも...
Re:VMWareイメージも (スコア:2, 興味深い)
OSそのものに「研究者が愛用してきたOS」という感じがしますよ。
そして、マイクロカーネルは結構「歴史が浅い」わけですから、
「研究用途から発展したものが多い」のだと考えると、
BSD系が多いというのはそれなりに納得できるような気がします。
UNIXという区分で元祖BSDと本家SystemV系を比較対象にもってきてGNUシステムを見た場合、
GNUが目指していたシステムの利用感、いわゆる古いLinuxで実現されている環境は
かなりBSDっぽいという意見も聞いたような気がします。
もしかするとSlackwareあたりのことを言っているのかもしれませんが。
Re:VMWareイメージも (スコア:1)
http://groups.google.com/group/comp.os.minix/msg/d12a0dde04b7f232?hl=en
Re:VMWareイメージも (スコア:1, 参考になる)
Linuxが支持されたのはMInixはあくまで教育用なので教育用として無駄な機能追加などは行わないという方針を貫き通したからです。
Minixに触れた多くの人は教育用ではなく実用に供することのできるUnixクローンが欲しかったのです。386BSD, FreeBSD, NetBSD が誕生してからはそちらに期待がかかったわけですが、例の訴訟で開発停滞があって Linux がその間隙を縫って伸びてきたってな感じです。
Re:VMWareイメージも (スコア:2, 参考になる)
1994年01月 USLのUCBに対する訴訟が和解
1994年03月 Linux 1.0
1994年03月 4.4BSD Lite
1994年07月 FreeBSD 1.1.5.1(最後の4.3BSD NET/2版)
1995年01月 FreeBSD 2.0(初の4.4BSD Lite版、結構不安定)
1995年11月 FreeBSD 2.1(ここまで来て結構安定した)
って流れですから、FreeBSDが黒くなってから
クリーンで安定したものが出るまでに2年近くかかってます。
その間に Linux 1.0 が発表され、Linux が台頭してきたのは確かかと。
Re:VMWareイメージも (スコア:1, 参考になる)
ioparm()のような無茶なことも可能です。
しかしBSDには古くからの歴史と流儀がある。
「こういう場合は必ずデバイスドライバ経由で扱え」
とか、必ず言われるわけです。
Linuxってのはそういうものを無視して
「とにかく面白そうなら作って発表してしまう」
という活気というか、若さというか、無鉄砲さがあったと思います。
カーネルレベルでWebサービスを高速処理してしまおうとか、
javaのバイナリを直接サポートしてみようかなとか、
盛り込まれたけど結局消えていった拡張は結構あります。
基本的にUNIXとしては「アプリケーションが移植できて使えればいいじゃないか」と、
その上で、「もっと便利にできるんならどんどんやって作りなおしてみよう」
みたいなスタンスなんでしょう。
それを使うユーザのほうも、
「何も知らない奴は俺のところに来い、俺も知らないけど心配するな、そのうち何とかなるだろ〜♪」
みたいな感じで布教していったような気がします。
Re:VMWareイメージも (スコア:2, 興味深い)
当たり前とは言えないけど、お金のない学生に取って、MINIX用のマシンを用意しなくてすむから敷居はだいぶ低くなりますよね。今も非常に強い教育志向だと思います。
もう15年も前、ASCIIから出ていたMINIX本を見ながら「メッセージ・パッシングの現場の様子を目で見る」のが楽しかったのを思い出します。MINIX 3もサイズは"extremely small"だそうで、完全なOSとして必要なこと全体を把握しやすいように作られているんだろうと思います。
ちょっと見てみようかな。
# 4000行か...。科研費を書き終わったら見てみよう。
Re:VMWareイメージも (スコア:2, 興味深い)
MINIXの配布しているイメージは先日の無償バージョン [srad.jp]で使えるのでしょうか
これを期にMINIXを…、と言うわけではないのですが
このような配布の時に使えるものなのかな～って思ったもので
Re:VMWareイメージも (スコア:2, 参考になる)
http://www.minix3.org/doc/faq.html#simulators [minix3.org]
Re:VMWareイメージも (スコア:1)
見に行ってみれば良かったのですね
ありがとうございマスです。
Re:VMWareイメージも (スコア:1)
Re:VMWareイメージも (スコア:1)
POSIX 的には、cd も外部コマンドとして存在する必要があったかと思います。
ただし、外部プログラムでカレントディレクトリを変えても呼び出し元は変わりませんので、
本来の目的としては意味無しです。
指定したディレクトリが存在するときは成功するので、
ディレクトリの存在チェックには使えたかと。
Re:VMWareイメージも (スコア:1)
シェルにカレントディレクトリの変更を依頼するメッセージをとばす。
みたいなコマンドにすれば解決？
せっかくマイクロカーネルなんだからさ。メッセージで会話しようよ！
Re:VMWareイメージも (スコア:2, 参考になる)
if [ -f foo ]; then …
って書いた時は、実は、
> [ -f foo ]
すなわち、
> test -f foo ]
というコマンドが実行されて、その実行結果の真偽を判定している、と。
この手のよく使うコマンドについて、イチイチ別プログラムを実行するのはオーバーヘッドが大きいので、
最近のシェルでは、built-in な内部コマンドになっていることが多いです。
で、そうなると、内部コマンドに用意されたものは、外部コマンドとしてはもう不要なわけですが、
POSIX 的には外部プログラムとして存在することを要求しているので、おそらくそのために、
> 今気づきましたが、MINUX では、１２個のコマンドが、同じハードリンクになってますね。
> [ cd command echo expr false getopts read test true umask wait
といったものを用意しているのでしょう。
おそらく、中身は、内部コマンドとして $0 を実行するようなシェルスクリプトになっているのではないでしょうか。
環境変数に結果を返す getopts と read なんかは、外部コマンドとしてはたぶん完全に意味無しですね。
随分昔だけど (スコア:3, 興味深い)
アレを買って四苦ハックしたのを思い出して
久々にMINIXも触ってみたくなったよ
当時はWindows3.0が出始めた頃だったと思いますが
MINIXでもX-Windowを起動できた事で
Windows3.0よりは安定してたけど
X-Windowって華やかさが無いなとも感じたものでした
Re:随分昔だけど (スコア:3, 興味深い)
Amoebaをしゃべれるようにするパッチを作ったり、古田さんからi386版パッチを譲り受けてリリースしたり、1.6.24辺りまで追いかけたり。1.7のMMとFSに1.6.25のkernelというキメラなバージョンを出したりとか。途中でNifty版が出たり私自身がLinuxの実用性にヒヨったりしたりした頃も、X68kの方々が結構活発にやっておられました。
あれから15年。
対象カーネルは変われど、やってることに全く進歩がないと気づき愕然。
#いまだに257倍ページ復活キボンヌとか責められるID。
from もなか
Re:随分昔だけど (スコア:1, 興味深い)
Install してみたはいいけど root の Password がわからーんて叫んでみたり、
1.5.10 ベースで 1.7.x への作業が細々となされてたり、
TCP/IP とか使いたくてごぞごぞやって挫折してみたり、
そんなこんなで 2 年もしたら海の向うでは MINIX 2.0 の
68k Atari への移植が進んでたり、なかなか熱かった時ですねー。
というわけで、257 倍のページ復活キボンヌ :)
め
Re:随分昔だけど (スコア:2, 興味深い)
MINIXでGUIというと、XよりもMGRのほうが注目度が高かったのではないかと。こちらも、PC-98版は多分日の目をみていないです。
もしや時期的に近いPANIXとか386BSD(98)とかと記憶が混じっているのでは…?
from もなか
Re:随分昔だけど (スコア:2, 興味深い)
日経MIXのMINIX会議の人が作ってました。Ver.1.3位だったかな？
CUJJの付録で見た覚えはあるけど使いませんでした。
って、わしゃ死語の辞典かいな
MINIXとLinuxの関係 (スコア:1, 興味深い)
#つーても、おいらも、「それがぼくには楽しかったから」に書かれてた事
#くらいしか知らないので、詳しい方のツッコミ大歓迎。
Re:MINIXとLinuxの関係 (スコア:5, 参考になる)
「タネンバウム教授でもLinusを説得しきれなかった」という意味では、
「Linuxをモノシリックカーネルとして開発させるきっかけになった」というのは
間違っていないだろうと思います。
でも、実際に当時のMINIXユーザたちが不満に思っていた点は、
マイクロカーネル方式であることそのものにあったのではなくて、
モノシリックカーネルでは普通に実現できる機能だった、
「マルチスレッドで動く高速なファイルアクセスサービス」が
きちんと実装されていなかったことらしいですね。
さっきのリンク先にこんな投稿が収録されています。
>Minixを使っている際、単一スレッドのファイルシステムが非常に苦痛だと感じています。
>（猛烈に遅い）フロッピーディスクからファイルを読み込んでいる間も
>何か行ないたいと思うことがよくあります。
>大きなCプログラムやLispをコンパイルして待っている間、rogueで遊んでいたいのです。
>プログラムをコンパイルしている間にエディタの1つのバッファでファイルを眺めていたいのです。
UNIXアプリケーションを使っていろいろしたい人から見れば、
確かに「ロクでもない制限をつけてくれたものだ」と思うでしょう。
Re:MINIXとLinuxの関係 (スコア:1)
当然、本家ツリーとは別ツリー。
hoihoi-p 得意淡然、失意泰然。
Re:MINIXとLinuxの関係 (スコア:1)
Re:カーネル氏は (スコア:2, おもしろおかしい)
# 体育会系？ 吉本系？
Re:お約束のツッコミ2 (スコア:1)
ただし、私はスラドの代表ではありませんので
お間違えのないようにお願いしますよ。
Re:MINIXとLinuxの関係 (スコア:3, 参考になる)
だから作ったというような箇所があったように思います。反面教師として、ウェイトは少なくないでしょう。
なにをどう間違えたのか、移植した [srad.jp]という虚報もあったなあ…
ま、別書籍の記憶かも知れないので、当該書籍にも引用
されているはずのメールのやり取り [oreilly.co.jp]でも貼っておくかな。
と技術的な不満だけでは無い事もかかれてますけどねｗ
Re:MINIXとLinuxの関係 (スコア:2, 参考になる)
> Minixに対する私の最も大きな不満の1つはなくなります。
これは、当時の Network 事情が大きいですよね。
低コストで Internet に接続できる環境がまだ一般的では
ありませんでしたから、版権に縛られてフリーで入手できなくても、
書籍として出版することで多くの人の手に行き渡ることを選んだわけですよね。
ただその後も MINIX はあくまで教育用だとして、ユーザからの
大きな改変要求を拒み続けた結果、その不満が Linux を生んだってのは、
まぁなるべくしてなったかと思いますが。
Re:MINIXとLinuxの関係 (スコア:1)
Re:MINIXとLinuxの関係 (スコア:2, 興味深い)
そのへんは大目に見てもいいんじゃないですか?
1を聞いて0を知れ!
次 Version は・・・・・ (スコア:1)
この構造だとチューニング次第で、かなり面白くなりそうな気がする。
マルチコアの挙動を把握することも、必要だしね。
IOS-XR (スコア:1)
世の中の流行なんですかね。
ちなみに、従来のOSであるIOSはモノリシックです。
Re:GNU Hurd (スコア:2, 参考になる)