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.
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í :)
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.
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.gentoo.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í internacionalizována ani řádka, tak to asi bude vlastnost.
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/package.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.
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.
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.
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?
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?
--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
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.
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.
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.
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.