Názory k článku
Arch Linux: rychleji už to nejde

bezva, arch jsem instaloval na 5 pocitacu a dneska jsem se konecne dozvedel, jak vypada instalacni program :-)

Ale no tak, borce jako jste Vy přece po prvních řádkách napadne, že jde o úvod pro nezasvěcené, nebo že by nenapadlo? :-) Jinak start, běh i halt jsou velmi rychlé, uživatelsky se ale dají zpomalit úlitbou za detekci exotického HW či zmatenou práci s moduly a démony :-) Taky přešlapovači s nainstalovaným KDE, Gnome, XFce a šesti WM zjistí, že to asi není provozně rychlostní optimum... Největší klad Archu kromě skvělé filozofie kolem initscripts, rc.conf, pacmana a ABS vidím v kompaktní skupině maintainerů a vývojářů a v pevných a sdílených pravidlech. Ukažte mi operační systém, který udržuje a vyvíjí systematicky doslova pár lidí! Ukažte mi OS, kde se komunita nehádá ale spolupracuje na vylepšování při respektování hlavních cílů. Zenwalk je Archu asi nejblíže a je dobře, že si z Archu vzal spoustu poctivých a vysoce funkčních prvků...

Ja jsem to radostne prekvapeni myslel vazne, predtim jsem to vzdy instaloval tak, ze jsem si do jine distribuce nainstaloval pacmana a pustil instalaci balicku pres nej. Takze instalacni program jsem ted videl poprve.

Optimalizacia sa nerobi tak, ze sa nieco skompiluje pre i686...ale tak, ze sa nerobia zbytocne vypocty a pouzivaju sa efektivne algoritmy.
Napriklad taka kniznica gtk+2 je nechutne pomala a ziadna "optimalizacia" i686 jej nepomoze.

s tymto si dovolim nie uplne suhlasit.
ano, optimalizacia je hlavne algoritmicka zalezitost, ale schopnost vyuzit vsetky featury architektury je tiez boost a niekedy nemaly. urcite to neznizi rad zlozitosti, ale moze upravit konstantu k dobru.

mat spravne nasekane instrukcie aby sa lepsie dali nahadzat do pipeline, moze pomoct, na tom sa dufam zhodneme. ved odcoho su v kompilatoroch tie "spravne options" pre tu "spravnu architekturu". pochybujem ze su tam len tak pre srandu kralikom...

" ... ved odcoho su v kompilatoroch tie "spravne options" pre tu "spravnu architekturu". "

Aby sa ziskalo +1% az +5% vykonu. Inymi slovami nic dolezite. Ale ked to je, tak je to fajn.

Pletete se, u některých, třeba kryptografických algoritmů, se tak dají získat až stovky procent oproti kompilaci pro i386.

Tak tak, já sice kryptografii nezkoušel, ale třeba jednoduchý quicksort zkompilovaný s -O3 dává oproti -O1 výsledky několikrát rychlejší - toť moje zkušenost.

Kdepak, tady nejde o -Ox. Nicméně někdy mohou být výsledky zajímavé... :-)))

Ale není to zadarmo. Často zaplatíte také několikanásobnou velikostí binárky.

Další možnost je používat v programech vhodné knihovny. Někde jsem viděl matematickou knihovnu pro C++ s jejíž pomocí byly matematické operace zhruba stejně rychlé v C++ jako s Fortranem. Nicméně se za to platí použitím dosti nestandardních technik a rozkopírováním kódu místo jeho voláním z funkcí.

Nebyla to macstl?

Spis veci z boostu (http://www.boost.org/). A pouzivaji tam brutalnim zpusobem sablony no..

blitz++

Zas tak uplne to neni, napriklad optimalizace pro cpu s malou cache binarku zmensi. Kdyz se nahodou stane, ze Vam cache s ramkama zacne hrat ping-pong, tak se beh velmi znatelne zpomali.
A optimalizace pro architekturu (zde i686) zapina pouziti "lepsich" instrukci typu sse, mmx atd a tim se binarka take moc nezvetsuje (mozna dokonce naopak).
Co ji zvetsi je rozbaleni cyklu, zarovnani kodu a inlineování funkcí. Bohuzel prekladac se nemuze uplne dobre rozhodnout, ktere cykly rozbalit a u kterych je to zbytecne, protoze se jimi projede jen jednou za 10 let, nicmene napriklad nerozbalene vymazavani pameti (pole) je zatracene pomale :-)

tak co nejaky profiler, na jehoz zaklade by pak bylo mozne podstrcit gcc vhodna data? :)

Ten už snad je v GCC zaintegrovaný, ne?

Ano je, ale nesetkal jsem se moc s tím, že by se používal.

Pomaha to cca 10%. http://www.suse.de/~gcctest/SPEC/CINT/sb-huckleberry2-fdo-64-FDO/
http://www.suse.de/~gcctest/SPEC-britten/CFP/sandbox-britten-FDO/index.html
navic to casto zmensuje binarky, zejmena tu cast co se po startu nahraje do pameti. S temer nulovou uzivatelskou zakladnou je problem, i kdyz ohackovat bezny balik, aby se prelozil byva tak snadne jako

CFLAGS="-O2 -fprofile-generate" make
make test
make clean
CFLAGS="-O2 -fprofile-use" make

Kdyby se to jednotlive utilitky naucily pouzivat, bylo by to fajn. Chybi nejakapodpora automake...

Ha! Kvalifikovaná pomoc! :-) Napadlo mě, když jsem dneska mluvil s Yokotashim, že by bylo taky pěkné mít mechanismus, který by volil -Os nebo -O2 podle toho, jakou část kódu právě řeší (a jak se chovala při profilování co do run-time footprintu). Když člověk chce nacpat kus kódu do kapesního zařízení, tak -Os pomůže, ale zase se to docela zpomalí. V Lispu tohle není celkem problém (na úrovni funkce, nebo dokonce i na úrovni jednotlivých výrazů uvnitř funkce), nešlo by to i v Cčku? Tedy pokud to už nedělá tahle funkce - do vnitřností GCC ale nevidím, abych posoudil, kam až při zmenšování málo používaných kusů kódu zachází.

dik za tip, ty vysledky jsou opravdu brutalni.... na jedne aplikaci me to dalo 20% a to uz je vcelku pekne cislo

Co já vím, tak i když je dnes distro kompilované pro i386, neznamená to, že by tam nebyla podpora pro "lepší fíčury". Je to složitější.

1. Podpora "zrychlovacích" instrukcí jako sse, 3dnow. Většinou je zapnutá, i když se kompiluje pro i386. Binárka však obsahuje i náhradní kód pro procesory bez těchto instrukcí. proto i386. Arch zdá se tento kód neobsahuje (kompilátor ho může vynechat), to znamená, že musíte mít minimálně fpu a mmx. Ale i i386 binárka může mít podporu pro sse4.

2. optimalizace na architekturu. Při tomhle se se binárka sestavuje tak, aby to vyhovovalo danému procesoru. Různé procesory různě "reagují" na kód. To se asi týká hlavně out-of-order kousků. Zkrátka se použije řazení instrukcí, které dané Pentium nebo Athlon nejméně zblbne... Binárka je ale pořád univerzální. Myslím, že jedna z možností optimalizace je taky i686, ale toto je stále kompatibilní s i386.

3. O1 O2 Os O3 - tohle jsou úrovně optimalizace gcc. Mezi O1 a O2 je IIRC rozdíl jen v času, který kompilace věnuje řešení. Os se snaží zmenšuit velikost binárky, O3 dělá různé věci, které můžou zvýšit velikost binárky ale i výkon. Potenciálně problémové. Tyhle binárky jsou stále univerzální.

Pak jsou ještě další volby, které můžou zvednout výkon a zbořit stabilitu :)

> 1. Podpora "zrychlovacích" instrukcí jako sse, 3dnow. Většinou je zapnutá, i když se kompiluje pro i386. Binárka však obsahuje i náhradní kód pro procesory bez těchto instrukcí. proto i386. Arch zdá se tento kód neobsahuje (kompilátor ho může vynechat), to znamená, že musíte mít minimálně fpu a mmx. Ale i i386 binárka může mít podporu pro sse4.

Pokud vím, tak tohle umí např. překladač od Intelu, ale GCC ne.

Mě se zdá, že umí i GCC. Jsou tam tuším dva přepínače - jeden udělá binárku bez a jeden s kódem pro obyčejné 386.

A kolik casu travite poustenim kryptografickych algoritmu? :D

Bavime se jeste porad o optimalizaci celeho systemu, nebo o optimalizaci na urovni jednotlivych kratickych rutin?
Ja jsem kdysi prepisoval nektere veci z C do ASM aby byly rychlejsi, takze mam velmi dobrou predstavu co se da poradnou optimalizaci nekterych loopu dosahnout, ale opravdu si myslim ze system prelozeny na i686 misto i386 z pohledu (obycejneho) uzivatele moc vykonu neziska. Asi neco jako pretaktovani procesoru (to mne osobne taky prislo ve vetsine pripadu zbytecne, jestli nekomu chybelo 5% vykonu, tak si nejspis koupil neadekvatni HW k tomu co potreboval).

Jo, ale je to vyborne pro lidi co pouzivaji pocitace na pomerovani kdo ma vetsi^H^H^H^Hykonnejsi system. To zase jo, to chapu. :D

Pokud mate sifrovany souborovy system tak velmi casto, pak to s prehledem udela mnohem vic nez Vasich 5%

Co je to za blabol? Cetl jste vubec na co reagujete? Peter mluvil o zoptimalizovanem systemu - tzn. command line utility, samba, xka, kde a ja nevim co jeste.... Rychlost sifrovaneho FS bude zaviset jen a pouze na tom, jak je prelozeno jadro a nejaky fuse modul. To mi vysvetlete, jak KDE nebo Apache prelozeny pro 686 muze mit vliv na rychlost desifrovani filesystemu?? Souhlasim, ze v tomto konkretinm pripade to muze mit dost velky vliv, ale na to, abych tohoto dosahl, nepotrebuju instalovat arch. Ten CryptoFS modul si se vsema moznyma optimalizacema prelozim i v ubuntu a vysledek bude stejny. O zbytku si stejne jako Petr nemyslim, ze by melo nejaky podstatny vliv (tech 5%).

Ja ano, ale Vy bohuzel asi ne. Odpovidal jsem na to, jak casto poustim rutiny pro kryptovani. Na tu druhou cast jsem uz nereagoval, protoze jsem nechtel zbytecne vyvolavat hadku.

Moje zkusenosti ukazuji, ze optimalizovat pro architekturu se vyplaci, napriklad diky tomu mi bezpoblemu funguje pocitac s via c3 jako video (bez optimalizace se celkem casto trhalo). Tez arch krasne slape na mem starem notebooku, vizte http://petris.webhosting.klfree.net/archnastarymhw.avi . Predtim jsem dlouho pouzival slackware, a narust rychlosti pri prechodu na arch byl znatelny.

Samozrejme vliv KDE na rychlosti desifrovani je velmi maly, konkretne zde se vliv optimalizace projevi spise opacne. Optimalizace programu X se totiz projevi zejmena v behu programu X a v behu aplikace Y az zprostredkovane, pokud jsou obe ulohy casove multiplexovany na stejna CPU. Tento vliv se velmi meni podle druhu aplikace, nejznatelnejsi je prave na sifrovani pripadne treba pri sledovani videa. Doufam, ze jsem Vam to vysvetlil dostatecne pochopitelne, jinak se ale klidne jeste zeptejte!

A nesnazte se mi prosim cist mezi radky, ze ubuntu je spatne, nic takoveho mezi ne totiz nevpisuji. Je mi zcela jedno, co maji ostatni na svych pocitacich, do te doby, nez s temi pocitaci musim pracovat ja.

Ale ja se v tomto s Vami v zadnem pripade nehadam! Sice jste v podstate opsal to co jsem psal ja, ale presto dekuji za nabidku dalsiho vysvetleni ;-)

Peter psal, ze optimalizovat cely system na architekturu je v zasade nesmysl, protoze to v celku prinese tak 5% zlepseni, coz je pri normalni praci nepostrehnutelne. Neminim se hadat, ze u nekterych konkretnich aplikaci to muze pomoct velmi vyrazne, ale tvrdit, ze je DISTRIBUCE dobra proto, ze je CELA prelozena pro 686 podle me nema moc smysl.

A vy jste na to napsal (alespon takto to vyznelo), ze to dulezite je, kvuli sifrovanemu filesystemu. A ja Vam na to oponoval, ze kvuli tomu nemusim mit zoptimalizovanou celou distribuci, ze si staci zkompilovat tu jednu danou aplikaci.

A v to cteni mezi radky jste expert Vy, protoze ja jsem Vam absolutne nepodsouval ze byste tvrdil, ze je ubuntu spatne (to by me skutecne zajimalo, kde jste na tohle prisel). Vzal jsem ho pouze jen jako priklad.

kde konkrétně prosím tvrdím toto: "DISTRIBUCE dobra proto, ze je CELA prelozena pro 686"

Nikde (a ja ani nepsal, ze to tvrdite Vy), ale oponujete clovekovi, ktery tvrdi, ze to tak neni. Ano, ve skutecnosti jste reagoval na jeho otazku, jak casto poustite sifrovaci algoritmy, ktera byla z casti recnicka (viz. ten smajlik) a dale vysvetluje, ze opravdu nema na mysli konkretni rutiny, ale cely operacni system (v cemz jsem s nim za jedno).

Vase nasledna reakce se tedy dala brat dvema zpusoby:

a) neosouhlasite, ze cely OS prelozeny pro 686 je zbytecnost, protoze pri pouziti sifrovaneho FS je optimalizace potreba. Tak jsem to pochopil ja a proto jsem Vam oponoval (zvlast kdyz je z ni citit lehke invektivum).

b) byla naprosto zbytecna,protoze jste se s Peterem vlastne shodl. Pak ovsem nechapu, proc jste to vlastne psal, protoze on sam se nikterak nehada, ze u konkretnich specializovanych rutin ke znacnemu zrychleni skutecne dojde.

Reagoval jsem na to, jak často se pouštějí ony šifrovací algoritmy, protože někoho třeba hned takový případ nenapadne (tím nemyslím konkrétně Petera, čte to tu více lidí).

A svým prvním příspěvkem ve vlákně Optimalizacia jsem podpořil názor vgt, který se vůbec netýkal konkrétní optimalizace pro i686 či zda se vyplatí optimalizovat celý systém, ale optimalizace pro architektury obecně. Odporoval jsem proto, že moje zkušenosti s optimalizací jsou jiné a totiž, že se mi dvakrát vyplatila:
1) Používám EPIU jako videopřehrávač a bez optimalizace se některá videa trhala, po optimalizaci se netrhají. Konkrétní číselný nárůst výkonu tady neodhadnu, ale i kdyby to bylo to 1%, tak se to sakra vyplatilo. (Spíš to bude víc, protože CPU má malou cache -Os a většinu doby tráví chroustáním multimédií -march=c3). Zde by samozřejmě stačilo přeloži s optimalizací jen některé aplikace, ale než se s tím zabývat, tak jsem radši nasadil gentoo a nechal přeložil vše.
2) Můj starý notebook po přechodu na arch ožil, subjektivně se zrychlil tak o čtvrtinu - start aplikací (X+KDE nabíha 10s) i odezva. Samozřejmě, že čím je CPU lepší, tím je výkonový zisk z optimalizace méně znatelný a limitem se postupně začne stávat rychlost přístupu do RAM.

No, pokud to mají dobře naprogramované, tak ty největší žrouty mají ručně napsané v assambleru, protože tak se dá docílit největší zrychlení (aspoň s gcc). A to samozřejmě kompilátor nezrychlí. Takhle to dělá xvid a x264.

Ja s vami souhlasim, jiste neni kompilace s prislusnymi C(XX)FLAGY apod. to nejdulezitejsi, ale i to se preci pocita.

Ono je to stejne jedno. To "I dnes se totiž stále kompiluje většina distribucí, i těch téměř striktně desktopových, pro i386 architekturu." je spis jen blabol - treba openSUSE ma .i586.rpm prekladane s "-march=i586 -mtune=i686".

Jiste, treba SuSE a kdyz uz jsme u toho, tak treba Mandriva take. Ale vetsina dister je kompilovana skutecne pro i386.

Kompilace pro i386 neznamená, že má být program schopen běžet na starých kompech ale to, že se nepoužijí multimediální instrukce, které jsou sice rychlejší, ale mají taky o osm řádů menší přesnost (nepracují s dvojnásobnou přesností). Na počítačích se nehrají jenom hry ale (budete se divit), občas se na nich i počítá. U výpočtů v integer - což je většina utilit a bitmapové gragiky - je optimalizace pro i686 zbytečná, protože celkem nic nepřinese. Každopádně by měl o direktivách kompilátoru rozhodovat autor programu a ne distributor.

Multimediální instrukce umí pracovat s dvojnásobnou přesností už od dob SSE2. A pro celočíselné výpočty se dají použít také.

Problém s optimalizací je taky to, že ne vždy dokáže kompilér automaticky najít místa, která by se dala zrychlit různými simd instrukcemi. Zkrátka automatická kompilace není samozřejmě dokonalá - co jsem slyšel - HLAVNĚ v gcc.

Ještě si vybrat kernel s ck patchsetem (buď přímo balíček 2.6.20.7.ck1-2 nebo si sestavit vlastní 2.6.21 ck) a potom je to opravdu ryché :) Taky kompletní update systému ve tvaru pacman -Syu je jednoduchý.

Tohle by me moc zajimalo. Beyond2, suspend2 a ck ... tri jine verze jadra v porovnani s originalem. Radeji bych to mel nejak po lopate, nez se lopotit na strankach a porovnavat. Je treba suspend2 obsazeny v ck (jasne: beyond = susp2 + ck + par dalsich)? Nebudu mit po volbe ck nejake konflikty (jak, v cem, je to mozne)? Co stabilita? Atd.

o cem to bylo? o screenshotech instalace? brrrrrr jezis no to bylo teda zajimavy :)

na uvod treba, proc se autor rozhodl odejit od Crux a udelat Arch. V cem je jiny a treba jake je srovnani se Slackware...

ok, je to jednoduchy distro - tak a v cem? kde a jak se ukaze a 'primocarost'? ukazka skriptu, pouziva to SYSV skripty nebo jak ty RC skripty vypadaji? umi to IPv6 v defaultu, pouziva to iproute2 ci jak? pouziva to vanilla kernel, ma to milion modulu nebo jen 'zaklad'?

jasny, ze mam predstavu, ale tenhle clanek byl kvapek o nicem. sam jsem spokojeny uzivatel Crux Linux :P

Treba pockat na druhe diely tam to uz asi bude podla tvojich predstav :)

nechci ze sebe udelat blbce ... ale kdyz mluvil o pribuznosti startovacich skriptu stylem ala BSD ... tak to je asi BSD like ... a ne SYSV ... takže sice laicky, ale zmínil to tam.

BSD skripty - to je mytus - nic takoveho vlastne uz neni jako nalepka. FreeBSD a NetBSD pouzivaji rcNG a OpenBSD stale zustava u jednoho /etc/rc a par includovanych dalsich skriptu...

Ok, uvedu přesněji, je to mýtus velice rozšířený, řekl bych tak, že je z toho až termín ( BSD-style init ), jinak BSD-style i tak může využívat služeb SYSV, nicméně je to o uspořádání, a o to že u SYSV je hlavní inittab a u rc... no nic, ale můžete se vrhnout do přepsání : http://en.wikipedia.org/wiki/Init ... ať to není tak zavádějící ;)

Asi tak jsem to myslel ...

Arch je distribuce jako kazda jina ma svoje vyhody a nevyhody. Byl jsem na nem dva roky momentalne jsem presel na ubuntu. Par pripominek k clanku:

* Optimalizace na i686 je k prdu. Neco jako -O3 optimalizace u Gentoo. Procesory jsou optimalizovany na chroustani i386/i586 kodu. i686 se muze projevit maximalne u videa, ale tam je to k nicemu protoze arch nema podporu dalsich instrukci. Pokud chcete skutecne neco optimalizovaneho tak rozhodne 64 bitu.

* Balickovaci system ma svoje vyhody a nevyhody. Je skutecne jednoduchy a kompilace z AURu je take jednoducha. Ale pacman mi osobne prijde docela pomaly a nektere dulezite featury z ostatnich balickovacich systemu postrada.

* Ucenuju vetsi stabilitu obsahu nez melo Gentoo. Balicky se zbytecne neprejmenovavaji / nestepi... Lokace konfiguracnich souboru se nemeni...

* Obsah mi prijde docela nestabilni. Verze v zavislostech jsou uvadeny velice volne a proste se predpoklada ze provadite aktualizaci kazdy tyden. Pokud nekdo zkusi aktualizovat pul roku stary system, muze narazit na dost problemu.

* Repositar obsahuje i komercni software (kodeky, Skype...) a prakticky vsechno ostatni se da najit pres komunitni AUR.

* Lepsi je instalovat arch pres quick-install skript rovnou z jineho live-cd.

Zaver? Arch je skvely system na uceni pro lidi co se kamaradi s konzoli. Startovaci skripty jsou jednoduche a da se s nimi neskutecne experimentovat. Take jde behem 20 minut nainstalovat na 90% funkcnosti, kterou clovek potrebuje. Zprovozneni nejakeho daemona je v nem rychle a primocare, ziskane poznatky se daji aplikovat na ktery koliv *nix (narozdil od gentoo, ci debianu/ubuntu).

Jako 'working horse' mi prijde lepsi Ubuntu, ci nejaky komercni linux. To ze clovek nainstaluje system, zapne automatickou instalaci bezpecnostnich zaplat a rok zapomene na jakoukoliv udrzbu, v Archu nefunguje. Take se mi nikdy nepodarilo zprovoznit par drobnosti (sleep, ACPI...) ktere v ubuntu funguji automaticky.

Takze asi tak...

komercni unix :) wtf?

ale je pravda, ze jsem videl na AIX Gnome :)

Emh... v původním příspěvku bylo napsáno "komerční linux"... chce to občas číst po písmenkách :-)

> Ucenuju vetsi stabilitu obsahu nez melo Gentoo....

> Obsah mi prijde docela nestabilni....


S tím tedy nesouhlas, dříve jsem taky používal Arch nyní mám Gentoo a mám z toho spíš opačné pocity.

No, kazdy kdo pouziva ciste distribuce jako je Slackware, Arch nebo Gentoo, tak potvrdi, ze jsou o dost sviznejsi nez treba nenapadne podsouvane Ubuntu. A to diky i takovym drobnostem jako je i686 optimalizace. Je to jen jeden z argumentu pro rychlost. Ackoli nejvice na to bude mit vliv absence ruznych ne-zcela nutnych veci (autodetekce vseho mozneho a veci co nejsou nutne k zivotu). U rolling updates musis pocitat, ze se neco vyskytne. To by jsi chtel moc parady naraz. Jinak co za featurky v balickovacim systemu postradas? Updatujes jednou za pul roku? To je dosti dlouho. Silne nesouhlasim treba s tvrzenim, ze znalosti ziskane v Gentoo nevyuzijete v jinych *Unixech. Mnohdy radim na forech jen diky tomu, ze jsem dane veci resil pres Gentoo dokumentaci a obcas odkazuji primo na ni. Clovek jednoduse nesmi ziskat dojem, ze jeho distribuce to dela "tim spravnym zpusobem". To ze ti v Archu nefunguji treba automaticke updaty bude nejspise absence znalosti zakladnich nastroju jako je *cron a schopnost venovat 5 minut dokumentaci jak jej pouzit. Kdybych nainstaloval system a ten by mel plno veci predem nastavenych zpusobem, ktery nepreferuji, tak by asi rychle letel z disku (tak jak pokazde letelo Ubuntu, kdyz jsem zkousel majoritni verze). Tvuj problem je ten, ze by jsi chtel mit Arch takovy jake mas Ubuntu. Ale k tomu Arch neni svou filozofii urcen... - nastesti.

dokumentace k gentoo a gentoo-wiki jsou dobre pociny... tot asi vse :P

Gentoo wiki používám např. pro Ubuntu. Na Gentoo bych si netroufnul, ale např. pokud jsem potřeboval pracovat s menceoder v Ubuntu, tak mi gentoo wiki přišla vhod ;-)

Ad rychlost - zadneho rozdilu Arch versus Ubuntu jsem si nevsiml. Programy startuji stejne rychle, start systemu me nezajima. Ale je pravda ze Arch bral o dost mene pameti.

Optimalizace i686 je k prdu, tecka. Vim o cem mluvim, dost dlouho jsem si hral s Gentoo a take cely arch jsem kompiloval z AURu pro svuj athlon.

> Silne nesouhlasim treba s tvrzenim, ze znalosti ziskane v Gentoo nevyuzijete v jinych *Unixech.
Polovina manualu v gentoo se nejakym zpusobem dotyka portage a jak ji priohnout aby neco delala. Pokud se vrtas v systemu aby jsi se neco naucil, Gentoo neni spravna volba.

>o ze ti v Archu nefunguji treba automaticke updaty bude nejspise absence znalosti zakladnich nastroju
>jako je *cron a schopnost venovat 5 minut dokumentaci jak jej pouzit.
Ted jsi me docela popavil. Ver mi ze cron pouzivat umim. A kdybych na Archu zapnul 'automaticke updaty' tak se mi muze stat ze jednoho dne take nenabootuji. Napriklad se menily parametry jadra. Rooling updates jsou obcas fajn, ale jine systemy maji take svoje vyhody.

>Kdybych nainstaloval system a ten by mel plno veci predem nastavenych zpusobem, ktery nepreferuji,
Ja preferuji kdyz program funguje. Proste nemam cas se hrabat v systemu.

>Tvuj problem je ten, ze by jsi chtel mit Arch takovy jake mas Ubuntu.
Ne, to neni. Arch jsem pouzival kdyz jsem se potreboval ucit, Ubuntu mam kdyz jsem zacal pracovat. Nechci aby Arch byl jako Ubuntu a ani obracene. Kazde distro se hodi na neco jineho.

mne uplne zarazila jedna reakcia

>Optimalizace i686 je k prdu, tecka. Vim o cem mluvim, dost dlouho jsem si hral s Gentoo a take cely arch jsem kompiloval z AURu pro svuj athlon.

a mate to podlozene niecim inym ako vasim pocitom? nechcem vam brat iluzie, ale ludske vnimanie nebude najlepsie meradlo.

ludia co sa trosku intenzivnejsie zaoberaju benchmarkovanim vam s kludom povedia ze len dve rozdielne spustenia jedneho kodu sa mozu lisit az o 30% co sa tyka casu behu. takze to ze ste sa hral s niecim dostatocne dlho este nic nedokazuje.

mozno by vam pomohlo byt trosku menej "uber master".

a funkcnost programu - mno to je zaujimave kriterium

>a take cely arch jsem kompiloval z AURu pro svuj athlon.
No já bych teda raději kompiloval z ABS :)

Polovina manualu v gentoo se nejakym zpusobem dotyka portage a jak ji priohnout aby neco delala.

To je ta druhá polovina, o té se nebavíme :D

Mam velice podobne zkusenosti, Arch jsem mel chvili, tehdy jako zacatecnik jsem vse hezky pekne zprovoznil, dost jsem se naucil, vsechno parada, az na to ACPI, nikde zadny navod, proste naprd, obzvlaste na laptopu, ze. Takova velice hezka, ale do-it-yourself distibuce. Od te doby jedu na Ubuntu a jsem spokojen.

"aa" mi mluvi z duse... distribuce jako Gentoo a Arch jsou fajn. Tak jsem si tim prosel :) Pro ty kteri, uz maji nadseni z tunigu za sebou tu je Ubuntu :) a pro ty uplne nejlinejsi je tu OS-X ;-) Tam to mate pekne vsechno odladeno. Oproti ubuntu odpada problem s 3d akceleraci, hibernaci(ta v os-x funguje opravdu spolehlive), pripojenim pocketpc, pripojeni mini-dv kamery, ipod, externiho monitoru, scanneru, skype s videem a dalsi vychytavky :) Stabilita a vykon (pokud nepocitam 3d a hibernaci) je v linuxu o neco lepsi, naroku na udrzbu systemu a administraci OS jsou v OS-X i ubuntu minimalni. Ubuntu ma navrch v balickovacim systemu a snadnem updatu celeho systemu.

Zaver?
Samozrejme zalezi co delate za praci a jestli nejste nuceni pouzivat nejakou specialni aplikaci pro konkretni OS.

Pokud jste svobodni :) svuj stroj pouzivate na praci, a zaroven chcete si obcas pohrat s multimedii (zpracovani videa, zvuku apod...) pripadne zaparit nejakou hru - lepsi je OS-X. Pokud mate stroj pouze na praci, multimedia nepotrebujete, Linux si poradi s ACPI vseho notebooku a zvladne spolehlive hibernaci, lepsi je Ubuntu. Pokud mate dost casu, chcete se ucit a bavi vas tuning, potom je tu Gentoo, Arch, LFS a dalsi komunitni zalezitosti. Jsem zvedav, jak bude behat Ubuntu na Dellovskych masinach. Bude to velka konkurence pro Apple, ktery je ted hlavne mezi vyvojari a dalsimi geeky velmi oblibeny diky skvelemu MacBooku (Pro) - ti ale stejne rychle od OS-X utecou, pokud nekdo nabidne neco lepsiho :) Stejne tak fandim Dellu spolu s Ubuntu aby trochu provetrali monopol Microsoftu :)

"Balickovaci system ma svoje vyhody a nevyhody. Je skutecne jednoduchy a kompilace z AURu je take jednoducha. Ale pacman mi osobne prijde docela pomaly a nektere dulezite featury z ostatnich balickovacich systemu postrada."

Tak takovéhle pindy miluju. Pacman (momentálně již ve verzi 3.x) je napříč distribucemi nepřekonatelný v několika aspektech: Rychlost (kdo si plete rychlost pacmana s rychlostí stahování je zoufalec), přesná detekce konfliktů díky headers, pouze nezbytné závislosti, snadná správa balíčků (pro milovníky GUI: pacman -Sy jacman), výpisy instalačních komentářů a upozornění. Neexistuje žádná vlastnost, pro kterou bych pacmana (přesněji Judda Vineta) dokázal právem kritizovat - je to vzor pro jiné distribuce a ukazuje cestu ve striktních pravidlech pro headers, kompilaci a systému uvolňování aktualizací do current repozitáře. Arch má snad jediné omezení - ne vždy je kompilace přes AUR cestou k trvale stabilní práci a některé užitečné drivery a utility se z AUR do community dostávají jen velmi zvolna.

Osobne sem nasel par veci co mi na ARCH linuxu vadili mam tu 2 stroje gentoo a jeden ARCH a ze zacatk usme byl z ARCHU trochu sklamany kdyz sme ho srovnal s gentoo, napr BSD-style init, (ale nakonec mi to ani nevadilo) pak to ze nelze instlaovat veci paralelne coz portage zvlada bez problemu, a pak estetorhcu nberpehlednsot vypisu mohli by tam bejt apson barevne syntaxe ale jinak je ARCH fajn a co se tyka notebooku asi mu dam prednost pred gentoo nebo tma dam oboje ;-) ... Linux akbar

barevny vystup: pacman -S pacman-color a hned kdyz si udelas alias pacman='pacman-color' tak i dal pises pacman... mimochodem, vynikajici nadstavba pacmana je yaourt, ten umi i prohledavat a instalovat i z AURu vcetne aktualizaci.

Eh? Co to bylo? Tohle ma byt jako clanek o Archlinuxu? A venoval mu autor vic jak 20 minut? Myslim, ze ne...

Ano, to byl clanek, ktery naplnuje svuj nazev: "Rychleji uz to (napsat) nejde."
Clanek podobneho typu by mel, podle meho nazoru, obsahovat daleko vice informaci, nez ze je cool mit zkompilovano pro i686 a ze instalator je v textovem rezimu.

Autor jinak pise celkem zajimave clanky, tento se ovsem vymyka; skoro mi pripada jako PR clanek, ktery spise vystihuje autorovo nadseni, nez aby se snazil byt objektivni.

Hujer

Proc? Byl to clanek uvodni, a ty jsou uz ze sve vlastni podstaty "takove okecavaci". Tezko to lze udelat jinak, pokud chci, aby z toho neco meli i lide, kteri nemaji o Archu ani paru.

Priste proberu konfiguraci, pacman, ABS a podobne veci. Myslim, ze si na sve prijdou vsichni.

ale na úvodní článek k sérii dle mého názoru používáte až moc velká zjednodušení (nedá se dále rozvíjet jenom polemizovat) a upřesňovat (v tomto případě umírňovat již napsané).

Jestli se jedná o sérii, bylo by dobré udělat první článek opravdu "okecávací" ale takový který lidi motivuje k dalšímu čtení ... nikde není například napsané co bude obsahem dalších článků, jenom na konci je zmíňeno, že příště se koukneme na veliké možnosti balíčkovacího systému, který snad má být směsicí apt a dalších nejlepších věcí... doufám že čtenáře nezklamete.

Proč jste tu poslední větu příspěvku nedal přímo do článku... byla by tam lepší než obsah "Tím to ale nekončí..." kapitoly.

Přeji ať se Vám další články vyvedou lépe... sám bych si je rád přečetl :)

PS: Zase na druhou stranu titul ani sumary nenaznačuje že půjde o seriozní článek... takže všechny chyby co jsem psal jsou pro jiný druh článku :)

Co presne minite temi zjednodusenimi? Je dost mozne, ze mate pravdu, ale zkuste mi to prosim priblizit vice.

Co se tyce obsahu dalsich dilu, neuvadim je zamerne. Mam zrejmou zkusenost, ze kdyz slibim, co bude priste (nedej boze co bude v popristim dile), tak to dopadne uplne jinak ;)

Diky za povzbuzeni, urcite se budu snazit napsat je co nejlepe a verim, ze se libit budou.

Ani ja to nemyslel nijak spatne, jen mi to, prestoze se jedna o uvodni clanek k serii, prislo ponekud informacne prazdne. Kdyz o tom tak premyslim, mozna by taky nemusel obsahovat tolik screenshotu (jenom) instalatoru...
Jinak jsem kouknul na jejich web a vypada to celkem slusne. Akorat jsem nikde nenasel, jestli maji security announcement, coz mi prijde jako celkem podstatne.

Například Maximální optimalizace... to mi připomělo "reklamštinu"(jak kdy a jak pro koho)... řekněme pokročilejší optimalizace pro desktop prostředí.

"ty nejnovější balíčky při dokonalé stabilitě." .. Jak dlouho je balík unstable,testing než přejde do stable? ... jak víte, že je to stable ... no dobře může to tak být, ale zní mi to také docela odporující samo sobě.

"neomezená konfigurovatelnost"... samozřejmě je omezená schopnostmi programů a systému ;) ..

Vaše články vesměs čtu, je to pro mě takový to "kdybych to sám testoval tak mám podobný dojem, podobné zkušenosti, jako když přečtu článek.". Ale jak říkám uvítal bych větší podrobnosti, víc textu (např. zde, obrazovky jsou cool, ale o ničem... místo dvou z nich dát dva odstavce textu o čemkoliv, jako kdy a proč vznikl arch, z jaké distribuce přešel autor, konkrétně proč vytvářel něco jinýho a nepřidal se ke CRUX :).

Mate pravdu. Priste jsem rozhodnut to napravit ;)

+1

+1

+1

Musím reagovat už na úvodní odstavec. Jakkoli je pacman funkční a dobrý nástroj, možnostem Debianního balíčkovače se rozhodně (zatím) nerovná.

Jake moznosti mas konkretne na mysli?

pacman neumi vyhledat balicek, pokud znam jmeno souboru, ale nevim v jakem balicku se nachazi,
pacman je dosti pomaly, pacman3 je sice o neco sviznejsi, ale stale je to neuspokojive,
nedostatek gui frontendu pro pacmana, snad se to zlepsi a prichodem pacman3
jinak ale zlate urpm[fiq] z mandrivy :-)

"pacman neumi vyhledat balicek, pokud znam jmeno souboru, ale nevim v jakem balicku se nachazi,"

Takže pacman -Qo je pro srandu králíkům?

pacman je dosti pomaly, pacman3 je sice o neco sviznejsi, ale stale je to neuspokojive

To není o možnostech, to je o rychlosti. ;-) A ta se dá vytunit.

nedostatek gui frontendu pro pacmana, snad se to zlepsi a prichodem pacman3 jinak ale zlate urpm[fiq] z mandrivy :-)

Masochisto!

to funguje jen pro jiz nainstalovane baliky a to je celkem nevyhovujici...
v mandrive:
urpmf bin/kmail
vysledek: kdepim-kmail:/usr/bin/kmail
instalace:
urpmi kdepim-kmail
doufam, ze jiz si rozumime;-)

>> Takže pacman -Qo je pro srandu králíkům?

Tak tohle mě většinou netrápí, protože když se divím, co že je to za podivný soubor na mém disku, tak většinou z nějakého balíčku pochází. ;-) A v popisovaném případě to stejně skoro vždy uhádnu (kdo by taky neuhádl? ;-)).

jo v tomto pripade mozna ano, ale treba pri kompilaci neceho, kdyz chybi nejaky .h fajl nebo knihovna, tak to zdaleka tak jednoznacne neni a pak je problem :(

Před kompilací si obvykle čtu README a INSTALL a tam obvykle bývá napsané, co potřebuju. 0:-)

Balíčky vyhledám pomocí YaSTu - umí hledat docela slušně. Dopíšu build dependencies a runtime dependencies do spec fajlu, spustím build a pokud se něco pokazí, najdu problém a odstraním ho, poněvadž umím číst a nesvéprávný nejsem. ;-) Pokud se nic nepokazí, je na výstupu pěkný balíček a po otestování shledám spec file jako vhodný k zařazení do veřejné Build Service, která mi umožní pohodlně sestavit binární balíčky i pro architektury, které nemám 0:-). Nechápu, proč pořád lidé hledají umělé problémy.

nechapu, proc sem pletes nejakej yast, kdyz se bavime o nedostatcich pacmana.
btw, yast je pekny moloch, ten jen nez nastartuje tak v mandrive uz mam vyhledano, prip. nainstalovano ;-)

Ehm, řeč byla o tom, proč bych měl potřebovat hledání čehokoli při kompilaci, ne? Podmnožinu toho, co umí libzypp, umí i Pacman, takže v Archi postupuju úplně stejně - prostě nepotřebuju hledat soubory v nenainstalovaných balících, a netuším, proč bych kvůli něčemu tak okrajovému měl držet na disku takový mamutí index. Leda, že by to byla online služba.

Mamutí index to zase není, dělá to myslím pár desítek MB včetně jpackage a plf. Na Gentoo tohle nemám, ale zase jedu skoro všechno z portage a v Céčku prakticky neprogramuju, takže pohoda.

stejne nerozumim :(
kdyz si stahnu nejakou apps, ktera neni v balickach, jen src, tak si chci prelozit z ruky.
./confugure napise ze soubor libxyz.so not found. v mandrive pomoci urpmf libxyz.so najdu balicek s tim souborem co chybi, nainstlaluju, pustim znovu ./configure vse jiz OK, dale pokracuju obvyklym postupem. nevim jak toto udelat v archlinuxu (frugal je na tom lepe, ten ma aspon webovou vyhledavaci sluzbu).

Já v takovém případě většinou hledám přímo název balíčku - ony jsou poměrně logické a ten balíček se povětšinou jmenuje "libxyz" nebo aspoň obsahuje "xyz" v názvu. ;-) A když ne, tak googlím. Je ale pravda, že zaintegrovat hledání souboru do pacmaního webu by snad nemusel být takový problém. Zkus napsat Vinetovi. ;-)

Jarní Mandrivu mám taky a urpmi, ač se v mnohém vylepšilo, na pacmana nemá v ničem podstatném a stále si zoufá nad dependency hell. Uvedený údajný nedostatek pacmana je ve skutečnosti nedostatek uživatele a ne pacmana, součásti instalovaných balíčků pacman ukáže čertovsky rychle a to bohatě stačí. Ty závislosti nejsou nikde vyřešeny lépe než v Archu, howgh!

Když už se tady píše o té optimalizaci, získám nějaký výrazněší nárůst výkonu, když začnu používat 64bit verzi? Mám Celeron D, který má podporu EMT64, ale jestli je to ve skutečnosti rychlejší, netuším. Dřívě me to moc nezajímalo, ale teď jsem si koupil videokameru a po sestříhání videa jej potřebuji převést na DVD. Urychlylo by se to nějak pod 64bit verzí? Používám Ubuntu, ale možná bych zkusil 64bit SuSE.

"Urychlylo" = Urychlilo

Na to bych ti doporučil vyzkoušet spíš 64 Studio live cd, před pár dny vyšla nová verze. Je to určeno přímo na multimedia.

Můžu se jen zeptat, jakým programem to video stříháte? Já jsem nic jednoduchého pro linux nenašel a udržovat si kvůli tomu windows se mi nechce.

Kino - velmi jednoduchý
Cinerella - nelineární střižna, docela slušný program na úpravu videa
Avidemux - nepoužívám, ale slyšel jsem na něj nějakou chválu

asi je jich víc, ale osobně vetšinou používám Kino

tady je přehled SW pro linux

http://trendspotter.bloguje.cz/350261-linux-ve-zpracovani-medii.php

jahshaka

Děkuju za tipy, vyzkouším to. To Kino jsem dřív zběžně zkoušel, ale nepodařilo se mně v tom otevřít soubory z digitální kamery. Ale to bude spíš obecnější problém.

já mám miniDV kameru a soubor z ní Kino otevře, ale dřív to tak možná nebylo

V cem je treba lepsi nez debian?

dej pokoj s temito otazkami... lepsi/rychlejsi... uhel pohledu je 'styl' - tyhle lightweight distra proste maji jiny styl - rucofuco, zadny 'ja myslim za tebe' techniky atd...

Arch je jeste jednodussi, ma prehlednejsi konfiguraci (mj. diky rc.conf), ma (velmi slusny) buildovaci system, prehlednejsi init a v porovnani s Debian testing (stable jsem na desktopu nikdy nemel) mi prijde mnohem mene problemovy. Vlastne problem jsem mel s Archem zatim jen jeden (kernel panic), ale diky tomu, ze tento problem byl dokumentovan jak to jen slo, okamzite jsem to bez vetsiho hledani opravil. Jinak ale i Debian mam rad, na server je to jasna volba.

Aj Debian vie kompilovat zo zdrojakov: apt-get build-dep $pkg; apt-get -b source $pkg, alebo by to malo ist cez sbuild.

5 ze 4 :) unixaku ti rekne, ze je urcite zmenit volbu v tech (Pkgfile, Makefile,ebuild) 'portovych Makefilech', nez hackovat zdrojovy deb balicek :)

lol, znam nekolik debianisti, kteri si radsi kompiluji vlastni apache... proc si tedy nedelaji vlastni deb balicek s vlastnimi volbami? :)

Ano, ja vim. Ale komfortnosti se to Archu zdaleka nerovna, alespon dle meho nazoru.

To jsem tedy zadostiv, co muze byt tak "zdaleka nesrovnatelne" s apt-build balicek

No tak predevsim to, ze apt-build mi zrovna dvakrat funkcni neprijde... prinejmensim pred pul rokem na Ubuntu rozhodne nebylo.

On se ale bavil o debu, ne o jeho radobykopii :D

Tak to jsi stastny clovek, ja to mel presne naopak, tri ctvrte roku jsem jel na archu, nebylo vyjimkou, ze druhy den jsem system nenastartil a stravil pul dne opravami a laborovanim, co zas update pritahl za bugu, tak jsem se vratil k debianu.

Je to mozne, jen rikam sve zkusenosti... anebo je mozne, ze jste zkousel Arch v dobe, kdy na tom nebyl tak, jako je ted - neni to zrovna stare distro.

Jasne, a taky to tak beru a jsem rad ze je na tom lip. Je to skvely distro a nemel jsem , krom stability jiny duvod odchodu zpet k debianu

Umoznuje ARCH linux instalator instalaci na encrypted fs? Ve fedore ci ubuntu je to nutne hodne hackovat.

Diky za pripadne odezvy.

Umoznuje, dokonce jsem i odzkousel. Na ArchWiki (http://wiki.archlinux.org/index.php/LUKS_Encrypted_Root) je vse celkem dobre vysvetleno.

Konfigurace systemu opravdu vypada krasne jednoduse. Diky!

Arch Linux pouzivam priblizne ctvrt roku. Dovolil bych si poznamenat, ze o dokonale stabilite nemuze byt rec, distribuce je skutecne bleeding-edge a chyby se cas od casu vyskytnou, nedoporucuji odchazet od monitoru pri pacman -Syu.
Jinak se jedna o skvelou distribuci, ktera mym potrebovam vyhovuje nejlepe. Konfiguracni soubory mohou byt samozrejme prepsany vinou Kde control center apod.. Ale s tim uz nic neudelame.
Distribuci bych vytkl pouze par detailu, binarky firefoxu se cpou do /opt, zpocatku neexistuje xorg.conf atd.. Jsou to ovsem pouze musince.

Asi jsem měl napsat "dle mych vlastnich zkusenosti", pravda je, ze bezvyhradne to asi tvrdit nelze. Ale zrovna v mem systemu jsem zazil pouze jedno jedine nepatrne selhani, a sice kernel panic, na ktery ovsem archovske novinky, wiki a vsechno upozornovala a nebyl nejmensi problem neprijemnost odstranit. Jo a tedy navic mi bohuzel obcas padaji gecko veci, ale to neni chyba Archu, protoze s tim samym se potykam na nekolika ostatnich distribucich :/

Jinak cpani velkych balicku do /opt mi osobne prijde dobre, ale je to vec nazoru.

Arch pouzivam priblizne rok a pol a estye som nemal az na spominany kernel panic pri upgrade probelem ...

zo stabilitou uz vobec nie ....

Neskoušel někdo, alespoň teoreticky, zvážit co by udělalo s rychlostí kódu jádra pokud by se připravilo do tvaru aby se dalo přeložit pomocí překladače od Watcomu ?

Ale zkusit icc (Intel) misto gcc by mozna stalo za to.

Benchmarky kernelu kompilovaneho ICC jsou nekde vygoogleni. Problem je, ze ICC je dobry prekladac na aplikace co zerou hodne CPU casu (hlavne FP a fortran, v C++ to zdaleka nemusi byt tak horke http://www.suse.de/~gcctest/c++bench/).
Generuje ale treba celkem velke binarky a tak distribuce kompilovana ICC neni vyhrou (pokud tedy neni na Itaniu).

Pominu-li, že tento článek je takové malé "Arch Linux rulez", musím se ohradit proti množství informací v článku obsažených. Mám-li být přímočarý já, řeknu, že jsem se dověděl HOVNO.

Taky jsem se dozvěděl kulový. Ale přimělo to k tomu, o čem jsem už uvažoval několikrát, tj. zkusit si Arch nainstalovat. A zatím nelituju.

"Evoluce" systémů na mým současným PC byla Mandriva 2006 s Gnome -> Ubuntu 6.10 -> Xubuntu 6.10 -> "self-made" Xubuntu 7.04 (nejdřív jenom řádka a potom jenom to, co potřebuju) -> Arch. Všechno změny (kromě první) byly typu "snad to bude svižnější". A kupodivu mi to pokaždý vyšlo. Žádná změna (snad kromě Gnome -> XFce) nebyla nějak super výrazná, ale poznat to bylo. A vzhledem k rolling-updates Archu doufám, že mě nečeká ani reinstalace, ani dist-upgrade. Leda až s komplet novým železem.

Pán neví, že Arch je opečováván lidmi, kteří teorii staví na hlavu a díky skvělé filtraci uvolňování aktualizací do currentu a díky doslova normalizaci pravidel pro náležitosti balíčků je výskyt podstatných chyb prakticky nulový (u výjimek je oprava vždy blesková) a drobné chybky jsou do pár dní také opravené. Celá komunita archerů je vzorem ne proto, že jsem taky archer, ale proto, že každý od maintainerů k uživatelům dělá striktně podle pravidel a pravidla mají jasný smysl a tím je rychlost, aktuálnost, funkčnost a spolehlivost. U velkých distribucí je problémů vývoje i užívání mnohem více, slušní linuxáci se netají problémy té své distribuce. Mně momentálně vadí pouze chybějící balík s driverem pro Avermedia 808...

Chcete mít absolutní kontrolu nad systémem? Jednoduchost a přímočarost v každém bytu? Dejte se na FreeBSD :D

To si spíš pleteš s Forthem, ne? ;-)

tak to by me pak zajimal jeden podstatny fakt ty chytraku , co jen odsuzovat umis. predpokladam , ze ty svoje visty mas legalni , ze? arch = po cistem bootu 32 MB RAM. vista ultimate 64bit = po cistem bootu bez vsech programu (antivir a dalsi balast) 1GB RAM sezrano + 2.3GB naswapovano !!! jestli tomu rikas dobry a pouzitelny system , pak ja tedy smekam. :) najedu na panel miniaplikaci (nebo jak se tomu nadava ... ja nevim , dlouho uz jsem videl win jen v nocnich murach :) ) a zatizeni dvoujadra stoupne na 90% -> to by me zajimalo , co je na tom tak narocne... hmm. tak bych mohl pokracovat jeste dlouho , ale cert to vem ... BFU zustane , jen silni preziji ... GLOTR !

prominte. spletl jsem si vlakno. toto bylo samozrejme mireno na usera Keff a jeho nazor ...

He he, jsi legracni. :-)

Tak jo. Já tu Vistu zkusím. Určitě už konečně obsahuje dodělanou podporu POSIXu, aby na ní chodily slušné vývojové nástroje. Taky už to určitě bude svobodné distro. :-)

Ne, humor stranou, hibernace očividně funguje, to jenom Ty děláš něco špatně. Za to ovšem kernel nemůže. Zkus najít problém u sebe a nevymýšlet ho někde jinde.

Presne tak, Keff ma pravdepobone problem mezi klavesnici a zidli, me hibernace (ne prilis pouzivana) a suspendace (pouzivana 2x denne i vic) funguje bez problemu - ubuntu 7.04 (laptop brave)

Autor archu je zmatenej web developer a zbastlenej kod pacmana je tomu dukazem. Arch je jeho smutnej pokus udelat z CRUX neco jako gentoo a zaspamovat to svym "(c) Judd Vinet".

tak prosim dokaz to , co dokazal on a pak kritizuj. mam rad lidi , co maji plnou hubu reci a skutek utek.