Instalace softwaru v Linuxu - 1 (co je špatně)

27. 3. 2007 | Michal Vyskočil | Systém | 10936×

Prakticky každá distribuce Linuxu se pyšní vlastním formátem balíčků, nástrojem pro jejich správu a vlastními formáty repozitářů. Dokonce i ty, které používají stejné formáty, nemusí být kompatibilní. Ovšem přes nepopiratelné výhody má tento způsob i svoje nevýhody.

Obsah

• Typy uživatelů
• Co je to balíčkovací systém a jeho výhody
• Nevýhody balíčkovacího systému
• Freestandards, LSB a Ian Murdock
• Řešení?
• Neexistující společný jmenovatel

Typy uživatelů

Poměrně často opomíjenou skutečností je fakt, že balíčkovací systém používají různé skupiny uživatelů mající různé potřeby a požadavky. Jejich skloubení není vůbec jednoduché, ale je nezbytné.

Základní požadavek běžných uživatelů by se dal shrnout do věty Ať je to jednoduché a především pořád stejné. To znamená, že všechny základní operace jako instalace, odstranění, upgrade nebo nastavení musejí být jednoduché a především konzistentní.

Podobné požadavky mají správci. Ti bývají navíc zodpovědní za bezpečnost spravovaných systémů, takže ocení kryptografické zabezpečení balíčkovacího systému (nejčastěji pomocí GPG) pro jeho větší důvěryhodnost. Ovšem i jim by se hodil jednotný způsob instalace např. bezpečnostních aktualizací. Navíc by pro ně bylo občas vhodné mít možnost vedle sebe nainstalovat několik verzí paralelně, což stávající systémy neumí.

Distributoři se naopak tváří, že právě jejich distribuce je tím pravým řešením. Prostě stačí, aby všichni vytvářeli balíčky pro tu konkrétní distribuci, a problém je vyřešen. Ovšem jedna z mála věcí, na níž se uživatelé různých distribucí shodnou, je, že právě ta, kterou používají, je ta nejlepší. Myšlenka dominantní distribuce, pro kterou budou všichni primárně tvořit balíčky, nevypadá reálně; tím spíš, že za poslední tři čtyři roky se do mainstreamu protlačily dvě, které mají svůj vlastní formát balíčků (Gentoo a Arch Linux). Daleko větší naděje se vkládají do aktivit jako LSB, které by měly vést k vytvoření společného základu pro různé distribuce. Problém je v tom, že balíčky třetích stran nemají podporu v instalačních nástrojích dané distribuce. Požadavek distributorů je nicméně jasný: chtějí mít co největší kontrolu nad instalovaným softwarem, protože nejsou schopni zajistit stabilitu/bezpečnost těch částí systému, které pocházejí od třetích stran. Na druhou stranu se v distribucích běžně vyskytuje spousta podobného softwaru - binární kodeky, Flash pluginy nebo třeba Opera.

Vývojáři zase potřebují jednoznačný způsob, jak vytvářet software dostupný i pro Linux. Poskytování binárky pro každý typ linuxového systému není vůbec jednoduché. Bez možnosti využívat definované a dostupné nástroje například pro updaty nebo konfiguraci se vývojáři ocitají ve stejné situaci jako na Windows, kde musí podobné věci řešit každá aplikace vlastními prostředky. Problém tvorby binárních balíků by mohl v budoucnu vyřešit OpenSUSE Build Service. Vývojáři navíc chtějí zasahovat do nainstalovaných knihoven, což je v Linuxu tradiční oblast distributorů.

Co je to balíčkovací systém a jeho výhody

Pojem distribuce jako třeba Debian GNU/Linux zahrnuje jádro Linux, základní systémové utility (coreutils a binutils), systémové knihovny (glibc, uclibc), systém init skriptů, různé podpůrné nástroje (update-alternatives) a hlavního hrdinu — balíčky ve formátu .deb. S těmi pracuje nástroj dpkg a jeho nadstavby apt, aptitude, nebo synaptic. Stejně tak distribuce Gentoo má svoje ebuildy ve stromu Portage, svůj nástroj ebuild a vysokoúrovňový emerge. Fedora má zase svoje rpm s programem rpm a nadstavbou yum. Jiné distribuce založené na rpm mohou obsahovat yast (SUSE), urpmi (Mandriva), nebo cokoliv jiného.

Všechny tyto nástroje v konečném důsledku dělají to stejné. Stáhnou odpovídající balíček, jeho případné závislosti (až na installpkg, který takto nefunguje) a vše nainstalují a nastaví. Máme jednotný způsob instalace balíčků, jednotný způsob prohledávání, jednotný způsob prohledávání nainstalovaného softwaru, jednotný způsob odebírání a také jednotný způsob updatů, o něž se samotné aplikace nemusí starat.

Balíčkovací systém tak nabízí samá pozitiva a sociální jistoty. Stará se nám o pořádek v systému, zajišťuje, že se aplikace stáhne a nainstaluje se všemi potřebnými závislostmi, že nám zlovolně napsané balíčky nebudou přepisovat soubory jiných balíčků, a odvádí spoustu mechanické a užitečné práce - třeba to, že nemusíme nic stahovat ručně. Poměrně opomíjenou (i když velice podstatnou) výhodou balíčkovacího systému je, že nejste vydáni na "milost" schopnostem tvůrce softwaru, ale používáte ověřený balíček (nejste-li příznivcem experimentálních verzí). Máte automaticky zajištěné updaty, takže jste chráněny před chybami, které se v softwaru najdou. A to nejlepší nakonec: toto vše se děje naprosto automaticky (ano, pokud nejste ten, kdo vytváří balíčky), takže autor softwaru se o nic podobného nikdy nestará. Těchto výhod by se mnoho uživatelů velmi nerado zbavovalo.

Nevýhody balíčkovacího systému

Tento přístup sebou nese i nevýhody. Vezměme si třeba program psi. Ten existuje v jedné binární formě pro Windows, v další pro systém OS X, ve formě platformně nezávislých zdrojových kodů. Dále potom jako balíček v x verzích pro distribuce Arch, Debian, Fedora, SUSE, Ubuntu, Mandriva, ... Nepříjemnou vlastnostní balíčkovacích systémů je skutečnost, že zvyšují počet vzájemně nekompatibilních verzí. Je však třeba říct, že takové Psi je poměrně známá open source aplikace a distributoři (více či méně) mlčky odvádí tu špinavou práci, takže ji máme jednou ve verzi pro Debian, podruhé pro Fedoru, potřetí pro Mandrivu, ...

Potíž v současném pojetí balíčkovacích systémů je jednak v tom, že vedou k obrovské duplicitě práce distributorů, ale hlavně v obrovském množství verzí toho stejného softwaru. Příkladem budiž Opera, která nabízí více jak 50 binárních balíčků pro různé verze různých distribucí. Toto číslo je až neuvěřitelně velké. Ovšem Opera vytváří svůj prohlížeč pro více jak 11 platforem (nepočítaje mobilní verze), tudíž pro ně nemusí být takový problém upravit svůj release tak, aby zahrnoval i více jak 50 binárek pro různé distribuce.

Nicméně, za současného pojetí, pokud jako vývojář vytvořím jednoduchou aplikaci, jsem de facto nucen vytvářet hromady binárních balíčků. Pokud ty balíčky přesto nějak udělám, nebude mít uživatel možnost aktualizace, protože ta se týká pouze softwaru z repozitáře. Pokud udělám staticky slinkovanou verzi, ztrácím veškeré důvody k používání balíčkovacího systému jako takového a mohu rovnou používat třeba GoboLinux. Pokud vystavím pouze zdrojové kódy, nutím tím uživatele si software zkompilovat (což ne každý zvládne nebo chce dělat) a buďto nainstalovat natvrdo, nebo udělat vlastní balíček (který se jen tak do repozitáře nedostane).

Stejně tak není možné vytvářet x balíčků pro tak drobné věci jako rozšíření Firefoxu nebo témata vzhledu. Respektive, možné by to bylo, ale vývojáři distribucí si rozhodně na nedostatek práce nemohou stěžovat a toto pro ně není tolik zajímavé. Takže stávající balíčkovací systémy mají jistou granularitu a i když by bylo hezké mít součástí distribuce i takový Adblock, nikdo to nedělá a raději systém obchází. S tím pak souvisí i potíž, že málokdo bude chtít updatovat distribuci jenom proto, že vyšla nová verze jeho oblíbeného rozšíření.

Druhou stranou mince jsou "third-party" aplikace, které z nejrůznějších důvodů v repozitářích nejsou. Příkladem může být sqldeveloper od Oracle, Netbeans od Sunu (kvůli licenčním omezením) a tak dále. Výrobci softwaru to většinou řeší tak, že aplikaci udělají v rpm (jsou certifikovány Red Hatem) a někdy i statickou binárku. Protože z mnoha důvodů není možné, aby byl takový software v rukách tvůrců balíčků jednotlivých distribucí, pro tyto aplikace neplatí vůbec žádná z výše uvedených výhod balíčkovacích systémů. Dokonce nikde nemáme v systému záznam o jejich instalaci - není žádný standardní prostředek, který by systém řekl, že tam a tam je ta a ta aplikace.

Prostě, v současné době existují pouze dva stavy:

1. Vše je v repozitáři - takže pro nás platí pozitiva a sociální jistoty. Ovšem u distribucí, které nepoužívají rolling updates [průběžné aktualizace], musíme v případě potřeby povýšit celý stávající systém.
2. Máme k dispozici balíček, tarball, zdrojáky nebo něco podobného, takže žádné jistoty a pozitiva nemáme a o systém se musíme starat sami.

Freestandards, LSB a Ian Murdock

Že je něco špatně, napoví i blogpost Software installation on Linux: Today, it sucks (part 1) od nikoho menšího než Iana Murdocka, zakladatele distribuce Debian. V jeho příspěvku naleznete i odkaz na porovnání postupu instalace Sun Studia na Windows a linuxové distribuci. Free Standard Group a její pracovní skupina LSB se ovšem zabývaly (počátek roku 2007 došlo ke sloučení FSG a OSDL, vznikla Linux Foundation) řešením tohoto problému na dvou úrovních. LSB definuje standardní množinu softwaru, který by měla distribuce obsahovat. To by mělo vyřešit potíže se závislostmi, protože aplikace si pouze zkontroluje (pomocí lsbappchk) přítomnost potřebných lsb balíčků, které by měly být v každé běžné distribuci.

Na prosincovém summitu LSB face-to-face (December 2006) se hovořilo o způsobu, jak by nezávislí producenti softwaru (ISV — Independent Software Vendor) mohli mít více kontroly, což se logicky střetává s odporem distributorů a velké části uživatelů.

Ve druhé části svého blogpostu Software installation on Linux: Tomorrow, it won't (with some cooperation) (part 2) Ian Murdock asi nadzdvihnul poměrně značnou část uživatelů.

After reading through the comments to part 1, let me first point out that our goal is to create a vibrant third party software ecosystem around Linux-you know, like the one Microsoft has built around Windows. No, it's not about imitating Microsoft. It's about being competitive. A platform is only as good as the applications that run on it.

Po přečtení komentářů k první části mi dovolte upozornit na to, že naším cílem je vytvořit živý a pulsující ekosystém nezávislého softwaru kolem Linuxu — něco podobného, co vytvořil Microsoft kolem Windows. Ne, není to o napodobování Microsoftu. Je to o tom být soupeřem. Platforma je pouze tak dobrá, jak dobré jsou aplikace na ní běžící.

Řešení?

FSG se rozhodlo vytvořit most mezi propastí, která je mezi tím, co distribuce potřebují a tím, co požadují ISV. Problém zní Jak? Z hlediska ISV by bylo nejlepší, kdyby pojem Linux zahrnoval jednu platformu, což znamená, že by stačilo zabalit software do nějakého definovaného formátu - stejně, jako je tomu ve Windows. Někteří (jako například Michael Leibowitz ze společnosti Intel) dokonce navrhují vznik nového balíčkovacího systému pro tyto aplikace (vizte některé nezávislé balíčkovací systémy).

Ovšem v následné diskusi se většina lidí shodla na vytvoření základního API, které bude spojovat dnešní existující balíčkovací systémy. Velkým usnadněním práce pro tvůrce může být, že většina ISV nebude potřebovat žádné složité operace. Většinu instalací by dokonce mohl řešit pouhý dotaz na to, zda systém obsahuje potřebné lsb závislosti (a jejich případné stažení plně v režii stávajícího balíčkovacího systému) a nějaký způsob registrace souborů, které s sebou software do systému nese (zde je nezbytně nutné, aby balíčkovací systém kontroloval instalované soubory, protože v opačném případě se ztratí jedna z nejužitečnějších funkcí tohoto systému). Ovšem vše je ještě ve stádiu příprav a spousta problémů není vůbec vyřešena. Proto vznikla pracovní skupina Packaging, která bude mít tuto problematiku na starosti.

Doufejme, že se podaří překlenout dnešní propast mezi centralizovanými a nekompatibilními repozitáři a balíčky třetích stran, ať se to týká rozšíření Firefoxu, pythonních vajíček, nebo aplikací od větších či menších společností. A to tak, aby dnešní nepopiratelné výhody instalace softwaru v Linuxu prostřednictvím balíčků a repozitářů zůstaly zachovány. Ovšem úkol to není nikterak jednoduchý.

V současné době není konference příliš aktivní (jak napovídá pohled do archívu) a navíc existuje pouze návrh API, který ovšem, z mně neznámých důvodů, v archívu konference chybí.

Neexistující společný jmenovatel

LSB definuje jako výchozí formát balíčků rpm s některými omezeními, která se týkají pojmenování, vlastností, virtuálních balíčků a závislostí. Protože se v mnoha případech nejedná o nativní formát, existuje nástroj alien, který jejich instalaci umožní. Dalším problémem může být fakt, že i když se jedná o formát používaný velkou částí distribucí, jednotlivé implementace se poněkud liší. Navíc vývoj tohoto nástroje dlouho stagnoval.

Specifikace také nedefinuje standardní způsob instalace/odstranění/upgradu balíčků, takže si to každá distribuce řeší sama. Program rpm je nízkoúrovňový nástroj, který používají vysokoúrovňoví správci jako rug, yum, yast, urpmi, apt4rpm anebo distribučně nezávislý smart. Ovšem přesné postupy, jak provést instalaci, jak spravovat repozitář a podobně, jsou distribučně závislé. Každý nadstavbový systém to řeší vlastními prostředky.

LSB rovněž zavádí omezení závislostí a virtuálních balíčky. Jak je stanoveno, balíček nesmí záviset na nějakém ne-LSB balíčku. Toto ovšem komplikuje situaci, kdy nejsou k dispozici žádné jednoznačné názvy. Každá distribuce si svoje balíčky (i ty virtuální) pojmenovává jinak. Například na Debianu existuje virtuální balíček mail-transport-agent, který zahrnuje sendmail, postfix, exim a jiné. Stejná věc se ovšem na Fedora Core nazývá smtp-server. Naprosto stejná situace panuje v systému pojmenování balíčků, kde opět platí, že každá distribuce má vlastní systém.

Příště

Příště se podíváme na zoubek existujícím distribučně nezávislým balíčkovacím systémům. Na řadě bude autopackage.

       

Komentáře

[sssssssss]

Do roku 2010 by se mohli dohodnout a vytvořit něco "nad" balíčkovače. Jinak hezkej článek

[USAMA]

hele michale jenom jsem to tak zhruba prolítl, tak kdžytak promin za muj názor, ale řešení balíčkovacích kravin je naprosto na snadě... Jenoduše jendou za rok se vydá nějaká papírovaá kravina jak má linux + programy vypadat jaká má bejt verze programů a to jak si to distributoři namíchat, adresářově je už jejich věc. A všici ostatní dodavatelé externích programů mají tím pádem jasno. Zkompilujou binárku která tak pojede uplně všude... a co by v základu distra nebylo tak si ostatní dodavatelé zkompilujou staticky a FUCK OFF! jednoduchý jako facka... mohl by se dodávat také i bez balíčkovacího systému nějaký binární základ linux+ programy a kdo by chtěl tak by jsi to ztáhnul a nadstavěl by jsi na to vlastní desktopový distro. Jo a ještě jedno řešení vidím: přejdeme na redhat, suse a nebo rovnou na SOLARIS páč tyhle komerční věci jsou jednoduše komerčnímy společnostmi podporovány a kam se hrabe ubuntu pánové (samozřejmě komu stačí firefox tak nekomerční distro kolikrát stačí). )

[jm]

No fuuj...

[Sešívaný]

Hmm... RedHat pro mě nemá žádnou rozumnou desktopovou (komerční) alternativu, Solaris bych si na desktop nedal a Suse mi IMHO rozhodně lepší než Ubuntu nepřijde. Pro servery je velmi dobrá nekomerční alternativa Debian, takže bych rozhodně netvrdil, že komerční distribuce jsou něco lepšího než nekomerční. Ostatně zaplatit si můžete i za nekomerční distro, viz. např. Ubuntu->Canonical.

[USAMA]

mužu se zeptat v jakém oboru makáš? já makám ve strojírenství a když si chci pořídit Pro/E pod linucha tak samozřejmě že si to mužu narvat na jakékoli distro, ale bez podpory a stylem starej se sám voe... A na to seti každá firmy víš co, vysere...

[Sešívaný]

Podpora nějakého softu pro určitou distribuci není ani tak otázkou toho, jestli to distro je komerční nebo ne, ale jestli je poptávka po podpoře pro ono distro. Kdyby byla poptávka po podpoře Pro/E pod Ubuntu, tak tu podporu mít budou. Pokud v nějakém konkrétním případě potřebuji komerční distro, tak si ho koupím, ale ještě to neznamená, že jsou nekomerční distra obecně horší, aby lidi měli hromadně přecházet na komerční.

[USAMA]

jde o to že o takovéto komeční programy se jednoduše nekomerční distribuce vubec nezajímají a je jim tak říkajíc u ... takže pro/ečko jednoduše podporuje 2 linuxové distribuce a to mu stačí. A navíc se i na to vykašlala páč prostě lidi o Pro/E na linuxu moc nestojí... takže koleběh pokračuje a a dokad nebudou pořádný programy tak lidi přecházet na linux nebudou...

[hwsoft]

No ja pracuju pro jednu znejvyznamnejsich elektro firem v republice, kumulovany obrat za minuly rok pres jednu miliardu Kc.

Co se tyka Pro/E tak tam sice o Debianu zminka neni, ale jinak je Debian, jako jedina nekomercni distribuce podporovany.

Pak uz je pravda, ze se mluvi pouze o velke dvojce RedHat a SuSe(Novel), pokud to neni firma ktera ma Linux jako vyznamny trh, ty pak podporuji i dalsi vyznamne distribuce.

(jinak svym vyjadrovanim, si nekde na urovni zive, chudacku)

[hwsoft]

To o tom Debianu plati pro dalsi firmy, ktere podnikaji na trhu SW pro Linux.

[USAMA]

To si mužeš pracovat kde chceš vole. Mě je to výsostně uprdele. Víš co to znamená podporovaný? když totiž chceš tak Pro/Ečko rozjedeš cekem na čemkoliv když chceš. ale žvástat o tom že je neco podporovanýho když to nemají nikde napsaný je slátanina njevětší páč v praxy jde o podporu která je podepsaná na papíře a né i žvásty nějakýho kreténa. PS tedka jsme se koukal na stránky dodavatele a podporuje pouze Solaris a RedHAt. A linuxová verze je jenom na 32 bit s tím že po verzi 3.0 končejí z podporou linuxu a zustane jenom windows a solaris vole! SW podpora

Jinak samozřejmě konkrétně vím o rozjetým Pro/Ečku na SUSE, DEBIANU, Gentoo,.....

[otula]

Vladimíre, prosím tě, piš své příspěvky až po přihlášení. Mám tě blokovaného, takže se mi tvé výplody nezobrazují. Když už chceš psát nechutně, buď alespoň ohleduplný k těm, kdo to nemají chuť číst.

PS: Možná by byla dobrá možnost volit blokování i podle IP adresy.

[Prcek]

Presne tohle jsem chtel taky napsat . Pred dvema dny jsem si Vladimira zablokoval (a to jsem si myslel, ze tuhle funkci nikdy nevyuziju) a on jako na potvoru zacal psat neprihlaseny - no to by mi z toho jeblo, Ivanku .

[social]

Netusim co cekate, kdyz si vezmete pocet distribuci, jejich vzajemnou vetsi ci mensi odlisnost tak jak bylo receno v clanku neni jednoduche pro vsechny udrzovat balicky a nabizet k nim podporu to se financne nemuze vyplatit. Navic podpora se nabizi pro ty distribuce kde to ma smysl (velky podil na trhu). Pokud se nejaka firma rozhodne vyvijet a nebo portovat svoji aplikaci na Linux tak vetsinou se setkate s podporou RHEL, mozna jeste SUSE. Samozrejme zase jde o to na jake zakazniky (v jakem oboru) se aplikace orientuje, pokud jde napr. o nejakou hru nema moc smysl podporovat Debian tam se moc hracu nenajde. Podporovat distribuce jako Slackware se taky nikomu moc nevyplati (i kdyz ja ji mam nejradeji). Je to da se rici jen o penezich a specializaci dane aplikace.

[xkesh]

Navic podpora se nabizi pro ty distribuce kde to ma smysl (velky podil na trhu). Pokud se nejaka firma rozhodne vyvijet a nebo portovat svoji aplikaci na Linux tak vetsinou se setkate s podporou RHEL, mozna jeste SUSE.

Až někdo vymyslí, jak by bylo možné, aby nebyla každá distribuce více či méně samostatným operačním systémem, tj. aby byly všechny distribuce totožné a lišily se snad pouze výchozím nastavením wallpaperu a barvami, tak to dejte těm firmám vědět. Budou jistě nadšené tím, že SUSE bude totéž co Red Hat což bude totéž co Mandriva. Skvěle se na to bude dělat reklama a skvěle se to bude prodávat.

Měli bychom si konečně zvyknout na to, že linuxové distribuce jsou prostě svébytné operační systémy podobného typu a přestat se tomu divit a stěžovat si na to. Monokultura, ač má jistě své finanční výhody, má také degenerativní nevýhody (např. Windows Vista ).

[social]

Ale jiste, o tom prave mluvim ze vzhledem k tomu kolik distribuci je a jak se lisi nelze ani prilis sjednotit balicky. To co jsi naznacil = sjednoceni distrubuci na jeden standard, postavilo existenci tolika distribuci na hlavu. Ja to spisechapu jako v jistem smyslu vyhodu spojenou ale se spoustou nevyhod ze "distribucni trh" je tak velky, ovsem v nekterych distribucich nevidim zadny hlubsi smysl proto se casto od svych "rodicu" lisi prave a jen tim wallpaperem. Skepticky se koukam i na ruzne mutace ubuntu.

[Mintaka]

Monokultura má mnoho negativních rysů. Protlačování monokultury pomohlo nejedné firmě ( často na úkor zákazníků) dosáhnout toho kde je. (IBM v 50. letech, Microsoft, ...)

Nezaměňoval bych to však s vytvořením a udržování vrstevnatého modelu. Stejně, jako dnes většinou neřešíte v jakém formátu máte uložená data na datových nosičích a prostě je jen používáte, mohla by vrstva starající se o instalaci programů zjednodušit tenhle problematický úsek.

Tuhle vyrstvu by mohlo řešit několik různých programů (stejně jako je třeba několik druhů poštovních serverů), byly by však standardizované vstupy a výstupy. Vstupem by byly požadavky a vlastnosti programu, jeho závislosti a pod, definované v standardizovaném konfiguračním souboru, výstupem by byl nainstalovaný program dle zvyklostí distribuce.

[bubo.]

Mozem sa Vas spytat na akom distre mate Pro nainastalovany? Ja som doteraz robil na Suse 10, skusil som nainstalovat Opensuse 10.2 ale na nom mi to nejde. Nejaka rada - pomoc preco to pod 10.2 nechodi, resp. preco to na inych distrach ide?

[USAMA]

hele na SUSE 10.1 ničce mě to chodilo bez problémů a na debianu to taky rozchodíš, v podstatě to potřebuje 32 bit distro (nebo multilib) s lestiffem, možná nějaký fonty. kdyžtak vyzkoušej ldd myslím něbo tak nějak se mejuje příkaz kterým vypátráš co to všechno potřebuje na rozjetí. kdžytak kdyby něco nechtělo jet tak mě pošli výpis z příkazovky na muj mail vzima at centrum.cz a já se ti pokusím poradit pokud budu vedět. Pro/E komunita na linuxu je zatí dost malá no...

[bubo.]

Poslal som Vam mail, ldd neviem pouzit...

[oziris]

hm no jo ale kde sa riesi podmienka uzivatelov o jednoduchost?

[Daniel Kvasnička ml.]

Ubuntu a nekomercni distro? Bud jsi nehorazne naivni nebo jen nesledujes deni Je jen otazkou casu kdy Ubuntu Shuttleworthovi zacne vydelavat...pokud uz tomu tak neni ted. Jen tak lejt do distra prachy, ktery neutratil na vylete po vesmiru, to by byla neudrzitelna kravina a Mark to vi.

[Peter Lehotsky]

Ubuntu je kompletní operační systém založený na Linuxu. Je volně dostupný a k dispozici je komunitní i profesionální podpora.

Komunita Ubuntu je postavena na principech popsaných v Manifestu Ubuntu: software by měl být dostupný zadarmo, softwarové nástroje by měly být dostupné v místním jazyce, pro lidi s různými postiženími a lidé by měli mít svobodu přizpůsobovat a upravovat software podle svých potřeb a svého vkusu.

Tyto svobody Ubuntu zásadně odlišují od tradičního proprietárního software: nejenže potřebné nástroje máte k dispozici zdarma, ale máte také právo měnit software tak, aby vyhovoval vašim potřebám.

Vývojový tým Ubuntu se svým uživatelům veřejně zavázal k následujícímu:

* Ubuntu bude vždy zdarma a nikdy nebude žádná "podniková verze" za speciální poplatek. Svou nejlepší práci dáváme k dispozici každému za stejných podmínek. * Ubuntu nabízí plnou komerční podporou stovek společností z celého světa. Ubuntu je vydáváno pravidelně a očekávaně; nové verze vycházejí každých šest měsíců. Každá verze je podporována vydáváním bezpečnostních aktualizací a oprav nejméně po dobu 18 měsíců. .... .... * Ubuntu je zcela oddáno principům vývoje svobodného softwaru; podporujeme lidi, aby používali svobodný a otevřený software, vylepšovali jej a šířili dále.

[Daniel Kvasnička ml.]

Myslite, ze neumim cist? Spis vam nedochazeji nektere souvislosti, treba ze na software se da vydelavat aniz by se primo prodaval...

[LFCIB]

[Michal Vyskočil]

Jenoduše jendou za rok se vydá nějaká papírovaá kravina jak má linux + programy vypadat jaká má bejt verze programů a to jak si to distributoři namíchat, adresářově je už jejich věc.

To by měla dělat právě LSB, ovšem skutečně netuším, jak moc se distributoři snaží něco takového dodržet. Já mám takový pocit, že od distributorů se nějakého sjednocení nedočkáme, ten popud spíš musí vyjít od uživatelů a vývojářů. Ovšem nezdá se mi, že by byla vůle toto řešit.

[Thunder.m]

Mě vyhovuje systém .deb, stahnu, kliknu, instalátor si v nejhorším doinstaluje dodatečné potřebné programy, nebo knihovny a je nainstalováno, už jsem takhle tahal pár programů a nemam s tím problém :)

[Josef Kufner]

Stáhnu a kliknu? To je moc pracný... nestačilo by prostě kliknout?

[.....]

Pche, co takhle neklikat, jen najet myší?

Absurdně: Nebo ani to ne!

[social]

Ehm... a co pro me porad jeste nejprijatelnejsi varianta : napisu a mam ? nejak mi ty GUI neprirostly k srdci.

Kazdopadne ve chvili kdy pro to Debian/RHEL/Mandriva/SUSE nebude mit balicek z ruznych at uz licencnich nebo jinych duvodu tak jsi nahranej.

[david]

To co vidím jako hlavní problém, který bude i nadále bránit společnému balíčkování pro distribuce Linuxu je, že každé distro má jiné sady základních knihoven (libc, libstdc++, grafick0, X-nadstavby jako gtk a další), které činí přípravu binárních balíčků (bez statického slinkování) prakticky nemožnou. Nebo se stane něco podobného děje u Java aplikací, každá aplikace si sebou přináší vlastní runtime (té verze a podverze, se kterou spolehlivě chodí).

[Gogol]

To nebude fungovat. Jak by takovy balickovac resil zavislosti? Modelova situace: Stahnu balicek, instaluju, system zjisti, ze v repozitari nema potrebnou zavislost. Co dal? Rekne uzivateli? No, ale to jsem opet na zacatku. Windows to resi jednoduse, staticky linkovani nebo v kazde instalaci potrebne knihovny v lepsim pripade se nacpou do instalovaneho adresare, v horsim do systemoveho Maximalne jsou uzivatele zvykli doinstalovat nove DirectX. Tento bordel ovsem nechceme, ze. Reseni je treba jeden centralni repozitar proti kteremu by se kompilovalo a potrebne zavislosti se dohravali k aplikaci ci do systemu odtamtud. Ovsem to zni jako zmena distribuce )

[Max]

... Co dal? ...

Co asi, ví, co ten balíček potřebuje za knihovny a podle toho by snad měl nabídnout instalaci dalších balíčků a to už jen přímo z balíčkovacího systému onoho distra .
Zdar Max

[social]

To opravdu nemuze fungovat ani tak, kazda distribuce se k tomu opravdu chova uplne jinak. Kdyz nic tak verze knihoven/kompilatoru nejsou vsude stejny, pripocitej si k tomu mnozstvi vlastnich patchu a mas ohromnej nesourodej bast. Vlastne vubec nechapu proc si kazdej hned jak se mu neco nezda na stavajicim distru dela nejaky novy kde stejne nakonec zmeni tak maximalne logo... Myslim ze chyba/problem je uz jen v tom poctu distribuci ktery je zbytecne velky.

[camlost]

competitive == souper? :-O

konkurenceschopny

[happy barney]

Nad-balíčkovač mi pravidelne zaberá nejaký ten čas šedej kôry Výsledky stručne:

- xml (nechce sa mi písať entity, tak [])
- dedičnosť balíčkov / verzií (inšpirácia WURFL)

  [version version="8.0" major-version="8.0" extends="7.4"/]
  [version version="8.0" extends="8.0"/]
  [version version="8.1" major-version="8.1" extends="8.0"/]
...

- optional depenedencies

[configure type="autoconf"]
  [option name="with-jpeg" default="no"]
     [requires package="lib-jpeg" min-version="..."/]
  [/option]
...

- bundle balíčky (aj bundle balíčkov)

[package name="my-slackware"]
  [use package="slackware" version="10.0"]
    [without package="mysql"/]
    [with package="kernel" version="2.6.20"/]
    [with package="php"]
      [option name="with-pgsql"/]
  [/use]
  [use package="postgresql" version="8.2.3"/]
...

- predefinované nastavenie (napr balíček vyžaduje špeciálne uid/gid)
- závislosti nielen na balíčky, ale i na resources

[require resource="shm-max" min-value="200000000"/]
[require resource="user" value="postgresql"/]
[require resource="group" value="dbmaster"/]

Finálna inštalácia je len ďaľší bundle.
Cieľom bolo vytvoriť build skripty jednotlivých distribúcií.

momentálny stav: zamrzol som

[Michal Vyskočil]

To mi připomíná Zero Install, ten se mi zdál hodně propracovaný ...

[happy barney]

hej, len ten chce nahradiť existujúce balíčkovacie systémy. Môj zámer bol vytvoriť vrstvu pod distribúciami, určenú hlavne pre vývojárov. Jeden si napíše svoj vlastný softík, k nemu jeho popis, stiahne si popisy jednotlivých distribúcii a build -skripty mu vygenerujú balíčky pre jednotlivé distribúcie (popr upozornia na konflikty).
Btw, viac to pripomína Gentoo.

[Filip Jirsák]

Chybka: Problém zní Jak?. – tečka na konci je navíc.

[Robert Krátký]

Dík, opraveno.

[boo]

Doprdele vzdyt linkujte staticky a vsechen ten bordel s balicky dependencema na libech a cojavimcojeste odpadne. Navic se vam nestane ze "upgradem" nejaky knihovny rozsypete system. Dynamicke linkovani je prezitok z dob kdy sme meli 16MB RAM tak se setrilo kde se dalo, ted kdyz je standard 1-2GB muze byt klidne vsechno zlinkovano staticky a "jedna binarka bude vladnout vsem" :) (dobra, dve binarky, jedna pro i386 a jedna pro x86_64 :)

[Filip Jirsák]

linkujte staticky a vsechen ten bordel s balicky dependencema na libech a cojavimcojeste odpadne. Navic se vam nestane ze "upgradem" nejaky knihovny rozsypete system. Dynamicke linkovani je prezitok z dob kdy sme meli 16MB RAM tak se setrilo kde se dalo, ted kdyz je standard 1-2GB muze byt klidne vsechno zlinkovano staticky a "jedna binarka bude vladnout vsem" :) (dobra, dve binarky, jedna pro i386 a jedna pro x86_64 :)

Takže když se najde (bezpečnostní) chyba v nějaké často používané knihovně (třeba zlib), musí všichni autoři vydat nové verze svých programů, které jen slinkují s novou knihovnou? Jak dlouho bude trvat, než tak opravdu všichni učiní? Jak dlouho bude trvat, než všechny ty programy všichni nainstalují?

[boo]

A co, kdyz vyjde zaplata tak se citis bezpecneji? Do tydne mas v distru dalsi bug. Ja se na to platani uz vykaslal, ma to smysl snad jen na serveru ale na desktopu kde mas stejne po pulroce novou verzi distra. A vubec vzdyt jde o linux, viry nejsou, firewal ma kazdej a to ze se nekdo naboura pres buffer owerflow v nejakym exotickem libu je cisto jenom v oblasti teorie.

[xxx]

Ano, ssouhlas. Mám Mandrivu, ta je dobrá, ale dneska jsem zkoušel Ubuntu, zkusmo instaloval blbý program, chtělo to pár lib... Výsledek? Přestal jít Adept, styl oken ten nejhnusnější hnus... Ubuntu letí z disku. Kdyby se byly knihovny instalovaly někam k programu a ne do systému, by se to nestalo.

[xkesh]

Ano, ssouhlas. Mám Mandrivu, ta je dobrá, ale dneska jsem zkoušel Ubuntu, zkusmo instaloval blbý program, chtělo to pár lib... Výsledek? Přestal jít Adept, styl oken ten nejhnusnější hnus... Ubuntu letí z disku. Kdyby se byly knihovny instalovaly někam k programu a ne do systému, by se to nestalo.

Asi by bylo zábavné, kdybyste sem popsal podrobnosti. Tohle vypadá spíš na klasickou fušeřinu při instalaci "blbého programu" ještě blbějším frikulínem

[xxx]

Toho blbého frikulína promíjím . V linuxu se dost orientuji. Baví mně skripty, kommandlajna mi není cizí. Ale mám rád hotový základ - proto Mandriva. Jen jsem chtěl po roce vyzkoušet, jestli už je tolik vychvalované Ubuntu dobré. Není. Je pravdou, že jsem blbnul i s Alienem a tak..

[Michal Vyskočil]

Ale pořád jsi nenapsal, co jsi dělal. Jsou dvě možnosti, buďto jsi to rozbil, ale v tom případě obviňuješ Ubuntu ze svých chyb, nebo je v něm chyba (což není vůbec vyloučené) a pak by se popis hodil, aby bylo možné to opravit. Zatím jsme tu od tebe slyšeli pouze, že jsi něco nainstaloval a ono se to rozbilo.

[xxx]

Dá se napsat, že jsem to rozbil. Ubuntu obviňuji, že pouhým povýšením několika systémových knihoven se rozbít nechalo. Nejvíce kritizuji, že programy vyžadují určité verze SYSTÉMOVÝCH knihoven. Pokud program není schopen fungovat např s x-lib-1.0 - 5.9, tak má mít svou knihovnu mimo /usr/lib/. Takové závislosti jsou špatná věc.

[Bluebear]

to ze se nekdo naboura pres buffer owerflow v nejakym exotickem libu je cisto jenom v oblasti teorie

To bohužel není jen teorie. V síti nejsou jenom hackeři (kteří se zaměřují na zajímavé systémy a tudíž po desktopech asi moc nejdou), ale taky červi, kteří mají nekonečnou trpělivost a zkoušejí všechny počítače, které najdou (do spamovací sítě je každá mašina dobrá).

[happy barney]

to je blbosť, odpadá možnosť voľby. O.i., ako chcete staticky linkovať iné balíčky (typicky: db, mta, ...)

[Michal Vyskočil]

Kdyby tomu tak skutečně bylo, tak by GoboLinux měl poněkud větší podíl, ne?

[robo]

Tak takyto bordel by som na compe mat nechcel :)

[Milan Jurik]

Az na to, ze staticke linkovani je prezitek, z dob, kdy se nezvladalo dynamicke linkovani. Krom toho, jak spustite na aktualnim jadre 10 let starou libc?

Zbytek toho vyblitku nema cenu komentovat, vy zjevne netusite, ze neni problem jen v knihovnach.

[boo]

Ja na to koukam prakticky, kdykoliv se mi povedlo zprasit nainstalovany linux tak to bylo v knihovnach. S binarkou nemuzou byt takove potize ponevac bud funguje nebo nefunguje. Samozrejme nemuzem jit do extremu a do kazde binarky linkout staticky treba glibc, ale bezna aplikace jako napriklad Amarok se spoleha na stado multimedialnich libu a pritom je to jednoucelova vec - prehravac. Proc ji tedy neudelat staticky a pobezi na libovolnem distru ?

[Tom.š Ze.le.in]

Tohle se tu už taky diskutovalo - odkaz na starší blog s diskusí :)

[Karel Zak]

Uff..linkovat staticky... odkud prichazis cizince? Mars? Venuse? Mozna uplne jina galaxie.

http://people.redhat.com/drepper/no_static_linking.html

Welcome to Earth, and: Never use static linking!

[;)]

Mozete vysvetlit toto:

Problém tvorby binárních balíků by mohl v budoucnu vyřešit OpenSUSE Build Service.

Doteraz som mal pocit, ze sa jedna o nieco ako Debiani buildd. Plus to ma moznost vyrabat custom OpenSUSE-based distra. Netusim ale, ako by ti malo riesit problem pre vsetky distribucie...

A este jeden dolezity rozdiel medzi DEB a RPM:

- DEB sa snazi pomocou debconf dotazat uzivatela na konfiguracne parametre a na zaklade toho nastavit instalovanu aplikaciu

- RPM nieco podobne striktne odmieta a instalacia je prezentoavana ako striktne neinteraktivna, nastavuje sa nejaka default konfiguracia

[boo]

Jo DEB je jako setup.exe, nechce se snad jeste zeptat kde mam Program Files ? Kdyz je treba neco dodatecne nakonfigurovat tak at to pri prvnim spusteni aplikace vyhodi okenko s options ne?

[Aleš Kapica]

DEB NENÍ to co setup.exe - spíš už by odpovídalo přirovnání k msi balíku. A ty jako user nemáš co instalovat software, od toho je admin. Pokud už se teda apt ptá při instalaci na nějaké věci, tak to jsou věci které se týkají administrace systému a ne uživatelských nastavení.

Takže si prosím nepleť uživatelská options se systémovými. To pokřivené uvažování o instalaci software - kdy user(!) chce rozhodovat o tom kde bude marasit systém je příšerné.

[xxx]

Tak jo, admine. Dám Vám 3k jako za Win a Vy budete po dobu 5 let jezdit 2x denně mi domů adminovat počítač. Platí?

[xkesh]

Tak jo, admine. Dám Vám 3k jako za Win a Vy budete po dobu 5 let jezdit 2x denně mi domů adminovat počítač. Platí?

Snad 3k za instalaci a optimální nastavení kompletního desktopu (automatizované aktualizace pouze jako bezpečnostní záplaty). I tak za ty peníze dostanete x-krát víc než "jako za Win"

[xxx]

Já to myslel jako kritiku pisatele výše, že programy má instalovat jen admin. Ve Widlích si to udělá i uklízečka doma sama. Většina lidí nejsou milionáři.

[Václav HFechs Švirga]

Ano? A proč mi do ICQ účtu chodí od pěti lidí nějake hlášky na porno weby, mají zavirované windows, přitom se jednomu aktualizuje, i má zaplý firewall a sám si nainstaloval antivir a stejně se mu tam nějaký šmejd dostal (toho už bych ohodnotil jako pokročilého uživatele, možná že si tak ceníte uklízečky, netuším), atd..

Nezdá se mi že by obyčejní uživatelé nějak administraci zvládali. Spíše jsou rádi že jim to nějak funguje a pokud něco nejde, tak to nepoužívají, vyhýbají se tomu a obcházejí to (například v jednom diskusním fóru dotyčný na konec každého příspěvku napsal, že pokud tam uvidí link, ať na něho neklikají, že má zavirovaný pc).

Proto nakonfigurování, nainstalování OS (a základních aplikací) a poučení o bezpečnosti uživatele administrátorem je docela nezbytné k bezproblémovému chodu stanice a to jak u windows, tak u linuxu.

Samozřejmě že si uživatel může občas doinstalovat program pokud ví jak (napsat apt-get jmeno_baliku po instruktáži či poklikat na důvěryhodný setup koupené aplikace, atd...). Ale těžko si vaše uklízečka nastaví firewall či antivir a bez toho to pak vypadá jak to vypadá.

[xxx]

Ale jistě, že kdo instaluje ap by mněl něco vědět. A Widle bych nejraději zákonem zakázal připojovat k netu. Ale to jsme odbočili jinam. Já pouze tvrdím, že knihovny patří k programu. Zjednodušila by se instalace, systém by se nemohl poškodit, binárky by byly spustitelné ve více distrech.

[xxx]

Případně aspoň externí knihovny co by si prgram nainstaloval do svého adresáře.

[AltOS]

Nojo, ale nedopadlo by to stejne jako u balicku PBI (PC-BSD), ze si to pak pri spusteni dane app nacte, trebas i duplicitne, do pameti prave ty knihovny urcene k te aplikaci?

[xxx]

A co? Kolik lidí má dnes 16 MB?. A ti zoufalci stejně nomohou spustit Amarok, Mplayer, K-programy, OOo...

[Peter S.]

ja som proti nejakým prešpekulovaným riešeniam, alebo nejakým centralizovaným - jediným správnym riešeniam. Neviem či také niečo existuje ale napada ma niekoľko možností ako situáciu uľahčiť:
1. Metabalík závislostí, teda išlo by o to aplikácia by bola binárna, ale kedže závislosti by boli zverejnené, mohol by v repozitároch exitovať metabalík (prázdny balík) povedzme pod názvom abcd1234-dependencies a ten by sa nainštaloval závislosti na program abcd verzie 1234, a človek by si iba stiahol a uložil binárku.
2. Pri prvotnom spustení, by si aplikácia skontrolovala prítomnosť potrebných knižníc, jednoducho by hľadala či v systéme existujú súbory ako /usr/lib/foo.so.2 a podobne a ak taký nenájde, tak môže skúsiť jedno alebo dve alternatívne miesta a ak ani tam nebudú, tak vypíše obvyklý názov chýbajúcej závislosti (knižnice) s tým, že nech si ich užívateľ doinštaluje obvyklým spôsobom...
no, zatiaľ asi toľko

[happy barney]

imho sa zamýšľate nad nesprávnym problémom Všetko, čo popisujete, už zvládnu existujúce balíčkovacie systémy. Problém je napr v pomenovaní, čo balíček žiada. Knižnica môže byť kdekoľvek (/lib, /usr/lib, /usr/local/lib, /opt/*/lib, ...), balíček sa môže rôzne názvy (jpeglib, lib-jpeg, ...).

Centralizovať imho treba, názvoslovie, postupy (čo iného vlastne sú vaše návrhy, ako centralizovanie postupov?)

[Peter S.]

"Všetko, čo popisujete, už zvládnu existujúce balíčkovacie systémy." - no o to ide, žiadne dlhodobé rokovania a potom prerábanie niečoho čo funguje, ale jednoduché nástroje. Ak ten inštalátor (kontrolný script z bodu 2) zistí, že chýba knižnica /usr/lib /libjpeg.so.1 (názov som si vymyslel), tak vypíše že je potrebné doinštalovať knižnicu jpeg, s tým, že možné názvy sú: jpeglib, lib-jpeg, ....
Áno, nie je to úplne automatická inštalácia, vyžaduje zásah užívateľa ale podstatne by sa inštalácia uľahčila, aspon by užívateľ vedel, že toto a toto chýba. Ak ide o úplne odstránenie zasahu uživateľa, tak na to by slúžilo riešenie z bodu 1)
Ale ide aj o to či hovoríme o domácnostiach alebo firmách, lebo ja predpokladám, že vo firmách majú ľudí ktorí sa do veci aspon trochu rozumejú a sú ochotný venovať pár desiatok minút inštalácii.
No a toto by sa mohlo spojiť so statickým linkovaním zriedkavejších vecí, a hádam by to fungovalo...

[happy barney]

toto všetko predsa už súčastné distribúcie zvládajú. Problém je ten, že každá s iným názvom

imho sa treba pozerať nie na používanie balíčkov, ale na ich tvorbu, tam sú rezervy.

[JaSel]

Tak je to ve Slackware, aspon já to tak dělám. Nainstaluju balíček, když nejede, tak na něho poštvu ldd, zjistím, co mu chybí, to doinstaluju a pak už jede. Výjimečně se to celé zopakuje.

Pak, že neřešení závislostí je nevýhoda :)

[Peter S.]

s tým rozdielom, že toto čo robíš je ex-post, a pracuješ s binárkou, ale ja som mal na mysli osobitný skript, ktorý zbehne pri inštalácii softu (a napríklad nedovolí dokončiť inštaláciu) alebo môže byť stiahnuteľný osobitne (aby človek nemusel sťahovať 100 MB súbor a potom zistiť, že to nejde)

[happy barney]

swaret

[Luki]

aha... myslite oddelit napr z DEB balicku hlavicku, ktera definuje zavislosti a tu spoustet napred? Ale proc to se prece uz deje u vsech balickovacich systemu, ktere se pokouseji zavislosti resit ( a vetsina z nich to okoukala v ports nebo dselectu )? Zavislost se vam zjisti jeste pred instalaci binarky (dokonce pred stazenim potrebneho balicku, na kterem to zavisi) a stazeni a doinstalovani binarky(dalsiho balicku) vam to navrhne a event. provede. Tedy pokud k dispozici je. A pokud neni, tak jste stejne v identicke situaci.

[PMD]

V OSX to je celkem vyřešené! Desktopové aplikace, eye-candy a utilitky už tam jsou, jsou na dobré úrovni, patche systému vycházejí hromadně v jednom balíku. Uživatelé si Macy kupují kvůli tomu, jak to je pěkné a příjemně se s tím pracuje, nemusí nic instalovat, přinesou to domů a začnou používat jako mikrovlnku. Nechtějí si nic vybírat a ladit, proč by to dělali, je to ztráta času. Pokud něco důležitého chybí, dá se to bez problémů nainstalovat (NeoOfficeJ, Firefox aj.), nikdo nemá problém. Kdo to má na grafiku, CS2 běhá jak víno...

Hlavní rozdíl vidím v tom, že v MacOS X existuje stabilní základ, v kterém už všechno je, dodatky jsou víceméně staticky slinkované (dynamicky využívají právě jen to stabilní jádro), takže je to jeden soubor s příponou .app a ten se zkopíruje do Applications. Tolik tedy k "balíčkovacímu systému" :)

Linux je jedna velká hromada. Všechno je pohromadě v jednom adresářovém systému (v MacOSX je podobný, ale ne pro uživatelské aplikace) a nainstalovat něco bez rootovských práv a/nebo odděleně od všeho ostatního je nadlidský úkol, snad jen s výjimkou Java aplikací. Navíc toho software jsou pro Linux oceány a oceány...

Přiblížit tyhle dva systémy nejde, právě kvůli tomu rozdílnému přístupu uživatelů. Linuxákům většinou nevadí, když se musí rochnit s výběrem distribucí, alternativních desktopů, programů atd... baví je to. O tu svobodu nechtějí přijít, takže tu vždycky bude roztříštěnost a nějaká LSB to nespraví. Jabkáři používají počítač jako vrtačku, nepotřebují vědět, jestli náhodou někde není lepší rukojeť, vypínač, nebo kolečko, ani o tom nechtějí přesvědčovat ostatní. Prostě vyvrtají a šlus:) Zde bych si dovolil přirovnání k Windowsákům, kteří za své peníze místo vrtačky dostali nebozízek, takže jim nezbývá než poohlédnout se po náhradních dílech:D

"Řešení" je podle mě nechat to koňovi (případně evoluci) :)

[rob]

+1, lepe bych to popsat neumel :) MacOS X pouzivam pul roku a spokojenost temer maximalni. Pro hracicky je tam take dost prostoru. Pred tim jsem mel na desktopu Gentoo - take melo neco do sebe, ale zhruba po 3 letech me prestalo bavit cim dal castejsi hledani v diskusnich forech.... Balickovani OS-X je opravdu fajn, organizace adresaru mi take vyhovuje podstane vice ne na WIN nebo Linuxu. Apple dodava a podporuje pouze svuj HW, takze mate jistotu, ze vse poslape jak hodinky.

[Aleš Kapica]

Předem předesílám, že nepoužívám a ani nehodlám používat Mac OS X, takže se na to koukám pohledem z druhého břehu, ale asi by mi vadilo že..

Pokud něco důležitého chybí, dá se to bez problémů nainstalovat (NeoOfficeJ, Firefox aj.), nikdo nemá problém.

Ano, nemá problém. Pokud však existuje port pro Mac OS X U linuxových aplikací má každý možnost přiohnout je k obrazu svému.

Linux je jedna velká hromada. Všechno je pohromadě v jednom adresářovém systému (v MacOSX je podobný, ale ne pro uživatelské aplikace) a nainstalovat něco bez rootovských práv a/nebo odděleně od všeho ostatního je nadlidský úkol, snad jen s výjimkou Java aplikací. Navíc toho software jsou pro Linux oceány a oceány...

No právě, každý má jiné gusto. Jenže existuje ta drobná nuance mezi administrací a užíváním systému. I v linuxu je možný vámi oblíbený postup. Nicméně Linux je z principu víceuživatelský systém. Tzn. uživatelské aplikace se instalují z jedné vody pro všechny co k nim mají mít přístup. Cpát je do každého uživatelského adresáře extra je z principu špatná volba.

Přiblížit tyhle dva systémy nejde, právě kvůli tomu rozdílnému přístupu uživatelů. Linuxákům většinou nevadí, když se musí rochnit s výběrem distribucí, alternativních desktopů, programů atd... baví je to. O tu svobodu nechtějí přijít, takže tu vždycky bude roztříštěnost a nějaká LSB to nespraví. Jabkáři používají počítač jako vrtačku, nepotřebují vědět, jestli náhodou někde není lepší rukojeť, vypínač, nebo kolečko, ani o tom nechtějí přesvědčovat ostatní. Prostě vyvrtají a šlus:) Zde bych si dovolil přirovnání k Windowsákům, kteří za své peníze místo vrtačky dostali nebozízek, takže jim nezbývá než poohlédnout se po náhradních dílech:D

Není to jen o tom že se linuxáci v systému rádi rochní. Spíš naopak. Je to o tom, že Mac OS X je orientovaný především na desktop a jako takový spoustu problémů neřeší, nebo je řeší jinak. Linux má zase dispozice pro to být skutečně masově používaným systémem. I když tomu česká realita zatím nenasvědčuje.

[happy barney]

dispozice ... hmm.
ano, v linuxe panuje sloboda, sloboda programátora (ale nie už užívateľa). V tomto ohľade je na tom lepšie OS X, dokonca aj windows ... jednoducho programátor nemá na výber API (GUI). A podobné drobnosti.

Prečo väčšina aplikácii pod Linux je napísaná neunixovo? Žeby preto, aby sa ľahšie portovali? Prečo napr neexistuje jedno (abstraktné) GUI, s implementáciou gtk+, qt, motif, ... podľa vkusu usera. Prečo napr pre správu mailov neexistuje jeden lokálny unix-socket daemon, vymeniteľný bez nutnosti zmeny aplikácie?

[Aleš Kapica]

Pracujete vůbec s linuxem? Mám totiž že mluvíte o nějakém mě zcela neznámém OS.

Nechápu totiž vaši představu jediného abstraktního GUI. Faktem je, že veškerý vývoj aplikací k němu pomalu spěje, ale proč bych se jako uživatel měl probůh nechat omezovat jediným tím správným GUI?

Vyhovují mi aplikace v GTK2 tak je upřednostňuji. Sedí mi více Qt aplikace? Fajn, proč ne. Pokud jde zrovna o maily, tak se nabízí rovnou celá přehršel nejrůznějších řešení. Každému co jeho jest.

Nebo vám uniklo, že i ta "většina" aplikací kterou zřejmě máte na mysli (OpenOffice, Firefox, aj.) si tahá svoje implementace GUI na jiné OS sebou a neunixově se chová pouze na neunixových systémech, resp. jsou-li neunixově zkompilovány?

Já tedy osobně v uživatelském adresáři mám pouze to co tam skutečně patří. Konfigurační soubory a svoje dokumenty s soubory s nimiž pracuji.

[happy barney]

užívateľ? obmedzovať? to nie, užívateľské nastavenie by bolo napr takéto:

preferred file open dialog = file-open-gtk
preferred widget set = qt

výsledok? funkcionalita file-open-gtk (ktorý by nevyužíval priamo gtk_* widgety, ale tie abstraktné) s qt widget setom, vo všetkých aplikáciach.

a ak vravíme "zrovna" o mail klientoch, tak osobne by som ich rozdelil na tri časti: retrieve (napr fetchmail), local-storage(-daemon) a klient. Napríklad.

[MaT]

Ad ta pošta - zrovna něco takového už nějaký ten rok používám. Lokálně provozuji imap server, do něj mi poštu stahuje fetchmail (ale možno nahradit třeba getmailem) no a jako klienta k tomu střídám Thunderbird, Evolution, Sylpheed, Sylpheed-claws - podle nálady. Takže co komu brání, udělat to stejně?

[happy barney]

keď už ten mail ... popisovaná kombinácia by vyhovovala, ak:
- imap server beží pod userom, počúva na unix sockete (napr $HOME/tmp/.imap-socket)
- klient konfiguruje priamo fetchmail (getmail)

predstavte si usera, NFS /home, non-root prístup k stroju, presúvajúceho sa medzi rôznymi strojmi

[PMD]

Ano, nemá problém. Pokud však existuje port pro Mac OS X U linuxových aplikací má každý možnost přiohnout je k obrazu svému.

Nechápu na co reaguješ, tak se zdržím komentáře. Snad jen na vysvětlenou - psal jsem o snadnosti instalace těch portů, ne o tom, zda existují, nebo jak snadno jsou dostupné.

No právě, každý má jiné gusto. Jenže existuje ta drobná nuance mezi administrací a užíváním systému. I v linuxu je možný vámi oblíbený postup. Nicméně Linux je z principu víceuživatelský systém. Tzn. uživatelské aplikace se instalují z jedné vody pro všechny co k nim mají mít přístup. Cpát je do každého uživatelského adresáře extra je z principu špatná volba.

OsX je taky z principu víceuživatelský. Střídám se na Macu s jiným grafikem a práva instalovat programy má jenom ajťák. Dohromady používáme jednu sadu grafických aplikací a každý má na svém účtu svoje dodatečné programy (MacAmp, ICQ...), které si nainstaloval sám. Opět nechápu, s čím bych měl být nespokojený

Není to jen o tom že se linuxáci v systému rádi rochní. Spíš naopak. Je to o tom, že Mac OS X je orientovaný především na desktop a jako takový spoustu problémů neřeší, nebo je řeší jinak. Linux má zase dispozice pro to být skutečně masově používaným systémem. I když tomu česká realita zatím nenasvědčuje.

Opět nechápu, pro co/proti čemu je tahle reakce... Nepsal jsem o rochnění v systému, ale o někdy křečovitému vybírání té jediné správné distribuce, aplikace apod. a také o lpění na tom výběru a jeho fundamentalistickém obhajování. Omlouvám se, jestli jsem se nevyjádřil jasně.

My se vlastně vůbec v ničem nerozcházíme, článek i moje reakce byly o instalaci balíčků, já jen přidal svoje subjektivní porovnání s Macem. Nepsal jsem to proto, abych říkal, že Linux je na hovno:)

Mimochodem, doma používám téměř výhradně Linux už nějakých 8 let, jen abych někoho nemátl, že snad za něco válčím...

[sssssssss]

Je vidět, že MAC OSX neznáš, mam jabko čtvrtej měsíc a nemam výhrady, přešel jsem po téměř třech letech z Linuxu (převážně Ubuntu)

[boo]

Detto je to ve vyse zminovanem PC-BSD, neni sice na to tolik predkompilovanych veci jako v linux distrech ale zaklad tam je, dokonce existuje i PBI balicek Photoshop7, pozuse se zepta na seriove cislo a nainstaluje vsechno, o tom ze je tam pribaleno i wine uzivatel nemusi mit ani paru protoze to je wine jen pro ten photoshop. Proste radeji mit v pameti 3x stejny liby s jistotou ze system funguje nez dnesni /usr/lib linux problem.

[Prcek]

Mne prijde idealni Portage. Vyvojari programu se nemusi starat o pripravu balicku pro x ruznych distribuci, ale vystavi jenom zdrojaky a tim je to vyreseny (mozna by mohli jeste napsat ebuild ).

[otula]

+1

Naprostý souhlas, i když Gentoo nepoužívám. Používám Arch. A ABS systém je tomu Gentoovskému velmi podobný. Na Arch se dívám jako na distribuci, kde je možno si balíčky, u kterých mi nezáleží na optimalizaci, stáhnout zkompilované (i když je asi servírována spíš opačně - že je možno si některé balíčky zkompilovat). Je velmi sympatické, že k mamutům, jako xorg, kde, openoffice, někdo šikovnější vymyslí postup, jak je optimálně zkompilovat, a zveřejní ho. A u ostatního softwaru mne vůbec, ale opravdu vůbec, netrápí, jestli jsou, nebo nejsou, v repozitáři. Prostě si napíšu PKGBUILD a udělám si svůj balíček, takže celá problematika kompatibility a závislostí balíčkovacích systémů/balíčků odpadá.

[hanzz]

Predem se omlouvam za to, ze nemam cas cist vsechny prispevky v diskuzi, takze nevim, jestli uz nekdo neco podobneho nerikal, ale zkusim nastinit muj nazor na vec z pohledu developera programu pro windows a linux.

Podle me je soucasna situaci hodne nevyhovujici. Vemte si, ze chce clovek vytvaret program s nejnovejsi knihovnou X, ktera ma verzi pro windows i linux. V repozitarich vetsiny distribuci je knihovna X ve starsi verzi, kterou nelze pouzit kvuli chybam (nebo nedostacujicim vlastnostem). Nezbyva tedy nic jineho nez staticky linkovat aplikaci s nejnovejsi knihovnou, cimz ale napriklad prijdeme o specificke nastaveni systemu (co se tyce QT4 tak prijdeme o prebirani temat z KDE atd.), nebo dodat knihovnu jako balicek do distribuce (s cimz je spojeno vytvoreni vlastniho repository + extra prace + moznost kolize knihoven mezi sebou atd)

Proste kdyz chce clovek delat program pomoci nejnovejsich prostredku, tak je to z hlediska pouzitelnosti programu zbytecne, protoze nepujde spustit rozumne nikde...

Naproti tomu na windows (vim, ze je to dano "systemem" "spravy" aplikaci, ale to srovnani si neodpustim), jednoduse pribalime knihovnu k programu a vytvorime instalator, ktery ji pak i odinstaluje. Vim, ze z hlediska spravy SW to je oproti linuxu o nicem, ale pro uzivatele to je Just Works. A tahle vec mi na linuxu chybi.

Jestli vi nekdo o rozumne ceste, jak vytvaret SW pro linux s pouzitim novejsich verzi knihoven, nez jsou v repozitarich, tak se rad priucim :).

[Bluebear]

jednoduse pribalime knihovnu k programu a vytvorime instalator, ktery ji pak i odinstaluje. Vim, ze z hlediska spravy SW to je oproti linuxu o nicem, ale pro uzivatele to je Just Works.

Bohužel, s tím Just Works to není zas tak horké. Dá se to použít u aplikací, které nejsou moc provázané se systémem, ale běda, pokud jsou (hry fungují jen díky tomu, že hráči jsou zvyklí, že musí mít nejnovější verzi DirectX, nebo jak se to teď jmenuje).

[Milan Jurik]

Zrovna to DirectX se za mych Wincasu distribuovalo zaroven s kazdou hrou. Takze ty, ktere potrebovaly aspon DX5, mely s sebou DX5. Ty, ktere chtely DX7, s nim prisly. To same platilo treba o popularnich knihovnach z VB. Ale to mohlo fungovat jen proto, ze:

a) jeden typ prostredi pro integraci

b) relativne velmi stabilni a zpetne kompatibilni API/ABI

Ani jedno z to v prostredi GNU/Linuxu neni (nic nerikam o tom, zda je to vyhoda ci nevyhoda, zbytecny podnet pro flame).

[Josef Průša]

..a zrovna tohle tak úplně nefungovalo. Nastaly situace, kdy novější verze DirectX rozbila funkčnost starších her. Např. mezi verzemi 8.x -> 9.x na W9x. To jen tak na okraj.

[Bluebear]

Instalátor ve Windows je bohužel veliké zlo v případě, že autor aplikace je čuně, protože pak má možnost neomezeně zprasit celý systém. Klasický příklad jsou nejrůznější drivery a různé pomocné prográmky, které se dodávají k hardwaru. Nainstalujete jeden - naleze vám tam pět dalších programů, které se spustí při každém spuštění, celou dobu běží na pozadí a krom toho, že kreslí ikonku do systraye, nejsou k ničemu, nebo v horším případě narušují funkčnost systému (například si zaregistrují nějaké přípony, takže pak se určité dokumenty otevírají v něčem úplně jiném, než by měly).

[Milan Jurik]

A on snad nektery z balickovacich systemu zabranuje tomu, aby autor aplikace, kdyz je cune, presne tohle zprasil i na "te prave" distribuci? Jedine, co tak vychytaji, je, ze zabrani prepsani jiz existujicich souboru.

Ja mel pocit, ze cilem je podpora ISV, ne pohlceni vseho software do distribuci, kde nad tim maji firemni balickari kontrolu.

[Mintaka]

Pracuji na diplomové práci, jejímž zadáním je navrhnout systém pro zjednodušení správy instalací. (Application deployment) Takže děkuji Michalu Vyskočilovi a ostatním za podnětné myšlenky.

Možná by pomohlo:

• Kdyby existoval jednotný formát popisu programu, který by obsahoval všechny údaje potřebné k případnému sestavení rpm, deb, ebuildů, msi a dalších. Případně pak rovnou pro nějaký nový (nejlépe multiplatformní) manager instalací.
  Univerzální popisný soubor (možná XML) by asi obsahoval:
  
  • odkaz na zdroj programu a informace o tom v jake podobě je distribuován (binárky/source/tar/zip)
  • názvy jednotlivých souborů, ze kterých se program skládá, jejich atributy (například i hash)
  • relativní cesty do jaké adresářové struktury mají být soubory umístěny
  • případné požadavky na HW
  • SW požadavky na OS, drivery, virtuální stroje, knihovny, služby, ...
  • cesty ke zdrojům potřebných knihoven
  Tento soubor by byl vytvořen ke každému buildu programu. Samozřejmě že nejlépe automaticky. Pro konfigurační programy by mohlo existovat něco jako centrální repozitář, lépe však něco decentralizovaného na způsob DNS.
• Druhý konfigurační soubor by obsahoval informace o konkrétním počítači. Informace o HW, SW. Obsah souboru by byl automaticky updatován před instalací (volné místo na HDD, aktuální verze JVM, GTK, ...).
• Třetí kofigurák by se vztahoval k údajům pro konkrétní program na konkrétním stroji konkrétního uživatele. Např: kde má program hledat knihovny / programy, se kterými spolupracuje. Snad by tak bylo vyřešeno používání více verzí stejné knihovny.
• V průběhu instalace by se hlídala řada věcí, např. aby nedošlo k přepsání souborů, které používá jiný program. Jedna verze knihoven by byla pro většinu stejná a pokud by některá aplikace potřebovala jinou verzi buď by admin tu původní updatnul, a nebo by nová knihovna byla uložena na jiné místo a program by dle konfiguráku věděl, kde ji má najít. To by ovšem znamenalo, aby programy tuto možnost podporovaly, jinak by se to muselo řešit nějakou formou maskování na úrovni OS.

Programátoři by mohli snáze používat nové verze knihoven.
Admini by připravili OS + základní knihovny + základní programy. A nemuseli by dělat image kvůli každé drobnosti.
Uživatelé by měli seznam dostupných aplikací, když by ji chtěli použít, tak by se aplikace buď rovnou spustila, a nebo by se pokusila automaticky nainstalovat a spustila by se až potom. V horším případě, by řekla, proč nemůže být nainstalována.

Nejraději mám programy, které prostě zkopíruji na ReadOnly disk na serveru, uživatelům udělám zástupce ve sdíleném adresáři se zástupci a vše funguje jak má, update se provede zkopírováním nové verze, odinstalace se provede smazáním.

Pravděpodobně zkusím spáchat program (asi v Pythonu), který by dokázal dle XML konfiguráků instalace řídit a hlídat. Pěkné by bylo, kdyby nezáleželo na tom, jaký OS máte a stačilo by vám říc, který program chcete nainstalovat. Buď by to šlo, nebo by bylo jasné, proč to nejde a co se dá dělat aby to šlo.

Řekl bych že na Linuxu je o poznání lepší situace (emerge, apt-get, ...) než na Windows. Tam jsem zaregistroval jen několik málo, většinou komerčních programů (LanDesk, Citrix Presentation Server, Ca unicenter) někdo se to snaží řešit přes Active Directory. (Trochu víc je na http://en.wikipedia.org/wiki/System_management) Jaké máte zkušenosti s programy pro správu instalací?

[Botanicus]

Clanek je moc hezky, nicmene ja nemohu souhlasit - povidacky o tristeni sil: OK, sily se tristi. Fajn, no a co? Je treba se zamyslet, zda nam to nahodou taky neco neprinasi (napoveda - kdyby mi na PC nekdo narval yast, tak mu zprerazim pazoury, kdyz mi vyhovuje pacman && abs ... BTW reknete to gentooinstum, budou mit radost ... ;) ). Pochybuji, ze bude nejaky nastroj, co bude vyhovovat vsem. Zaroven nepovazuji tristeni sil za tak kriticke. Dle meho nazoru se to jednoznacne vyplati. Za sebe mohu prohlasit, ze ackoliv spravuji nekolik dister s nekolika BS, tak si nestezuji.

[Martin]

Já ten linuch moc nechápu. Když ve Windows vyšla nová verze nějakého programu, stáhl jsem setup.exe a nainstaloval. A bylo to.

Když vyjde nová verze linuxového programu, jsem s mým Ubuntu v koncích. Musím počkat, až se distributorovi uráčí tu novou verzi nacpat do distribuce místo té staré a až na to dojde, musím aktualizovat všechno a doufat, že se nic nepokazí. Tohle má být nějak lepší způsob? Nechápu.

[xkesh]

Já ten linuch moc nechápu. Když ve Windows vyšla nová verze nějakého programu, stáhl jsem setup.exe a nainstaloval. A bylo to.

Když vyjde nová verze linuxového programu, jsem s mým Ubuntu v koncích. Musím počkat, až se distributorovi uráčí tu novou verzi nacpat do distribuce místo té staré a až na to dojde, musím aktualizovat všechno a doufat, že se nic nepokazí. Tohle má být nějak lepší způsob? Nechápu.

Opominu, že je to evidentní flamebait a že se jeho stvořitel samozřejmě nehodlá přihlásit, protože se mi zrovna odpovědět chce.

1) Především musí člověk sám hlídat, kdy vyjde nějaká verze programu (a nikoliv ve Windows, ale pro Windows). U jednoho či dvou to ještě může být zábavné, ale u všech, co má člověk nainstalovány? Uživatel linuxové distribuce toto zjistí zpravidla několika povely: nemusí ani hledat, ani stahovat, prostě jen vydá příkaz: aktualizuj systém včetně programů.

2) Distributorovi se uráčí nacpat novou verzi do distribuce zpravidla poté, co ji někdo vyzkoušel a zbavil základních bugů. To také stojí za to, že máte některé programy k dispozici o pár dní či týdnů později: že už je někdo jiný vyzkoušel.

3) Pokud ale tu trpělivost nemáte anebo novou verzi skutečně nutně potřebujete (anebo se chcete podílet na testování), mají solidní distribuce něco jako experimentální větev, kam se zařazují ty nejnovější programy velmi aktuálně, a kromě toho nabízejí postup, jak si vytvořit ze zdrojových kódů balíček pro vlastní distribuci.

Shrnuto: instalace programů pro Windows je z hlediska jejich aktualizace předpotopní a velmi nepohodlná záležitost, protože viděno komplexně nevyváží pohodlí uživatelů linuxových správců balíčků ani možnost instalovat jeden program stylem next next finish.

[Robert Krátký]

nevyváží [...] možnost instalovat jeden program stylem next next finish.

Nehledě na to, že většina distribucí nabízí možnost instalace i aktualizace ještě přímočařejší než "next next finish".

[Prcek]

Presne tak - jeden prikaz v terminalu a cely system se aktualizuje... nadhera, kam se hrabe windows .

[J]

Navíc by pro ně bylo občas vhodné mít možnost vedle sebe nainstalovat několik verzí paralelně, což stávající systémy neumí.

Nevim jak jiny distra, ale Gentoo s portage tohle bez problemu umi, ve svym systemu mam celkem dost balicku od nihz mam nainstalovano vicero verzi.

[Mintaka]

Ano Portage to umí. Tzv. instalace do slotů.

Kromě toho nabízí také virtuály pro situace, kdy nějaký program ke své činnosti vyžaduje určité služby, které poskytuje řada různých aplikací, a dopředu se neví, pro kterou se uživatel rozhodne. Virtuál je zde něco jako zástupné jméno za danou službu.

Další fičůrkou je přizpůsobení systému pro určité vývojové větve SW. Stable / unstable - můžete celý systém postavit na vývojových verzích SW nebo si zvolit jen konkrétní programy, u kterých chcete jít na unstable větve. Funguje to i obraceně. Můžete zastavit některé programy na určité verzi a zbytek systému se bude dál aktualizovat.

Hlídání kruhových závislostí. A další.

Podrobněji na http://www.gentoo.org/doc/cs/handbook/handbook-x86.xml?part=2&chap=1

[Michal Vyskočil]

No na sloty si, pokud vím, spousta uživatelů stěžovala, protože slotovaných balíčků zase tolik není. Virtuální balíčky a mixování verzí umí Debian také ovšem něco jako sloty imo nemá ...

[happy barney]

blbá otázka: ako zapadajú sloty do FHS ?

Osobne, keď potrebujem, to riešim post-install skriptom, ktorý presunie obsah balíčku do (napr)/usr/Linux/{package}/{version}/. Pre hlavnú verziu urobí

ln -s {version} current
cp -Rs /usr/Linux/{package}/current/* /

[Michal Vyskočil]

Nemyslím, že je to proti FSH. Teď mám nainstalované dvě verze jvm. Verze 1.5 je v /usr/lib/jvm/java-1.5.0-sun a verze 1.6 je v /usr/lib/jvm/java-6-sun. Ovšem java je v Debianu výjimka, protože to technicky jsou dva různé balíky sun-java5-xxx a sun-java6-xxx.

[tomas]

jsem zacatecnik chtel bych se zeptat proc je takovy problem v linuxu a aby si program sebou nesl i potrebne knihovny ktere by nenarusli system? treba neco podobneho jako puziva pcbsd

[Mintaka]

No, asi aby si pak sebou program nenesl celý linux.

V prostředí closed source kde si kde kdo hraje na svém písečku, není propojení mezi knihovnami zase tak moc velké. Většina si vystačí s tím co dostanou (třeba od MS DirectX, nebo knihovny k jejich oblíbenému vývojovému prostředí "Delphi"), ale v prostředí open source, kdy se dá navázat na dostupné kvalitní knihovny, kdy se pracuje modulárně, tak je to jiné.

Spíše by se měl standardizovat přístup ke knihovnám a v podstatě k celému "software deployment".
Jak vidět, někdo už to zkouší http://www.w3.org/Submission/2004/04/

[Predator]

Podľa mňa je riešením PBI z PC-BSD. Nielen že je inštalácia banálne jednoduchá, ale má ďalšie dve výhody - pre užívateľa jednoduchý upgrade aplikácie a ďalej to, že pri manipulácii s aplikáciou sa nemôže stať, že kvôli upgradu jednej aplikácie nepôjde päťdesiat iných, lebo sú linkované na knižnicu, čo bola zamenená novšou.

A to, že by sa sprasil systém, to už vôbec nehrozí. Už len preto nie, že v BSD je systém a jeho knižnice striktne oddelený od aplikačnej časti. Navyše tu to je posunuté ešte ďalej - každá aplikácia má svoj adresár a v ňom konfiguráky, binárky, knižnice ... teda každý program sa hrá na vlastnom piesočku a keby sa niečo nepekné stalo pri upgrade či inštalácii, neohrozí to ostatné aplikácie.

Myšlienka zdieľaných knižníc je síce svojím princípom elegantná, ale podľa môjho názoru sa začína dostávať k svojím limitom. Je vhodná len tam, kde je iba pár aplikácií a tieto nemajú mnoho prekrývajúcich sa závislostí. Teda na serverové inštalácie, kde dajme tomu beží apache+MySQL+php, a to je všetko ... Pre desktop sa to ale mení na nočnú moru. Udržiavať konzistenciu v systéme, kde sú desiatky aplikácií a každá je závislá na polovici vesmíru, je poslednú dobu stále tvrdší oriešok aj pre skúsených užívateľov Linuxu či iných unixových systémov. Kompilovať všetko zo zdrojáku je zase časovo náročné, kto si skompiloval napríklad kompletné KDE či OpenOffice, vie, o čom rozprávam.

Vývojári z Apple to pochopili a tak vymysleli systém, kde v balíčku je všetko, čo aplikácia potrebuje na to, aby sa rozbehla. A podobným smerom mieri aj PC-BSD.