さまざまなアーキテクチャで動作するバイナリ仕様「FatELF」、頓挫 31
ストーリー by hylom
「太ったエルフ」 部門より
「太ったエルフ」 部門より
あるAnonymous Coward 曰く、
マイコミジャーナルで紹介されているが、LinuxやFreeBSD、Solarisなど複数のアーキテクチャで動作するバイナリ仕様「FatELF」の開発が頓挫したようだ。
FatELFは複数の異なるアーキテクチャ向けのバイナリを1つのファイルに収納するフォーマット。Mac OS XではPowerPC向けバイナリとIntel向けバイナリを同一のファイルに収納できるが、これと似たようなものを想定していたようだ。
開発者のRyan Gordon氏は、中止の理由としてFatELFの利点がなかなか理解されなかったことを挙げている。
しかし、実際のところ例えば「WindowsとLinuxとMac OS Xで動く実行ファイル」というものがあったとしても、それが便利か、また必要か、と問われると微妙ではないだろうか。x86とx64のように、単一のファイルで複数のアーキテクチャに対応するメリットがある場合も考えられるので、そちらの方面での活躍を願いたいところだ。
ある大学のシステムに、 (スコア:1)
僕が通ってた大学にはsparcのSolarisと、i386のLinuxでホームディレクトリを共有しているシステムがあった。
自分でインストールしたプログラムがもう片方のOSでは動かないわけで、面倒な事もあったけど結局はPATHとLD_LIBRARY_PATHを設定すれば問題なく使えるわけだ。
なのでどっちでも使えるバイナリってのは考えもしなかったな。
コンパイルするのも大変そうだし。クロスコンパイラ複数使って作るのか？それとも既にあるバイナリをコマンドでくっつけるのかな。
それにSolarisやLinuxで使えるようにってことだけど、結局はOSにパッチ当てて再構築しないといけないわけだし、理解が得られなかったのもうなずける。
でも面白そうだからやってみようって考えたのも理解できる…
Re:ある大学のシステムに、 (スコア:1)
懐かしネタというと、Sony NEWS は symbolic link に環境変数への参照を突っ込むことができましてですな。
# あとは saitoh 先生に任せた
LinuxやFreeBSD、Solarisなど (スコア:1, すばらしい洞察)
tarball拾ってmakeしてる連中相手にしてもしょうがないと思う。
Re:LinuxやFreeBSD、Solarisなど (スコア:1)
ホントに、その通りだと思います。
商用アプリケーション(ソフトベンダからバイナリのみが供給されるという意味で)がもっと繁盛してる世界だったのなら状況も違ったかもと思いますが…
とは言うものの、Javaで逃げるって手もあるわけだし、商用ソフトベンダにとってあまり魅力的な世界でもないし、fatバイナリで得をする人が少ないのは現状致し方ない気がします。fatバイナリにしようにもアーキテクチャが多岐に渡りすぎるし、エンタープライズな世界ならアーキテクチャ別にリリースした方が良い事もあるでしょうし。
個人的にはfatバイナリと言えばMacintoshに手を出したのがPowerPC604から(KT7.5.3時代、やっつけPPC対応な頃)なので非常に世話になったのですが、Macの場合は異なるアーキテクチャへの移行をスムーズに行う目的があったので必要だったし、PPCからIntelへの移行が収束しつつある現在でも必要な物だと感じています。(そうじゃないとPPC+Tigerな俺っちが泣く)
そういえばWindowsNTで4アーキテクチャ対応なfatバイナリもありましたね。
#なんかApple Computerから高級な靴べらがリリースされましたねoTL
凛々しく、あほらしく。
Re: (スコア:0)
PPCとx86の同居が役目を終えても、x86とx64の同居という新しい役目ができましたしね。
オフトピ(Apple Inc.的な意味で) (スコア:0)
Apple "Computer"て昔の社名ですよ。
Re: (スコア:0)
>商用アプリケーション(ソフトベンダからバイナリのみが供給されるという意味で)がもっと繁盛してる世界だったのなら状況も違ったかもと思いますが…
かと言って競争が激しければ一番最初に手を付けて問題無い改善場所になるという。
というか、バージョンアップでパフォーマンスを謳おうとするだけで消えてしまう可能性が。
Re: (スコア:0)
やっぱり要らないかも。
Re:LinuxやFreeBSD、Solarisなど (スコア:2)
.txt最強伝説ですね、わかります。
役に立てられそうな用途を見つけた (スコア:1)
コンピュータウイルスとかトロイの木馬とかワームとか……
Re: (スコア:0)
> コンピュータウイルスとかトロイの木馬とかワームとか……
はっきり書こうよ。「HOS」って。
--
for(;printf("BABEL "););
太ってるのは (スコア:0)
Re:太ってるのは (スコア:1)
かぼちゃとか大根のエルフかもしれない。
＃まずビート（砂糖大根）が思い浮かんだけどもマイナーだよな。
らじゃったのだ
Re:太ってるのは (スコア:1)
> ＃まずビート（砂糖大根）が思い浮かんだけどもマイナーだよな。
今年のビートは天候のせいか、小ぶりで糖度が高いという話を聞いた。
Re:太ってるのは (スコア:1)
残念ながらデバッグ用データファイル形式でDWARF [dwarfstd.org]という名前が使われていますね…
MIYAZAKI Yasushi
Re:太ってるのは (スコア:1)
「呼ばれた気が…」by 体脂肪率30％超えの妖精(4x歳独身)
Mach-O (スコア:0)
まさにその方面で頓挫 (スコア:0)
> x86とx64のように、単一のファイルで複数のアーキテクチャに対応するメリットがある場合も考えられるので、そちらの方面での活躍を願いたいところだ。
その段階ですでに頓挫したって言ってるんだろう?
特に新しいことしなくでも可能 (スコア:0)
オプソじゃないバイナリ提供ソフトのインストーラなんかで, どうしてもそういうのが必要なんて状況があったとしても
ファイルの頭をシェルスクリプトにして, そこで環境判断してファイルの適切な部位からバイナリ呼び出すとか
現状で普通にできるからな.
本気で存在意義がわからない.
Re:特に新しいことしなくでも可能 (スコア:1)
FatELF [icculus.org]のページを見ると、それと同じことをやろうとしてたみたいですよ。
で、しかもkernelとlibc、binutilsなんかを修正してまで。そりゃコミュニティにパッチを拒否されるだろうね。
コミュニティ側のコメントに、「存在しない問題を解決するために多くのコストをかける」とか、「少しの利点のためにファイルサイズやパフォーマンスを犠牲にする」 とかコメントがあったけど、全くそのとおりだと思う。
実行ファイルよりデータが大部分を占め、起動時のパフォーマンスがたいした問題にならないゲームとかなら、単一バイナリ配布はそれなりにメリットがありそうだけど、
結局こんな仕様じゃ、ファイル先頭のシェルスクリプトでの振り分けで十分だしね。本当に存在意義が分からない。
ライブラリのことは難題ではありませんでしたか? (スコア:0)
ffmpegという八面六臂の大活躍のオープンソースソフトがあるじゃないですか?
それのLinux用のrpmやdebのパッケージのサイズを調べて見てください。
で、ffmpegを含む携帯動画変換君のFFMPEG.EXEのサイズを…
同様にVLCのLinux用パッケージとWindows版VLCのパッケージサイズを…
これって、静的リンクされたライブラリ分ですよね?
これだけライブラリの扱い方に違いがあると
WindowsとLinuxで動くバイナリーって
すごく限定的な運用しかできないんじゃないでしょうか?
Windowsの50GBでも食いつぶしかねないC:と
64bit版でも5GB越えるのが難しいLinuxの/パーティションを比べて…
Windows用バイナリまでしょったバイナリーなんて…ねぇ。
Re: (スコア:0)
>64bit版でも5GB越えるのが難しいLinuxの/パーティションを比べて…
それはX-WindowやGNOMEまで入ってるのか？
Re: (スコア:0)
ハードディスクが安くなったから、NFSとかで/usrとかのバイナリを共有して容量節約する動機も薄れてるしね
(しかもSATAとかで繋がってるハードディスク程には、ネットワークの速度は速くなってない)。
X抜きでGB単位の消費は無いよなぁ… (スコア:0)
NetWalkerがなぜ4GBしか無い内蔵ストレージでUbuntu採用なのか?
3GBにも及ばないんですよ。NetWalkerのOOo,Firefox入り環境で。
少し越えて5.4GBとなっているうちの環境には
Blenderとか試しに入れたソフトまで放置されているし
GnomeとKDEの両方が入っています。
#なぜか発売してくれない→超速8GBで激安のSSD
ネイティブである必然性はあるのかな？ (スコア:0)
Javaのような中間コード形式のバイナリでもいいんじゃないのん？
とか思っちゃいましたが…。
実行効率とかはこの際無視でｗ
Re: (スコア:0)
実行効率とかあまり気にしなくてもいいなら、
それこそ ruby なり perl なりで script 書くだけで大抵のことはできちゃうからなぁ。
(Javaもコンパイルとか実行環境とか多種揃えようとするとメンドクサイ)
script なら使用メモリ量とか引っかからなければ、CPUもOSも気にせず結構使いまわせちゃうし。
そもそもどのくらいの規模？のツールに、これを適用するといいことになるのかが想像しにくい……
所謂GUI利用するものだとそもそもダメだよねぇ
Re: (スコア:0)
.NETで書いたアプリだとインストーラで、インストールの最後にその環境に合わせたネイティブコードのキャッシュ生成が、とくに手間かけずに出来ますね。JIT の欠点である起動速度も劇的に改善されてます。これのおかげで、.NET で書かれてるものでも、ネイティブアプリだと思いこんで使われてるものも多いはず。
バイナリ配布問題後の 午後のこーだ の配布形式は、この手があったかって思いましたが、今じゃインストール時にコンパイルしちゃうってことは当たり前になっちゃってますので、中間コー
Re: (スコア:0)
以前、OSFがANDF(Architecture Neutral Distribution Format)とかやってましたね。
http://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format [wikipedia.org]
更に遡るとUCSD p-Systemとか。
http://ja.wikipedia.org/wiki/UCSD_p-System [wikipedia.org]
# 多分じじいなのでAC
Windowsには昔からあった (スコア:0)
MS-DOSとWin16、MS-DOSとWin32の両方で動くバイナリとか。NEヘッダやPEヘッダの前に今でも付いてるMZヘッダは飾りではありません。Borland C++の一時期のバージョンは実際にこの仕組みを使っていて、MS-DOSではDOSエクステンダで、Win32ではコンソールアプリとして動作する32ビットコンパイラでした。
.NETアプリは、MS-DOS環境ではDOSアプリ、Windows 2000以前ではネイティブアプリとして動く3アーキテクチャ対応にもできます。
Re:Windowsには昔からあった (スコア:1)
それより前はプログラム本体よりstubに書く文をどうするか悩んだものだが。
# でもほとんど気づかれなかっただろうな…
残念、 (スコア:0)
きょうびのネット掲示板風でいくなら、太ったエルフと言うより
と言うべきだった…