[ random @ 07.10.2003. 17:28 ] @
Iako sam ranije bio veliki zagovornik kompajliranja svega i svačega (a posebno kernela) u lokalu, sa optimizacijama za određenu arhitekturu (-O2 -march=athlonxp i tome slično), bez suvišnih stvari, praksa me je naučila da je dobitak u performansama neznatan ili nikakav, a operacija zamene kernela je podložna greškama (zaboraviš da ubaciš određenu opciju, pa onda jovo nanovo) i uzima dosta vremena.

Drugim rečima, ako kernel koji je došao uz distribuciju zadovoljava potrebe sistema, ne treba ga menjati. Eventualno ga treba ažurirati iz sigurnosnih razloga, opet pre-kompajliranim kernelom iz paketa.

Postoji neko nepisano pravilo među Linux adminima da je build from source Jedini-Pravi-Način™ da se instaliraju bitni delovi sistema (recimo kernel, zatim Apache, MySQL, PHP i tako dalje). Smatram da je ovo mit.

Za kernel sam već gore dao primer, a evo još jednog — zadnji put kad sam bildao MySQL iz sorsa (Linux, GCC 3.2) na nekoj Athlon mašini, imao sam problema jer je mysqld stalno pucao. Onda sam promenio CFLAGS (isključio optimizacije), preveo ponovo i tek onda je radio kako treba.

Znači pitanje je: koliko ručnim kompajliranjem softvera zapravo dobijamo (performanse, security) u odnosu na to koliko gubimo (vreme, podložnost greškama i problemima)?

Naravno izuzimaju se slučajevi kada nam je potrebna funkcionalnost koju ne možemo dobiti iz već gotovog paketa (recimo neki ređe korišćen PHP modul ili egzotična kernel opcija).
[ Dejan Lozanovic @ 07.10.2003. 18:06 ] @
Hmm pa ja opet mogu da navedem par primera sa nekim programima( http://dc.ketelhot.de/) koje sam skidao kao rpm i to cak za distribuciju koju sam koristio pa taj program nije hteo da radi kako treba pa kada sam lepo sam uzeo source u ruke i iskompajliralo gle cuda radi ko ludo.

A sa druge strane sto se tice mita o kompajliranju svega i svacega pa sada se ta potreba smanjuje, ali ranije su sve distribucije gurale i386 kompatibilnost, pa su tada dobici bili mnogo veliki danas kada je ciljna arhitektura P1, ili cak P2 onda se razlike i ne osete bash toliko osim kada aplikacija ne radi mnogo sa realnim brojevima. Pa da bi se dobilo na brzini upotrebom novih ekstenzija koje imaju noviji procesori, ali za takve stvari potrebno je znati sta to svaka generacija procesora ima ekstra u odnosu na predhodnu i da li kompajler te ekstenzije upotrebljava.
[ Miroslav Strugarevic @ 07.10.2003. 18:17 ] @
Citat:
random:
Drugim rečima, ako kernel koji je došao uz distribuciju zadovoljava potrebe sistema, ne treba ga menjati. Eventualno ga treba ažurirati iz sigurnosnih razloga, opet pre-kompajliranim kernelom iz paketa.


Potpuno se slažem.. Čovek može samo da se nervira.. i ništa više.. Evo mene kao živog primera.

[Ovu poruku je menjao [rammstein] dana 07.10.2003. u 20:47 GMT]
[ popeye @ 07.10.2003. 18:44 ] @
Citat:
random:
Iako sam ranije bio veliki zagovornik kompajliranja svega i svačega (a posebno kernela) u lokalu, sa optimizacijama za određenu arhitekturu (-O2 -march=athlonxp i tome slično), bez suvišnih stvari, praksa me je naučila da je dobitak u performansama neznatan ili nikakav, a operacija zamene kernela je podložna greškama (zaboraviš da ubaciš određenu opciju, pa onda jovo nanovo) i uzima dosta vremena.

Drugim rečima, ako kernel koji je došao uz distribuciju zadovoljava potrebe sistema, ne treba ga menjati. Eventualno ga treba ažurirati iz sigurnosnih razloga, opet pre-kompajliranim kernelom iz paketa.


U principu vecina distribucija danas isporucuje vise image-a optimizovanih za razlicite arhitekture i sa te strane smatram da nema potrebe rucno prevoditi jezgro. Pored toga, uglavnom jezgro u distribuciji dolazi sa vecim ili manjim brojem korisnih zakrpa za cije rucno uklapanje bih izgubio previse vremena/zivaca.

Potreba za rucnim prevodjenjem se ukazuje pri primeni posebnih zakrpa, koje ne dolaze u sklopu distribucije.

Citat:
random:
Postoji neko nepisano pravilo među Linux adminima da je build from source Jedini-Pravi-Način™ da se instaliraju bitni delovi sistema (recimo kernel, zatim Apache, MySQL, PHP i tako dalje). Smatram da je ovo mit.

Za kernel sam već gore dao primer, a evo još jednog — zadnji put kad sam bildao MySQL iz sorsa (Linux, GCC 3.2) na nekoj Athlon mašini, imao sam problema jer je mysqld stalno pucao. Onda sam promenio CFLAGS (isključio optimizacije), preveo ponovo i tek onda je radio kako treba.


Pored stabilnosti, a sto je logicno jer se distribucija razvija duze vreme i razvojni tim ima vise vremena da uoci sve probleme sa optimizacijom (pomenucu OpenOffice, ko se nervirao - shvatice), bitno je i postovanje FHS-a. Samostalnim prevodjenjem koda, cak i najuredniji admin ce pre ili kasnije ispustiti prefix, sysconfdir ili slicnu opciju. Posledica je da vise (logicki istovetnih) servera imaju razlicite konfiguracije (moze se primetiti kod nekih provajdera).

[ Miroslav Strugarevic @ 07.10.2003. 18:51 ] @
Gentoo Linux je odličan primer odlično optimizovanog sistema za razne arhitekture..
[ popeye @ 07.10.2003. 20:50 ] @
Citat:
[rammstein]:
Gentoo Linux je odličan primer odlično optimizovanog sistema za razne arhitekture..


Izmedju ostalog, mada sama optimizacija zavisi od korisnika. Izdvojio bih Portage sistem koji odlicno prepoznaje medjuzavisnosti, cuva konfiguracione datoteke i uopste veoma dobar sistem za azuriranje.

Odlican izbor ukoliko zelite da optimizujete sistem, a da ga odrzite u dobrom stanju. Usput, da li je neko testirao FHS kompatibilnost Gentoo sistema?
[ silverglider @ 08.10.2003. 09:57 ] @
Mislim da odluka "kompajlirati ili ne" zavisi i dosta od primene/hitnosti. Npr. ukoliko se radi o serveru i pronadjena je u nekom kljucnom paketu rupa velika kao avion - da li cete cekati distributera da pripremi novi rpm ili deb paket (i cekati tako sa spustenim gacama na hladnom vetru), ili cete zbog svoje sigurnosti i kozze otici na sajt doticnog paketa, skinuti tarball i kompajlirati/instalirati rucno paket?

[ tvucko @ 08.10.2003. 13:31 ] @
Ne volim bas da gubim vreme na kompajliranje, ali mislim da je to bolji nacin da se dobije optimalniji program. Nisam dugo kompajlirao kernel zato sto svucem update u rpm i to je to, ali za kernel 2.6 sam se malo potrudio i mogu reci da se isplatilo. Masina je nakon zamene kernela sa 2.4 na 2.6 bila sasvim neka druga.

PS. Ko ima vremena neka proba nece se pokajati :-)
[ random @ 09.10.2003. 00:59 ] @
Citat:
silverglider:
Mislim da odluka "kompajlirati ili ne" zavisi i dosta od primene/hitnosti. Npr. ukoliko se radi o serveru i pronadjena je u nekom kljucnom paketu rupa velika kao avion - da li cete cekati distributera da pripremi novi rpm ili deb paket (i cekati tako sa spustenim gacama na hladnom vetru), ili cete zbog svoje sigurnosti i kozze otici na sajt doticnog paketa, skinuti tarball i kompajlirati/instalirati rucno paket?


Sa druge strane distributeri su uglavnom vrlo ažurni po tom pitanju. Recimo za ovu poslednju u nizu OpenSSH rupa, novi Slackware paket se pojavio istog dana. Red Hat tim je isto tako brz.
[ popeye @ 09.10.2003. 01:21 ] @
Sve vece distribucije uglavnom brzo reaguju (RH, SuSe, Debian, Mandrake,Slackware, Gentoo), narocito (u roku od par sati) ako su propusti kriticni i postoji exploit.

Mada stoji da ako distribucija nije izbacila zakrpljenu verziju na vreme, mora se kompajlirati licno. Naravno, po izlasku zvanicnog paketa treba zameniti ovaj iz manufakture.
[ silverglider @ 09.10.2003. 10:26 ] @
Citat:
random:

Sa druge strane distributeri su uglavnom vrlo ažurni po tom pitanju. Recimo za ovu poslednju u nizu OpenSSH rupa, novi Slackware paket se pojavio istog dana. Red Hat tim je isto tako brz.


Kako je bre RH tim brz? :)
Listam securityfocus i gledam koliko je rupetina prijavljeno vezano za sve kernele ispod verzije 2.4.21 (nevezano za distro) jos u avgustu, a RH se jos uvek drzi na 2.4.20 po apdejtima za sve svoje distroe, iako je vec i 2.4.22 u opticaju neko vreme. Cekam ih ko ozeblo sunce :) mada imam osecaj da je njima veca briga da sacekaju 2.6.0, pa da lansiraju RH 10. OpenSSH 3.7.1 u opticaju, kod RH-a najveci apdejt na 3.4p1, ako se ne varam napamet. Da ne nabrajam dalje...
[ popeye @ 09.10.2003. 21:33 ] @
Zakrpljene verzije. Nije poenta imati poslednju (bleeding edge) verziju, ako prethodna radi kako treba. Ukoliko ima propusta zakrpis - to je ono sto RH (i ostale distribucije) rade. Ko koristi BIND 4, zna o cemu govorim :-)
[ random @ 10.10.2003. 01:30 ] @
Upravo tako. RedHat samo krpi istu verziju, a Slackware ponekad izbaci i noviju kao zakrpu.
[ popeye @ 10.10.2003. 01:36 ] @
Citat:
random:
Upravo tako. RedHat samo krpi istu verziju, a Slackware ponekad izbaci i noviju kao zakrpu.


Aha. Ponekad izbaci i zakrpu. :-)
[ neetzach @ 10.10.2003. 14:14 ] @
Citat:
[rammstein]:
Gentoo Linux je odličan primer odlično optimizovanog sistema za razne arhitekture..


Mislim da je Gentoo van konkurencije makar sto se teme tice, utoliko sto je pitanje kompajlirati ili ne - kod Gentooa nema ovo drugo :)
[ alex @ 10.10.2003. 14:50 ] @
Says who?? Postoji Gentoo stage3 instalacija gde je sve kompajlirano..
[ popeye @ 10.10.2003. 18:01 ] @
Moze i celokupna instalacija preko gotovih binarnih paketa.
[ impaque @ 11.10.2003. 16:56 ] @
Citat:
popeye:Usput, da li je neko testirao FHS kompatibilnost Gentoo sistema?


Hm, "testirao" ?

Citat iz Gentoo Linux Developers HOWTO:
Citat:
The filesystem layout standards used in Gentoo Linux closely follow the FHS, short for Filesystem Hierarchy Standard.
Valjda ne lažu ;))

Što se tiče ručnog kompajliranja, ja sam za, ako je mašina brza. U principu, najviše vremena treba za kompajliranje X-a, ovih ili onih grafičkih biblioteka i window menadžera, tako da za servere, kojima to nije potrebno, nije problem iskompajlirati kernel, sql, apache etc. Uostalom, zar serveri ne bi trebalo da su brzi? Problemi se naravno javljaju kad se pretera sa CFLAGS parametrima za GCC, ali tu je na adminu/useru da se ne zaleće ;) Što se tiče kompajliranja kernela: A MUST. U default kernelu (tj, u default kernelu distribucija koje poseduju dotični ;)) uvek nešto fali ili je nečeg više nego što treba...

Što se performansi ručno-kompajliranih aplikacija tiče, pogledati ovaj izveštaj. Ukratko, jasno se vidi razlika u brzini između Gentoo-a i Mandrake-a (koji je, podsećam, i586 optimizovan, a ne daj Bože kao neke distribucije koje su još i386, ugh..)
Citat:
HispaLinux 2003: Load-time conclusion

Here are the conclusions of the load-time test:

* Mozilla loads nearly twice as fast under Gentoo Linux 1.4 for Pentium III (both initial and subsequent loads)
* Initial load time for NetBeans under Gentoo is over twice as fast as on Mandrake 9.1
* Subsequent load time for NetBeans seems about even for both Gentoo and Mandrake
* With prelink, Kmail loads over 10 times faster than Gentoo Linux without prelink or Mandrake 9.1 without prelink


Meni na mojoj AthlonXP 1800+ mašini, koja još odavno nije bleeding-edge, stvarno nije problem da išta iskompajliram. Jeste da za X/KDE ode koji sat, ali Bože moj... One pričice "stavi da se kompajlira i odspavaj malo" odavno ne važe.

[Ovu poruku je menjao impaque dana 11.10.2003. u 21:01 GMT]
[ impaque @ 11.10.2003. 17:01 ] @
Citat:
alex:
Says who?? Postoji Gentoo stage3 instalacija gde je sve kompajlirano..


Eh, pa nije baš sve... Taman za komforni početak rada na Gentoo-u. ;)

Daleko je to od onih mega-giga-masivnih rpm/deb/tgz repozitorijuma koji se daju naći na netu i na instalacionim diskovima RH-a, Debiana i Slacka.
[ Marko_R @ 12.10.2003. 21:36 ] @
Citat:
popeye
U principu vecina distribucija danas isporucuje vise image-a optimizovanih za razlicite arhitekture i sa te strane smatram da nema potrebe rucno prevoditi jezgro. Pored toga, uglavnom jezgro u distribuciji dolazi sa vecim ili manjim brojem korisnih zakrpa za cije rucno uklapanje bih izgubio previse vremena/zivaca.


Većina distribucija ima odgovarajuće src pakete, dakle sa primenjenim zakrpama.

Iz svog iskustva mogu da kažem da u principu kompajliranje je gubljenje vremena, a čak može da ima i kontra efekat. Jednom prilikom, hteo sam da kompajliram mozillu 1.2a, misleći da će raditi brže. Prvi pokušaj je propao jer je paketu trebalo > 1GB prostora za to. Posle kreiranja nove particije od 7GB, kompajlacija je uspela, ali je program radio znatno sporije nego prekompajliran *.i386.rpm paket (distro je bio RH7.3), što znači bar duplo sporije ?!?!?!?
[ popeye @ 13.10.2003. 02:00 ] @
Citat:
impaque:
Citat:
popeye:Usput, da li je neko testirao FHS kompatibilnost Gentoo sistema?


Hm, "testirao" ?

Citat iz Gentoo Linux Developers HOWTO:
Citat:
The filesystem layout standards used in Gentoo Linux closely follow the FHS, short for Filesystem Hierarchy Standard.
Valjda ne lažu ;))


http://www.opengroup.org/testing/lsb-fhs/
[ Markoxxx @ 13.10.2003. 03:22 ] @
Citat:
[rammstein]:
Citat:
random:
Drugim rečima, ako kernel koji je došao uz distribuciju zadovoljava potrebe sistema, ne treba ga menjati. Eventualno ga treba ažurirati iz sigurnosnih razloga, opet pre-kompajliranim kernelom iz paketa.


Potpuno se slažem.. Čovek može samo da se nervira.. i ništa više.. Evo mene kao živog primera.

[Ovu poruku je menjao [rammstein] dana 07.10.2003. u 20:47 GMT]




polako miki.... moras malo da se nerviras da bi nesto naucio ;) ;)
[ impaque @ 14.10.2003. 20:59 ] @
Citat:
Marko_R:Jednom prilikom, hteo sam da kompajliram mozillu 1.2a, misleći da će raditi brže. Prvi pokušaj je propao jer je paketu trebalo > 1GB prostora za to. Posle kreiranja nove particije od 7GB, kompajlacija je uspela, ali je program radio znatno sporije nego prekompajliran *.i386.rpm paket (distro je bio RH7.3), što znači bar duplo sporije ?!?!?!?
Hm, a jesi li dobro odabrao CFLAGS?

Recimo:

CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -funroll-loops -malign-double

ili recimo sigurnija, ali sporija kombinacija:

CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"

i naravno:

CXXFLAGS="${CFLAGS}"