Vlákno názorů k článku Ako som inštaloval Debian 3.0 od Peter Murphy - Debian je MEGA distribucia,s ktorou som sa mal...

  • Článek je starý, nové názory již nelze přidávat.
  • 23. 10. 2002 14:23

    Peter Murphy (neregistrovaný)

    Debian je MEGA distribucia,s ktorou som sa mal moznost zoznamit dost dobre.Nepaci sa mi jej konzervativnost a ak chces bezat nove veci musis switchnut zo stable na testing alebo este lepsie na unstable.No co ja viem... Menezment balikov je z RPM distribucii asi najlepsi ale dependencies!? saize!Nikdy nevies ked spustis taky update co vsetko sa poserie.Co tak vratit sa k Slackwar-u,pripadne spravit si linux from scratch;)Ale na to treba vediet co robim a co potrebujem riesit.To ale vacsina FBU nevie;)

  • 23. 10. 2002 15:33

    Milan Keršláger (neregistrovaný)

    Závislosti jsou od toho, aby se Vám nestalo, že nainstalovaný program nebude fungovat (nebo některá jeho část), protože Linux hojně využívá společných knihoven (např. pro práci s JPG nebo PNG obrázky). Každý program pak použije tyto knihovny a nemusí se vše programovat znovu a znovu kolem dokola (a nasekat v tom X krát tolik chyb). Ovšem pokud takové knihovny v systému nemáte (mohou to být i podpůrné prostředky - např. pokud máte v Gimpu plugin napsaný v Perlu, tak bez Perlu ten plugin protě fungovat nebude). Takže kdo nevěří závislostem, brzy spláče nad výsledkem. Pokud si něco přeložíte sám, pak díky configure skriptu (pokud je správně) bude do programu začleněna podpora jen toho, pro co máte v systému podporu, tj. například se pak budete divit, že Gimp neumí PNG (protože v systému nemáte vývojářskou část PNG knihoven). Naopak kolega Hužva ocení, že si disk nebude muset zasvinit vývojovou podporou pro knihovny (když si stejně nic překládá).

    Proto bych prosil kecavou část zdejších vychvalovačů, aby se zamysleli nad svými argumenty (zejména proto, že balíčkovací systém ve Slackware neřeší téměř nic a údržba takového systému je práce pro vraha - tedy pokud nechcete dělat celé dny nic jiného).

    Výhodou balíčkovacích systémů tedy je, že tvůrce balíčku může ošetřit desítky skrytých podrobností, které běžný uživatel vědět nepotřebuje (a odborník je chápe). Proto jsou v distribuích některé programy rozlámány na části - uživatel si pak nainstaluje jen to, co potřebuje. Například chci-li PHP, potřebuju balíček php. Chci-li v PHP podporu MySQL, potřebuju k tomu balčíek php-mysql, který ovšem závisí na balíčku mysql (pochopitelně, protože používá knihovny, které jsou v něm ukryty). Je vidět, že je to naprosto logické. Pokud bych si přeložil PHP sám a neměl v době překladu v systému MySQL, musel bych vše znovu přeložit. Pokud použiju balíčky, budu mít v systému vždy jen to, co nutně potřebuju. Navíc při překladu nebudu muset vynalézat kolo (použiji výsledek práce tvůrců balíčku) a budu se moct věnovat tvůrčí činnosti. O jednoduchosti aktualizace se už nemusím zmiňovat asi vůbec (kdo si "vše" překládá sám, spotřebuje na údržbu systému spoustu zbytečně promrhaného času). Když už někdo nutně potřebuje něco "navíc", je jednodušší upravit originální balík z distribuce, protože opět bude snadnější aktualizace a navíc se budeme moci o svoje výsledky podělit s ostatními.

    Mimochodem - závislosti řeší u RH automaticky nástroj up2date (stačí třeba napsat up2date ntp a dojde k automatickému stažení knihovny libcap). V RH 7.x můžete pro určení jmen závislých balíků (bez připojení k Internetu) použít volbu --redhatprovides (potřebujete k tomu mít v systému nainstalován balíček rpmdb-redhat) a v RH 8.0 tuto radu dostanete dokonce automaticky (zase je potřeba mít v systému přítomen stejný balíček). Takže zde zmíněné výhrady "že jiné systémy" mají neschopný balíčkovací systém, jsou nesprávné.

    Je však pravda, že existují distribuce, které místo tvorby všeobecně prospěšného nástroje vsadily na existenci proprietálního produktu, který sice pohodlnou práci s balíčky řeší, ale jen a pouze pro vlastní distribuci (což je obrácený přístup vůči filozofii ostatních GNU nástrojů). Ovšem i tak existuje například kpackage, gnorpm, rpmfind a další.

  • 23. 10. 2002 17:34

    Petr (neregistrovaný)

    slackware a dependencies:
    kazdy inteligentni clovek ktery udela nejaky balik do slacku vyzadujici neco spec... , vyvori bud take balik splnujici ony pozadavky, anebo k info o svem baliku pripise co zvlastniho je vyzadovano, a prip. kde k tomu prijit pokud to neni primo od nej nebo slackware.com.

    Tohle se mi libi podstatne vice nez automaticke reseni, protoze mam jednoduchy prehled. Pravda, v Deb. to jde treba taky, ale cely ten zakladni mechanismus je precejen trosku jiny a mne protste nevyhovuje, protoze ja potrebuju uz od zakladu 100% prehled. Kdyz se mi neco nezda, balik si prohlednu, co obsahuje a prip. ho jednoduse upravim.. (to jde ale v Deb. snad taky takze tahle poznamka jen tak na okraj.)

    A nakonec..taky spise preferuju cestu..stahni source, zkompiluj si ho... . Z kazde veci kterou si vytvorim si tky vytvorim balik ktery pak mohu pouzit v budoucnu treba na jinem PC. Vim totiz jak jsem ten balik udelal, co v nem je a tak mu aspon muzu celkem verit.

    Nekompiluju maximalne tak ty rozsahlejsi veci typu XFree a dalsi, protoze by to trvalo ponekud dele nez jsem ochotny cekat. Nemam zrovna extra vykonny pocitac.

    Ale je treba rict ze kazdy ma sve preference, kazdemu samozrejme vyhovuje neco jineho. Proto tady mame na vyber ze spousty ruznych distribuci a staci jen nalezt tu svou. Pripadne kdyz na to mate, muzete si vytvorit svou vlastni.

  • 24. 10. 2002 10:03

    Troton (neregistrovaný)

    Ano - toto je presne ten dovod, preco sa budem vzdy zastavat Slackwaru - 100% prehlad a zrozumitelnost. Ziadne ultra/mega/hyper instalacne automaticke procedury, ci nastroje s minimalne 5D grafikou :-)

    A vo vseobecnosti musia byt balicky (binarne) predkompilovane, aby chodili vsade, tym padom nejaka optimalizacia (procesor,kniznice,features) asi mozna nie je.