Názory k článku
Gentoo a jeho klony

„nebo byly z Gentoo vyhozeni“
Předpokládám, že slečny vývojářky to nebyly.

To ne no :P Ale tedko mame minimalne jednu vyvojarku ;]

rolling updates byl jeden z hlavnich duvodu proc jsem presel na gentoo

A u me to byl zas duvod, proc jsem od nej odesel.

Zajímavé čtení. Ke Gentoo jsem přešel v době, kde se Mandrake transformoval na Mandrivu a natáhl vývojový cyklus, čímž se pro mne stal nezajímavý. Nebudu řešit, jak moc to je dlouho nebo naopak, nicméně za tu dobu jdou nějaké klony zcela mimo mne. Že existuje nějaký Sabayon jsem matně tušil a pak se taky docela hovořilo o nějakém live CD, které mělo v názvu nějaké dívčí jméno, ale opět o něm nic nevím a to ani název. ;o)

IMHO škoda, že to nebylo rozvedeno na samostatné články po klonech, rád bych si přečetl i víc. Jinak držím palce v psaní a těším se na další díly.

Máte na mysli Saxanu? Snad se o ní něco objeví v seriálu, díky tomu, že to je live verze.. Docela by mě to zajímalo, už proto, že ji sám používám denně jako desktop..

Vcelku pekný prehľad, mňa najviac zaujal popis vzniku nového distra, citujem „byla založena bývalými vývojáři Gentoo, kteří nesouhlasili s některými rozhodnutími Gentoo Councilu, nebo byli z Gentoo vyhozeni kvůli špatnému chování k lidem“. No, aspoň vidno, ako vznikajú nové distribúcie a kvôli komu. Myslel som si to už dávno. Nevadí :)

Tak tohle jsem taky nepochopil :-))) Pouzivam paludis i v Gentoo a nemuzu si ho vynachvalit at uz z hlediska rychlosti, tak moznosti vyhledavani a odinstalovani nepotrebnych zavislosti, atd. Povazoval bych za plus pro Gentoo, kdyby se preslo oficialne na Paludis.

Rozhodne :]

Ne ja osobne proti paludisu nic nemam, jen proti vyvojarske komunite co je kolem nej.

Jen si zkuste aktualizovat KDE4 mezi minor verzema s paludisem. To je pohadka sama o sobe. :]

No nebojte v dalsim dile budu popisovat jak dostat KDE4 do pocitace a co je k tomu potreba.

Ja sem se o paludisu nechtel moc rozepisovat protoze vetsina lidi co ho pouziva se chova jako fanatici (nerikam ze vsichni, ale pouze ti se kterymi sem se setkal na irc) i pokud jim ukazem statistiky. On zase o tolik rychlejsi neni, v nekterejch vecech je portage dokonce rychlejsi.

Jen si zkuste aktualizovat KDE4 mezi minor verzema s paludisem. To je pohadka sama o sobe. :]

Tohle ja bezne delam a problem jsem nezaznamenal. V cem konkretne by mel byt problem?

Nechci se chovat jako fanatik, ale uz umi portage odinstalovat balicek i s nepotrebnymi zavislostmi? Nebo aspon nejak ukazat jake balicky v systemu nejsou potreba? Tohle byl hlavni duvod, proc jsme presel k paludisu, protoze, uprimne na dnesnich strojich, ten rozdil v rychlosti nema cenu resit.

PS: vyvojarska komunita kolem paludisu je fakt obcas dost neprijemna, s tim naprosto souhlasim.

> Nebo aspon nejak ukazat jake balicky v systemu nejsou potreba?

emerge --depclean

emerge –depclean a po te revdep-rebuild

Ale pred tim se nesmi zapomenout na:

$ emerge -avuDN @system @world

ten set @system neni potreba , je automaticky soucasti @world

S timhle jsem moc dobre zkusenosti nemel, protoze to chtelo vyhazovat nektere dost dulezite balicky, ale mozna uz se to zlepsilo (paludis pouzivam uz asi 2 roky, mozna i dele). Treba, az mne prestane vyhovovat paludis, tak to zkusim.

jo, to uz vetsinou nedela, na –depclean je ted celkem spoleh

Umí, ale (stabilní verze) používá jiný algoritmus pro aktualizaci (-uDN world) a jiný pro hledání nepotřebných balíků (–depclean). Nedávno jsem takhle čistil dva stroje a zatímco –update tvrdil, že vše potřebné je nainstalováno, tak –depclean si stěžoval, že něco (kolem perlových modulů taru) chybí. A skutečně při –update postiženého balíku emerge svůj názor přehodnotil. Sice to ukazuje na chybu, ale na druhou stranu mít kontrolu dvěma nezávislými algoritmy je dobrá věc.

Osobně mi v portage spíš chybí dotazovací nástroje typu vypiš stav (stable, masked by keyword, by package.mask) všech verzí daného balíku (jako poskytuje web packages.gento­o.org). Pak další vadou na kráse je (zatím) chybějící automatické řešení závislostí USE flagů nebo parametrizování CFLAGS a FEATURES pro každý balík zvlášť.

A nakonec jakožto zastánce lokalizace bych rád viděl nějaké snahy v tomto směru. Jenže protože z portage není internacionali­zována ani řádka, tak to asi bude vlastnost.

A jéje. Redakční systém je moc chytrý. Když napíšu dva spojovníky, tak chci dva spojovníky a ne pomlčku.

jojo, tar modul prelu neco takovyho delal, ale zas to nebylo tak tezky to opravit

na jednom stroji stacilo myslim perl-cleaner reallyall

jeste je dobry vedet pyhton-updater

CFLAGS a USE per-package existuji, CFLAGS jsou tochu obskurni, USE je v /etc/portage/pac­kage.use

a loalizace? ja mam vsude USE=„-nls“ a pouzivam localepurge :)

Nastavovat CFLAGS per balík není obskurní. Když potřebuji najít brouka v jedné knihovně, tak nebudu kvůli tomu mít celý systém přeložený s ladicími částmi kódu, s frame-pointery, nestripnutý a tak dále. Tohle byla narážka na paludis, který to prý umí.

USE flagy jsem myslel řešit jejich závislosti. Od EAPI 2 může balík vyžadovat konkrétní use flag na konkrétním závisejícím balíku. Technicky vzato závislosti mezi use flagy a mezi balíky je jedno a totéž. Takže když umí portage řešit závislosti balíků, může umět řešit závislosti use flagů. Někde jsem četl, že se to plánuje.

no tim obskurnim per-package CFLAGS sem myslel spis to technicky reseni s divnym bash skriptem

jinak jednu knihovnu s jinyma flagama udelas lehce takto:

CFLAGS=„-udelej-divny-veci“ emerge knihovna

A při remergi/upgradu se vlastní CFLAGS ztratí. To je řešení, jako volat USE="" emerge.

no asi sem to uplne nepochopil, kdyz hledas v nejake knihovne brouka, tak ji asi nebudes upgradovat, ne?

nahodou USE=„divny veci“ emerge pouzivam casto, kdyz to pak funguje, tak to dam do /etc/portage/pac­kage.use a pak se to neztrati ani pri upgrade

to dotazovani na verze zvladne eix, je to vlastne jen nadstavba nad portage co ma veci v db misto ve stromu na disku, misto emerge sync pak zadavas eix-sync kterej udela emerge sync + db eix …

na to je very good eix

Ahoj,
kdysi jsem zkusil g. – rikam si – mam maly disk a slaby stroj, tohle je ono. Zkusil jsem si spoustu zajimavych veci ohledne staveni systemu, to bylo fajn, ale pak jsem zacal kompilovat X a po 2 dnech to dobehlo a kdyz jsem chtel prikrocit k gnome, tak jsem uz nejak neprosel. Cela instalace by mi trvala asi rok, coz odpovida tomu, ze muj kamos mi asi mesic rikal, ze si kompiluje doma gentoo a ja jsem tenkrat nechapal, co tim presne mysli…

Mate nejaky komentar, jak se to ma delat apod?

Jde o to, jak slaby stroj mate. Ty 2 dny na Xka, to vypada na Pentium 90MHz, to asi neni optimalni stroj na build Gentoo. Instalace Gentoo trva a vzdycky bude trvat radove dele, nez u jine distribuce, ale vetsinu casu to bezi samo. U mne je to vetsinou pul hodiny prace, pak 8–10 hodin kompilace (samo), pak pul hodiny donastaveni a hotovo. Je pravda, ze nepouzivam Gnome ani KDE a OpenOffice zasadne z binarniho baliku. Dulezite je si rozmyslet, co na tom systemu chcete a nastavit patricne USE flagy na zacatku. Pokud mate dost RAM (2G+), tak doporucuji /var/tmp na tmpfs. Je to v mem pripade 2× rychlejsi, nez RAID-0 z 15k SCSI320 disku. U slabsich disku to bude predpokladam jeste vetsi rozdil.

A samozř. ccache výrazně urychlí překompilovávání nebo aktualizace, ale ne na /var/tmp pokud je jako tmpfs :)

To pujde jedine pomoci distcc kdy se ta slaba masinka pripoji na nejakej silnejsi stroj. Treba ja si vsechny balicky pro laptop pripravuji na svem ctyrjadrovem desktopu protoze proste 5 minut vs. 20 je rozdil.

No je pravda ze se to da kompilovat lokalne, ale ja osobne bych nemel nervy na to to instalovat tejden :]

A ma hodně slabém stroji krom distcc ještě přichází v úvahu spíš komplet cross-compiling na jiném stroji a výsledek nakopírovat na ten slabší, protože i při tom distcc má lokální stroj dost práce se stahováním, ./configure, rozdělováním, slučováním.. Ale je otázka proč potom vlastně Gentoo.

No rozhodně se to nemá kompilovat na slabém stroji, to napadle leda blba. Kompilovat se má buď na silném stroji (cross-compiling), nebo se nemá kompilovat vůbec (používat jiné distro).

Diky za oznaceni blb. Moc si ho necenim, ale vim, ze pro nektery geeky je to vrchol schopnosti v jejich socialni interakci. Obsahem tveho postu je, ze jsi trochu hrube shrnul poznatky, ktere jsem jiz predestrel vyse.

Pro ostatni – pouziju li gentoo, dostanu vetsi vykon ze stroje, nez pri std distribuci?

Pokud presne vis co delas, tak je to mozne, ale neni to zarucene. Velmi snadno muzes vytvorit moloch s hromadou zbytecnych zavislosti. Moje prvni 2–3 Gentoo instalace pred lety byly uplne k nicemu.

no mel by byt o trochu vetsi, ale zase je problem, ze pouzivas stejny optimalizace pro vsechny programy

nektery programy jsou proste rychlejsi s -O3, nektery s -O2 a nektery s -Os; nehlede na dalsi moznosti -ftree-vectorize, -ffast-math, -funroll-loops, -fprofile-generate/-fprofile-use…

jo, kdyz jsme u -fprofile-generate/use, proc se to vlastne nepouziva systematicky? sice se program defacto kompiluje dvakrat, ale to zas neni takovej problem; vysledna binarka je vzdy rychlejsi a kupodivu i mensi

Výkonový rozdíl většiny voleb je minimální, s výjimkou optimalizace pro vhodný procesor, zvlášť v porovnání s i386.

Kdyby byly ostatní volby tak bezproblémové, jistě by je autoři gcc aktivovali automaticky.

-ftree-vectorize se automaticky zapíná s -O3

-ffast-math Zrychlí některé programy. Programy, které spoléhají na matematické funkce přesně podle IEEE/ISO, však rozbije.

-funroll-loops je poněkud sporná. Snaží se zrychlit kód za cenu jeho zvětšení, což někdy paradoxně vede ke zpomalení (pokud se nový kód už nevejde do cache).

Pokud není na stroji mnoho paměti, lepší než -O3 je -Os, třeba v kombinaci s -fexpensive-optimizations -frename-registers.

-fomit-frame-pointer: Poměrně účinná, ale velmi problematická volba. Na mnoha platformách a v mnoha situacích uvolní jeden registr procesoru. Ovšem za cenu praktické neladitelnosti programů.

Aby bylo profilování k něčemu, musí se aplikace profilovat při reálném použití. U konzolových aplikací to lze udělat pomocí profilovacího běhu, u GUI aplikaci to jde hůř.

Pouzivam na AMD Phenomu vychozi optimalizace z
http://en.gentoo-wiki.com/…/Safe_Cflags

CHOST=„x86_64-pc-linux-gnu“
CFLAGS=„-march=amdfam10 -O2 -pipe“

da se to nejakyma volbama vylepsit, pro vyssi vykon?

neni na skodu misto -march=amdfam10 mit -march ci mtune nastavene na native .. at si to gcc nadetekuje samo:)

no muzes zkusit navic pridat „-fno-ident -ftree-vectorize“ (funguje na mym amd64 bez problemu)

a LDFLAGS=„-Wl,–O1,–-sort-common,–-hash-style=gnu,–-as-needed -s“

diky

--hash-style=gnu vylepší start programu. Popravdě řečeno, viditelnou změnu jsem nepozoroval ani na svém PDA.

--as-needed může ušetřit linkování s knihovnami, které aplikace nepoužije. S pomalým diskem to při nedostatku paměti také někdy ušetří pár desítek milisekund (občas i stovek) při startu. Ovšem některé programy se špatným makefile to zmate a spadnou.

--sort-common ušetří pár bajtů v tabulce symbolů. Možná, že OpenOffice žrát o pár kilobajtů méně.

-s (strip) se hodí, když máte málo místa na disku a nechcete posílat chybová hlášení.

-fno-ident ušetří asi 30 bajtů na každý objektový soubor. Odstraní informaci o použitém kompilátoru.

Mohu se zeptat, k čemu je -Wl,–O1? Podle mně to jen vypíše při každé kompilaci varovavání, že je to k ničemu.

Když už honíte milisekundy při startu programu, můžete si hrát s volbami linkeru (za -Wl,):
Třeba -zcombreloc (setřídí relokační tabulky). Pak také -Bdirect (namísto interposingu se provede linkování thread safe/unsafe verze natvrdo v čase kompilace), -zlazy (pozdrží nahrávání dynamických knihoven). Ty jsou poněkud nebezpečné, ale pokud zafungují, máte pár milisekund k dobru.

A u C++ programů byste neměli zapomenout zkusit -fno-rtti a -fno-exceptions. Pokud autor náhodou nepoužívá RTTI resp. výjimky, slušně tím program zrychlíte.

Není hash-style GNU standardně zapnut od binutils-2.18. Já jsem s tím měl na MIPSu problém.

Nestripnuté symboly zabírají také místo v paměti a v cache za běhu. Nebo ne? Vzhledem k tomu, že rozdíl ve velikosti ELFu je značný, tak pokud nejsou uložený nějak chytře (že by jádro při execu mapovalo jen některé sekce, jsem neslyšel).

ad –hash-style=gnu: defaultni je –hash-style=both a to dela delsi binarky

k vylepseni casu startu programu je potreba kombinovat s prelink

ad –as-needed: netsina veci (vsechny co mam instalovny) s tim ted jedou, takze neni duvod to nepouzit

ad -s: toto prej neni podporovany, portage by mel sam stripovat binarky, ale nicemu to nevadi, takze to tam mam

ad -Wl: toto uvozuje celou radu LDFLAGS oddelenych nasledne carkami

ad -O1: This tells ld to optimize the hash table. As a side effect the hash table gets larger. This optimization is usually safe. For more information see http://lwn.net/…cles/192082/

-ftree-vectorize má bohužel bugy — viz zde: http://gcc.gnu.org/…show_bug.cgi?…

Předpokládá, že zásobník je zarovnaný, což ovšem pro některé programy není pravda (ty, co mají kusy napsané v assembleru), a pak hrozí náhodné padání.

Bohužel názor některých vývojářů GCC je „my gcc opravovat nechceme, ať se přepíšou všechny ty programy“ :-(

no ja to myslel tak, ze v make.conf mas „bezpecny“ CFLAGS, ktery ti zaruci, ze se vsechno zkompiluje jak ma

ale nektery programy jedou rychleji s jinejma CFLAGS, musi se to proste vyzkouset

jinak na amd64 -fomit-frame-pointer je zapnuty defaultne, na x86 se to vrele doporucuje a je to bez problemu, az na debugging

ad profilovani: vetsina slusnych programu ma predse make test; to vetsinou staci na nabrani statistiky pro profiler

Profilovací běh by měl být co nejvíc podobný běžnému používání. To účelem běžných „make test“ nebývá.

Výsledkem může být nákladné rozvinutí smyčky v prakticky nepoužívaném místě programu, jen proto že „make test“ jí prošel milionkrát. Příště vám zcela jistě poběží rychleji „make test“.

Pokud máte dokonale odladěný systém, kde nic nepadá a není potřeba hlásit chyby, pak je jistě -fomit-frame-pointer výborná volba. V obráceném případě je lépe kompilovat bez ní, a navíc důsledně používat -g. Jen u vybraných aplikací ji můžete zapnout (např. mplayer).

Pokud chci aplikaci ladit, vůbec nejlepší je překompilovat ji s -O0 – nemusíte řešit inline a místa, kde optimalizátor vynechal kód, a můžete jít rovnou k jádru problému.

no a co teda podle vas dela spravnej „make test“?

nemyslim si, ze vetsinou dochazi k „nakladnemu rozvinuti smycek“, staci se podivat na velkost binarky bez -fprofile-generate/use a s

profilovana binarka je vestinou o dost mensi a o trochu rychlejsi, staci kdyz si to zkusite

proc by se s tim jinak namahali treba developeri firefoxu?

jinak si myslim ze mit zapnutej debbuging -g uplne u vseho je dost blbost, ja debugguju jen veci co nefungujou, nebo svoje vlastni programy

Profilování samozřejmě smysl má, a výkon zvýší.

Jenže typický make test zkouší nejpodivnější kombinace parametrů a vstupních dat. Většina testů vzniká jako vedlejší produkt řešení chyb nebo bezpečnostních děr, a snaží se zajistit, aby se stejná chyba nikdy v budoucnosti neobjevila.

Exploity na starou verzi, kde vstupy překračují povolené meze, nejsou dobrým vstupem profileru. Kontrola na vstupní parametry se může optimalizovat přesně obráceně, než je třeba.

Profilování v kombinaci s -funroll-loops, případně -fpeel-loops se snaží rozvíjet ty smyčky, které jsou vykonávány často. Ostatní profilové optimalizace (if/else větve, pořadí funkcí,…) asi na velikost velký vliv nemají.

U binárních distribucí je často dokonce povinnost vše kompilovat s -g. Nové gdb umí pracovat s externími tabulkami symbolů, takže symboly se uloží jako samostatný balík, a nainstalují se, když je potřeba. (-debuginfo a -debugsource v RPM distribucích a -dbg v distribucích odvozených od Debianu)

U kompilované distribuce to nejde jednoduše vyřešit. Pokud ladící symboly jednou odstraníte, už je nemáte. Abyste pak vyrobili hodnotný backtrace, musíte rekompilovat s -g aplikaci a všechny použité knihovny, a pak čekat, než to znovu spadne.

no -fprofile-use zapne automaticky navic (gcc4.3) -fbranch-probabilities, -fvpt, -funroll-loops, -fpeel-loops, -ftracer

pritom -funroll-loops vzdy zvetsuje vyslednou binarku; pak porad nechapu proc s -fprofile-use je binarka vzdy mensi?

ad make test: jasne ze je lepsi pouzit statistiku z beznyho provozu nez make test, ale myslim si, ze i jednoduchy make test a profilovani (coz by slo jednoduse udelat u vetsiny programu) by prineslo zvetseni vykonu a snizeni velikosti binarky

To by mohlo být téma pro libtool. V strip(1) je u volby –only-keep-debug pěkné povídání.

Za blba se omlouvám, reagoval jsem na „mam maly disk a slaby stroj, tohle (Gentoo) je ono“, připadalo mi to jako flame starter, neboť mi nepřipadalo pravděpodobné, že by někdo dobrovolně na slabém stroji šel do KOMPILOVANÉ distribuce, a protože jste si říkal „to je ono“, dalo by se čekat, že jste věděl, že budete muset dost kompilovat.

Čili pro Tebe: Gentoo nezvedne výkon stroje tolik, aby mělo smysl ho instalovat na slabý stroj a myslet, že tím získám nějaký extra výkon. Výhoda je, že lze velmi snadno vytvořit systém z vybraných komponent aniž by tam bylo navíc cokoliv dalšího, například můžete použít nějaký nenáročný WM místo kompletního DE jako KDE nebo GNOME. Ale nemá smysl to kompilovat na tom slabém stroji, dá se to udělat na jiném stroji přes cross-compile, nebo u stroje který je „na hranici“ lze použít distcc.

Co se týče výkonu apolikací jako takových, nějaký zanedbatelný výkon navíc můžete získat naopak u silného stroje, na který nejsou standardní distra optimalizované (ta jsou optimalizované právě pro slabší stroje). Monhem větší (tentokrát viditelná) úspora je ale prostě instalovat méně náročné aplikace.

Jsou podnacpané, nebo mají jen málo lidí? :-)

Overstuffed & understaffed. :P

Po pravde sem mel vskutku za cil napsat understaffed. :D
Tak to dopada, kdyz si clovek mysli ze to poradne precet :]

To opravdu neumíte, čárky se učí snad v šesté třídě ZŠ, držím palce, abyste to dobře zvládnul, až to budete probírat.

PS: BLEK. si stěžuje, že má poruchu osobnosti, vy zase, že jste závistivý blb. Nechcete si spolu zachatovat?

Jako ten váš překlep pokus vs pokud té vaší drsňácké kritice dal poněkud komický nádech, takže pokud chcete být ještě víc směšný, ještě něco napište :)

Ne, myslel jsem čárky mezi slovy, například před „kterou“. Čárka na anglické i české QWERTY klávesnici je napravo od M.
Omlouvám se, že jsem silně podcenil vaši inteligenci, příště budu výrazně polopatičtější, abych vás ušetřil sebeztrapňování.

Jeho inteligenci jste stran čárek tedy přecenil, ne podcenil. Ale myslím že tohle vlákno už humorem přímo kypí, nebudu už víc přilévat :)

Máte samozřejmě pravdu, už mi z toho taky začíná hrabat.

je lepší ze sebe udělat idiota dříve než později, poučení nebude zapomenuto :-)

Tohle je nevýhoda, pokud chcete na server sahat jen jednou za půl roku, tak je to utrpení.

S tim nemohu souhlasit. Mam Gentoo na 10ti serverech a pravidelnou aktualizaci CELEHO systemu provadim jen jednou rocne. Po zbytek roku jen kontroluji GLSA a opravuji jen pripadne problemy. Takto se dosahne docela stabilniho systemu, ktery nevyzaduje temer zadnou udrzbu.

Navod:
1) Kazdy den provadet sync Portage Tree.
2) Po kazdem sync spustit glsa-check a vystup poslat na e-mail.
3) Pokud je nalezena nejaka dira, tak ji co nejrychleji opravit.

Vyse popsane se da udelat pres crontab (opravy provadim rucne):

0 0 * * *    /usr/bin/eix-sync 1>/dev/null 2>&1 && /usr/bin/glsa-check -t all

Pak jednou za rok udelat aktualizaci CELEHO systemu. To zabere priblizne tak tyden (vhodny cas jsou Vanoce ;o)). Samozrejmne ze i behem roku se mohou vyskytnout problemy (napr. chceme nainstalovat novy program, ktery vyzaduje jiny balik, ktery je zasadni), ale to se da vyresit individualne, nebo aktualizaci CELEHO systemu presunout z Vanoc na leto ;o)

Kazdopadne NEDOPORUCUJI spoustet automatickou aktualizaci CELEHO systemu pres crontab! Clovek pak nevi jestli se pri aktualizaci neco nepokazilo, nebo jestli nezapomene spustit nejaky dodatecny konfiguracni prikaz. Cele to spis vede k destabilizaci celeho systemu. U serveru by se aktualizace CELEHO systemu (s ohledem na jeho stabilitu) nemela proste vubec provadet.

Aktualizovat cely system z crontabu mi prijde take dost ujete, alespon u produkcnich serveru.

A proč tu vaší přichytralou poznámku píšete do tohoto vlákna, když s ním absolutně nesouvisí?

Příspěvek z adresy ---.cern.ch má váhu :)

ja som presiel na gentoo ked som hladal system ktory budem schopny standardnymi prostriedkami nainstalovat na 256M flesku aj s X a kaniznicami ktore som potreboval a doteraz to nelutujem, bolo to dobre rozhodnutie

Když jsem hledal novější instalátor gentoo (byl jsem líný provádět celou instalaci ručně) tak jsem se dostal na stránky http://www.calculate-linux.org . Zdá se to docela udržované a ke gentoo to má blíže než sabayon. Jen je to vyvýjeno v rusku a i po přepnutí to EN to občas někde vyhodí azbuku.

Boris, jak ty mohla udelat takova Fehler? Poslechni, jak to mekkce zni: vyyyytr… :-D

Just to correct a few misconceptions about Exherbo.

First (and most important) Exherbo is not a fork of Gentoo or for that matter based on Gentoo. We definitely borrow some ideas from Gentoo but we also borrow ideas from Debian, Ruby, C++ and tons of other projects. That doesn't mean it's based on any of those projects however as we have our very own goals that differ greatly from any of the mentioned projects.

Secondly we're not elitist but we do require mutual respect. That is, don't ask us trivial questions that's already covered in details in the documentation and make sure you follow our mailing list. It's fairly low volume (a couple mails per week maybe) and it's there for a reason.

Please try to describe Exherbo more accurately in the future as it's disrespectful to the developers working on it to do otherwise and betrays potential future users as they get the wrong idea about our goals when you compare it to Gentoo.

Co si Gentoo uzivatelia myslia o FreeBSD?

http://www.gentoo.org/…lt/bsd/fbsd/

Nekdy je dobry se misto emerictiny vyjadrovat spis cesky. Totiz ``understuffed'' melo byt spis asi `understaffed'', ne? Jako, ze neni moc lidi. Understuffed je, kdyz se clovek malo naji a ma malo naplnene brisko. ;-)

Viz vejs ;] uz sem napsal ze to je fakt preklep :]
A preferuju bejt overstuffed nezly understuffed :]

no tak to rozhodne a kazdopadne :-))

… hmm … jednu dobu v Gentoo byla knihovna ElectricFence, která spadla při puštění jakéhokoli programu. Evidentně ji nikdo nikdy nezkusil použít. Viděl jsem to na několika počítačích, takže se to nedá svést na konkrétní instalaci.

Ono celkem zalezi na tom jaka cast stromu to je.
Jak rikam do KDE se moc sajrajtu nedostane.

Jine casti stromu sou na tom podstatne hur, ale minimalne tinderbox testama vsechno semtam projde.

Pokud najdes neco rozhasenyho tak na to otevri bug QA se na to rada koukne.