bod 1 clanku se ponekud opira o to, ze windows existuji pouze pro jednu hardwarovou platformu (pokusy s nt alpha a xp x64 nepocitam). u linuxu a jinych systemu je situace slozitejsi. ruzne binarni verze programu tedy existuji zejmena z duvodu ruznych platforem; na jednu platformu je pak obvykle dodavana pouze jedna binarka, nezavisle na pouzite distribuci apod.
Nemyslim si, ze je to jenom tim. Je fakt, ze ruzne distribuce jsou na ruzne urovni vyvoje, pouzivaji jine verze knihoven a balicku, nerku-li system reseni zavislosti a pojmenovani balicku. Moc bych nedoufal v to, ze lze vzajemne prohazovat a pouzivat baliky z fedory, ubuntu, debiana, mandrivy tam, kam originalne nepatri. Na druhou stranu - pro tyto sachy by nemel byt duvod.
Je-li pak nejaky program komercni event. z jinych duvodu do distribuce nezarazeny a distribuovany ve forme binarnich baliku, bud existuji porty pro vyznamne distribuce, prip. je program zkompilovan rozumne a vsechny zavislosti ma vice ci mene prilinkovane staticky. Kupr. s vmware jsem v tomto ohledu nemel problem na suse, debianu a ubuntu, ac jde o balik binarni.
Kdyz si to tak po sobe ctu, vlastne rikame to same. S tim, ze autor mozna mel na mysli dependency hell baliku urcenych pro speficicke distribuce. Mozna. Ja na tento stav nenarazil ;) vetsinu veci jsem vzdy nasel pekne prichystanych v repositories :)
no ono ten problem je i u windows len tak ho dodavatelia SW skrivaju pred uzivatelmy
zatial co unixy sa snazia mat jednu verziu kniznice pre vsetkok SW a casto preto nebandluju potrebne kniznice
windows sw vecsinou ma vsebe vsetky potrebne kniznice a preto ich casto v systeme najdete viackrat.
problem je rovnaky na VSETKYCH platformach rozdiel je len v tom ako sa ktomu postavi dodavatel SW (zazil som komercne unix SW ktory mal vsebe zabandlovanu i Javu, TCL ci vsetky potrebne kniznice.
Proc ne? Protoze kdyz se objevi chyba, je potreba opravovat misto jedne veci kazdou aplikaci, u ktere pojal autor ten "bajecny" napad, ze k ni pribundluje i knihovny.
No zase tak černobíle bych to neviděl. Už jste někdy dodával software masově? Nemůžete si totiž dovolit, aby kvůli nějaké chybě v knihovně, kterou má každý uživatel v jiné verzi, by nefungoval váš software. Váš software, za který váš zákazník platí! To je nepřípustné, raději se posílí webové servery a zákaznící budou každou verzi stahovat 200 MB i s JRE Javy, než aby nastala tato situace.
Prostě je to tak, dodává se na otestovaných knihovnách. Já v tom nevidím problém - běhové prostředí můžete smazat a používat systémové (Java, Python, Perl), horší je to u staticky linkovaných knihoven. Slušní dodavatelé ale dávají ke stažení dvě verze...
To je sice hezka teorie, ale v naproste vetsine pripadu to bude prave naopak - objevis se chyba v knihovne, mozna jedna aplikace bude pracovat spravne a 10 dalsich naopak prestane pracovat vubec (protoze s tou chybou byly odladene a pocitali s ni).
Podle me by se usetrilo spoustu nervu a casu, kdyby se v Linuxu nechalo tak 5% .so a zbytek by se linkoval staticky (glibc, stdc++, x11 a fontconfig staci). Aplikace by byly kratsi(!), rychleji by startovaly a bylo by po problemech.
To bych chtel videt: kazdy z 361 programku v KDE (vcetne ktrash, ktere ted ma 57kb) bude mit staticky prilinkovanych 7MB knihovny QT, 3MB libkio, 3MB kdeUI, 2 MB kdecore, .... vsechny ty knihovny budou tedy jak na disku, tak v pameti mnohokrat a presto budou aplikace kratsi a budou rychleji startovat ?
Za prve, ne vsechny by mely prilinkovanych 10MB. A 1MB aplikace neni zadne nestesti.
Za druhe, pro sady programku by bylo mozne vytvorit jednu "sdruzenou" binarku a jednotlive programy by se z ni poustely pres linky (proste by jedna binarka klidne obsahovala vsech 360 KDE utilit a na zaklade arv[0] by se rozhodlo, co se ma spustit). Ostatne, Trolltech tuhle technologie pouziva v Qtopii aby setril pamet PDA. Binarka se stejne netaha do pameti cela, jenom stranky virtualni pameti ktere jsou potreba, takze spotreba pameti je stejna. Ve vysledku by to zabralo z mnoha duvodu i podstatne mene mista na disku.
Samozrejme, pokud by si clovek stahl jednotlivy program, mel by 3-5 MB. Ale to klidne obetuju za to ze se zbavim problemu s binarni nekompatibilitou a startovacimi casy.
Mozna te to prekvapi, ale VETSINA programku potrebuje bud KDE, nebo GNOME ... a tedy nejmene 10MB knihoven.
Sdruzenou binarku jde pouzit pokud jsou vsechny zminene aplikace z jednoho baliku. To jednoduse neni pravda (i kdyz ten problem s 360 KDE utilitkami ze zakladnich balicku by se tim vyresil).
Ja to neobetuju a ani nemusim. Multibaliky a spravne oznacovani verzi knihoven resi problem binarni nekompatibility mnohem elegantneji, zatimco startovaci casy resi prelink a trocha zdraveho rozumu pri psani C++ kodu (nebo mozna specialni linking+optimizing phase na resolving sablon a virtualnich funkci). Jasne, neni to kouzelne reseni typu staci mavnout kouzelnou hulkou a bude to (to ovsem ani to vase, pokud pridate sdruzene binarky) ale bude to fungovat a nezpusobi to nutnost kupovat vic pameti a disku.
Tak Powerchute teda ani nahodou bez JAVY nepojede. Testovano vcera.
Konkretne tohle povazuji za velmi absurdni, protoze co ma delat JAVA treba na firewallu, ktery ma 32 MB ram, to opravdu netusim.
Kazdy rozumny clovek co vidi do problematiky vi, ze knihovny jsou od toho, aby existovaly ve vice verzich a ruzne smichanych kombinacich verzi. Staci treba vzpomenout na peklo s OLE knihovnami v dobach 95, 95osr1, 95osr2, 98, 98me, 98se. Borland/Inprise to resil tak, ze distribuoval svoje programy spolecne s konkretni verzi MS OLE knihoven, protoze jinak by se v 90% pripadu asi ani nespustily, jak byly ty zmeny v rozhranni OLE nezanedbatelne a caste. Temer kazda zaplata v te dobe obsahovala novejsi verzi rozhranni. A to ty zmeny probihaly bezne v ramci jedne "vetve" windows...
Rad bych upozornil, ze linux umoznuje mit soucasne nainstalovan libovolny pocet verzi jedne knihovny a porad to bude centralni. Distribuce to zatim malo vyuzivaji, protoze byva jednodussi prelozit program proti nove verzi, ale nepochybuji ze az se rozsiri binary-only aplikace, budeme proste mit (treba) libpdf-2, libpdf-3 a libpdf-4 soucasne v systemu. Kdyz se k tomu prida poctive meneni verze pri nekompatibilni zmene binarniho rozhranni, bude vse skvele fungovat a pritom bude 15 aplikaci stale mit 3 knihovny misto 15ti.
Vidim budoucnost v multibaliccich - software prijde v 50MB balicku, ktery se pri instalaci rozpadne na 13 dnesnich balicku a kazdy se zkusi nainstalovat samostatne. Uzivatel zmackne velke sympaticke tlacitko OK pod zpravou na tema "5 subpackages installed, 4 upgraded" kterou si samozrejme neprecte a vsichni budou spokojeny ...
Mmch. podobnou cestou (více fyzických balíků, ale 1 stažení a klikání, ale balíky spolu knihovny moc nesdílí) jde systém klik, i když má zatím mnohé mouchy.