- rozházená stromová struktura
- různé distribuce - různé konfiguráky v jiných místech(nenodržení standardu)
- neekvivalence kitu jako je DX (OpenGL není DX)
- user unfriendly instalace
- někdy komplikované nastavování uživatelských práv
(wokení desktop/wokení programy /více uživatelů)
To se dá obrečet a překonat.
Ale závislosti se mě často pokouší dokáží dohnat k šílenství.
Možná už jsem se zbláznil :-E
Zavislosti urcite dokazu rozculit nejedneho uzivatela balickovacieho systemu RPM. Avsak treba si uvedomit, ako by sme skoncili, ak by si museli programy nosit vsetky potrebne kniznice so sebou; Ak opomenieme instalaciu zo zdrojvych kodov, tak by to v zasade by skoncilo tak, ze program vyuzivajuci GTK+ by musel obsahovat kniznice GTK+ (neviem, ako je to s linkovanim s kniznicami zostavenymi pre iny typ procesora, nez je program, s ktorym sa kniznica linkuje), casto zbytocne. Toto by viedlo k tomu, ze lenivi programatori by urcite chceli instalovat prave tu svoju verziu GTK a vysledkom by bolo `kniznicne silenstvi` podobne Windowsom a instalacne baliky siahajuce do radovo megabytov.
Na skrotenie zavislosti do rozumnych rozmerov staci, ak balickovaci system vie urcit zavislosti nainstalovaneho balika a ma dostatocne velke repozitare balikov online. RPM je podla mna extrem, pretoze implicitne nedovoli nainstalovat balik, ktory nema poriesene zavislosti (teda byvalo to tak, neviem, ako to je dnes). Druhym extremom je slackware pkgtool, ktory sam o sebe ma zavislosti na haku.
Swaret, emerge, apt-get, yum a ja neviem co este sa snazia zavislosti riesit co najefektivnejsie, takze s ich vyuzitim su zavislosti takmer banalnou zalezitostou.
Me nejvic vyhovuje zpusob distribuce app na m$ windows, vetsinou si opravdu vsechny dll nese sebou, ale pozor uz jsou pryc casy, kdy je to pralo do systemu. Zustavaji v adresari aplikace, jak jednoducha je pak instalace a odinstalace (staci smazat adresar :) Samo ze jsou vyjimky ktere ti zaserou cely system...
Nerozumim proc se to v linuxu nedela stejne, balicky by byli vetsi, ale na druhou stranu, kdyz si neco stahnu tak vim ze mi to bude hned fungovat.
Protoze pokud je knihovna nainstalana globalne v systemu, tak jednotlive procesy sdili jeji kod (v RAM). Pokud by si kazdy program tahal vsechny knihovny s sebou, tak by je ani nesdilel v RAM a tedy by programy zabraly vice RAM (odhaduji tak 2-3x vic).
a) je potreba uvazovat ze spousta knihoven je v systemu treba ve 20ti verzich - pak se stejne neda sdilet jejich kod
b) AFAIK pokud ma dllhost nactenou knihovnu v pameti tak se prvne diva pred loadovanim nove jestli uz tam takovou nema a az potom pripadne nacte dalsi knihovnu
c) ale hlavni je ze samotny kod DLL knihoven neni natolik velky (DLL pres 5MB se vidi hodne malo) aby jich nemohlo byt v pameti vic - v kazdem programu jsou mnohem vetsi zrouti nez samotny cisty kod DLL.
Přesně tak, ale nejenom u gentoo. Před pěti rokama to byl problém, ale dnes? Use emerge / aptitude / yum / yast / rpmdrake / swaret / ipkg / na_co_jsem_ještě_zapomněl. V podstatě mi vždycky stačí, když vím, který program chci používat a která optiona mi ho nainstaluje, tak jaképak dependency hell? Možná u LFS, ale pokud něco takového dělám, tak je to právě proto, že se v těch závislostech cíleně chci ručně babrat.
No momentalne po me nektere balicky z distribuce Fedora Core 4 pozaduji knihovnu libc.so.6(GLIBC_2.4),
bohuzel nevim ktery jim mam kvuli tomu predhodit balicek (nejaky ekvivalent compatlibs ci tak) a ani yum nepomaha. Kompilovat to ze rpm-src je mozne, ale u automatickych updatu to uz vyzaduje neautomaticky zasah. A to jsem do ted zadny hrozny "dependency hell" nezazil.
Hmmm, pokud jsou ty balíčky z FC4, pak je to chyba FC4 (a měla by se hlásit), pokud odněkud jinud, pak buď nejsou pro FC4 určené (co k tomu říct?), nebo jsou blbě udělané (a pak to hlásit jako chybu do toho repozitáře).
vo windowse ma MS Project 148MB bez dependency hell
funkcny rozdiel je naozaj takmer minimalny (pracujem s tymi aplikaciami skoro kazdy den).
mimochodom, ak si windowsovska aplikacia prinesie vsetky .dll vo svojom instalacnom baliku a potom sa pri odinstalovani pyta: "xxxx.dll seems to be no longer used by any application, delete? yes/no", tak podla vas toto nie je dependency hell? nemal by sa skor system starat, ci sa dana .dll moze vymazat? (zlaty apt-get)
mimochodom - za to ze odinstalator pta nemuze windows ale autor toho instalatoru ;)
navic tenhle problem s nastupem .NETu mizi (stejne jako problem DLL Hell u COMu). u .NETu si aplikace nese veskera DLL s sebou a jedine co udela, je ze je zaregistruje do GAC a pri odinstalaci je zase smaze.
Jen tak na okraj: většina knihoven se do GAC ani neregistruje - to je vyhrazeno pro balíky, kde je velká pravděpodobnost, že budou používány větším množstvím aplikací (např. jádro .NET, různé služby, middleware apod.).
nesrovnávej MS Project (což je nástroj pro řízení projektů) s gantovým malovátkem MrProject. Znám obé a jejich možnosti jsou přímo úměrné velikosti kódu.