NewsInsight

LSB3.2でようやく対応APIが十分に

Linuxの標準化が進まなかった理由

2008/03/11

　Linux対応アプリケーションの多くは、サポートするディストリビューションやバージョンを特定している。典型的なのはRed Hat Enterprise Linux 4や5を前提としており、ほかのディストリビューションでの動作は保証しないというものだ。同じLinuxでもディストリビューションが違えば、カーネルだけでなく、インストールされているライブラリやコマンド、ディレクトリ構成、GUIなどに違いがあるからだ。パッケージシステム、コンフィグファイルも異なることがある。

　ディストリビューションごとの非互換性は、UNIXがSun OS、AIX、Ultrix、HP-UXなどに分裂したのと同じ過ちを犯すことなる。そうした懸念から、Linuxの標準化を推進する非営利の業界団体「Linuxファウンデーション」が立ち上がったのは1997年。以来、同団体が策定する「Linux Standard Base」（LSB）は改訂を重ね、2008年2月18日には最新版のLSB 3.2をリリースしている（参考記事：Linux標準にPerlとPythonが追加）。2006年にはISO 23360として、国際標準規格にもなっている。

　すでに36のディストリビューションがLSB 3.0をサポートしているほか、30弱のディストリビューションがLSB 3.2への対応を表明している。これはほとんどのメジャーなディストリビューションをカバーしており、中でもエンタープライズ向けは、ほぼすべてがLSBをサポートしている。

　一方、アプリケーションでLSB対応をうたうものは、ほとんどなく、わずかに3社のISVのアプリケーションがLSBの認定を受けているに過ぎない。

LSB 3.2でようやく“Hello, World！”が書けるように

　ディレクトリ構造の標準化やプリンタドライバの標準化など、LSBによって多くの成果がもたらされた一方で、10年以上にわたる標準化の努力の割にISVによるLSBサポートは遅々として進んでいない。

　「LSB 3.0までは欠けている機能というのが常にあった。“Hello, World!”を表示するプログラムを書いただけで、LSB 3.0のカバー範囲からはみ出てしまっていた」。LSBが抱えていた課題をこう指摘するのは、LinuxファウンデーションでCTOを務めるマーカス・レックス（Makus Rex）氏だ。パラメータの受け渡しに関してLSB 3.0は規定していなかったなどの理由で、最もシンプルな文字列表示アプリケーションすらLSB 3.0準拠とならない可能性があったという。「しかし、LSB 3.2ではまったく事情が異なる。われわれはISVに、どの機能（API）が欠けていてLSBに足すべきかを聞き、LSB 3.2に入れていった」（レックス氏）。

　どのアプリケーションが、どういうライブラリの、どのAPIを使っているのか。そうした具体例を統計的に調べ、LSBでの対応に優先順位を付ける試みを行っている。「LSB Navigator」と名付けられたWebサイトは、LSBに含まれるライブラリやコマンドのAPIをすべて網羅したデータベースだ。LinuxアプリケーションがOSSのもので約800、非OSSのもので約160ほど登録されている。特定のアプリケーションを選択すると、そのアプリケーションが、どのライブラリのどういうAPIを使っているか、またそれがLSBに含まれているかといったことが即座に分かる。

　LSB以外のAPIをどれだけ使っているかもパーセントで表示する。Linuxファウンデーションでは、LSBが含まないAPIに関しては、LSBに含まれるほかのAPIを使うよう推奨したり、ライブラリをスタティックにリンクしてアプリケーションに含めるよう促すという。

　逆にLSB Navigatorでライブラリを選択すると、それがどのディストリビューションに含まれるかが分かる。「LSB Navigatorを使うと、これまで知らなかったことが分かるはず」（レックス氏）。

　例えば「libbzip2」は、ほとんどすべてのディストリビューションに含まれているが、登録されたアプリケーションのいずれからも利用されていない。こうしたライブラリはLSBに入りづらい。「誰もが使っていて十分に枯れたAPIを入れるのがLSBの方針。そういう意味では仮想化関連のライブラリ“libvirt”などは、まだ早いかもしれない。いったんLSBで標準化されれば、その後バージョン改訂を行ったとしても最低限6年はサポートしていくという方針だから、慎重にならざるを得ない」（レックス氏）。LSBではサーバやアプリケーションのライフサイクルが長いエンタープライズ用途を想定し、長期的な互換性の確保を念頭に置いている。LSB 3.0向けに書かれたアプリケーションは、LSB6.0上でも動く。

　Linuxファウンデーション自体は、どういうライブラリを標準化すべきかという価値判断を行わない。民主的に開かれたLSBの策定プロセスで、ニーズが多いものからLSBに取り込むというスタンスだ。「窓のブラインドを操作するリモコンのライブラリをLSBに提案していただいても構わない。多くの関係者が必要と認めるならLSBに入ってくるだろう」（同氏）。

　PythonやPerlがLSB 3.2に追加された一方、Rubyが入っていないのも、まだ仕様が不安定なほか、英語による正式な仕様書が存在しないことも大きな理由だという。ISVからの要望が強いことも条件だ。

LSBにJava VMを入れるべきかで激論

　LSB 3.2の登場によって基本的なライブラリのサポートは一気に充実した。「今の時点でLSB 3.0やLSB 3.2に対応したアプリケーションを作成すれば、2010年にLSB5.0上でも問題なく稼働する」（レックス氏）という安定した土台ができたことは、ISVにとって喜ばしいことだろう。ディストリビューションベンダにしても「すでに古いバージョンのあれこれをサポートするためのRPMパッケージというのを山ほど提供している。それに比べればLSB対応はディストリビューションベンダに新たな負担を強いるようなものではない」（同）。Debianを代表とするコミュニティ系ディストリビューションにとってLSB対応には大きなインセンティブはないが、エンタープライズ系ディストリビューションやISVにとってはLSBの存在意義は大きい。

　現在、LSBにとって最大の懸案事項はJavaだという。

　Javaに対する要望は、ほとんどすべてのISVからLinuxファウンデーションに対して上がってきているが、多くのベンダが独自のJava VMを提供しており、特定のものを標準とするわけにはいかない。アプリケーションが特定のJava VMに依存している可能性があるからだ。大手ISVは自前のJava VMをアプリケーションとともに提供するため問題は小さいが、そうでないISVにとってはJava VMの非互換性は対処が難しい問題だ。

　ただ、Java VMを必要とする多くのアプリケーションはインストーラをJavaで作成しているだけで、比較的仕様の安定したコア機能だけで十分事足りる。そのため、LSBでJava VMの標準化を行うという案や、「Java認定を受けた何らかのJava VM」という仕様をLSBに入れるという可能性、インストーラ作成ニーズに応えられるJava代替の技術を推奨していくなど、さまざまなアイデアを議論しており、提案を受け付けている最中だという。