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サポートは遅々として進んでいない。

lsb01.jpg LinuxファウンデーションCTOのマーカス・レックス氏

 「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からの要望が強いことも条件だ。

lsb02.png LSB Navigatorを使えば、どのライブラリが、どういうアプリケーションから使われているかが分かる
lsb03.png LSB NavigatorはxtermやcvsといったOSSの定番から、Oracle Secure Backupといった業務アプリケーションまでカバーする。中央のパーセント表示がLSB非対応のAPI利用率

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代替の技術を推奨していくなど、さまざまなアイデアを議論しており、提案を受け付けている最中だという。

(@IT 西村賢)

情報をお寄せください:

アイティメディアの提供サービス

TechTargetジャパン

キャリアアップ


- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

ソリューションFLASH

「ITmedia マーケティング」新着記事

LINEと博報堂DYデジタル、「LINE」上での広告効果測定の精緻化を図る共同プロジェクトを開始
LINEは、同社の広告サービスにおいて、効果測定の精緻化を図るプロジェクトを博報堂DYと...

SSP「fluct」、Bulbitの全自動マーケティングプラットフォーム「UNICORN」と連携開始
fluctは、SSP「fluct」がBulbitのモバイルアプリ向け全自動マーケティングプラットフォー...

「All About」、記事型ネイティブ広告にIASのアドベリフィケーションツールを正式導入
オールアバウトは、総合情報サイト「All About」で販売および配信する記事型ネイティブ広...