新・闘わないプログラマ No.12

UNIXにするか、NTにするか


どっちか選べと言われたら、断然UNIXです、以上。

これで終わってしまってはミもフタも無いので、少しばかり、私の経験したこと、感じていることを書いてみたいと思います。
企業のシステムを構築する場合、近ごろはクライアント・サーバー型にすることが非常に多いのですが、今まではサーバーにはUNIX、またはそれ以上のOSを使うというのが暗黙の了解事項に近かった(少なくとも私の周りでは)のですが、最近PCサーバーを入れてNTにしろ、という要求が増えてきて困っています。クライアントは以前からWindows系のOSを使うことも多かったのですが、まぁこれは仕方が無いですけど。
われわれ開発者から見れば、NT上での開発は非常に大変です。出来れば避けたいと思っているのですが、PCサーバーの方がUNIXマシンより安いから、という上の方からの鶴の一声(って私は聞いたことが無いですけど(^^;))でNTになってしまうことが多いのです。実際問題として、NTの方が安上がり、というのも結構マユツバなんですけどね。まぁ、NTもファイルサーバーくらいでおとなしく使っている分にはそれほど問題も無い(ホントか?)のですが、もっといろいろやろうとすると、とたんに問題が湧いて出てきます。
順不同ですが思い付くままに、そんな問題を挙げていきたいと思います。

まともなスクリプトを書く標準的な手段が無い。
バッチ処理をやらせようとすると、スクリプトを書く必要があります。UNIXならシェルスクリプトでかなりの事が出来てしまいます。NTではCMD.EXEのバッチファイルがこれに相当しますけど、これはご存知の通りあまりにも非力です。ろくな制御構造は書けない、変数の使用がいまいち、標準入出力の制御が出来ない、戻値が無い、等々、とてもまともな処理には使えません。
標準じゃなくてもよければ、確かにREXXやperlやshやtcshやbashも使えなくも無いのですが、標準じゃないだけに必ずしもその動作環境を構築することが出来ないことがあります。たとえば客先の機械などで、勝手にそういうものを入れられない場合、「素性の不確かな物は入れてはならない」と要求される場合があります。フリーソフトなど入れるのはもっての外、という場合も多いのです。でも、ここだけの話、マイクロソフトの製品より、定評のあるフリーソフトの方がよっぽど信頼性があるんだけどなぁ・・・。
また、そういったバッチファイルじゃない、他のスクリプト実行環境を整えたとしても、スクリプトはあくまでもプログラムを順に起動してゆく手段に過ぎませんから、UNIXのように豊富なツール群(たとえば、grep, sed, awk, sort, uniq, find, date, 等々、いくらでもある)が無いと使いものにならないわけです。これらもやはりNTで動作するものがあるにはあるのですが、やはり標準じゃ無いので、上と同じような問題にぶつかってしまいます。
私は以前、NTで「あるディレクトリの下の拡張子が○○○のファイルをすべて指定ディレクトリに移動する」という操作を、他に方法が無く、仕方無しにCで書きました。UNIXならfindコマンド一発で出来るものを・・・

ファイルシステムがタコ。
過去のしがらみ(DOS)を引きずっているせいか、非常に扱いにくいです。でも、こう言っても実は理解してくれる人が少ないのが悲しいのですが。DOSで育ってきた人にとっては、どこが扱いにくいのか不思議に思うらしいのです。
まず「ドライブ」という概念があること。しかもドライブにAとかBとかCとか・・・あまりにも無味乾燥な名前(とすら呼べないな、単なるコードじゃないか)を付けていることが挙げられます。ファイルにアクセスするときに、ドライブなる物理的な実体をあらわに指定しなければいけないのは、抽象化のレベルがきわめて低いと言わざるを得ません。しかも、その物理的実体は「ボリューム」じゃなくて「ドライブ」だと言うのです。「ドライブ」には「ボリューム」がマウントされていない可能性もありますし、読もうと思った「ボリューム」じゃない別のものがマウントされているかも知れないのです。
次に、リンクが出来ないこと。UNIXにはhard linkとsymblic linkという2種類のリンクがあります。Hard linkは、別のファイル名や別ディレクトリにあるファイルで同じファイルにアクセスしたい場合に使われます。Symbolic linkはmacintoshのaliasと同様に、別のところに実体があり、それを指し示しています。Windows95/NT4.0のshortcutも似たような機能ですが、explorerでしか使えない等、機能的には全然お話になりません。
いま挙げたこれらの事項は、システムを柔軟に構築・運用してゆく上では是非必要なものなのです。

リモートでの運用管理が不便。
UNIXの場合、たとえば遠く離れた所にあるサーバーで何か問題が発生しても、ネットワーク的に接続さえされていれば、telnetやrloginでその機械に入って、いろいろメンテナンスをすることが出来ます。
NTはこれが簡単には出来ないんですよね。まず、標準でtelnetサーバーが無い。一応、マイクロソフトが無保証で提供しているtelnetサーバーが入手出来ますが、これがまたよく落ちる。そんな恐いものを業務で使用しているサーバーに入れるのは勇気が要ります。あとは市販製品のtelnetサーバーがいくつかありますが、この場合当然の事ながらお金がかかります。
そこまで苦労して、仮にtelnetが使えるようになったとしても、これでリモートメンテナンスが出来るようになるか、といえば、実はたいしたことはほとんど何も出来ません。というのも、NTの管理ツールはほとんどGUIで操作する類のものだからです。申し訳程度にコマンドプロンプトで動作するツールも付いてくるのですが、これがまた使い勝手が非常によくない。
実は、NTの管理ツール、たとえば「イベントビューア」とか「レジストリエディタ」とか「パフォーマンスモニタ」とか「プロセスビューア」とか、はリモートコンピュータのメンテナンスが出来るようになっています。マイクロソフトの言い分では、リモートメンテナンスにはこれらのツールを使え、ということのようです。
ところが、これが使いづらい。これらのツールは、NetBIOS経由で相手コンピュータと通信します。ですから、相手コンピュータ名の指定にはNetBIOS名(普通NTの「コンピュータ名」と呼んでいるやつ)を指定する必要があります。NT4.0からは、このNetBIOS名の代りにIPアドレスも書けるようになったのでかなり楽になったのですが、以前は出来ませんでした。ここでは書く余裕がありませんが、NetBIOS名の名前解決は結構厄介で、特にルータ超えの場合(リモートメンテナンスの場合は通常ルータを越えますよね)は面倒です。
他にも、コンピュータ同志が同じドメインに属しているか、または信頼するドメインに属していない場合には、向こうのコンピュータにあるユーザーアカウントと同じアカウントでログオンしていて、かつ、そのパスワードも一致している必要がある、そうでないと管理ツールが相手のコンピュータに接続できない、なんていう面倒な話もあります。

何か、まだ3つしか書いていないのに、だいぶ長くなってしまいました。まだまだ、いくらでも言いたい事がある(^^;)のですが、今回はこの辺にしておきます。また、そのうち続編を書きたいと思います。
上に書いたようなことはこまかいことに見えるかも知れませんが、実はそうでもありません。NTにおいて、その設計思想(というか「設計思想の無さ」)が、システムを構築して運用してゆく上において、大きな障害になっていることは確かです。

[前へ] [次へ]

[Home] [戻る]


mailto:lepton@amy.hi-ho.ne.jp