FatELF: jeden inst. balík pro všechny architektury

Phoronix odkazuje na projekt FatELF Ryana Gordona, který má za cíl vytvoření standardu pro "univerzální binárky" pro linuxové systémy (po vzoru Mac OS X, kde jsou k dispozici binárky spustitelné na platformě PowerPC i Intel). FatELF by distribucím umožnil poskytovat vždy jen jeden balík pro všechny podporované architektury najednou.

26.10.2009 09:26 | Robert Krátký | Zajímavý software

Komentáře

[belisarivs]

Nechtel bych to zavrhovat, ale nedojde k poklesu vykonu nebo narustu spotrebovane pameti vysledku?

[Boris Dušek]

Podle toho, jak tomu rozumím, tak to jedině spotřebuje víc místa na disku (je tam kód pro více architektur), a pak už jen loader binárek operačního systému podle hlaviček najde kódovou sekci přislušnou současné architektuře a tu a jenom tu načte do paměti. Takže paměti víc ne, místa na disku ano. Prostě jako kdyby měl člověk 4 separátní binárky, jen pro snadnost distribuce je to v jednom souboru.

[Boris Dušek]

4 separátní -> N separátních (4 mi tam vklouzly proto, že zrovna na Macu je maximální varianta se 4: i386 x86_64 ppc ppc64; na linuxu jich tam může být víc)

[belisarivs]

Zajimave. A mista na disku to sezere kolik? Nekolikanasobne vic (podle poctu architektur)?

[default]

Například TextEdit (příklad dodávaný s Xcode) — velikost binárky, nikoli celého bundelu:

• i386: 188 KB
• x86_64: 252 KB
• ppc: 216 KB
• ppc64: 312 KB
• i386 x86_64: 444 KB
• ppc ppc64: 532 KB
• i386 x86_64 ppc ppc64: 972 KB

[Vykook]

Hodnotna by byla spis velikost bundlu, protoze samotna binarka toho nemusi zabrat az tak moc. Ja sem ted bohuzel jen u SL, takze to nejsem schopen zjistit...

[default]

V bundelu neni nic jinýho, než vobrázky, nějaký XML nesmysly a pár NIBů. A to se s platformou nemění. Takže si k tomu přičti konstantních 732 KB.

[Vykook]

Ano, u textmate to tak urcite je, ale u nekterych programu muze bejt tech platformne nezavyslejch veci pomerne dost...

[Vykook]

Pardon, spletl jsem si textedit s textmate...

[default]

Nevadí.

[wintermute]

Nieje na to ziaden dovod. Ta binarka obsahuje viac sekcii s kodom pre kazdu platformu (podobne ako binarky na MacOS) a do pamate sa mapuje len sekcia pre danu architekturu takze pamat to zaberat nebude. Leda tak disk. Vplyv na vykon to ma nemeratelny ak vobec nejaky.

[Salamek]

to jako znamena ze na i386 procesoru si nainstaluji balik a budu tam mit navic i x86_64,ppc,arm,etc? ? co ten pan huli ? to abych si pak misto 20GB na / daval 60GB

[majvan]

Co takto dat na 100MB distribuciu typu System CD Rescue binarky vo formate FatELF a toto CD spustat na mnoho architekturach a konfigurovat pre svoju potrebu len na jednom USB kluci?

[Salamek]

to uz by tak spatne nebylo

[Jendа]

Ale úplně stejně na tom CD můžeš mít N kernelů a N squashfs obrazů (nebo co je libo, co používáš pro liveCD), každý pro jednu architekturu. Ale nevím, jak by to takové multikulti CD řešilo se zavaděčem.

[Salamek]

normal grubem,vyberes ktere jadro zavest ... v podstate by sly udelat v pohode DVD i386/x86_64

[Jendа]

Jak spustíš x86 GRUB na ARMu?

[Salamek]

a na to sem nemyslel

[Limoto]

Tohle ti ale žádnej FatELF nevyřeší...

[Jendа]

No vždyť jo.

[M. Lox]

Das U-Boot?

[Michal Kubeček]

Těch 20 GB vám zabírají programy a dynamické knihovny?

[Salamek]

to ne, momentalne jsem na 5,5GB, ale obavam se ze pri FatELF by mi tech 20GB co mem ted pro / bylo opravdu malo

[l4m4]

Tak toto by skutečně byl důvod pro změnu distribuce -- ve směru pryč od té, která to zavede.

[Každému vyhovuje něco jiného]

Gentoo tohle s největší pravděpodobností nezavede.

[Amarok]

Arch doufam taky ne. Pri castem updatu by to byl pekny rozdil, jednou za par dnu to dela i download 150 Mb, nechtel bych misto toho stahovat 350. Spis si myslim, ze se toho chytne par distribuci a vetsina zustane u stareho osvedceneho zpusobu...
A nejde jen o CPU architekturu, jde i o optimalizace, nektera distra optimalizuji pro rychlost apod., to by ten clovek pak taky rozlisoval?

[AHAHA]

IMHO to neni ani tak urcene pro distribuce jako spis pro externi dodavatele software. Uzivatel si potrebuje nainstalovat nejaky software a misto aby dlouho hledal, ktery ze to zrovna balicek je vhodny pro jeho system (hodne BFU rozdil mezi AMD64 a i386 neznaji) si stahne univerzalni.

[Amarok]

To v tom pripade ma resit uz www stranka s downloadem, pomoci skriptu zjistit OS a CPU a je to. Jinak taky existuji prece konvertory mezi balickovymi formaty, stacilo by je trochu dal vyvijet, aby to bylo pouzitelnejsi.

[AHAHA]

To v tom pripade ma resit uz www stranka s downloadem, pomoci skriptu zjistit OS a CPU a je to.

To je take reseni. Moznost volby je ale dulezita.

Jinak taky existuji prece konvertory mezi balickovymi formaty, stacilo by je trochu dal vyvijet, aby to bylo pouzitelnejsi.

Konvertory IMHO nejsou resenim. A tohle se prece balickovymi formaty nezabyva ...

[l4m4]

To se samozřejmě dávno dělá a není k tomu zapotřebí dávat různé architektury do téže binárky.

[Luboš Doležel (Doli)]

Líbí se mi, že to dělá zrovna Ryan Gordon. Že by byly hry jím portované v budoucnu pro více hardwarových platforem?

[Andrej Herceg]

Pár dní dozadu o Fat Elf písal aj Erik de Castro Lopo (okrem iného autor knižníc libsndfile a libsamplerate). Hlavný problém pre FLOSS projekty vidí v tom, že UB knižnice/programy budú nedostatočne testované (keďže autori takých knižníc/programov nemajú prístup ku všetkým architektúram, na ktorých by to malo fungovať).

[LangPa]

S tímto nastane hodně problémů a příjde mi že to nepřinese kýžené ovoce. Třeba prelink, první komplikace co mě napadá, prostě se prelink vynechá, což bude škoda. Dále potom nárůst místa na disku.. Universální balíčky ok, ale nešlo by to i jinak s již otestovanými metodami? vždyť i instalační skripty v balíčku by dokázaly detekovat správnou architekturu a nahrát jen potřebné soubory pro konkrétní architekturu. Balíček bude jeden velký distribuovaný na nějakém médiu a vždy se z něj vezme akorát to potřebné a to pro potřeby distribuování stačí. Jinak nevidím moc smysl, krom architektury amd64 s x86 chrootem, to by byl jediný přínos pro takovýto formát ELFu.

[Nicky726]

No minimálně na záchranná CD/USB by to mohlo být šikovné. Univerzální instalační médium taky nezní úplně špatně. A když to bude i na disku usnadní to upgrade PC...

[Limoto]

Šikovný? Protože nebudu muset na 64b systému mít 32b userspace?

[Salamek]

univerzalni nezmanena jen x86

[Limoto]

A jak uděláš univerzální bootloader?

[Salamek]

nijak,ae to uz resis uplne jinou vec

[Limoto]

Já na to narážím od začátku. Jenom tobě to došlo až teď...

[default]

Kydž vyjdu z předpokladu, že stroje s PowerPC procesory používají něco jako OpenFirmware (nebo jak se to jmenuje), tak to zase takový problém nebude. Třeba instalační DVD Fedory umí nabootovat jak přes BIOS tak přes EFI.

[Grunt]

O čem je furt řeč? Bootloader vy stylu GRUBU nebo Lilo používá jenom x86 platforma. Většina ostatních umí Linuxové jádro načíst už v BIOSu(či spíše jeho ekvivalentu).

[vlastikroot]

Tak by se vybraly různé nejčastější metody bootu různých zařízení, jako třeba x86 bios, openfirmware, efi, u-boot a přizpůsobil by se tomu iso obraz. Třeba na ARMovských platformách je kernel samorozbalovací, nepotřebuje externí bootloader, stačí ho nakopírovat do paměti a pustit. Určitě by to nějak šlo, kdyby se oběvil někdo, komu by se to hodilo (ale o tom pochybuju).

[Grunt]

Doporučuju se podívat jak se bootuje třeba takové OpenWRT. Je třeba brát v úvahu, že x86.

[vlastikroot]

Tak já vím jak to funguje na takových zařízeních, ale kdo bude na routeru bootovat live CD ? IMHO celá tahle pakárna s bundlovanýma binárkama je dobrá zas a pouze pro proprietární soft, tam se tvoří takové prasárny ... Ohledně bootloaderů - na x86 se už multi-kulti instalační média dělají (na archu byl myslím pokus, snad to v dalším vydání bude oficiální), jinde to potřeba není.

[Grunt]

Tak já vím jak to funguje na takových zařízeních, ale kdo bude na routeru bootovat live CD ?

No tim jsem chtěl říct, že na ARMech a jiných platformách než x86 to není o moc jiné. Co zařízení, to jiný druh startování. LOAD MBR do 0x7C00 - 0x7DFF; JMP 0x7C00 platí jen na x86. Ti vyspělejší umí už spouštět ELFy.

[vlastikroot]

Tak já v ruce žádnou mašinku co by pouštěla kernel v ELF formátu neměl (i když třeba u-boot to umí, ale to už je externí bootloader) ... všechno to prostě někam skočilo, a náhodou zrovna tam, kde začínal kernel v flash (občas dokonce uplně přímo na začátku flash). I když, pokud beru na ARMu bootloader jako obdobu BIOSu na x86, vyjde to pak nastejno.

[Grunt]

Vždyť jo. Mají bootloader a ne BIOS. Proto je nesmysl uvažovat o nějakém multi-GRUBu nebo co. I když to je vlastně i nesmysl přemýšlet i o nějakém multi-Linuxu nebo co, ale to nechme prozatím stranou.

[Vykook]

Prilis plasite, da se predpokladat ze se tak budou sirit akorat closed source veci, pokud vubec neco. Nehlede na to, ze urcite vznikne program na stripovani tech binarek. Pro OS X existuje a proste odstrani namy zvolene platformy(doporucuji pouzivat pouze za strizliva ) .