Arch Linux (diskuse)

[Triton]

Z mého pohledu bych přidal k nevýhodám nevhodnost pro serverové nasazení díky systému aktualizací pomocí "rolling updates", známé třeba z Gentoo, u kterého je to všechno navíc ještě zkomplikováno fází kompilace ze zdrojů (heh, kolikrát si člověk musel pomáhat hledáním na disk. fórech při nedokončené kompilaci např. díky chybě v ebuildu ?) . Odzkoušená stabilní verze + systém pouze bezpečnostních updatů je to co, od serverového distra očekávám.

S Arch Linuxem mám vlastní zkušenost od verze 0.6 . Jeho dodržování KISS filozofie, systém inicializačních skriptů - aneb /etc/rc.conf "one rule them all" , formát instalačních balíčků, pacman a ABS mi byli velmi sympatické. Bohužel dojem zkazily občas některé balíčky z currentu, které nebyly správně připravené a po aktualizaci některé aplikace přestaly fungovat, jednou dokonce i celý systém. Vždycky se to podařilo nakonec zprovoznit, ale byly to IMHO zbytečné problémy a navíc jsem zvyklý na spolehlivější distra.

[Triton]

s/one\ rule/one\ rules/

[finn]

s/díky/kvůli/g ;–)

[Zdeněk Štěpánek]

Zdravim

Tak vida, zase jsem se dozvedel neco noveho. Z clanku jsem to ale pochopil trochu jinak, no co, nevadi.

K tem zavislostem, ja nedokazu odhanout jestli je ta zavislost udelana spatne nebo je lepsi ji tam nechat kvuli tomu zbytku kterejm to nevadi.

Je to jiste velmi zajimava distribuce, urcite ji jeste budu nejak zkouset.

Imponuje mi i moznost nainstalovat z mini-iso (pres torrent bylo za 2 hodiny doma), hned upgradovat (ted je to kolem 70MB) a zbytek tahat z FTP. Ja jsme zatim skoncil za upgrade, KDE se vsema zavislotma jsem z netu netahal. U slackwaru je sice mozne instalovat current z ftp nebo nfs, ale bud musim mit diskety a tudiz disketovku nebo stahnout cele CD ktere je zastarale.

Zdenek

[juice]

nemal byť tento váš komentár náhodou odpoveďou na môj príspevok nižšie ? tu na tomto mieste tento komentár mi nedáva príliš zmysel

[Zdeněk Štěpánek]

a ja jsem hledal kam se ten prispevek ulozil.... patri samozrejme nekam na konec.

[Mikos]

I když je mojí nejoblíbenější distribucí stále Gentoo (protože portage je prostě geniální a navíc mám rád koncept source-based distribuce ), tak sem z několika různých důvodů přesedlal nedávno na Arch Linux. Hlavním důvodem bylo asi to, že ve stable x86 byly pořád čím dál tím starší ebuildy (zkrátka pomalé aktualizace) a Gentoo developeři mi přišli velmi uzavření (jako by nechtěli moc přijímat pomoc zvenší).

Proč sem si vybral Arch? Instaloval sem ho předtím už na dvou počítačích a přijde mi jako naprosto dokonalé binární distro. Kombinuje ty nejlepší vlastnosti ze Slackwaru (krásně čistý systém) spolu s těmi nejlepšími vlastnostmi z Gentoo (vynikající balíčkovací manager pacman, Arch Build System - obdoba portage, optimalizace pro i686). Co se mi na něm líbí nejvíc je to, že nemá žádné pevné verze, ale podobně jako Gentoo se drží systému "rolling updates". A hlavně má opravdu aktuální verze programů - vyjde li nová verze, do pár dní jí máte. Některé stable verze v Arch Linuxu jsou dokonce novější než unstable verze v Gentoo, což je úžasné.

Jinak zkušenosti s ním mám opravdu skvělé - pokud binární distro, tak prostě jedině Arch, nic jiného na mých desktopových počítačích být nesmí Pořád se mi hrozně moc líbí idea source-based distribuce a na Gentoo nedám dopustit (a stále ho považuju za to nejlepší distro pod Sluncem ), ale dokud se nezlepší situace ohledně rychlosti aktualizace ebuildů a jejich přijímání do stable x86, je Arch mým favoritem.

Navíc sem ho instaloval spolužákům z jaderky, kteří nikdy v životě předtím na Linuxu nedělali (jen měli vůli zbavit se břemene Windows a opravdu se naučit Linux), a ti jsou také velmi spokojeni. Zkrátka nemám co bych Archu vytknul

[xkesh]

ve stable x86 byly pořád čím dál tím starší ebuildy (zkrátka pomalé aktualizace)

Nejaky priklad by pro zajimavost nebyl? Aniz bych pripisoval zavodum o dny a mini-upgrady nejaky velky vyznam, tak jen namatkou:

AL: k3b 0.11.24-2 (Extra)

Gentoo: 0.12_beta1 (hardmasked) / 0.11.24 (masked) / 0.11.23-r2 (stable)

AL: elinks 0.10.5-1 (Extra)

Gentoo: 0.10.5 (masked) / 0.10.4 (stable)

AL: alsa-driver 1.0.8-3

Gentoo: 1.10.9 (masked) / 0.10.8 (stable)

Jeste se musim podivat, co znamena v ArchL "stable" :) Moje nadseni pro experimenty prave zchladilo Ubuntu 5.04, ktere bych po selhani konfigurace xorg (nenastavilo zadnou refresh rate, bez varovani, rucne nastavenou ignoruje!) oznacil velkym BETA. Krome toho si stahuje klidne za mymi zady (v konzoli pod nabehlou grafikou) celej openoffice kvuli zavislostem, diky chybam v ceskem instalatoru neni mozne instalaci korektne ukoncit, nefunguje diakritika v konzoli... na dalsi zjistovani uz jsem nemel nervy.

O Ubuntu se ovsem pise stejne nadsene jako ted o ArchL... mam to zkusit, nebo taky brat nadseni radsi s velkou rezervou?

[Michal Karas]

Zkus ho. Ja pouzivam Arch od te doby co jsem ho objevil, tedy asi trictvrte roku, a pred tremi tydny jsem instaloval KUbuntu. Zatimco z Archu jsem porad nadseny, tak na KUbuntu mi vadily stejne veci jako tobe. Nejvic je rozdil filozofii techto distribuci videt asi na init scriptech. Zatimco v Archu si hezky nastavis v prehlednem rc.conf, co vsechno chces pri startu poustet, tak v KUbuntu musis naopak vyhazet vsechny ty pytloviny, ktere ti to pousti samo. Arch mi svou jednoduchosti pripomina Slackware. Nastesti co se tyce balicku, tak je na tom podstatne lepe.

[Jan Kundrát (jkt)]

Hlavním důvodem bylo asi to, že ve stable x86 byly pořád čím dál tím starší ebuildy (zkrátka pomalé aktualizace)

Uved prosim konkretni priklad, o kterych baliccich mluvis.

a Gentoo developeři mi přišli velmi uzavření (jako by nechtěli moc přijímat pomoc zvenší).

Priklad?

[Mikos]

Příkladů je mnoho, třeba MySQL, PHP, KDE, GCC, sun-jre a sun-jdk, atp. Můj /etc/portage/package.keywords už zabíral asi cca přes 6 obrazovek, to už sem rovnou mohl přejít kompletně na unstable ~x86 (jenže to pak člověk ztratí kontrolu a to sem nechtěl). Navíc dost věcí bylo i hard-masked (třeba ta java 1.5, mysql 4.1.x, atp.) a to sem opravdu pokoušet nechtěl (i když něco sem ručně unmaskoval).

A co se týče přístupu developerů - když člověk pravidelně čte bugzillu a fóra, tak mu prostě utkví jak developeři jednají. Né že by byli nějací arogantní nebo tak něco, to opravdu ne, ale prostě mi přišli uzavření. Rychlost přijímání nových verzí do portage se oproti tomu když sem s Gentoo začínal opravdu dost zpomalila (minimálně je to můj subjektivní pocit) a Gentoo developeři moc nepřijímají pomoc od uživatelů (např. v Bugzille sem narazil na spoustu ebuildů na novější verze programů, které ovšem ani po dlouhé době do portage nebyly zahrnuty).

S tim má přímé zkušenosti i kamarád. Možná je to jen můj osobní pocit, nevím... rozhodně nechci práci Gentoo developerů nějak zchazovat, dokázali obrovskou věc. Ale prostě přišli že v poslední době nejsou dost otevření pomoci od komunity. A muj pohár trpělivosti holt už přetekl...

[Jan Kundrát (jkt)]

Příkladů je mnoho, třeba MySQL, PHP,

Jeste zminit verze. Kdyz proste neco neni podle rozhodnuti vyvojaru stabilni, tak to tak neoznaci. V cem je problem?

KDE

Pokud mluvis o KDE/3.4, tak je tam bug s -fvisible optionou pro gcc.

GCC

Pokud ke sve praci potrebujes nove GCC, samozrejme si ho muzes nainstalovat, aniz bys nutil Portage pouzivat prave tu novou verzi.

sun-jre a sun-jdk, atp. Můj /etc/portage/package.keywords už zabíral asi cca přes 6 obrazovek, to už sem rovnou mohl přejít kompletně na unstable ~x86 (jenže to pak člověk ztratí kontrolu a to sem nechtěl). Navíc dost věcí bylo i hard-masked (třeba ta java 1.5, mysql 4.1.x, atp.) a to sem opravdu pokoušet nechtěl (i když něco sem ručně unmaskoval).

Tak ted Te ale vazne nechapu - nechces pokouset stesti, a protim Ti vadi, ze neco jeste "neni dozraly"?

ale prostě mi přišli uzavření.

Mohl bys mi prosim vysvetlit, co tim myslis?

např. v Bugzille sem narazil na spoustu ebuildů na novější verze programů, které ovšem ani po dlouhé době do portage nebyly zahrnuty

Oficialni vysvetleni od vyvojaru: "Je nas malo."

[Mikos]

To "nechci pokouset stesti" je zcela na miste, protoze kdyz clovek odmaskuje hard-masked ebuild, muze se rozloucit s podporou developeru kdyby mel pripadne nejake problemy. Navic je to vec kterou opravdu nemam rad, prijde mi to proste "neciste".

Co se tyce GCC, tak ja nechci mit jen moznost pouzivat novejsi GCC (GCC 3.4.x), ale chci mit cely system zkompilovan s GCC 3.4.x, protoze generuje lepsi a rychlejsi kod. Samozrejme ze ja tohoto sveho cile dosahl relativne jednoduse (stacilo v prubehu stage1 instalace pridat potrebne ebuildy do /etc/portage/package.keywords jako ~x86), ale zas jak rikam to neni uplne koser reseni a myslim si, ze kdyby nastali nejake problemy, muzu byt odpalkovan s tim at pouzivam bud komplet stable x86, nebo komplet unstable ~x86 system. Ale tohle rikam opravdu jen tak namatkove, s timhle sem problemy nemel. Jen mi to prijde trosku divne, ze zatimco dnes jiz temer vsechny moderni distribuce (o Debianu se samozrejme vubec nebavim ) pouzivaji standardne GCC 3.4, v Gentoo je GCC 3.4 stale jako unstable (a to jiz opravdu hooodne dlouho).

Co se tyce KDE 3.4, tak opravdu nechapu proc by to mel byt problem, kdyz vsude jinde uz je KDE 3.4 standardne pouzivano. Nevim jaky konkretni bug mas ted na mysli, ale nastavovat rucne -fvisibility GCC flag stejne neni vubec v poradku a kazdej Gentoo developer by te v pripade problemu vyfuckoval, pokud by zjistil za mas napr. v CXXFLAGS dano -fvisibility=hidden. Ale mozna je ten bug o kterem mluvis o necem jinem, fakt nevim, ted jen strilim od boku...

Ad to tvoje: Oficialni vysvetleni od vyvojaru: "Je nas malo."

To je sice pekne (a vim o tom), ale to je presne to jadro pudla o kterem sem mluvil, kdyz sem rikal ze mi Gentoo developeri prijdou uzavreni. Sice se omlouvaji ze jich je malo, ale ze by tedy zacali prijimat ve vetsim poctu nove developery, to nee...

[Jan Kundrát (jkt)]

To "nechci pokouset stesti" je zcela na miste, protoze kdyz clovek odmaskuje hard-masked ebuild, muze se rozloucit s podporou developeru kdyby mel pripadne nejake problemy. Navic je to vec kterou opravdu nemam rad, prijde mi to proste "neciste".

Ale tim padem mi proste prijde mirne schizofrenni na jedny strane horekat nad tim, ze neco neni oznaceno jako stabilni, a na druhy strane se to bat pouzivat kvuli obavam o stabilitu. Chapes?

muzu byt odpalkovan s tim at pouzivam bud komplet stable x86, nebo komplet unstable ~x86 system

IMHO bys nebyl.

Ale tohle rikam opravdu jen tak namatkove, s timhle sem problemy nemel. Jen mi to prijde trosku divne, ze zatimco dnes jiz temer vsechny moderni distribuce (o Debianu se samozrejme vubec nebavim ) pouzivaji standardne GCC 3.4, v Gentoo je GCC 3.4 stale jako unstable (a to jiz opravdu hooodne dlouho).

Predpokladam, ze se bavime pouze o x86, treba amd64 uz ho pouziva hodne dlouho. Zrejme k tomu maji (x86) nejaky duvod :-P.

Co se tyce KDE 3.4, tak opravdu nechapu proc by to mel byt problem, kdyz vsude jinde uz je KDE 3.4 standardne pouzivano. Nevim jaky konkretni bug mas ted na mysli, ale nastavovat rucne -fvisibility GCC flag stejne neni vubec v poradku a kazdej Gentoo developer by te v pripade problemu vyfuckoval, pokud by zjistil za mas napr. v CXXFLAGS dano -fvisibility=hidden. Ale mozna je ten bug o kterem mluvis o necem jinem, fakt nevim, ted jen strilim od boku...

Mluvim o tomhle.

To je sice pekne (a vim o tom), ale to je presne to jadro pudla o kterem sem mluvil, kdyz sem rikal ze mi Gentoo developeri prijdou uzavreni. Sice se omlouvaji ze jich je malo, ale ze by tedy zacali prijimat ve vetsim poctu nove developery, to nee...

Vis, asi takhle - pokud mas zajem, tak ho nejdriv nejak ukaz (napriklad patchema do bugzilly), a az potom muzes cekat, ze z tebe "bude developer". Musi zustat nejaka hranice, vyvojare nemuze delat kazda cvicena opice. QA musi byt

[Mikos]

Ale tim padem mi proste prijde mirne schizofrenni na jedny strane horekat nad tim, ze neco neni oznaceno jako stabilni, a na druhy strane se to bat pouzivat kvuli obavam o stabilitu. Chapes?

Neni to schizofrenni Ja proste chci pouzivat distribuci, kde budou v jeji _stable_ vetvi vzdy (pokud je to mozne a nebranni tomu nejaky osklivy bug) ty co mozna nejaktualnejsi verze programu. Kdyz odmaskuju neco co je hard-masked, tak tim ztracim podporu developeru, a to nechci. Provozovat komplet unstable ~x86 system take neni zrovna idelani, protoze clovek ztraci nad svym systemem kontrolu (a v mem pripade, kdy uz sem mel /etc/portage/package.keywords dlouhe pres 6 stranek, to uz zacinalo byt neunosne).

Predpokladam, ze se bavime pouze o x86, treba amd64 uz ho pouziva hodne dlouho. Zrejme k tomu maji (x86) nejaky duvod :-P

Ano, bavim se o x86 A sem si vedom toho ze amd64 uz ma docela dlouho gcc-3.4 jako stable. Jedine moje vysvetleni je, ze developeri co maji na starost x86 architekturu jsou oproti tem z amd64 prehnane konzervativni.

Vis, asi takhle - pokud mas zajem, tak ho nejdriv nejak ukaz (napriklad patchema do bugzilly), a az potom muzes cekat, ze z tebe "bude developer". Musi zustat nejaka hranice, vyvojare nemuze delat kazda cvicena opice. QA musi byt

Ja se o to byt developerem nikdy nesnazil, ale znam lidi co na to opravdu maji a delali by to radi, protoze se jim soucasna situace okolo portage zacina zdat take pomalu neunosna. Jiste, QA musi byt, ale vseho moc skodi (prikladem budiz treba Debian ). A tady je to opravdu na ukor budoucnosti portage (a nemusim pripominat ze na portage stoji a pada cele Gentoo).

Ale dost uz Tohle nema smysl, ja opravdu jen chtel prezentovat sve duvody proc sem presel na Arch Linux, ne se tu hadat...

[xkesh]

Jedine moje vysvetleni je, ze developeri co maji na starost x86 architekturu jsou oproti tem z amd64 prehnane konzervativni.

KDE 3.4 je maskovano z dobrych duvodu, postupne se prichazi na drobne chyby, napr. pokud nekdo instaloval zaroven Gnome 2.10 a kdebase-startkde-3.4.0, coz se asi nedeje tak casto, rvaly se oba desktopy o jedno menu...

Kde beres tu jistotu, ze kdyz neco jine distro oznaci jako "stable", ze to take skutecne je vychytane? Protoze se jeste na nejakou chybu neprislo? ;)

Uz vickrat se v portage ocitla nevychytana "stable" aplikace, takze nyni je skvele, ze se venuje testovani dostatek pozornosti a casu. Jestli tohle ma byt "konzervativni", tak zaplatpanbu za to :) Zvlast kdyz jsou prave k dispozici ty maskovane a postupne opravovane ebuildy (napr. zminovany kdebase-kdestart-3.4.0-r2), jen holt stale nepracuji tak, aby za ne dali vyvojari ruku do ohne. Ze se obcas nektere ebuildy zpozdi, je logicke, protoze jejich celkovy pocet nepochybne roste rychleji nez pocet vyvojaru.

Pokud presne nevis, jaka kriteria vedou k zarazeni do "stable", neni fer srovnavat podle toho konzervativnost distribuce. Oznacit neco za stabilni, i kdyz to neni dostatecne vyzkousene, to neni zadne umeni. Tim se nechci nejak dotknout vyvojaru ArchLinuxu, mozna je jich opravdu tolik a maji tolik feedbacku od uzivatelu, ze testovani supernovych balicku je dukladne...

Kriteriem by mohly byt zaznamy v bugzille u stabilnich verzi :) Ostatne, nevim, jake touhy vedou k okamzitemu upgrade za kazdou cenu o tyden dva driv, pokud mi aplikace pracuje spravne...

[Mikos]

Holt mame kazdy jine priority - pro me je mit vzdy co nejaktualnejsi system jednou z tech nejdulezitejsich. Ale chci mit zaroven o systemu dokonaly prehled a pritom i pripadne moznost podpory od developeru. Coz mi bohuzel v soucasnosti Gentoo uz nenabizi tak, jak by mi to vyhovovalo... ale snad se to casem zas zlepsi.

U toho KDE trochu chapu ze tu verzi 3.4.0 mohlo v Gentoo zpozdit to, ze byla rozsekana na hromadu malych ebuildu pro jednotlive KDE aplikace, ale proste uz me nebavilo dal cekat (nebo rucne pridavat tu miliardu splitted KDE ebuildu do /etc/portage/package.keywords, kdyz uz takhle mel ten soubor u me delku pres 6 obrazovak).

A jinak co me k tomu vede? Nejde o to mit za kazdou cenu nejnovejsi verzi, ale kdyz proste vidim ze vysla nova verze ktera ma nejake featury ktere se mi opravdu libi, tak ji proste a jednoduse chci mit co nejdrive (a to pri zachovani konzistence meho systemu - tzn. zadne nesystemove reseni nechci). To je treba pripad toho KDE 3.4.0, ktere je z meho pohledu nesrovnatelne lepsi nez predchozi verze...

[juice]

Pokud presne nevis, jaka kriteria vedou k zarazeni do "stable", neni fer srovnavat podle toho konzervativnost distribuce. Oznacit neco za stabilni, i kdyz to neni dostatecne vyzkousene, to neni zadne umeni. Tim se nechci nejak dotknout vyvojaru ArchLinuxu, mozna je jich opravdu tolik a maji tolik feedbacku od uzivatelu, ze testovani supernovych balicku je dukladne...

Ako ste si mohli prečítať v článku, tak nové verzie balíkov sa najprv zaraďujú do testing a po otestovaní sa zaraďujú do current alebo extra. Napr. gcc je v current vo verzii 3.4.3, verzia 4.0.0 je ešte stále v testingu.

Určitá procedúra platí aj pre balíky od užívateľov (aur). Užívateľ, ktorý zostaví balík, ho môže uploadnúť do systému aur. tým pádom sa automatický stáva aj správcom balíku (v rámci aur). Je teda zodpovedný za jeho aktualizáciu atď. Tzv. trusted user môže hociktorý balík z aur adoptovať (najmä populárne balíky, v aur existuje aj hlasovací systém), čím sa on stáva jeho správcom. Následne môže balík byť zaradený do jedného z current/extra/unstable/testing repository.

Trusted userov (TU) je len pár, ale tí môžu navrhnúť ďalších ľudí za TU, následne všetci TU demokraticky hlasujú o prijatí nového TU. TU môže byť podobne aj odvolaný.

Priznávam však, že neviem ako dôkladne sa jednotlivé balíky testujú, kým sa stanú stable. Ale práve od systému aur (ktorý bol zavedený len relatívne nedávno) sa očakáva zníženie záťaže kladenej na vývojárov pri spravovaní balíčkov, takže tí sa budú snáď môcť viac sústrediť na testovanie podporovaných balíčkov.

Dúfam, že som to príliš nepoplietol. Ak áno, tak mi kľudne hocikto vynadajte, prípadne ma opravte .

[Mikos]

Jeste jen jednu vec doplnim (preci jen mela by to tu byt diskuze o Archu, kdyz je to clanek o Archu ) - Arch ma podle me spolupraci mezi normalnimi uzivateli a developery vyresenou naprosto vyborne.

V current (stable) vetvi Archu jsou od kazdeho programu vzdy ty nejnovejsi verze (nebo alespon se o to snazi a zatim jim to jde dobre). Pokud tam nekomu nejaka aplikace chybi, muze sam napsat svuj PKGBUILD (obdoba ebuildu z Gentoo) a umistit ho do Arch User Repository. Tam pak nad vsemi balicky dohlizi jednotlivi Trusted Users (maj je rozdeleny podle kategorii). No a kdyz je nejaky balicek oblibeny, muze byt nasledne prevzat do zakladniho systemoveho repositare.

Umoznuje to vytvaret balicky, ktere jsou pak pristupne siroke uzivatelske obci, doslova komukoliv. Kazdy tak muze prispet svou troskou do mlyna. Kdyz to porovnam s Gentoo, tak tam je to sice samozrejme mozne take, ale takove ebuildy se pak povaluji ruzne ve forech nebo v Bugzille a do samotne portage se dostanou jen velmi vyjimecne (vetsinou lezi v bugzille nebo ve forech ladem). Bezni uzivatele Gentoo kteri neprolejzaji casto fora nebo bugzillu pak nemaji moznost se k nim dostat. Proste je to nesystemove, vypomoc od uzivatelu neni tolik podporovan jak by podle me byt mela...

[martink]

[...] o Debianu se samozrejme vubec nebavim

V Debianu je gcc 3.4.3 v unstable i v testingu. Kdy uz si nekteri odpusti ty vecne narazky na neaktualnost Debianu? Neaktualni je pouze stable, se kterym se ale stabilni verze vetsiny ostatnich distribuci nemohou vubec srovnavat.

[xkesh]

Kdy uz si nekteri odpusti ty vecne narazky na neaktualnost Debianu?

Nikdy, protoze nejlip se delaj nejapny narazky na distro, ktery clovek nepouziva a tudiz nezna ;)

[Mikos]

Musim vas zklamat, Debian znam

[Mikos]

Jeste bych dodal ze treba v pripade te MySQL je situace opravdu zoufala (tyka se vsech 4.1.x verzi)... o tom by mohl kamarad co ma Gentoo na serveru vypravet...

Jinak ale stve me to kam se tahle diskuze ubrala. Mam Gentoo hrozne moc rad a mrzi me ze tu sem momentalne v roli jeho kritika Ja se jen snazim vysvetlit proc sem presel na Arch Linux, ne Gentoo kritizovat... je dost mozne (a i pravdepodobne) ze kdyz se situace okolo spravy portage v budoucnosti trochu zlepsi, rad se k Gentoo zas vratim. V soucasne dobe se mi ale proste zda, ze Gentoo pomalu a plizive (na prvni pohled neznatelne) v jeho stable x86 verzi "debianovati", a to je neco co bych opravdu za zadnou cenu nechtel...

[Jan Kundrát (jkt)]

Ad MySQL - viz thread.

[xkesh]

Na rozdíl od Gentoo však Arch Linux používá binární balíčky (balíčkovací systém Pacman), takže se vyhnete zdlouhavé kompilaci,

emerge --usepkgonly foo

neboli Gentoo samozrejme umoznuje instalovat predkompilovane binarni balicky. Neznam sice nikoho, kdo by to nejak pravidelne delal, ale sam jsem tuto moznost jednou kvuli casu vyuzil. Neni rozdil jako rozdil ;)

[Triton]

Toto bych nesrovnával. Arch Linux má k dispozici v binární podobě všechny balíčky včetně aktualizací. Nebo mi něco uteklo a Gentoo už má, podobně jako FreeBSD, clustery na kompilaci updatů ? Btw. ani u Freečka nejsou k dispozici všechny binární balíčky k portům a některé je nutné si stejně zkompilovat vlastními prostředky.

[Jan Kundrát (jkt)]

Kolik ma Arch linux k dispozici balicku (Gentoo aktualne tusim asi 9500)? Na kolika architekturach bezi (x86, amd64, hppa, ppc, ppc64, sparc, sparc64, alpha, mips,...)?

[Triton]

A co jako ? Jde přece o to, že binární updaty nejsou u Gentoo k dispozici, tj. kompilacím se nelze vyhnout.

Mimochodem FBSD má skoro 13.000 portovaných aplikací a zvládaj dělat binární aktualizace pro platformy i386, amd64, aplha, sparc, itanium a bůhví co ještě. A co teprve takový Debian, že

[Jan Kundrát (jkt)]

A pointa?

[Robert Krátký]

A pointa tvého komentáře?

Kolik ma Arch linux k dispozici balicku (Gentoo aktualne tusim asi 9500)? Na kolika architekturach bezi (x86, amd64, hppa, ppc, ppc64, sparc, sparc64, alpha, mips,...)?

Když si někdo pochvaluje binární bezpečnostní updaty u jedné distribuce, tak mu odpovíš tím, že jiná distribuce má ebuildy pro mnoho architektur?

Dalo by se to chápat tak, že říkáš: "Arch to má snadné, když kompiluje jen pro jednu architekturu. Gentoo by to mělo těžší, protože podporuje architektur více." A proto se ti dostalo odpovědi, že existují i distra, která tu kompilaci zvládají i pro množství architektur.

[Jan Kundrát (jkt)]

Dekuji Ti za vysvetleni, po Tvem komentari to jiz chapu.

[camlost]

"Konzervativní správci mohou pro server použít pouze balíčky ze stromu Current, které jsou otestované a prohlášené za bezpečné..."

Nejspíš Stable, viďte?

Problém těchto "malých" distribucí vidím především v jejich nejisté budoucnosti (autoři dostudují, založí rodiny a na distro jim nezbude čas) a potenciálně menšímu množství balíčků.

Pro je mě podstatná třeba informace o použitém kernelu - vanilla?

[Michal Karas]

Balíčky jsou, podobně jako u Slackware, soubory *tar.gz.

V clanku to myslim nezaznelo, tak bych jen doplnil, ze balicky jsou podobne tem slackwarovskym, ale narozdil od Slackwaru jsou u nich reseny i zavislosti.

Co se tyce tech zaporu, ktere autor uvadi, tak bych jen dodal, ze nejake nelokalizovane aplikace podle me nejsou problemem distribuce, ale toho, ze se nenasel nikdo, kdo by je prelozil a prislusny .po soubor zaslal autorum. Myslim si, ze s cestinou je na tom Arch stejne jako jine distribuce. Alespon ja nevidim rozdil.

O ceske dokumentaci (a Archu vseobecne) jsem se zrovna vcera bavil s Jokerem, ktery se do neceho pustil (je to mozne nalezt ve WIKI Archu) a vlastne i tady na Abicku v diskuznim foru o tom informoval a hledal pripadnou pomoc. Zaver nasi debaty byl takovy, ze Joker ted nema na pokracovani v prekladu cas a ja to zase nepovazuji za tolik potrebne, aby mel Arch svoji ceskou dokumentaci.

[Zdeněk Štěpánek]

Zdravim

Tak s archem jsem si pekne uzil. Viz muj nedavny doatz v diskuzi.

Prvni vec co jsem nepochopil ze to nepouziva balicky ala slackware ale ala debian, takze se software neinstaluje stylem "pacman -Sy mc-1.2.3-i686-1.tgz", rve to nejakou divnou chybu, ale musim udelat "pacman -Sy mc" a on si midnighta sam stahne z webu a nainstaluje. To ma svoje vyhody.

Co me ale dostalo bylo to dependency hell. Dal jsem nainstalovat KDE, nejprve se to zeptalo na skupiny, dal jsem vsechny. Co to na me pak vyplivlo, to jsem nechapal, nema ani smysl sem lepit seznam vsech zbytecnejch balicku na kterych kde nezavisi ani omylem. Bylo to proste tak ze ze v KDE menu je ikona na XMMS, no tak nainstalujeme XMMS. XMMS ma plugin pro jackd, no tak nainstalujeme jackd. Na XMMS se pak samozrejme nabalil glib, no a mohl bych pokracovat, nebyl to samozrejme jen pripad XMMS. Chtelo to instalovat treba vnc a rdesktop. Jen proto, ze v KDE je na to grafickej programek. Jsem stokrat radsi kdyz mi KDE potom zarve, ze nemuze najit knihovni libXYZ, at si ji doinstaluju, nez aby to vsechno instaloval sam od sebe.

Zdenek

[Petr "Glubo" Sýkora]

nejprve se to zeptalo na skupiny, dal jsem vsechny

A nebylo to dependency hell zpusobeno timto? Ono kdo chce kam, pomozme mu tam ;)

[Sodalite]

Nechci nijak nasazovat flame, ale mám pocit, že pokud distribuce řeší balíčkové závislosti, tak se určitému "dependency hell" nevyhneme. Autoři Arch Linuxu doporučují, aby se z CDčka nainstalovaly jenom základní systémové balíčky a zbytek se dotáhl z internetu.

Osobně nemám pocit, že bych za půl roku používání Arch Linuxu dorazil do onoho pekla. Co chci mám nainstalované, co nechci nemám.

S dokumentací se to má tak: Ozval jsem se na onu výzvu, zapojit se do překladu instalační příručky a podobně, soubory už mi dorazily a nezbude, než na tom zamakat. :)

[Zdeněk Štěpánek]

Zdravim

Nikoliv, byly to vlastne neco jako pseudobalicky, takze kdebase, kdemultimedia, kde.... Vsechno to zacinalo kde a navic tam byl artsd.

Uznavam ze kdybych si s tim hral asi bych si vybral co chci, ale Na jednu stranu ta jednoduchost "pacman -Sy kde", vcelku pekne udelanej stahovac, hezky udelana aktualizace (mimochodem pro odstreleni Ctrl-c navaze na prerusenej soubor bez ptani) a pak abych si hral a rucne vybiral co chci a co nechci.

Nemam nic proti zavislostem, ale chtel bych ciste jen nutne zavislosti (ze kdeapps zavisi na kdebase jeste dokazu pochopit) a ne volitelne zavislosti jako je treba to XMMS (samozrejme priklad, xmms pouzivam).

Zdenek

[juice]

Prvni vec co jsem nepochopil ze to nepouziva balicky ala slackware ale ala debian, takze se software neinstaluje stylem "pacman -Sy mc-1.2.3-i686-1.tgz", rve to nejakou divnou chybu, ale musim udelat "pacman -Sy mc" a on si midnighta sam stahne z webu a nainstaluje. To ma svoje vyhody.

balíček sa dá samozrejme nainštalovať aj lokálne z fs a to príkazom pacman -U resp. pacman -A, teda pacman -U mc-1.2.3-1.tar.gz nainštaluje (upgraduje) mc tar balíček, ktorý máme v aktuálnom adresári

pacman -S naproti tomu inštaluje z repository, či už ftp, alebo lokálneho (-S znamená synchronize), viď man pacman

... dependency hell ...

ako by ste to chceli ináč riesiť v binárnej distribúcii ktorá rieši závislosti ? keď správca balíčka chce myslieť na viacerých ľudí, tak bohužiaľ musí robiť kompromisy medzi množstvom závislostí a požiadavkami userov.

napr. viď kernel, ktorý distribúcie robia čo najvšeobecnejší

ak však máte pocit, že tam naozaj bolo priveľa závislostí, tak môžete podľa mňa postupovať týmito spôsobmi:

1. zmieriť sa s tým, obetovať trochu diskového priestoru a užívať si prepracovaného balíčkovacieho systému

2. inštalovať jednotlivé balíčky ručne bez použitia závislostí, pacman --nodeps (to by zodpovedalo zčasti vášmu popisovanému ideálnemu stavu: Jsem stokrat radsi kdyz mi KDE potom zarve, ze nemuze najit knihovni libXYZ, at si ji doinstaluju, nez aby to vsechno instaloval sam od sebe.)

3. prekompilovať inkriminovaný balíček s inými configure voľbami a zmenšeným počtom závislostí, vďaka systému abs je to naozaj veľmi, veľmi jednoduché, proste zoberiete PKGBUILD, prekopírujete do vlastného adresára (ja používam abs/local/nazov_baliku), upravíte configure voľby a zoznam závislostí, dáte makepkg a máte nový customized balík

4. spraviť 3. a ponúknuť váš customized balík do AUR, aby ste pomohli rovnako nešťastným ľudom ako vy

5. ak je to s tými závislosťami v inkriminovanom balíku naozaj tak zle a podľa vás nelogicky spravené, tak treba upozorniť správcu balíka, prípadne diskutovať na fórume, správa balíkov je kontinuálny proces a určite sa nedá spraviť balík hneď naprvý krát dobre, tiež môže mať svoje bugy. myslím, že aj správcovia balíka sú ľudia a určite dokážu prijať nejaké tie pripomienky

PS: arch linux používam od verzie 0.3 (bez reinštalácie) a som nadmieru spokojný, nemám dôvod meniť, možno arch nie je pre každého ale aspoň za vyskúšanie rozhodne stojí

[Luboš Doležel (Doli)]

Když jsem měl Mdk 10.0 a chtěl jsem si nainstalovat novější Mdk (10.1) balíčky na OpenOffice.org, tak jsem nakonec (po mnoha závislostech) skončil u toho, že si musím nainstalovat i nový balíček kernel. Přímou ani nepřímou závislost mezi OpenOffice.org a novější verzí kernelu jsem nikdy nenašel .

Takže nejen Arch Linux v tom může mít hell.

[Luboš Doležel (Doli)]

...Přímou ani nepřímou logickou závislost mezi OpenOffice.org...

[Mikos]

V Archu dle mych zkusenosti naprosto zadne dependency hell neni, pacman ma zavislosti reseny vyborne. To ze nekomu se zda desive kolik treba kompletni KDE vyzaduje zavislosti je jeho problem Kdyz chce nekdo full-featured desktop environment, tak se nemuze divit ze to chce hromadu veci okolo... ja treba KDE pouzivam (a mam ho opravdu rad) a vubec mi to nevadi

Nikdo prece daneho cloveka nenuti aby si instaloval cely KDE meta-balicek, muze si nainstalovak jen qt, arts, kdelibs a kdebase, k tomu zas tak moc zavislosti nebude. Nebo kdyz to tomu cloveku tak vadi, tak vubec KDE nemusi pouzivat

Tohle neni problem Archu ale proste toho, ze u hromady aplikaci je nutno delat kompromisy - bud zkompiluju program s podporou nejake veci a pak danou vec v systemu mit proste musim (jinak mi program vubec nebude kvuli chybejicim knihovnam startovat... neplati to sice vzdy, ale ve vetsine pripadu bohuzel ano), nebo ho zkompiluju bez te podpory ale pak lidi co to chtej maj proste smulu. Sice by si ten program pomoci vyborneho ABS mohli jednoduse rekompilovat, ale v pripade kolosu jakym je KDE (nebo OpenOffice, GNOME ci cokoliv jineho) to uz je trochu problem. No a pocita se proste s tim, ze DE ma byt plne integrovany balik co podporuje vse co nekdy uzivatel v budoucnu muze potrebovat. To uz je proste koncepce full-featured DE. Komu to nevyhovuje at pouziva nejaky light-weight WM.

[Jan Kundrát (jkt)]

Tohle neni problem Archu ale proste toho, ze u hromady aplikaci je nutno delat kompromisy - bud zkompiluju program s podporou nejake veci a pak danou vec v systemu mit proste musim (jinak mi program vubec nebude kvuli chybejicim knihovnam startovat... neplati to sice vzdy, ale ve vetsine pripadu bohuzel ano), nebo ho zkompiluju bez te podpory ale pak lidi co to chtej maj proste smulu. Sice by si ten program pomoci vyborneho ABS mohli jednoduse rekompilovat, ale v pripade kolosu jakym je KDE (nebo OpenOffice, GNOME ci cokoliv jineho) to uz je trochu problem.

/me mysli na Gentoo

[Mikos]

Neboj, na moji nejoblibenejsi distribuci nezapominam a nikdy zapominat nebudu Ted sem ale mluvil jen o binarnich distribucich, tam jaksi USE flagy jsou celkem k ničemu Leda by existovalo vždycky několik verzí daného programu (každý zkompilovaný s jinými závislostmi), jenže to by bylo asi dost šílené něco takového spravovat

[Mortal]

díky za článek, mezi archem a gentoo jsem se jednou rozhodoval, když jsem si uvědomil, že jestli se na tom linuxu chci něco naučit musím se zbavit grafických nastavovacích klikátek a nainstalit si nějakou "hardcore" distribuci

vyhrálo to gentoo, protože kámoš ho má taky a nestěžuji si

ale snad se k archu taky někdy dostanu

[juice]

ešte by som rád doplnil pre tých, ktorí chcú vyskúšať Arch Linux bez inštalácie

Archie - Arch Linux live CD je možné nájsť na adrese http://user-contributions.org/archie.html

Live CD by malo byť dostupné v štyroch verziách: s KDE alebo Xfce desktopom, obe vo verzii s glibc alebo stripped down verzii s uclibc

ako som vyrozumel, tak zatiaľ je pripravená len verzia Xfce-glibc, ktorá má okolo 300 MB

podľa popisu na stránke je Archie plnohodnotným Arch Linuxom, má vlastný nástroj na detekciu hw (lshwd) a umožňuje (okrem iného) aj inštaláciu na disk

priznám sa, že osobné skúsenosti s týmto live CD nemám, zatiaľ som nemal čas ho odskúšať, možno dnes si ho nájdem a potom môžem zreferovať ako to funguje

[BalWan]

Myslim ze script "hwd" by mohl byt zminen i v clanku, protoze je to velmi uzitecny nastroj. Zvlaste zacatecnikum by mohl pomoci pri instalaci a nastavovani systemu. Velmi uzitecna je IMHO detekce nastavebi Xserveru a vytvoreni xorg.conf . Alespon v mem pripade fungovala autodetekce pomoci hwd lepe nez autodetekce v Ubuntu, ktera se ale narozdil od Archu radi k desktopovym distribucim

[Sodalite]

Pravda, to že tam je tento skript jsem si uvědomil, až když to zaznělo tady v diskusi. Prostě mi to nějak vypadlo z hlavy. Jinak souhlasím, že se může velmi hodit, hlavně méně zkušeným.

[Havli]

jenom bych doplnil k rozdeleni balicku - ve clanku je zrovna zminen typicky priklad OO

duvod, proc neni OO 2.0 beta v current je prave ten, ze je to beta, pokud by vysla verze oznacena release, tak bude zarazena do current.

Balíčky jsou, podobně jako u Slackware, soubory *tar.gz.

pokud vim, tak balicky jsou ve formatu pkg.tar.gz, takze je na prvni pohled videt, ze jde o balicek

Jinak se musim pripojit s nadsenim pro tohle distro - presel jsem ze slackware, ktrery sam o sobe je bezva (doporucuji ho jako startovaci distro - s pomoci slackbooku ho dokaze rozjet kazdy a neziska "zlozvyky" z klikacich disribuci - ale to je jen subjektivni nazor, no flame please), a ziskal distro, ktrere je mozna jeste o trosiscku tezsi na nastaveni (coz povazuju za plus - resp. to, ze je to system, ktery se nesnazi byt lepsi a chytrejsi nez uzivatel), ovsem samostna sprava systemu a balicku je diky pacmanu az nechutne trivialni. Dokonce existuje rozsireni pajman, ktere je neco na zpusob pkgtool v slackwaru, to jest dava moznosti pacmanu do jakehosi "menu"

K dokumentaci - neni prilis velka, ovsem je to proto, ze se problemy resi na phoru ci irc a pokud je shoda na nejakem "obecnejsim" reseni, tak se da na wiki stranky.

archlinux je skutecne velmi povedena distribuce a jak nekdo napsal vyse, i po dlouhe dobe jsem z nej stale nadsen

[xobot]

da sa cez pacman vyhladavat z databazy nenainstalovanych balikov? mieco ako:
> emerge/swaret --search castnazvu

[juice]

pacman -Ss castnazvu

[Pajk]

Super distro, spokojeně používám. Kromě návodů na oficiálním webu můžete pochytit něco o instalaci a používání pacmana etc. na mojích stránkách:).