Názory k článku Source Mage GNU/Linux - I

No zni to vsechno hezky - zadne silene zavislosti mezi rpm baliky, instalacni iso obraz zhruba 120MB (komprimovany, ale i tak to je dost malo). Ovsem mne by zajimalo jak dlouho zhruba muze trvat cela kompilace takove distribuce. Kdesi jsem cetl, ze kompilace OpenOffice na prumernem pocitaci (tusim to byl procak ~1GHz a 256MB RAM, ale nevim to jiste) trva az 10 hodin - osobne jsem to nezkousel...

Ta predstava, ze by mi tyden v kuse bezela kompilace vseho softwaru, ktery potrebuju je docela srandovni :)

Junichi Uekawa si zkusil zkompilovat celou distribuci Debianu ze zdrojáků na svém počítači a trvalo mu to 15 dní. Tak asi tak :)
http://lists.debian.org/debian-devel/2002/debian-devel-200212/msg01508.html

Procesor PII 350MHz, 256MB RAM, kompilace celeho FreeBSD vcetne X a KDE trvala 2 dny pocitaje i cvsup celeho stromu po kabelovce (128kbps)

Myslim ze linux bude obdoba

Ale takhle to opravdu neni - Já mám teda Gentoo linux cca 1/2 roku, a první instalace je šílená, protože musí člověk "pochopit". A pak to jde samo. Krom toho - OpenOffice je lepší stáhnout v binární podobě - přeložené a lokalizované, než je kompilovat :-)
Jinak je to Supr :-)
Krom toho - velké věci nad 20 MB jsou většinou v Gentoo k dispozici v binární podobě - pouze pokud jseš fajnšmejker, můžeš si stáhnout kod a přeložit si to :-)
A nestane se ti typická věc pro Debiana (moje oblíbené distro) -- zastaralé knihovny a nemožnost instalace :-)

tak v tom pripade jsem fajsmekr. Mam gentoo a vsecko, a kdyz rikam vsecko tak ti myslim vsecko mam zkompolivany ze zdojaku :o)

stejnej nazor mam i na Debian, zkusil sem vetsinu tzv. hlavnich distribuci ale Gentoo je proste super, narust rychlosti je znacnej !

Musim souhlasit. Taktez patrim ke spokojenym uzivatelum Gentoo Linuxu a uz bych nemenil ;o)

nejake detaily pre lfs system: ako host distribucia slack8.1, dual pIII/800MHz, 1GB ram, kompilacia zakladneho systemu (bez xsiek a pod.) za menej ako pol dna, momentalne makam na bash skripte ktoremu sa na zaciatku zada par conf suborov a potom to bezi same; detaily na poziadanie mailom; avsak na slabych masinach to je naozaj pomale (napokon, co sa cudujete? kompilacia naozaj nie je easy job), rovnaky system na 486-stke skoro tyzden; podla mna vyhody daleko prevysuju nevyhody;

laco.

zdravim

podobne ako tu nad mojim prispevkom
rozbehanie zakladneho lfs mi na mojej k-6-III s 320MB ram trval prvy krat menej pol dna + dalsie 3-4 hodinky na X + zakladne kniznice na png,jpeg,...

samozrejme je treba pred zacatim precitat
minimalne prvych par kapitol z lfs-book

NO na mojom kompe sa kompilovalo (iba) jadro asi 4-5 dni a to bolo v skutku dost...

A to je výhoda, že jako root musím pamatovat, že když jsem instaloval GIMP, musel jsem taky nainstalovat gtk, pango, glib, libpng, libart, a že když budu GIMP chtít odstranit, tak jsou tyto knihovny zbytečné? Gentoo tuhle věc řeší elegantně - používá systém správy balíčků založený na systému "port" z BSD. Navíc si pro instalaci každého balíčku nemusím zjišťovat všechny jeho parametry "--with-mysql" apod. Prostě jednou v parametrech správce balíčků nastavím USE="X mysql java alsa" a já vím, že každý balík, který tyto vlastnosti podporuje, je také bude mít zahrnuty při kompilaci.

To je ono, proc bych mel pouzivat system spravy balicku zalozeny na systemu z BSD, kdyz muzu pouzivat primo BSD? Obsah clanku mi velmi pripomina instalaci NetBSD. Tam se rozbali binarky opravdu jen minimalniho systemu a pak si muzete vybrat, bud instalujete z binarek, nebo - a to je nadhera si to vyzkouset - systemem pkgsrc. Najdete si jen prislusny SW v seznamu dostupnych, date 'make install' a uz to jede. Pozoruju na sobe odklon od klasickych distribuci Linuxu k BSD. Mozna ze si ale zde popisovanou distribuci vyzkousim, je mi zatim velmi sympaticka :)

bez spravy balicku je administrace UNIXu veliky krok zpet a nikdy bych se k nemu nechtel dostat. Osobne miluju system balicku FreeBSD. ne pro moznost make install a jede, ale pro prehlednost, cistotu a moznost aplikace vlastnich oprav a konfigurace s minimem usili.

Povídání o těchto distribucích ze zdrojáků se vždycky hezky čte. Optimalizovaný výkon, vyladěný počítač, minimální instalace... Ale jak to máme dělat my, co máme k pevnýmu drátu přístup jenom občas? Třeba Gentoo Linux se dá instalovat z CDček, ale z binárek, takže ta kompilace už jaksi není ono... Nuže?
Jáchym

Debian ma i source CD a z tech by to melo jit instalovat podobne jako gentoo (jen ta aktualnost chybi). Ale jen si to myslim, doufam ze jsem nevypustil blud.

je celkem jedno, jestli ty zdrojáky jsou na CD

kdo nemá pořádný přístup k netu, ten prostě aktuální nebude -- leda že by celý dny akorát pálil, přenášel CD a instaloval

> jen ta aktualnost chybi

coz tahkle si ty zdrojaky stahnout z debian unstable a zkompilovat si nejnovejsi verzi treba pro "zastaraly" debian woody.

Vcera jsem to zkousel, pres apt jsem stahl *.orig.tar, *.diff a jeste nakej treti soubor - uz nevim jakou mel koncovku. Myslim ze to bylo prikazem "apt-get -b source jmeno_baliku". Myslel jsem si, ze se to i samo zkompiluje, ale one ne:-). Normale se mi to nakopirovalo do /home a smitec. Jeste jsem to moc nezkoumal, ale nevite nekdo jestli to jde taky "ala gentoo"?

vcera jsem to psal:
apt-get source -compile neco.deb

stahne to ty vsechny pomateny pakaze, prelozi a
vyrobi deb soubor, pokud to chce clovek optimalizovat napr na pentium, athlon atd, nebo chce pouzit jiny nez gcc prekladac pak se doprucuje stahnout pentium-builder pakaz

Přeju hezký den ve spolek. Source distribuce se mi velmi líbí a taky nad nějakou přemýšlím. Článek je hezký, ale mám jedno ALE. Jste si jistí, že aktuálnost distribuce je vždycky prioritou ? Aktuální balíčky = nové a neodzkoušené. A to nemusí být vždycky dobře.

Hezký den přeje Petr

proto ma gentoo stabilni a vyvojovou vetev ;) A taky http://forums.gentoo.org :)

jinak Gentoo je fakt super :) a kdo ma pomaly pocitac, muze prekladat pomoci distcc

No o kompilaci balicku na miru se uvazuje uz peknou radku let, ale v parxi to nikdo nedela, protoze se to nikomu nechce a nema na to cas, mozna, ze gentoo nebo Source Mage uz ma dostatecnou podporu automatickeho kompilovani, takze uz se zase vyvoj vraci zpatky a zase budem instalovat ze zdrojaku..:-)

Vyplati se tedy ta drbacka s kompilaci a vsim kolem na normalnim pracovnim citaci? Na serveru? Pouziva to nekdo dlouhodobe na produkcnim serveru? Zkusenosti?

jinak jsem to ted trochu zkoumal a vypada to, ze balicku maj jak gentoo tak tenhle wiki dost a vnich vse potrebne, takze to asi zkusim, jak je to s bezpecnostnomi updaty? je to tak jednoduchy, jako u debianu? tezko bych se odhodlal k vetsim akcim...

jak kdy. napriklad u FreeBSD jednoznacne ANO. U linuxu je to tak nejak na pul. Problem je spis v tom, ze co distribuce to nekompatibilita. Misto aby se lisily nastroji, lisi se umistenim souboru a to zcela zbytecne.
Dalsi problem je financovani. Jedna vec je mit vyladeny server s distribuci kompilovanou na miru a druha je co s nim kdyz distro skonci pro nedostatek financi.
A do tretice otazka jsou upgrady a nasledna udrzba. Jak jsem rikal, BSD ma system velice propracovany a proto jej zasadne kompiluji. Linux ze misto toho zameril na binarni balicky a podle toho to vypada.

Podle meho pro vyber distribuce hovori spis jeji stabilita na trhu nez to, jestli je ci neni kompilovana ze zdrojaku. (Vykon pocitacu dnes je vic nez postacujici a cenz nizke)

BSD je pro me neprijatelne, nema patricnou podporu pokud jde o ovladace.

Spis me zajima jina vec, je mozne kompilovat balicky
na jinem storji nez na kterem pak pojedou? Ani v jedne distribuci jsem to v FAQ nenasel, tohle by fakt hodne pomohlo na pomalejsich strojich.. typicky notebook s P100 je za 10000.- ale kompilovat na tom treba X je na tyden urcite..:-)

Tohle je naprosto standardni konfiguracni volba kompilatoru gcc. Takze odpoved je ANO. Na P4 je mozne zkompilovat balicky pro i386.

tady ale nejde ani tak o volbu kompilatoru, to je jasny, ze to pujde, tady jde o to, jestli muzu prekompilovat neco do balicku a ten si pak prehrat
a naisntalovat, a to vse jednoduse, hromadne, proste abych mel minimalne prace, neni problem se treba v necem trochu povrat, ale sorry ja nejsem hard-core uzivatel, pouzivam system jako infrastrukturu pro svou parci, nemuzu se prilis drbat s instalaci, na druhe strane nemam nic proti tomu volat ifconfig rucne:-)

Ano da sa to, bolo to tu na root.cz v clankoch o make, len si uz presne nepamatam nazov toho serialu. Kludne sa da kompilovat aj na uplne inej platforme a architekture.
To si vazne myslis, ze napr. redhat to pre i386 kompiluje na 386-tke ?? ;-)

jinak tu obdobu si predstavuju asi takhle:

apt-get source --compile --k7 mozilla.deb

Gentoo tohle neumí. Bylo to probíráno v diskuzi, plánuje se to ale teď to nejde.

ok, diky

Nejde? V Gentoo muzes normalne pouzivat binarni balicky a to bud uz hotovy (od Gentoo) nebo ty, ktery si sam vyrobis. No, a ty vlastnorucne vyrobeny, pak muzou bejt klidne pro 386.

ja to pouzivam na produkcnej pracovnej stanici v robote, uz by som nemenil za ziadnu predkompilovanu distribuciu; okrem toho na strankach linuxfromscratch.org je mnozstvo "hintov" pre prelozenie xsiek, rozchodenie tlaciarne a pod.; poobede si pre kompilaciu pripravim rozne zakladne konfiguraky, pustim to a rano ma caka cerstvo prelozena masina (odpurucam zlozit bocny kryt z compu, zapnut klimatizaciu naplno, nech mu to chladi);kua, ale robim reklamu, len sa mi tak z huby prasi ;o)) tak radsej skoncim;

laco.

Co se tyce rychlosti, tak soft z kompilace "na miru" mi neprijde nijak vyrazne rychlejsi. Dokud bylo napr. KDE 3.1 unstable, cely sem si ho pravidelne s novym rc kompiloval sam. Ted mam binarky pro Debian z ftp.kde.org a rychlost je stejna. Nic co by se dalo _kdekoli_ poznat. Stejny zkusenosti mam i s kompilovanou vs. binarni mozillou. Jediny co bych nikdy nebral jako binary je jadro, ale to je jednak jasny a dvajak to ma vic duvodu.

Clanek se mi moc libi. I ja jsem priznivec kompilovani vseho co je mozne. Nicmene par veci ve clanku chybi:
Predevsim je treba se pripravit na to, ze kompilace ze zdrojovych kodu je velmi narocna na misto na disku. Rozbaleny tar.gz archiv spolkne nekolikanasobek sve puvodni velikosti. Behem kompilace pak muze jeste dale nekolikanasobne zbytnet. Napr. Gnome zabere necelych 100MB, ale pri kompilace se doporucuje mit 1,2GB volneho mista na disku!
Po kompilaci je mozne zbytnely zdrojovy adresar "procistit" pomoci make clean, ale ani potom nebude tak "maly" jako byl po rozbaleni. A smazat ho dle meho nejde, protoze by se do budoucna vyloucila moznost odinstalovani pomoci make uninstall (ale tady me mozna nekdo opravi a ja budu rad:o). Navic, jak v claku zmineno - nektere balicky volbu uninstall nemaji.
Dalsi vec jsou zavislosti. Pokud nemate FreeBSD, Gentoo nebo podobny system, ktery ma hlidani zavislosti i u kompilace ze zdrojaku v popisu prace, tak na nevyresene zavislosti budete narazet tak casto jak u Red Hata z binarek. Kdyz si zdrojaky stahuje clovek sam, musi si na reseni zavislosti (stare knihovny ap) zvyknout jako na nutne zlo.
Taky chci reagovat na to, ze OpenOffice, Mozillu, XFree86 a dasli superbaliky si nemusim kompilovat, ale mohu pouzit binarni (predkompilovane) baliky. To je pravda, ale pak je po vyhode zrychleni pomoci kompilace "na miru".
Instalovat binarni balicky je vetsinou pohodlnejsi a rychlejsi. Kompilace vetsich softwaru na i486 je vetsinou casove neunosna. Navic, kdyz to podstoupite a po 8 hodinach to skonci chybou...;-) Resenim muze byt cross-kompilace - preklad na rychlem stroji s nastavenim parametru tak, aby kompilator kompiloval pro onu 486ku. Ale to uz se hodne vzdalujeme domacim pomerum.
A navic stahnout si kompletni distribuci pres modem...
Opakuji, sam kompiluju, co se da, ale nadseni bych hodne hodne brzdil. Ja osobne kompiluju veci, ktere nemam v distribuci (nejaky ten special-sw stazeny z Internetu, pripadne hodne nove veci a ja jsem netrpelivy). Jinak se do toho zas tak moc nehrnu.
Ale proti gustu...:o)

Jo, s tím make uninstall Tě opravím :-).

Stačí si nechat MakeFile, případně si po kompilaci udělat balíček pro Tvou distribuci (třeba alien, nebo makepkg - tuším), pak ho normálně nainstaluješ a nepotřebuješ nic.

Nehledě na to, že jsem někde v konferenci četl, že dost programatoru v MakeFile na volbu uninstall kašle, ale nemůžu to ani potvrdit, ani vyvrátit, nikdy jsem to nepotřeboval. Postup přes balíčkovací systém je jistější. Pokud je k dispozici.

Petr

Uz jsem si zvykl, ze uzivatele debianu se povazuji za nejlinuxovatejsi z linuxovatych, takze jsem jen cekal, kdy se objevi nekdo jeste vic "hardcore". No a uz jsou tady - "prekladatele" vseho. ;-)
Ted uz jen pockam, az i techto bude hodne a vznikne mezi nimi skupina, kterym samotne pouzivani a prekladani bude pripadat prilis ubohe a zacnou vsechny aplikace psat sami. (Back to Linus?:-))
Takze nic proti, prekladani vseho je urcite zajimava kratochvile, ale ja musim obcas i pracovat a ne se jen bavit, takze zustanu u svych rpm a v zachvatech "prekladatelskeho" chtice se uspokojim nejakym src.rpm balikem. ;-)

nerozumis tomu

Rozumi tomu az moc dobre. Kdo chce pracovat nema cas si hrat. Na to maji cas jen studenti, pripadne firmicky s jednim, dvema servery.

a ty tomu nerozumis taky

No a? ;-)

ale,ale...na jedny konzoli kompiluju a na druhy pracuju, tak jaky zdrzovani

1. pokud mi jde o strojový čas, tak není jedno, že počítač furt něco kompiluje (nice toho moc nevyřeší, celkové množství strojového času, který je k disposici, se nicem nezvětší)

2. pokud s tím programem potřebuju pracovat, tak musím počkat, až se zkompiluje, takže na druhé konzole můžu leda tak čumět na prompt

aby se kokot nemusel namáhat s odpovědí: samozřejmě tomu taky nerozumím :o)

ačkoliv se jako uživatel debianu cítím hrubě uražen ;-) nezbývá nic jiného než souhlasit. kdysi v počátcích portu debianu na MIPS jsem si vyzkoušel jaký je _skutečný_ bootstrapping, tj. vezmete zdrojáky gcc, binutils a libc a ty na architektuře X (u mě i386) přeložíte pro --target=Y (tady linux-mips). Pak je potřeba přeložit jádro, libc, nějaký init a spol pro cílovou platformu. Už ted jste zabili půlden... zkoušel jsem totéž pro linux-arm a ejhle: konfigurační skripty nebylo možné použít. člověk by čekal, že bude stačit upravit --target a věci okolo použitého procesoru, ale ono to není pravda. enable-threads vs. disable-threads, with-headers aj. jsou věci tak křehké, že je třeba testovat každou verzi toolchains zvlášt. když překlad skončí chybou po dvou hodinách je vážně veselo. toolchain-source je zkrátka solidní balík :)

tahle distribuce neřeší nic, je to jenom učebnice překladu ze zdrojáků. apt-get source <package> dá lepší výsledek a vyřeší závislosti. to musíte udělat stejně. *BSD systémy fungují velmi podobně. debian unstable obsahuje v podstatě tentýž sw. a jakpak je asi vyřešena situace, kdy host != target (jinými slovy potřebujete něco pro svůj embeded systém)? tohle umí i RH :-)

když se podívám na buglist kteréhokoliv projektu, je z takového mrhání silami smutno... ale co, každý dělá, co ho baví :-)

hlavně s poslední větou musím naprosto souhlasit.

za chvíli bude linuxových distribucí víc než aplikací, a k čemu to? nikoho nezajímá, že v programech jsou tuny chyb a nedodělaných featur, hlavně že má nejnovější verze zoptimalizované pro jeho procesor a správu balíčků, která je nefunkční jiným způsobem, než správy balíčků v ostatních distribucích.

např. z gimpu budou nejspíš zase odstraněny mmx optimalizace základních grafických rutin, protože není, kdo by se o to staral. takže kompilace s -O9 -march=pentium5 vám bude stejně na prd.

Sam jsem si take prosel obdobim byt "in" a zasadne nepouzivat binarni balicky. Toto obdobi me uz ale opustilo. Nerozumim prilis vasim argumentum.

> nejsou optimalizovány pro konkrétní hardware, a proto nemohou využívat všech jeho možností

Kolik procent systemovych prostredku tim ale ztratite? Trofam si rici, ze u "beznych aplikaci" nejvyse nekolik procent (u vsech programu kde jsem to zkousel byl rozdil minimalni). Navic "kriticke" aplikace byvaji i v binarnich distribucich optimalizovane (jadro, libc, multimedia,...)

> obvykle jsou již v době svého vzniku zastaralé, tj. obsahují zastaralé verze softwarových produktů

Ovsem u kolika programu opravdu potrebuji tu nejnovejsi verzi? Zbytecne riskuji, ze narazim na chyby v novych verzich (to nikdo krome testeru a vyvojaru nechce). Kvuli nedockavosti u jednoho balicku, nechci riskovat znestabilneni celeho systemu.

> binární balíčky a závislosti mezi nimi, obvykle považované za klad binárních distribucí, se často stávají noční můrou náročnějších uživatelů.

Ano zavislosti jsou ma "nocni mura" a to proste proto, ze se o problem jedna. Zavislosti mezi (binarnimi ci zdrojovymi) balicky se ho snazi resit - nakonec i configure script zavislosti testuje, protoze ani zdrojove tar.gz balicky nejsou kompatibilni. Se zavislostmi si nepomuzete ani kdyz budete instalovat jen nejnovejsi software. Nektere aktualni stabilni verze programu chteji nejnovejsi knihovny, jine ne.

Vas nazor Vam neberu (jak rikam, drive jsem jen kompiloval a i dnes to delam rad :-), jen argumenty me moc nepresvedcuji.

naprostý souhlas.

abych k tomu taky něco dodal: všichni, kdo používáte ty nejaktualizovanější a nejoptimalizovanjší distribuce, se zamyslete nad tím, u kolika programů potřebujete ty nejnovější nebo optimalizované verze

0. programy, kde byla opravena nějaká bezpečností díra nebo vážná chyba (spíš opravené stabilní verze, než nejnovější)

1. jádro, libc (spíš optimalizované a stabilní, než nejnovější)

2. multimédia, jak bylo taky zmíněno (opět spíš optimalizované, než nejnovější)

3. programy, které intenzivně a netriviálně používáte -- vzhledem k definici jich je pouze několik; navíc při netriviálním používání chcete upgradovat spíš co nejbezbolestněji, a ideálně vůbec, pokud zrovna nečekáte na nějakou novou konkrétní featuru

4. programy, na jejichž vývoji se podílíte -- takových je opět pouze několik

a ten zbytek (90%)? nejspíš byste si ani nevšimli, že máte rok a půl starou verzi zkompilovanou jen s -O -march=i386. takže o co jde?

navíc v případě 4 a občas i 3 stejně nepoužíváte žádný balíček, ani zdrojový, ale checkujete je přímo z CVS (resp. jiného RCS), patchujete, modifikujete a kompilujete nezávisle na distribuci

kam ten svet speje, tak takovyto nazor od snezneho muze me uplne vyrazil dech

už dospěl ;-)

já si toho kompiluju poměrně hodně -- aspoň vzhledem k tomu jaký tady prosazuju názory

třeba 10%. ovšem těchto 10% jsou intenzivně používané věci, které zaberou třeba 90% celkem spotřebovaného času procesoru. na zbytek kašlu.

základní pravidlo optimalizace je optimalizovat bottleneck, ne něco, co se použije jednou za půl roku, možná, za dobrého počasí, a výstup se pošle do /dev/null.

Zhruba souhlasim. Do 1 bych pridal gcc a mozna by se naslo i par dalsich, podle toho co na pocitaci delate, ale ve vetsine pripadu nema smysl prekladat si komplet distribuci z duvodu rychlosti. Pochopitelne, z duvodu ze si tak pripadate vic in to ma smysl vzdycky. Osobne volim variantu nainstalovani normalni distribuce a pak postupne prekladam co mi nevyhovuje. Vite ze mplayer 0.90rc3 jde prelozit pod libc5 jenom s tremi upravami, kazda s mene nez 3mi radky ?

jeste jeden dotaz dnes a uz vas prestanu otravovat,
pouzivate nekdo programy prelozene intelovskym c/c++?

ja jich nekolik pouzivam (athlon,pIII xeon, itanium1+2), proc?

Dobry den
chtel jsem se vas zeptat ten intelsky prekladac je volne stazitelny nebo patri mezi placeny software. Uz jsem nekolikrat slisel, ze veci na nem prelozene jsou o dost rychlejsi ? Intel pri ma prekladac na Fortran pouzivate ho nekdo pod Linuxem?
Omlouvam se jestli tento prispevek neni uplne k veci.

Dekuji IQ8

oboji je pod linuxem volne stazitelne a licence je takova ze primo podporuje prekldani gnu sw temito prekladaci, intel se snazi o maximalni kompatibilitu s gnu prekladcem, takze chce to jen vyzkouset, me osobne by zajimalo neco takoveho jako Xka (jadro zatim nejde), fortran intenzivne pouzivam

Zdravim, do Gentoo se mi zrovna nechce ;), ale zkousel jsem nedavno prekladat pres apt-build world par vybranych balicku, mj. i X-server a skonci to na tomhle:
-----> Installing build dependencies (for xbase-clients)

Nevim jestli bych chtel vymenit
zrychleni pocitace o nejake dve procenta,
protoze vic to urcite nebude za
tydny kompilace (nemam superstroj),
absenci balickoveho systemu (v me distribuci balickovy system funguje perfektne a nechci nic jineho,
ze v red hatu to nejak dobre nefunguje je problem red hatu), bordel na disku (jak zjistis ktery soubor patri ke kteremu software bez balickoveho systemu?),
a pravdepodobne i nestabilitu atd. atd...
Ja chapu ze ta nebinarni distribuce muze mit i vyhody,
ale chce to skutecne argumenty a ne jenom prazdne
zvasty nicim nepodlozene.

Myslim ze kvalita clanku na rootu jde velmi dolu,
coz me velmi mrzi.
Typicky vzorec je, ze si
nejaky amater neco nainstaluje,
za tyden (nebo za mesic, to je jedno)
se prohlasi za odbornika
a napise o tom necem clanek na roota,
zalozeny na naprosto nepodlozenych tvrzenich
typu JE TO RYCHLEJSI, JE TO VYKONEJSI,
JE TO LEPSI, NAINSTALUJE SE TO TAK.
Predchozi takovy clanek
stejneho razeni se tusim jmenoval
Smazime v Linuxu, nebo tak nejak. Jestli
to tady takhle pujde dal, tak si asi budu muset
najit nejaky jiny zdroj informaci. Nevytykam nic
autorum, za tohle muze rootova redakce, ze takove
clanky pousti --- asi nemaji nic lepsiho.

Jiz podobna distribuce existuje, s vlastnim balickovacim systemem, ktery vse kompiluje ze zdrojoveho kodu a vetsinou i s nejakym gentoo patchem.
Osobne jiz asi rok tuto distribuci vyuzivam na serveru a vykon pri optimalizaci bych hodnotil tak 10-20% dle aplikace...

Vsiml jsem si, ze kdyz selzou vsechny mirrory Gentoo, tak zacne stahovat zdrojak primo z jeho nativniho ftp, takze tato featura je u Gentoo tez.