特集Linuxで動く.NET環境「Mono 1.0」の実力(前編)―― なぜMonoは作られ、何を目指すのか? そしてその実力は? ―― |
|
UNIXという価値観を共有したWindows NTとLinux
しばしば、筆者は「マイクロソフト信者」と呼ばれる場合がある。マイクロソフト製品利用者の多くは、熱狂的にマイクロソフトやその製品を崇拝したり心酔したりしないので、そもそもマイクロソフト「信者」なる人種はほとんど存在しないだろう、という点を差し引いてもまったくのぬれぎぬである。
というのも、筆者は、世間のほとんどがLinuxという名前を知らないころに、Linuxを次の時代の主力OSの候補として検討していたからである。まだ、Windows 3.1が最先端のOSであった時代、通のマニアであれば後継OSとしてIBMが開発したOS/2を支持するのが当然だという風潮がまかり通っていた時代に、筆者はずばり本命はWindows NTであり、それがうまく行かなかった場合これに代わるのはフリーのPC UNIX、つまり、LinuxやFreeBSDなどであると考えていた。
この時代、マイクロソフトは主力OSとして、Windows NTよりもWindows 95を売り込もうとしていたので、明らかにマイクロソフトの望む方向性に反する予測を立てていたことになる。マイクロソフトの特定の製品を支持したからといって、それがマイクロソフトの思惑どおりだとは限らない。マイクロソフトの営業方針に逆らう意見を平然と述べていた筆者は、さぞかしマイクロソフトから見て嫌なやつだったに違いない(笑)。
この時代に、筆者はWindows NTとLinuxをLAN上で共存させて使うということも試みている。Windows NTの方は正確なバージョンを忘れたが、かなり初期のバージョンであった。Linuxの方は、恐らく最近のLinux愛好家が知ることもない初期のディストリビューションであるYggdrasil Linuxを使用した(申し訳ないが、正確なバージョンは失念してしまった)。
さて、話を戻そう。このようにしてインストールしたYggdrasil Linuxマシンは、LAN上で、Windows NTと共存していた。すでに詳しいことは覚えていないが、両者の間の相互運用性はかなり良好だったと記憶している。例えば、Windows NT側からtelnetコマンドでLinuxマシンにログインして操作することは問題なかったし、ftpコマンドによるファイル転送もできた。
もちろん、いまの視点から見れば、それらの初歩的な機能が使えることなど当たり前と思うかもしれない。しかし、当時の時代背景を考えれば画期的なことだったといえる。この時代、インターネットのブームはまだ来ておらず、Linuxのブームも来ていない。多くのパソコン・ユーザーは、TCP/IPもtelnetもftpも知らずにパソコンを使っていたのである。イーサネットも普及しておらず、ネットワークといえばモデムと電話回線を使った無手順通信で、Nifty-ServeであるとかPC-VANといった「パソコン通信」と呼ばれるサービスにダイヤルアップ接続することを意味していた。そんな時代に、Windows NTに標準で入っているtelnetを使ってLinuxに接続できたことは、ある種の感動を感じさせるのに十分であった。
このような相互運用性が実現された理由は、決してWindows NTがLinuxとの相互運用性を意識していたからではない。この状況を理解するには、“UNIX”と呼ばれる、似てはいるが相互に互換性があるとは限らない一群のOSの存在を意識する必要がある。UNIXという名前の単一のOSが存在するわけではないが、ここではそれらをUNIXと呼ぶことにしよう。
最初のUNIXは、巨大複雑化したMulticsというOSのアンチテーゼとして、AT&TのBell研究所で開発されたという。その後、UNIXは研究所や大学などで多く使われていた。しかし、徐々にUNIXは浸透し、商品へと変化していく。それまで大学などであればタダ同然で入手できたUNIXが、急に商品として高額の料金を求められるようになったのである。これに不満を感じたリチャード・ストールマン氏が始めたのが、無料ですべてのソース・コードを入手できることを要求するライセンスを提唱するGNUということらしい。
また、UNIXの商業化の流れは、ワークステーションと呼ばれるUNIXを採用した高性能小型コンピュータのブームを呼んだ。現在Javaで注目されることの多いSun Microsystemsは、本来このワークステーションで一世を風靡(ふうび)した企業である。ワークステーションは、ミニコンよりも下、パソコンよりも上の領域で普及し、企業内のビジネス・システムを含めて多くの利用者を獲得した。
さて、不正確かつ大ざっぱではあるが、Windows NTとLinuxはこのような状況下で生まれてきたことになる。その当時のパソコンよりも上の領域を切り開くことを期待されたOSであるWindows NTには、当然UNIXとの互換性が要求された。米国政府のシステム導入規約をクリアするためには、標準化されたUNIX仕様の一種であるPOSIXとの互換性を確保する必要があると同時に、すでにUNIXワークステーションが多く使われる一般企業のシステムに食い込んでいくためにも、UNIXとの互換性は必須要件だった。その結果として、POSIXのアプリケーションを実行するための「POSIXサブシステム」を装備し、UNIXで使用されるプロトコルであるTCP/IPにも標準で対応して、telnetやftpといった基本的なコマンドも備えることになったのだろう。
一方、Linuxの方はどうか。こちらもUNIXを意識していたことは間違いないだろう。当時のUNIXワークステーションは、平均的なパソコンOSとは比較にならないほど強力なOSであり、それを知るマニアであればぜひ使いたいと思うのが当然というだけの存在感があったと思う。現実的かつ実用的にUNIXを使うには、32bit CPUが必要であったが、Intel 386が普及し始めたことで、このハードルはクリアされつつあった。しかし、ハードウェアのハードルはクリアされても、ソフトウェアのハードルは依然として残っていた。マルチユーザーOSであるUNIXは、まともに買おうとするとべらぼうに高価で、また当時すでに活動を開始していたGNUも、無料で入手できるOSを提供することはできていなかった。
このような背景が存在する状況で生まれてきたのがLinuxである。当然、安価に個人レベルでもUNIXを使いたい、というニーズを満たすからこそ、多くの利用者から注目を浴びたのだと思う。とすれば、Linuxの目標は全く新しいアーキテクチャのOSを開発することにはない。それよりも、UNIXと互換度の高いOSを手に入れることが、当然の期待される目標となるだろう。
この2つの経緯を見れば、Windows NTとLinuxが驚くほど良好に接続できた理由は明らかだろう。UNIXという価値観を共有すればこそ、それは可能となったものといえる。UNIXの圧倒的な存在感がある限り、この2つのOSの相互運用性は確保されたも同然と思えた。
そして、時は流れた。
WindowsとLinuxとを結ぶ「Mono」
2004年現在、UNIXの圧倒的な存在感は過去のものとなった。いまや、Linuxという名前は、UNIXという名前の存在感を上回る大きさを備えている。そして、WindowsとLinuxは、UNIXという価値観を介すことなく直接向かい合っている。OSとしての価値だけでなく、企業、思想、社会運動などのさまざまな思惑が絡み合い、両者の関係は極度に冷え切ってしまったといえる。
いま、Windowsが自発的にLinuxとの相互運用性を積極的に求めていく理由は考えにくい(「Windows Services for UNIX」というソフトウェアもあり、結果的にLinuxとの相互運用性を高めることに寄与していることも事実だが、その対象はLinuxを含む“UNIX”であって、Linuxに限定されない。Linuxを含むUNIXとの相互運用性改善策は見られるものの、Linux限定の策は見られないように感じる)。逆に、Linuxが、より多くのシェアを持つWindowsを切り崩すためにWindowsとの相互運用性を高める動きはある。しかし、Windowsのファイル・サーバになるといったレベルでは成果が見られるものの、Linux上でWindowsアプリケーションを稼働させる試みについては、実用レベルでは成功しているとはいいにくい。つまり、相互運用性は限定的にしか得られていないといえる。
それにもかかわらず、まだWindowsとLinuxの間にある程度の相互運用性が保たれている理由は、インターネットという開かれたネットワークの存在があるためだろう。インターネットを経由して通信を行う場合、通信相手のOSが何であっても、通信を成立させる必要性が発生する。それ故に、特定OS固有の技術をインターネット上に持ち出すことは受け入れられないことが多く、どうしてもインターネット標準に準拠する必要があり、それを介してWindowsとLinuxの間には最低レベルの相互運用性が確保されることになる。それによって、例えば、Windows付属のftpを用いて、Linuxマシンにファイルを転送するような作業は、依然として良好な相互運用性を保ったまま維持されている。
しかし、インターネットに直接依存しない処理については、そのような強制力は働かず、非互換性が拡大する傾向が生じる。その典型的な例が、Webアプリケーションを開発するためのフレームワークであるASP.NETだろう。ASP.NETはWebのコンテンツを提供するためのサーバ側で動作するプログラムを実現する。送信されるコンテンツそのものは、単なるHTML文書であるため、必ずしもクライアント側を特定OSに制限するわけではない。その点で、相互運用性が維持されているように見えるが、コンテンツを生成するプログラムは特定OSに強く依存しており、OS選択の自由度は著しく制限される。例えば、ASP.NETでWebアプリケーションを開発してしまった場合、それを継続して運用していくためには、常にサーバOSとしてWindowsを使い続けねばならないという拘束が生じてしまう。
だが、驚くなかれ、そのような拘束を打破してしまうプロジェクトが世の中には存在している。ASP.NETを、Linuxを含むUNIX上で動作させてしまうというのである。それは、「Mono」と呼ばれるプロジェクトである(ここで、Linux上でWindowsアプリケーションを稼働させることができていないのに、同じWindows上の技術であるASP.NETならできるという話はウソくさいと思った人は、次のコラムを読んでいただきたい)。
[コラム] Windowsアプリケーションは無理でもASP.NETアプリケーションならLinuxでも動く(かもしれない)理由 |
果たして、本当にASP.NETアプリケーションが動作するのか。長い前置きになったが、実際にLinux上で動作させてみた体験記を書いてみたい。
ここでは、Fedora Core 2とMono 1.0.1を使用してみた。Fedora Core 2は、Linuxの有名ブランドであるRed Hatの実験的な無料Linuxディストリビューションである。そしてMono 1.0.1は、Mono Projectが開発した.NET Framework互換環境であり、Linuxなどで動作するC#コンパイラ、BASICコンパイラやASP.NETの実行環境を含むオープンソース・ソフトウェアである。
INDEX | ||
[特集]Linuxで動く.NET環境「Mono 1.0」の実力(前編) | ||
1.WindowsとLinuxとを結ぶ「Mono」 | ||
2.Monoが生まれた背景 | ||
3.Monoの機能とインストール | ||
4.C#コンパイラとVB.NETコンパイラ | ||
[特集]Linuxで動く.NET環境「Mono 1.0」の実力(後編) | ||
1.バイナリの互換性を検証する | ||
2.環境間の相違と対策/Monoと.NET Frameworkとの速度比較 | ||
3.XSPを用いたASP.NET | ||
4.Apacheを用いたASP.NET | ||
更新履歴 | |||||
|
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|