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 :)
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 :-)
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.
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 :)
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
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"?
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
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?
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..:-)
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:-)
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. ;-)
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)
No tak to je taky pekna blbina...
ad 1) Kdyz clovek potrebuje strojovej cas -> viz. "nice" ev. "renice".
ad 2) Kompilace samozrejme vubec nesouvisi s aktualni instanci toho programu. Event. problemy muzou nastat az u "make install" (pouhy kopirovani), ale to vetsinou taky nevadi, protoze ten program uz je natazenej v pameti. Ted mluvim samozrejme o updatu toho programu, ne o novy instalaci. Tam je samozrejme potreba si pockat, ale to samy plati i u binarnich distribuci (jen to trva min)...
1. Ach jo. Mluvím do zdi nebo co? Když procesor za skundu zvládne dohromady třeba miliardu instrunkcí, tak pustím pár programů s nicem a on z ničeho nic zvládne miliardy dvě? Škoda že to nevědí u Intelu a AMD :o) Jak podle tebe zvětší nice celkové množství strojového času k disposici, o kterým píšu?
2. No to teda souvisí. Dokud se nová verze nezkompiluje, musím používat starou, případně žádnou, pokud jsem program doteď neměl nainstalovaný. Na vyzkoušení nějakého programu nebo nové featury je to naprosto na prd.
Když jsem instaloval gentoo, tak jsem to samozrejme delal ve stavajici linuxove instalaci, kde jsem si na to vyhradil jednu konzoli. Chrootnul jsem si na novej disk, zadal par parametru, nakopnul to a pak prepnul zpatky do X a pracoval jako obvykle. Akorat sem tam jsem se juknul jestli to nepotrebuje popohnat a zase se vratil k praci. Pohoda. Kdyz uz jsem mel natahane vsechno co jsem potreboval, tak jsem si pretahl home adresar na partisnu s gentoo, upravil zavadec a rebootnul, upravil par veci a od te doby jedu v Gentoo. Ztrata casu minimalni, jelikoz vsechno kompilovani se odbude nekde na pozadi a clovek pritom muze pracovat jakoby se nechumelilo.
Jinak gentoo nepouzivam ani kvuli tomu kompilovani, ale spis kvuli te filozofii ala BSD. Debian sice takhle v podsate funguje taky, ale od pouziti na desktopu me odrazuji nutne sarady s balicky z ruznych vetvi.
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
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 ?
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
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.
Internet Info Root.cz (www.root.cz)
Informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2021 Internet Info, s.r.o. Všechna práva vyhrazena.