Linuxové distribuce jsou často k dispozici pro několik architektur. To mohou někteří výrobci považovat za překážku, musejí totiž svoje programy šířit v několika variantách. Klasickým příkladem je třeba x86 a x86_64. V budoucnu se možná začnou více rozšiřovat ARM procesory. Tady ale výčet nekončí. Např. Debian je k dispozici hned pro 12 architektur. Ryan Gordon, vývojář, který se angažoval v mnoha linuxových projektech, by rád na Linux dostal vlastnost známou z Mac OS X. Jde o univerzální spustitelné binární soubory, které je možno spouštět jak na PowerPC, tak na x86. Nevýhodou jsou větší výsledné soubory.
Ryan Gordon chce v Linuxu univerzální spustitelné binární soubory
30. 10. 2009
21
nových názorů
-
Nevím, co je na tom nápadu tak super, že ho postupně nadšeně předkládají všechny linuxové servery.
Mac OS X podporuje 2 platformy, tak si 100% plýtvání místem může dovolit. Debian podporuje 16 platforem, a kdyby binárky narostly o 1500%, uživatelé by vývojářům právem nadávali.
V linuxovém světě máme balíčky. Jejich úprava pro více platforem by byla jednodušší, a instalovaný výsledek by nezaujímal 16násobně více místa na disku.
Ale i s 16násobně větším instalačním balíčkem by nás uživatelé hnali.
A proto máme v linuxovém prostředí metabalíčky. Ty mají pár bajtů, a samy balíčkovacímu systému naznačí, co a kde má stáhnout.
Výhody:
+ Žádné zbytečně obsazené místo na disku.
+ Žádná zbytečně stahovaná data.
+ Už je to napsané a není nad tím třeba bádat.
Nevýhody nevidím žádné. Snad jen, že si to každá distribuce zatím dělá jinak.
-
Izak (neregistrovaný)
Presne tak, vetsi hovadinu jsem jeste neslysel, linux s tim nema problem, ma kvalitni balickovaci system.
Jinak ale nesouhlasim s tou 16× vetsi distribuci, obrazky, data etc jsou stejne a i mnohe binarky obsahuji datove oblasti … ale samozrejme nechapu, proc by se to melo implementovat, vyzadovalo by to upravy kernelu, ld, glibc … a bylo by o celkem k nicemu.
-
Ono to neni jenom o zabrani vic mista na disku, ale take v pameti. Na to by dost doplatily netbooky, mobily, PDA atd.
A jak to pomuze vyrobcum? Stejne bude treba kompilovat pro vice platforem, akorat ze se to bude distribuovat v jednom balicku. Vysledek bude akorat vetsi provize pro majitele datovych linek (vetsi prenos dat).
PS: Ze by novy tah vyrobcu HW jak prodat vetsi disky, pameti a rychlejsi CPU? :D
-
Jsou ale i jine moznosti, Python, Perl, konec konců i Java nebo C#. Bez ohledu na to, jak nektere jazyky, resp. jejich intrepretaci mam rad, tohle je to reseni.
A mista kde je nutna optimalizace, hold pro kazdou platformu zvlast, nedokazu si totiz predstavit co by delal takovy firefox napsany v Jave, nebo OpenOffice.org v c#.
-
Akoze som za to, keby mali vsetky distra pre danu architekturu jednotne binarky/instalatory, ale cpat do balicku/binarky kod pre vsetky mozne architektury, hoci aj tie najrozsirenejsie, mi pripada ako poriadna pakovina.
Ako uzivatel mac osx pouzivam softver od inych dodavatelov na ocistenie ppc balastu v nainstalovanych aplikaciach, niekedy to robi riadne megabajty… skoda ze aj instalatory nemaju oddelene ale su ako univerzal binary – zbytocne to zabera miesto. Cize skor by som tiez uvital keby boli DMG pre ppc, intel zvlast. -
Quake (neregistrovaný)
To za chvili vsechno pobezi v basicu, nebo nejakem trapnem interpretu, nebo byte kodu. Jdete se s javou a C# vycpat. Ja chci veci prelozene do strojoveho kodu a ne nejakou interpretovanou matlaninu. Pracuji v Developeru, ktery je v jave, jsem s nim spokojeny temer ve vsem, krome rychlosti, protoze je pomaly. Psat v takovych jazycich operacni system je nesmysl. Windows Vista zacali psat v C# a .NET a po dvou letech prisli na to, ze to z duvodu rychlosti musi psat zase ve starem dobrem C/C++. Snad si kazdy uvedomi, ze si ma stahnout prislusnou prelozenou platformu. Kazda strojova instrukce navic spotrebovava zbytecne vykon. Tam, kde mi staci na program v C jedno jadro procesoru, tak abych na javu mel dve.
-
Program (neregistrovaný)
Zvláštní názor, nechci být nezdvořilý, ale k čemu je dobré, že program je v nativním kódu, je to nějaký psychologický efekt? A s tou rychlostí, kdyby se před tak 10 roky výlučně používaly bytecody a VM, dnes by všechny programy pracovaly několikanásobně rychleji, protože bychom nebyli svázání kompatibilitou s neefektivní architekturou. Hardwaráři by mohli místo tuny tranďáků, který řeší jen, jak x86 kód zpracovat rozumnou rychlostí tam hodit další výpočetní jednotky a efektivnější instrukce. A kdyby se něco neosvědčilo? Tak by se to přestalo používat… Takže s rychlostí je to přesně naopak a čím dřív se odprostíme od nativního kódu, tím dřív bude možné přejít na výkonnější procesory…
Jinak jeden z největších problémů dneska řešených je jak programy paralelizovat. Pokud jedno jádro zabiju tím, že na druhém ten program poběží 2× rychleji, tak jsem happy. A pokud jedno jádro ze 4 zabiju tím, aby program běžel i na dalších třech, místo toho, aby běžel jen na jednom, tak jsem happy3.
-
Petr (neregistrovaný)
„…Jinak si myslim, ze vzit kod a prelozit ho pro jinou architekturu neni takovy problem…“ No, pokud by ho opravdu stačilo vzít a spustit make, tak by to problém nebyl. Ovšem realita je výrazně jiná. Už si někdy zkoušel portovat nějakou reálnou aplikaci na odlišnou architekturu? Myslím, že ne.
-
sindelar.fr (neregistrovaný)
No…chapu ze kdyz pouzivaji treba nejake knihovny, ktere pro danou architekturu neexistuji tak to problem je…ja jako vyvojar do toho moc mluvit nemuzu jedine co jsem zkousel prelozit na vice platformach (x86 a x86_64 chapu…to neni nijak reprezentativni) byl muj jabber klient v c++/Qt a bylo to v pohode… ale jak rikam chapu ze u velkych projektu to muze byt problem… nicmene pak je tady ta java :)
-
x (neregistrovaný)
No asi tim chtel jemne naznacit, ze Unixy jsou v C a tudiz neni problem s prenositelnosti jako napriklad u http://www.netbsd.org/…ackages.html#…
Autor zprávičky
