こういう,複数の実装間でのバイナリ互換性を保証しようという
話は昔からありまして,UNIX System V での System V ABI (Application Binary Interface) とか,OSF でやっていた
ANDF (Architecture Neutral Distribution Format) とか,
死屍累々という感じです。
Java もある意味,似たような目標を掲げているわけですが。
LSB は,仕様書を読んでいただければわかりますが,
System V ABI の焼き直しです。
使用できる API の範囲を限定し,
それぞれの API の動作を規定し,
その範囲での互換性を保証しようというわけです。
ですね。
API の標準化は,
特定の分野について標準的なインタフェースを規定し,
その範囲での互換性を図るもので,それ自体はシステム全体としての機能を制限するものではないのですが,
ABI の標準化は,システムの提供する機能範囲を限定して,その範囲での共通化を図るという,機能を制限する方向の標準化なので,
うまく行かないのかな,という気はします。
もう一つ,Li18nux について,この関連で言えば,
I18N/L10N の機能は API 仕様だけでは閉じていなくて,
「詳細の動作はロケールの定義に依存する」
という部分が多いのが難しいところ。
ロケールの詳細定義まで標準化しないと互換性が保証できない
のですが,こちらもまた標準化がうまくいっていない部分です。
他の標準でも同じですが (スコア:2, すばらしい洞察)
LSBに準拠したプログラムはLSBに準拠したシステム上で動くことは保証されますが, LSBに準拠したシステムの上で動いたプログラムが他のLSBに準拠したシステムの上で動く保証は全く無いんですよね.
ですから
Re:他の標準でも同じですが (スコア:3, 参考になる)
こういう,複数の実装間でのバイナリ互換性を保証しようという 話は昔からありまして,UNIX System V での System V ABI (Application Binary Interface) とか,OSF でやっていた ANDF (Architecture Neutral Distribution Format) とか, 死屍累々という感じです。 Java もある意味,似たような目標を掲げているわけですが。
LSB は,仕様書を読んでいただければわかりますが, System V ABI の焼き直しです。 使用できる API の範囲を限定し, それぞれの API の動作を規定し, その範囲での互換性を保証しようというわけです。
問題は,
ですね。 API の標準化は, 特定の分野について標準的なインタフェースを規定し, その範囲での互換性を図るもので,それ自体はシステム全体としての機能を制限するものではないのですが, ABI の標準化は,システムの提供する機能範囲を限定して,その範囲での共通化を図るという,機能を制限する方向の標準化なので, うまく行かないのかな,という気はします。
もう一つ,Li18nux について,この関連で言えば, I18N/L10N の機能は API 仕様だけでは閉じていなくて, 「詳細の動作はロケールの定義に依存する」 という部分が多いのが難しいところ。 ロケールの詳細定義まで標準化しないと互換性が保証できない のですが,こちらもまた標準化がうまくいっていない部分です。