Vlákno názorů k článku Linux očima jeho odpůrců od pht - bod 1 clanku se ponekud opira o to,...
-
pht (neregistrovaný)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.
-
jaro (neregistrovaný)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 :) -
zz (neregistrovaný)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. -
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... -
cxl (neregistrovaný)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 ?
-
cxl (neregistrovaný)Ano.
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. -
anonymní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 ...
