FatELF: univerzális binárisok Linux-ra

Címkék

Az Apple Intel processzora váltásával megjelentek az univerzális binárisok. Az új fájlformátum mind a PowerPC, mind az Intel architektúrák számára tartalmaz natív kódot, így az Apple-féle univerzális binárisok képesek natívan futni mind PowerPC, mind Intel-alapú Macintosh gépeken.

FatELF

Ennek a kompatibilitásnak nyilván van ára: az univerzális binárisok - mivel egynél több architektúra számára tartalmaznak kódot - nagyobbak a hagyományos társaiknál. Ettől eltekintve az univerzális bináris kényelmes szoftverterjesztési forma mind a végfelhasználó, mind a szoftvergyártó számára.

A Linux nem támogatja a "fat" binárisokat, de Ryan "icculus" Gordon (Linux alatt aki játszik, kizárt, hogy ne ismerné a nevét) úgy döntött, hogy változtat ezen.

A linuxos játékportjairól ismert fejlesztő létrehozta a FatELF projektet, amely végső soron megvalósítja az univerzális bináris támogatást Linux-on. Ahogy OS X-en a "universal binaries", úgy Linux-on a FatELF fájlformátum lehetővé teszi több architektúra natív binárisainak egy fájlba csomagolását. Ryan egy lépéssel tovább lépne, {Open,Net,Free}BSD és OpenSolaris támogatást is belegyúrna a projektbe.

Ryan elindította FatELF projektoldalát, ahol - egyebek mellett - arról ír, hogy a fájlformátum segítségével létre lehetne hozni olyan univerzális Linux telepítő DVD-t, amely automatikusan támogatná az x86 és x86_64 (vagy akár a Power, MIPS stb.) rendszereket. Nem lenne szükség arra, hogy a disztribútorok külön letöltéseket kínáljanak a különböző platformokhoz. Megszűnne a "most melyiket kell nekem letöltenem?" probléma stb.

Ryan projektje a következő állapotban van jelenleg: elkészült a specifikáció és a dokumentáció, a patch-ek a Linux kernelhez, a file(1) és binutils-hoz, gdb-hez, glibc-hez.

Az elmélet igazolásához elkészült egy teljes FatELF-es Ubuntu 9.04 VMware virtuális gép formájában.

További részletek a projekt weboldalán és a Phoronix cikkében.

Hozzászólások

hmm, volt már olyan, hogy főoldalra kikerült kép?:)

Máshogy viselkedik az "objektumok fókusza" is, Linuxon sokkal gyakrabban kell flash objektumra vagy magára a html dokumentumra kattintani, ha görgetni akarunk vagy input vezérelni a flash movie-kat.
Ha nincs felpakolva az ms tt core fonts csomag (és hülyén van konfigurálva a firefox default fontok tekintetében), akkor rengeteg oldal csúszik el / néz ki máshogy mint ahogy az emberek 99%-ánál (vagyis ahogy a dizájner eltervezte).
GTK-téma függő a form objektumok kinézete, mérete, színe, fontja, ami szintén szétdobhatja az oldalt.
Meg ami még nem jut eszembe.

********************
"Aki nem backupol az tehetsegtelen :-)"
"...ha nem tévedek!" (Sam Hawkins)
http://holo-media.hu

"Az Apple Intel processzora váltásával megjelentek az univerzális binárisok."

A probléma és megoldása, a "fat" binary sokkal régebbi baleset, és az Apple 68k -> PowerPC migrációjához köthető, a 90-es évek első felében, azaz jó 15 éve... Később a PowerPC-s Amigákon is ismert fogalom volt. Lásd még wikipédia.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Az OS 9 és előtti világban elég bizarr módon kezelték ezt (forkok rémlenek?). Sokkal inkább a NeXT munkásságát emelném sokadszorra ki, lásd fat binary-k a Mach-O formátumban. Először a NEXTSTEP 3.1-ben jelent meg valamikor '96 környékén. Az Apple csak szimplán átvette és - hála nekik - nem kukázta ki, hanem használta tovább.

Ahogy számolom, ennek már 13 éve, a Linux közösségben ennek szükségességére mégcsak most ébrednek rá.

--
Kinek nem inge, ne vegye gatyára

Megszűnne a "most melyiket kell nekem letöltenem?" probléma

Hatalmas probléma...

- - - - -
Tagadom a Microsoft Windowst. Szerintem ilyen operációs rendszer nincs és nem is volt soha. A létezése nem igaz, meg sem történt. Egyszerűen nem hiszem el, hogy van. Nem hiszek a létezésében és abban sem, hogy ilyen.

Lehet kacagni de elsore mikor megvettem a Q6600-at es ujdonsagnak szamitott, azt hittem hogy az is IA64 es az kell hozza. Sehol nem talaltam relevans infot, csak annyit hogy van amd64 ami minden 64esre, meg IA64 ami Itanium. Mondom jolvan. :)) Ez van. (vegul mire leert az iso, kideritettem hogy az nem nekem valo. :))

>> Megszűnne a "most melyiket kell nekem letöltenem?" probléma
> Hatalmas probléma...

Nekem epp most problema. Ki kell mennem ket regebbi gepre linuxot rakni. De nem tudom milyen hardver, igy azt sem, hogy 32 vagy 64 bites. Tehat letoltottem, kiirtam es viszem mindket telepito cd-t, pedig csak az egyiket fogom hasznalni.

Az egeszben akkor latnek fantaziat, ha ugyan az x86_64 binaris menne Solarison meg Linuxon, FreeBSD is ugy hogy merete nem novekszik szamottevoen.
Igy szerintem nem hasznalhato. MIPS,ARM cuccon altalaban hely az amibol keves van, alltalaban mar az alap libc is mas. Libc kulonbseg mar azonos arhitekturan is mas platformnak szamit nalam (uclibc,(e)glibc, newlib ...).

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

azert ha egy blender letoltheto lenne 32/64 bites binarisban azert az nem hulyeseg
vagy egy olyan program, aminek a merete mellett elhanyagolhato a bianris merete (pl jatekok tipikusan ilyenek)

kozos syscall api meg eleg fapad lenne, de nem megoldhatatlan (kerdes igazodnanak-e hozza olyan projectek, amik pont az instabil api-jukrol hiresek :) )

--
NetBSD - Simplicity is prerequisite for reliability

"(kerdes igazodnanak-e hozza olyan projectek, amik pont az instabil api-jukrol hiresek :) )"
Kezd elegem lenni ebbol a FUD -bol. Userspace alkalmazasok szamara a Linux kernel API stabil. BSD -sek inkabb nezzenek szet a sajat hazuk talyan -e teren, mert ott nem az. Nem veletlen, hogy bizonyos libiket "egyutt fejlesztenek a kernelel". Ami troll nyelven annyit tesz, hogy instabil koztuk az API.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Szerintem az volna okosság, ha pl az adat szegmenseket meg tudná osztani és csak egyszer rakná bele. Talán a debug szimbólumokkal is lehetne hasonlóan spórolni. Nem tudom, hogy ez elvileg kivitelezhető-e. Biztos, hogy jobb, mint a lib32* csomagok, amire néha sajnos rá van kényszerülve az ember.
---
Internet Memetikai Tanszék

Újabb use flag-ek megjelenése várható a Gentoo-ban.. :)

azért az ut3 linuxos portját még befejezhette vna előtte :P

Nem teljesen vilagos miert olyan nagy otlet ez, talan mas kisegit ezzel kapcsolatban.

Azok az elonyok amiket a linkelt oldal emlit, kicsit szerteagazoak, de en ugy latom mindegyik potty abban a listaban olyan, amit masfelekeppen (azaz nem berhelt binarissal) mar regen meg lehetett volna elegansan oldani, felteve ha akarjak. Ha az egyes pottyoket atgondolom, pont hogy nem a kozos binaris fajl jutna eszembe mint megoldas.

Hihi,

Amikor CD írót vettem, mellékeltek egy Easy CD Creatort, ami vagy 700 megát foglalt becsomagolva. Ha mindent kikapcsoltam, 1 Giga helyigénnyel fel is települt volna, csakhogy 60G a Winchesterem, így lemondtam az Easy CD Creator telepítéséről.

Azért mindennek van ugye határa és elég illetlen dolog lenne a Krusader-hez úgy binárist kiadnunk, hogy a kdelibs/... bele van csomagolva.

Mert ugye: két paneles fájlkezelő és 500 megát foglal??? vagy elfelejtették kiszedni a pornóképeket a repo-ból??? vagy miért ennyi???

Akkor tekintsd át hogy az indítható binárisok meg a mellékelt libek mekkora helyet foglalnak el abból a 700 megából, szerintem az nagyrészt artwork.
És egyébként is OMG, tessék használni CDBurnerXP Pro -t ( 4.2 MiB setupostul ) és/vagy ImgBurn -t ( 2.1MB setupostul ).

********************
"Aki nem backupol az tehetsegtelen :-)"
"...ha nem tévedek!" (Sam Hawkins)
http://holo-media.hu

Nem szeretem az ilyet. Megint az van, hogy ahelyett, hogy gondolkodnának a felhasználók, a fejlesztők kénytelenek beledrótózni valami egyátalán nem elegáns, behemót megoldást a programjaikba/rendszereikbe.

--
Keep it simple, stupid.

Mért nem csomagolják be az összes architektúrára összes oprendszerre lefordított kódot egy .tar.gz-be, vagy valami más konténerbe, ami minden érintett oprendszeren kicsomagolható. És akkor a felhasználónak nem kell választania a sok letöltés közt :)

Na nem akartam negatív lenni, de nem tudom kinek fog ez tetszeni. A usernek biztosan nem.

Hát kb ugyanaz. Itt is ki lehet tömöríteni a számodra szükséges részt i386 vagy akármi. Csak egy kicsit nehezítettek a user dolgán, mondhatjuk most. Csak nehogy elterjedjen, és elfelejtsük, h ki lehet tömöríteni. Aztán egyszer arra ébredünk, h az ubuntu 5x akkora lett (vagy tudomisén mennyi architektúrát támogatnak). Hajlamos az ilyesmi megtörténni.

csaknem – meglepne, ha a processzor-architektúrákban minden hívás egyedi és rá jellemző lenne.
B verzió, hogy úgy fog picit működni, mint a Java, valami virtuális gépféleségben ami jól lefordítja az architektúraspecifikus dolgokat valami közös nyelvből.

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Én baromságnak tartom, ráadásul, az opensource-vel teljesen szemben megy, (tudom zárt kódú driverek lehetnének, amik evekig használhatóak, és így használhatsz évekig szemetet.....), de az opensource filozófiájával abszolút ellenkező. Mivel szerintem a kutatások , és a fejlődés legnagyobb kerékkötője a szabadlamak, és a zárt kód, én is csatlakozom Ryan Gordon-hoz.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

télleg, mikor jön már az, hogy minden binary disztrib rossz, mert backdoorokat csempésznek a computerekbe az ellenőrizhetetlen bináris csomagjaikkal?:) meg vendor lockin, mert nem is kompatibilisek a binary .rpm és .deb csomagok:) és csakis kizárólag forrásalapú disztribúciókat szabad használni:D

Nagyon jó kezdeményezés, az Ubuntu Software Center mellett ezt látom a mostani újdonságok mellett olyannak, ami hosszú távon nagyon lendíthet a Linux elterjedésének ügyében :)

Megszűnne a "most melyiket kell nekem letöltenem?" probléma stb.

lesz helyette "most benne van-e azaz arch ami nekem kell" probléma

Csak legyen modszer ra, hogy "kivagjam" a nekem tetszo reszt, es a tobbi ne foglaljon helyet feleslegesen :) Igy akinek gond az architektura kivalasztasa, tobbfele download stb az hagyja ugy ahogy van, akinek nem, az szepen "le-strip-peli" a nem kello reszeket :)