FatELF: univerzális binárisok Linux-ra

 ( trey | 2009. október 26., hétfő - 16:54 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

sign up
-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

+1

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

en sem emlekszem ra. viszont nagyon hulyen nez ki, mert van egy jo nagy szakasz amikor nincs szoveg, csak a kep a jobb oldalan az egesznek.. :) (vagyhat nalam igy nez ki, ff3.5.3/win7)

Nálam teljesen jó (ff 3.5.x/xubu9.10). Az a fránya win7.

1024*768-ban nálam is, nagyobb felbontáson már nem
--
Én TUDOM, hogy igazam van. És ha nincs is, akkor is NEKEM van igazam, mert én vagyok az Admin. Ennyi!

Biztos nem a Windows 7 hibája, Kubuntu 9.04 alatt, Firefox 3.5.3-at használva is olyan, ahogy NagyZ leírta. A felbontás 1366x768 (15,6"-os WXGA kijelző).

http://noob.hu/2009/10/26/fatelf.png

a win7 csak azért kellett oda, hogy aki nem tudná, hogy windowst használ, az most megtudja

A Firefox Windows meg Linux alatt sokszor egészen máshogy viselkedik, ami nem csak abban nyilvánul meg, hogy Linuxon lassabb.

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

Pl. tapasztalataim szerint ha ugyan az a kép többször van beágyazva egy oldalba Win alatt egyszer szedi le, Linux alatt mindegyikhez külön.


Bye Bye Nyuszifül

ha valoban ki lenne kapcsolva a cache, akkor egy gmail inbox oldal betoltese 2 percig tartana, eroteljes proci- es halozati terheles mellett. szoktam igy jarni webdeveloper toolbar buzeralasa miatt. szerintem az altalad megfigyelt jelenseg nem egeszseges :)

Upsz, a WebDeveloper toolbar volt a ludas :D Thx


Bye Bye Nyuszifül

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

Ssss! Ilyet itt nem szabad mondani. Linuxon minden gyorsabb!

Jajj te "Uborkat" hasznalsz? NE!!!! zOMG!!!!111 (Az a franya Ubuntu...)

"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?" -=-

hat csak kihalt dolgokat senki sem emlit meg ;)

Sose értettem, mit foglalkoznak ennyit a filmkészítők a dinoszauruszokkal...

----------------
Lvl86 Troll

a cikk írója Intel fan:) abban pedig 3 évtizede nincs érdemi változás:)

az intel fanok is olajozasra szorulnak neha!

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

Mert a Linux közösségnek nincs is rá valójában szüksége. Mesterségesen gerjesztett igény... :)

Ki is volt a NeXT alapítója? Az Apple meg inkább megvette (több, mint 400 millióért), mint átvette az OpenStep-et és a UB-t.

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.

Live rendszereknél szintén lehet előnyös.
Esetleg ha akarom, akkor indítok egy 32 bites kernelt, mert épp arra van szükség…

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

Ilyen liveCD megoldasbol van jopar. Lehet valtogatni milyent akarsz.

Miért van szükséged 32 bites kernelre? (64 bitessel szemben) Hacsak nem 32 bites driverek használata a cél, semmi értelme.

Én már találkoztam egy focicsapatnyi emberrel, akik IA64 -re készült iso-kat töltögettek ész nélkül.

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

"Itanium Admin Team SE" :)
---
Internet Memetikai Tanszék

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. :))

Javát mindenhova! :)

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

Beb.szna! :)

>> 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.

De én meg tudom, hogy a kettő közül melyiket kell használnom. Akkor miért töltsek le egy kétszer akkora fájlt?

Fogyasztói társadalom

Mit szerettél volna mondani?

Azt hogy nem fogok helyetted gondolkodni.

Én meg helyetted megfogalmazni, hogy mit akartál mondani. :)

Kha.

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.

peldaul?

--
NetBSD - Simplicity is prerequisite for reliability

Process,network info.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

peldat szeretnek olvasni, nem tippet :)

--
NetBSD - Simplicity is prerequisite for reliability

pl. libkvm


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

kernel apirol volt szo, te meg idecitalsz egy userspace libet. tudtam, hogy az irassal gondjaid vannak,
de mostmar az olvasassal is? :)

User es kernel kozotti API rol volt szo. Olvassd el megint.
Ha megnezed mi ez library nem lesz nehez rajonnod mi koze kernelhez, nem o az egyetlen.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

jo de ezek hasznaljak a nem publikus api-t is :-)
uvm/uvm_extern.h a publikus, ha barmi mast hasznalsz u vm strukturakbol, akkor magadra vess (vagy hasznald a libkmv-et, amit stabil api)

--
NetBSD - Simplicity is prerequisite for reliability

Tehát igaza van GKH-nak, hogy az in-kernel stable api non-sense. Sőt nem csak az in-kernel, hanem a kernel és egyek library-k közötti is. :-P

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

Izé... tudtommal nem a syscall API az instabil...

igy van.

Sot meg a syscall ABI is elegge stable (adott architekturan belul persze), nem csak az API.

elegge? az evekben mit jelent? :)

--
NetBSD - Simplicity is prerequisite for reliability

Mindig visszafele kompatibilis.
pentium pro megjelenesekor ertelem szeruen uj modszer is tamogtva lett x86-on (sysenter,sysleave)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

umm, a sys{enter,leave} az hol syscall? :)

--
NetBSD - Simplicity is prerequisite for reliability

LOL :) ABI -rol volt szo.


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

valaha a MIPS alapú computerek nem a "kevés helyről" voltak híresek. könnyen előfordulhat még, hogy a kézikütyükből és routerekből és stbk világából visszaköltözik a MIPS a mainstream computerekbe. a Kínai népköztársaság jelentős háttérszelet jelent a MIPSnek.

Ú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???

jajjj???? mostmilesz??????

Már figyellek egy ideje: kezdesz egyre inkább cinikus, vén trotty lenni. Rád férne egy nyaralás valami thaiföldi szextúra formájában, hogy levezesd a stresszt. :))

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

en is oregszem.. atmenjek hozzatok dolgozni, ott van ceges (a fentebb vazolt korulmenyeket kielegito) szabadsag? ;)

Varj, mutatom hova menj :~))))))))

Nincs, viszont még szeptemberben behoztam otthonról egy gumimellett (egy testszínű labda, szilikonnal töltve, van rajta bimbó is :D), hogy a kollégák le tudják vezetni a stresszt. :))

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

Szerencse hogy most mar feltudnad rakni az "Easy CD Creatort" (en a hardcore wayt szeretem, ImgBurn-t hasznalok) mivel az 1TB-os lemezeket is csak ugy hozzadvagjak.

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.

Senki sem mondta, hogy holnap este 8-tól mindegyik disztró élni fog ezzel a lehetőséggel.

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

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.

Kibontja, lett 58Gb-nyi binárisa, meg adatfájlja, és a 320 különböző binárison egyesével duplaklikk, melyik is indul el?

"The way to find what the mainstream will do tomorrow is to associate with the lunatic fringe today." -- 1995, Jean-Louis Gassée
/ http://haiku-os.org /

Dehogy. Lesz egy runme.sh, ami ciklusban vegigmegy az osszesen!

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Imádnám. Indulási idő megnő (380*betöltési idő)-vel, rossz esetben.
"The way to find what the mainstream will do tomorrow is to associate with the lunatic fringe today." -- 1995, Jean-Louis Gassée
/ http://haiku-os.org /

Dehogy dehogy, letöltöd a packot, kicsomagolod és letöltöd hozzá azt a runme.sh-t, ami a te gépedhez megfelelő binárist indítja. És akkor rögtön márcsak az lesz, hogy melyik runme.sh-t kell letöltened :D

--
Keep it simple, stupid.

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

Ennyire sötéten azért nem látom a dolgokat. ;) Egyenlőre 2 architektúra támogatásához 2x akkora futtatható készül. Ha igaz.

sot lehetne valami olyasmi is mint a .net/mono, oh wait

--
NetBSD - Simplicity is prerequisite for reliability

É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.

Eszmeletlen osszefugges van az unibin es a zart forraskod kozott. Csoda, h eddig meg nem fedezte fel senki.

---
pontscho / fresh!mindworkz

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

lefordítás nélkül :)

Lol, you made my day.

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

"mink itt ennyire előre gondolkoztunk, amikor a gentoot választottuk"

JavaScript alapu disztribek lesznek, jOS alatt, jQuery libbel. :)

ez a jOSlatod?

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

Inkább a mondanivalójának eleje és vége között van eszméletlen összefüggés. :)

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 :)

És mennyire menő lesz strippelni a binárisokat, hogy csak a platformnak megfelelő részek legyenek benne. Aztán meg milyen forradalmi lesz az a lépés, amit most az apple lépett meg a ppc támogatás elvetésével...

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 :)

Aha kiraly, elolvashattam volna elobb a FAQ-t esetleg ... :)

+1
de akkor is marhaság