FatELF: nem túl fényes jövő

 ( trey | 2009. november 5., csütörtök - 16:39 )

Nemrég volt szó a FatELF-ről. Icculus projektje univerzális bináris támogatást hozhatott volna Linux-ra és később akár más operációs rendszerekre is. A fejlesztő most frissített infókat tett közzé a FatELF témában.

Icculus arról ír, hogy a kernelfejlesztők nem fogadták az ötletét jól. Sőt. Volt, aki megértette mit szeretne, volt aki nem, de a fogadtatás rosszalló volt.

Emellett a Software Freedom Law Center sem válaszolt még a szoftverszabadalmakat feszegető levelére. Igaz, még csak néhány napja küldte el. Ügyvédre költeni - feltehetően a szabadalmi dolgokkal kapcsolatos kérdések tisztázására - jelen helyzetben kidobott pénz lenne.

De, ha netán meg is győzné a kernelfejlesztőket a patch-ek beolvasztásáról, akkor következő lépcsőfokként meg kellene győznie Ulrich Drepper-t, hogy fogadja be a glibc patch-eket. Erre sem lát sok esélyt, főleg mivel erre már most jelek utalnak.

Éppen ezért Icculus úgy döntött, hogy a FatELF ennyi volt. A weboldalt archeológiai okokból meghagyja. Csalódottságát nem rejti véka alá.

A bejegyzés itt.

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

Mindamellett, hogy értékelem Icculus - főleg a játékok portolásában végzett - munkásságát, nem sok értelmét láttam a FatELF-nek azután, hogy mennyi mindent kellene patchelni miatta. Ha pedig patent aggályokat is felvet, akkor jobb is így.

Mondjuk azt nem értem, hogy ha a Linux fejlesztőknek nem kell, akkor miért adja fel automatikusan. Voltak ott Solaris, BSD tervek is.

--
trey @ gépház

Vagy miért akarja mindenképpen a mainline kernelbe rakatni. Csinálhatna egysaját patch készletet ami tartalmazná a megoldását. Pampoghatnának a fejlesztők..

Én nem bánkódnék a helyében. Kiraknám az oldalamra hogy továbbfejlesztettem az ötletem: SlimELF! És már meg is valósult!!!

"Please don't infect GNU/Linux with this completely braindead crap!"
Hat nem csoda, hogy elveszti a kedvet ilyen fogadtatas lattan ...

Haha.. De egyetertek a velemennyel. Semmi ertelmet nem latom a dolognak.

Amig egy csomo geek fejleszi a linux egy csomo geek-nek nincs is semmi ertelme.

Viszont van egy csomo ember a vilagon, akiknek fogalmuk sincs es nem is akarjak megerteni mi a kulonbseg 32-bit es 64-bit OS kozott, csak leszeretnek tolteni az adott programot es hasznalni.

A geeknek meg lehetnenek segedprobgramok, amivel ki lehet szedni a folosleges arch-ot a binarisbol, hogy tudjak hasznani az osszehackelt netbookjukat a 2GB-os SDD-vel.

Amit nem ertek, hogy miert nem probalkozik eloszor az ELF specifikacio kiterjesztesevel az egesz vilag azonnali megyozese helyett, a kezdeti prototpusok utan.

Az egesz hozzaaallasat nem ertem, de szamithatott volna erre a reakciora. Mint mar irtak, eloszor inkabb patchek / live imagek formajaban demonstralni, valamifajta specifikaciot osszeutni (nem v1 mint most), es akkor talan.

De amugy nem geeksegrol van szo, csak 2x akkora fajlokat en nem TUDOK letolteni. Egyszeruen nincs annyi savszelessegem. Fasza hogy ez neki tetszik meg elvezi amit csinal, de rohadtul nem kenyelmes _szerintem_. Igy is DeltaRPM-re szorulok.

Úgy tűnik, hogy a szerző sem biztos abban, hogy ez szabadalom szempontból rendben van - különben miért írt volna az SFLC-nek. Kinek hiányzik egy újabb "szabadalmat sért a Linux" balhé? Épeszű vezető erre nemet mond.

--
trey @ gépház

hát persze, pont mint az exFAT esetében, mi?

Mi is itt az összefüggés?

--
trey @ gépház

"Kinek hiányzik egy újabb "szabadalmat sért a Linux" balhé? Épeszű vezető erre nemet mond"

Nyilván értettem, hogy mit írtam. Azt nem értem, hogy mi köze van a kernelfejlesztőknek és a mainline kernelnek egy külső cég és a Microsoft megegyezéséhez.

--
trey @ gépház

a TomTom sem azért került bajba, mert kernel szinten támogatták a gépeik a FAT rendszert, hanem csak azért mert támogatta. ha FUSE FAT támogatást használt volna, akkor is beperelik, ha lenne ilyen persze. eléggé evidens ez a párhuzam. pure linux kernelt senki sem használ. ha disztribúciókba/eszközökbe bekerül az exFAT ugyanúgy per lehet belőle. a Ms is a TomTomot perelte, nem az OSDLt, vagy Linust személyesen.

"Aha"

--
trey @ gépház

multiplatform livecd? azt kicsit nehéz lenne összehozni:) a FatELF csak userspaceben működött volna. Icculus valószínűleg főleg játékokhoz szánta volna, ott pedig elenyésző a binárisok mérete a hatalmas grafikai és hang tartalomhoz képest. 1GB helyett lenne 1.1GB egy ilyen FatELFes játékcsomag.
viszont erre most is adott a lehetőség az install script esetében. azzal is lehet kezelni a több szoftver és hardver architecturát, akár egyetlen fájlon belül is. az installált állományokat ma már ritkán mozgatják kézileg, pláne platformok között.

Ennél azért többről volt már szó. Már olyanról is szó volt, hogy óriási kernelmodulok szállítására is milyen jó lenne.

http://thread.gmane.org/gmane.linux.kernel/904188/focus=907811

--
trey @ gépház

ilyen szinten még az OSX sem csinálja. Icculus elvetette a sulykot.

Az osx kernel modulok is unibinek.

---
pontscho / fresh!mindworkz

ez esetben túl erős volt a "Please don't infect GNU/Linux with this completely braindead crap!" megjegyzés. sőt...

Egy linket kaphatok erre? Ki mondta ezt, hol és milyen szövegkörnyezetben?

--
trey @ gépház

tessek Gondoltad en talaltam ki? ;)

Megtaláltam én is. A kérdés, hogy kicsoda az úriember. Idézgettek egy levlistán elhangzott személyes véleményt valakitől, mintha az legalábbis a kernelfejlesztők közös nyilatkozata lenne. Ez kb. olyan, mintha egy indexes kommentel érvelnél az LKML-en.

--
trey @ gépház

Te linkelted be fent a threadet, en csak vegig olvastam ;)

Aha, mi?:) a szövegkörnyezet sem tünteti fel jobb színben, ezt az arrogáns kijelentést. elsőre eléggé meredeknek tűnik, de a gyakorlat bizonyítja, hogy működik. ilyen és hasonló "crap" ötleteknek köszönhetően USAben már 15% körüli részesedésre küzdötte fel magát a Mac, hasonló minimál szintről, mint ahonnan a desktop linux évek óta képtelen elmozdulni.

Ez egy opcio, ha neked nem futja nagyobb savszelessegre, akkor olyan distribet fogsz valasztani ahol nem tomik az elf-et mindenfele architecutraval. Megteheted, mert geek vagy.

Viszont az atlagos Joe 6Mb/sec internet csomagot kap az USA-ban, a tv, telefon, popcorn csomag melle. Tovabba fogalma sincs mi az a delta rpm es nem is erdekli. Es az USA egy kicsit nagyobb piac mint Mo. (Persze ha a kinai piacra akarsz betorni ahol 1Kb/sec az atlag ez egy masik tema.)

"Viszont van egy csomo ember a vilagon, akiknek fogalmuk sincs es nem is akarjak megerteni mi a kulonbseg 32-bit es 64-bit OS kozott, csak leszeretnek tolteni az adott programot es hasznalni."

Repository.

ezek szerint az OSX meg van fertőzve egy ilyen "completely braindead crap"pel:)

Lassan kigyógyul.

Ezt hogy érted?

Tudsz futtatni Snow Leopardot PPC-n?

Vajon mennyi koze van egymashoz a PPC arch-nak es az UniBinnek? Varj, koltoi volt a kerdes, mert azon kivul, h az is beleteheto semmi. Amugy megsugom csendesen, a 10.6 irgalmatlan sok PPC kodot tartalmaz, meg kernel szinten is.

---
pontscho / fresh!mindworkz

Akkor futtass PPC-n Snow Leopardot. Hajrá!

(Ha az unibin azért jött létre hogy zökkenőmentes legyen a váltás PPC-ről x86-ra, és lassan kihullanak a PPC-s részek a rendszerből, így okafogyottá válik a technológia, akkor most min is rugózol?)

A dolog nem lehetetlen, csak tul maceras es valoszinuleg nem lenne jobb, mint a Tiger azokon a gepeken, ezert nem foglalkozik vele senki. Masreszt egyaltalan nem valt oka fogyotta a technologia, mert nem csak i386 letezik, hanem x86_64 is. Az is egy binarisban van, nincs ilyen szanalmas szuttyoges, h /lib64, nem kell ket (tobb) binarist adminisztralni egy bundleban, stb. Harmadreszt akad olyan lib is amiben nem csak i386, x86_64 van, hanem arm is, de olyan is, amiben arm es armv7 szerepel, mint peldaul az iPhone SDK-ban. Es akkor a sokak altal mar beharangozott tabletrol meg szo sem esett.

Ez a "baromsag" mocskos mod megkonnyiti tobb arch tamogatasat ugy, h az ember esze nem all kette, mert adminisztralnia kell ezer fele helyen, h melyik binaris merre talalhato, hogyan linkelje, satobbi. Ehelyett mindenutt ugyanaz a lib/binaris/bundle/plugin neve, utvonala, az os ugyis el tudja donteni, h o most min fut, melyiket kell hasznalnia. Ha meg nem tetszik, akkor fogsz egy multilingualt, es kihanyod a szuksegtelen libeket.

Nem az x86/ppc valtas miatt jott letre, ez egy eleg regi technologia, lassan egy evtizedet hagy maga utan. Most mindossze atneveztek, h a marketingesek se unatkozzanak. Nem ez a "brainless", hanem ez a /lib64-zos, System64-zos "dll hell".

---
pontscho / fresh!mindworkz

Hogy csinálod, hogy a végén egyetértek veled, nem tudom... Respekt.

Amit te annak minősítesz, az valójában remekül működik és életképes dolog. Nekem otthon van Mac-em két architektúra típusból és nem kicsit egyszerű alkalmazásokat hurcolászni köztük vagy egyszerűen ugyanazt telepíteni egyiken és másikon.

--
Kinek nem inge, ne vegye gatyára

Hint, Irónia!
"<< idézőjel:)

Így eléggé utána olvasva a linkeken keresztül, én mondjuk nem használtam volna (így is túl sokat foglalom a hálómat, hogy csak a tényleg telepített csomagokat töltöm le nem az egész telepítőt, nemhogy még minden architektúra bele is legyen csomagolva azokba). Viszont dicséretes, hogy ha van egy ötlete, akkor megpróbálja megcsinálni. Ez volt a piackutatás rész, ahogy elnéztem (Október 23-án jelentette be a projektet és November 5-én derült ki itt a HUP-on, hogy le is állítottat). Ezek után igazán nem értem miért dühös (ahogy azt kifejtette, hogy őt is meglepte), nem minden piaci ötlet jön be. Legalább megvizsgálta, nem csak szájhősködött róla, hogy lehetne egy ilyet csinálni :). Majd valaki aki akar bele még több munkát fektetni, az folytatja, ha lát benne fantáziát.

+1

Icculusnak ez főleg a játékok miatt jött volna jól. de a probléma ott van, hogy a gnu/linux belátható időn belül úgysem lesz mainstream játékplatform. inkább Javara kellene fejlesztenie, ha új projektről van szó. portolásnál persze meg van kötve az ember keze. majd a Native Client, ha egyszer készen lesz. ott lenne helye egy ilyen ötletnek.

ulrich drepper: the enemy of open source

--
NetBSD - Simplicity is prerequisite for reliability

Nem bánom, szerintem is ,,braindead''. Inkább látnék fantáziát egy afféle közös install megoldásban, hogy pl. ha i386 a platformom, kiválasztom azt és letöltöm a gépemre a csomagot, elindítom és majd megoldja helyettem azt, hogy épp deb csomag, vagy rpm vagy bármi. Szerintem sok felhasználónak gyűlik meg a baja ezzel, főleg kezdőknek.

--
Keep it simple, stupid.

A Slashdoton írta egy illető (egész véletlenül az, aki a MacOSX fat bináris betöltőjét tartja karban, tehát nem ért hozzá), hogy nem csak architektúra, hanem disztribúció markerek szerint is meg lehetne különböztetni a binárisokat a fájlban...

Üdv,
Gergely

Egész virtualizációs rétegeket kéne mindenféle függőségekkel együtt belegyömöszölni mindenféle fájlba a hecc kedvéért.

A vilag kezd vegleg elveszni.

Ez egy lehetoseg lett volna arra, amit a win jelent. Eloszedek egy 10 eves cdt, beteszem es megy, sot, ez ma is mehetett volna minden gepen.
Nem ez mentette volna meg a fizetos dvdn terjesztett tartalmat, de ez kezdte volna az osvenyt taposni, egyszeruen ms es minden egyeb cegnek alapveto erdeke, mert a lemeradas olyan sulyos lesz hogy azt nem lehet leirni ..... ebreszto minden szoftvefejlesztonek, mostantol csak web cimek lesznek es web alkalmazasok, ez van. Majd megyonk unokakkal retro boltba retro sw dvdt vasarolni, hogy nezd, ehhez igy lehetett anno hozzajutni es nem fogja erteni hogy hogy lehetett igy elni, vagy reggel wcre menni.

Rossz volt a marketing. Nem "zsíros"-nak kellett volna nevezni. Ez az amúgyis elhájasodott amerikaiakban (gyk. pizza zabáló, diétás kóla nyelő zsíros hajú igénytelen amcsi linux kóder) csak undort kelt (saját maguk iránt).

Ha MultiELF, CombinELF, stb. stb. néven hívta volna, már több esélyt adott volna magának :)