UNIXプログラミングはこの20年間で変わっただろうか 58
ストーリー by yoosee
その根幹を成すもの 部門より
その根幹を成すもの 部門より
BSD 曰く、 " informITに Advanced UNIX Programming 第2版の出版にあたり、 著者である Marc Rochkind が書いた 「UNIXプログラミングはこの20年間で変わっただろうか」 (日本語訳) という記事が掲載されている。 著者によれば、基本的に UNIX は何も変わっていないが、 20年間の時間の流れに伴って、システムコール、使用言語、サブシステム、移植性、標準規定 について非常に多くのものが付け加えられたと述べている。 読者の皆さんはどのような考えをお持ちだろうか。"
富豪になったな (スコア:3, 興味深い)
必要なライブラリもでかくなってますし、種類も増えた。
また、富豪的プログラミングが可能になってビンボ臭さが消えてきたと思います。
perlが普及しだしたあたりから、KISSの思想は薄れたかなと。
大型のハイエンドマシンから、小型のラップトップ、いやマイコンに至るまで移植されて、
「何でもできるＯＳ」を目指してどんどん開発されていった経緯がありますので、
多分これで方向性は間違ってないのだと思いますが。
カーネルに関してはいまだに、
マイクロカーネルを主流にする動きは噸座したままのようですね。
柔軟なモジュラー構造は採り入れるとしても、
空間を分離して実装するのは面倒ってことでしょうか。
HURDもあまり元気な話を聞きませんし、
マイクロカーネルなのに、性能が結構出てると思ったら、 [tu-dresden.de]
サービスを全部１コにまとめて実装してたりして。
そんな謎な実装をしてるL^4 Linux [tu-dresden.de]なんかを見ていると、
なんだかその方面は迷走してる感じがしてきます。
UNIX vs. MULTICS (スコア:2, 参考になる)
サブシステムが比較的相互独立に作られているので、小さく カスタマイズすることができ、それで救われていますが、 大きくなりすぎたマンモスのように絶滅するのではと 心配です。
あの当時と違うのは (スコア:2, 参考になる)
１．ハードウエアの性能アップと劇的なコストダウン
２．Linuxなどのオープンソースの環境の拡大と充実
３．UNIXの大衆認知とアプリケーションの社会的拡大
４．UNIXを使える技術者の数の増大
５．コンピュータ利用の爆発的拡大(ネットの拡大含む)
こういった状況が、(1)MULTICSのような複雑さ→(2)UNIXでシンプルに→(3)でもまた「複雑化」「巨大化」、という流れの(2)→(3)の道筋をたどりやすくしたのだと思う。
UNIXが小さくてわかりやすいまま、というレベルで止まることができなかったのは、そういう周りの状況の変化によるものだと思いますが。それが喜ばしいことであったか、そうでなかったのか、という評価は人それぞれでしょうから、おいておくとして。
Re:UNIX vs. MULTICS (スコア:0)
マイクロカーネル (スコア:1)
小さくしすぎてもダメ、大きくなりすぎてもダメ、微妙なバランス があるのでしょう。
Re:マイクロカーネル (スコア:1)
今後のトレンドとしてマルチプロセッサ化が進みそうですが、
OSそのものをマルチスレッド化する、という方向になれば、
マイクロカーネルなOSの方が有利になってくると思います。
Re:マイクロカーネル (スコア:0)
Re:マイクロカーネル (スコア:1)
Mac OS XはMachベースのマイクロカーネル。FreeBSDサーバはカーネル空間に存在するが、これはco-locationと呼ばれるマイクロカーネル高速化のための技術。
Re:マイクロカーネル (スコア:0)
サーバをカーネル空間に置くのじゃ単にモジュール化された
モノリシックOSと区別できなそうだけど。
Re:マイクロカーネル (スコア:2, 参考になる)
Re:マイクロカーネル (スコア:0)
その上で、それはマイクロカーネルなのか? と。
# Machはマイクロカーネルではない、という説もありますし。
正しいマイクロカーネルの定義(あるいは条件)は何でしょう。
Re:マイクロカーネル (スコア:2, 参考になる)
結局、サービスを独立させると言っても無理があるのでしょう。 ちょうど企業の情報部門をアウトソーシングした時の利点と欠点 に似ているような気がします。「アウトソーシング」して良いこと ばかりあるわけではありません。
マルチプロセッサ環境で効率が上がると言いますが、これも口で 言うほど簡単ではありません。リソースの競合を制御するのは やはり至難の技のようです。BSD の SMP 対応の作業を見ている とそういう感じがしませんか。
Re:マイクロカーネル (スコア:1)
これを見ていて、なおかつ、MacOSX とか WindowsNT があっさりとSMPに対応しているところを見ると、
「OSをSMPに対応させるなら、マイクロカーネルの方が有利なんだな」
と思ってしまいます。
#外から見えてないだけで、 apple や MS の 社内では SMP 対応に苦労していたのかもしれませんけど…
Re:マイクロカーネル (スコア:1)
>「OSをSMPに対応させるなら、マイクロカーネルの方が有利なんだな」
>と思ってしまいます。
で、使いたい機材が XP 対応などと言いつつドライバが SMP に対応していなくて泣く、と。
OS のコアの部分での SMP 対応やスレッドの実装などと同時に、
現実世界との接点であるドライバの実装で苦しんでる部分も多いのではないかと。
Re:マイクロカーネル (スコア:1)
つまり構造はマイクロカーネルなんでしょうが、BSDサーバー自体の作りはあんまりカーネルから独立してなくて、モノリシックな作りになっているんじゃないでしょうか。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:マイクロカーネル (スコア:1)
マルチコアのプロセッサの普及で条件が変わるかも
Re:UNIX vs. MULTICS (スコア:0)
惜しむらくはアプリが少ないことだなぁ。Debian無いのかしら。
マイクロカーネル (スコア:1)
Rob Pikeの論文 (スコア:2, 参考になる)
Rob Pikeの Systems Software Research is Irrelevant(PDF) [bell-labs.com](和訳 [takushoku-u.ac.jp]) というのが2000年に出ています。 合わせて読んでみるといいです。
非常に多くのものが付け加えられた (スコア:2, おもしろおかしい)
一番付け加えられたものは、利用者だろう。
よくも悪くも…
なんだかなぁ (スコア:1)
こうやって振り返ってみること自体は意味があるんだろうけど，読んでもあんまり面白くないかな．
例えば，「Lispはこの20年間で変わっただろうか」とか「吉野家はこの20年間で変わっただろうか」とか，書いてもあまり変わらない無いようになる気がする．
それが，枯れてて良いってことになるのかもしれないけど．
アンチテーゼとしてのマイクロソフト (スコア:2, 興味深い)
祈願牛丼復活!!!(おふとぴ) (スコア:0)
おいちょっと待て、20年前の吉野家はまだセゾン傘下じゃなかったことないか?!
…という疑問をいだきつつ調べたら、セゾンのてこ入れは1983年から [yoshinoya-dc.com]だな。
# おかげさまで松屋派に転んだがキムチ豚めししか喰ってないのでAC
Re:祈願牛丼復活!!!(おふとぴ) (スコア:0)
牛丼一筋八十年「やったぜパパ、明日はホームランだ」
だったけど、もう一筋ではなくなっちゃったね。
というか (スコア:1)
ということで、普通に日本のこの業界で仕事をしている個人にとって、20年のOSの変遷、20年の言語の変遷、というのは、「ああ、そうなの」という程度のことであって、「歴史をたどる」以上の意味がなかなか見出せない、ということも多いのではないかな？それでも、もちろん「歴史をたどる」ことに意味がない、とは言えないのですが。
Re:というか (スコア:1)
あなたが 管理職 [neweb.ne.jp]であることはよくわかりました。
#5章1節です。
#冗談なのでID
Re:というか (スコア:0)
20年に渡って UNIX の世界で生きてこれたとのことですので、おそらく、かなり恵まれた環境で、それなりに技術も蓄積されたのだと推測できますが、その 20 年間、世間に流され技術に流され、追随で手一杯な感じが…。
いや、日本の技術者の場合、大概そうで、それさえできず、多くは、Win 系を強いられ、また、管理職掌という名で現場を追わ
第1版の訳本 (スコア:1)
原著第1版の翻訳は 「UNIXシステムコール・プログラミング」 [amazon.co.jp] と題してアスキーから出ていました．
内容は UNIX System V Release 1.0 の頃のものなので， socket などのネットワーク関係の記述はまるでなく， プロセス間通信も非常に基本的なものだけ， という非常にシンプルな作り．
いま見直してみると，これはこれとして，古典的でいいかな， という気もします．
Socket (スコア:0)
Socket 関数ってもう少し綺麗に実装できなかったのかなあと
一昔前に考えたのを思い出しました。
BSD44 のやりかたも今ひとつ見えにくい。
Java の Socket はまああんなもんでしょ。
:wq
Re:Socket (スコア:1)
もちろん、read、writeしているだけのプログラムは、 同じファイルデスクリプタという概念を使って処理できるのですけれど。
Re:Socket (スコア:3, 参考になる)
> ファイルとデバイスは同じように取り扱えます。これが UNIX の 特徴の1つですね。
より正確に言えば「キャラクタ型」デバイスですよね. 入出力の口しかない. それゆえに全ての通信は基本的にread/writeシステムコールで統一されると.
そう考えると, UNIXプログラミングの転換点は実はmmapシステムコールが実装され, 入出力とメモリアクセスの境界が無くなったときだったんじゃないかと思えます. これでプログラミングの自由度が大きくなった代わりに通信の同期がやっかいになり, そのあたりを隠蔽するためにもオブジェクトに対するメッセージ通信というオブジェクト指向のプログラミングモデルが有効だったんじゃないでしょうか.
Re:Socket (スコア:2)
trueOne
Re:Socket (スコア:0)
でメールを盗み見できるんでしょうか？
Re:Socket (スコア:1)
Re:Socket (スコア:0)
Re:Socket (スコア:0)
使ってみたいと思いつつ、まだ手が出せていません。
Inferno 買ってみようかな。
:wq
Re:Socket (スコア:1)
Re:Socket (スコア:1)
Re:Socket (スコア:0)
ファイルシステム名を忘れてしまった。
なんだっけ?
# 俺の妄想かもしれん。
Re:Socket (スコア:1, 参考になる)
4.4BSD からあったんだね。
当時は未完成という位置付けだと思ったけど、今はどうなってるんだろう。
Re:Socket (スコア:1)
socket API 以前に、私は VMS [hp.com] 方面から Unix 界に渡って来た人なので、「UNIX のネットワーク (incl. uucp, TCP/IP) ってなんでこんなに後から取ってつけたっぽいの？」と思ったりしました。
# まだ、DECnet の phase が...えーと、忘れた。頃。
Re:Socket (スコア:0)
実装 => 設計
の間違いでしょうか？
Re:Socket (スコア:0)
設計です。はい。
:wq
Re:Socket (スコア:0)
# わかっちゃいるんで、他人に押し付ける気はございませんとも。
tcp_input()とか (スコア:0)
UNIXはこの20年間でTRONに取ってかわられた (スコア:0)
閑話休題 (スコア:0)
リアルタイム (スコア:0)
Re:M1してる方へ (スコア:1, すばらしい洞察)
Re:M1してる方へ (スコア:0)
んで、「余計なもの」に変わったんじゃないかと。
// ネタにマジレスかもしれないのでAC