Linux za Sve forum

Ja isto, lik je ili trol ili ....

drade je napisao/la:Nisam se htio oglasavati, no potaknuli su me tvoji postovi.

Ajmo ispocetka, sto je za tebe optimizacija ? Na sto se odnosi ta optimizacija, i koje su pogodnosti tvoje optimizacije nad onom koju na primjer ja radim na linux sererima koje odrzavam ? Koji vid sigurnosti mislis da manjka u binarnim distribucijama poput debiana i/ili redhata i njihovih derivata ?

Dobitak od bilo kakve optimizacije kôda je toliko miniskulan (citaj: kompiliranja sourcea za specificnu arhitekturu), da o njemu uopce nije smisleno pricati u ozbiljnijim omjerima + sav taj arhitekturno specifican kôd se ne moze vrtiti na nicemu drugome osim na tom stroju. Sve ostalo je ricerska prica ...

Zasto svi kad cuju rijec optimizacija i kompajliranje pomisle na gradnju sustava za odredjenu arhitekturu ?
To je samo jedan mali dio svega i prije bi ga svrstao u stabilnost nego optimizaciju, mada igra ulogu i u optimizaciji jer gradis sve za svoj proc koji je najglavnija komponenta tvog racunala, upravljac svom memorijom.
Mada i to znaci puno ja uopce ne govorim o toj vrsti optimizacije.
Optimizacija u source je nesto puno vise od toga.
Sad bi o tome mogao ispisati cijelu stranicu ali nemam volje i tesko je naci rijeci da se takvog nesta objasni.

Ti u source optimiziras sam kod u svrhu njegovog brzeg izvodjenja, stabilnijeg rada i sto gladjeg odaziva na pozive kernela ili poziva kernelu. Doslovno ti izmjenjujes, brises i dodadjes kodove u program za svoje potrebe. Upravo to je najveca moc linuxa nad ostalim osevima, ali on tu ima jednu jos vecu moc, a ona je to sto postoje razni precaci da to ucinis bez da manualno editiras kodove u vimu ili nekom text editoru (kojeg neki misle da nema smisla komapjalirati , ohoho ga se isplati iskompajlat).
Recimo za pocetak primjer sam kernel, on se sastoji od 50 000+ tisuca kodova i pisan je u C. Linux nije toliko star i popularan pa jos danas mnogi ozbiljniji linux korisnici misle da se kernel kompajlacijom gradi za tvoj hardware.
To je netocno jer kompajlacija je samo proces da bi ti iz source izgradio program za instalaciju i uz sve ima pogodnost da ga izgradis za svoj hardware ali to je 10% ukupne optimizacije koju ti kernel nudi.
Jer ti ne moras biti programer da bi editirao i unosio kodove u source kad je tu konfiguracija kernela koja to sama za tebe radi onako kako je ti konfiguiras. To je ono sto je linux, to je ono zasto ga ja koristim.
Ne znam kako da ti to objasnim, da sam programer vjerojatno bih znao, pa cu seljacikim jezikom:
recimo zelis linux koji ce koristit scheduler taj i taj da koristi kernel u tom i tom sektoru memorije koji ce slati pozive za sektore memorije u tom i tom smjeru jer znas da ce tocno tamo biti aplikacije koje trebaju odgovoriti. ne zelis da koristi takve i takve cacheve, ne zelis da ima u rezervi toliko i toliko memorijskih sektora za te i te debugove i logove jer ce ti sektori uvjek biti nedostupni i rezervirani. Zatim zelis da ti kernel direktno cita uredjaje poput acpi, usb i sl a ne da to defaultno cini cekajuci bios da ga reportira o istim uredjajima
...ukopcas usb pa ti kernel ceka bios da mu kaze "ej kernel, ja sam bios, ukupcan mi je usb", zatim kernel ceka neki svoj driver da mu kaze "ej kernel, ja sam ti taj i taj driver, potvrdjujem usb", "sad pogledaj i nadji slobodnu memoriju pa ga pokreni i daj useru na koristenje", kernel si tad misli "ah u ovom sektoru sam ja, ovaj mi je rezerviran za alociranje, ovaj za cache, ovaj za debug, ovaj za ... evo ga ovaj je slobodan, tu cu si sjesti pa poslati poziv useru na usb"... kad tamo user iz ko zna kojegg sektora primjeti zaruljicu iz kernela za usb, odraditi ce svoje i evo ga napokon tebi pristupa za usb...

(To je samo jedan mali primjer u nizu optimizacije)
Sto ces uciniti ako to zelis ?
Imas dvije mogucnosti:
Kontaktirati Linus Torvaldsa da ti kodira takav kernel ili iskoristiti najvecu moc linuxa; konfiguraciju kernela koja ce na osnovu upita tebi na koje ces odgovoriti sloziti takve kodove u source sto ces kasnije kompajlirati u kernel sliku.
Kompjaliranje je daleko ozbiljniji i mocniji cin od pisljevog prilagodjavanja software na tvoju konfiguraciju.

To je sto se tice kernela ali sto sa kompajliranjem ostalih aplikacija ?
I one se grade za tvoj procesor ali to je najmanje sto mozes jer ti kompajleri nude tisuce razlicitih flagova i rijesenja za savrseno prilagodjavanje aplikacije tvojoj potrebi. a ti flagovi rade isto sto i konfiguracija kernela, direktno izmijenjuju kod aplikacije u samom procesu kompajliranja za sve tvoje potrebe.

Ti neces dobrom optimizacijom dobiti samo aplikaciju gradjenu za tvoj hardware, dobit ces isto ono sto bi dobio da ti je autor te aplikacije pisao kod specificno optimizirajuci ga za tvoje osobne potrebe
U jednoj aplikaciji tipa alsa koja ima desetke tisuca kodova, ti ces optimizacijom njih vise od pola istrijebiti a ostatak ce ostati savreseno poslozen za tvoje potrebe. Time ces sigurno za 50 % dici optimiziranost alse

Usput, baci oko na ovo: http://www.nodraw.net/2009/12/optimizat ... nstration/

drade je napisao/la:Sve binarne pakete, glavnih i podrzanih distribucija od strane vendora ocvrsja, uvijek mozes rebuildati prema svojem ukusu (ukljucujuci ili iskljucujuci feature (USE) i postavljajuci odredjene optimizacije za kôd {C, CXX}FLAGS). Da, portage to radi izdavanjem jedne naredbe, dok u binarnim varijantama imas malo vise manualnog rada (iako se i to da automatizirati; uostalom kako mislis da se buildaju svi ovi silni repozitoriji paketa ... skriptama ...).

Svakako da postoje skripte koje automatiziraju proces ali:
u distibucijama izuzev gentoo i slicnih te skripte koriste uglavnom developeri i mozes ocekivati padove i bugove ako ih koristis jer nisu namjenjene korisniku koji za njih ima podrsku tek nesto vecu od broja nula.

drade je napisao/la:Na kraju, Iskoristavanje pojedinih linux varijanti se svodi na vrijeme ulozeno koje ti treba da podignes/iskonfiguriras novi server, koji je u potpunosti poslozen i spreman za produkciju odmah nakon deploymenta (ja dizem u potpunosti iskonfiguriran/spreman server za produkciju u vremenskom razmaku od 7 - 10 minuta; instalacija ground-up).

Zasto ne ?!!

shrike je napisao/la:Ja isto, lik je ili trol ili ....

.. ili neko ne razumije sto je to linux...
(sori novi sam korisnik i nemam kredibilitet da tako govorim pogoto vama starosjediocima, ali linux je vrlo slozen i kompliciran projekt, daleko veci nego sto mnogi od vas misle da je i daleko veci nego ja mislim da je)
Nitko osim desetak kernel developera u potpunosti ne razumije linux, ne varaj se da ga razumijemo ja ili ti

i ne podrzavaj korisnika koji ide usporedjivati gentoo sa debianom a o gentoo ne zna ni g jer njegov post i tvoj je ovdje trolanje ja samo pokusavam reci sto mislim jer se s time ne slazete pa me tu nabadate a kad pokusam objasniti onda trolam .. koji vam je k ?

da ne ulazim u same detalje svacega posebno, mislim da je tvoj osnovni problem sto ne znas sto se sve moze sa distrama sa paketnim managerom (dakle ne moras rjesavati dependecy hellove cak i ako prekompjaliras iz sourcea, a dobivas puno vise optimizacije u smislu da je netko vec proucio sto se onak in general moze optimizirati, s cim se mozes sloziti ili ne ili samo dodatno optimizirati za sebe), a drugi problem je sto iznosis hrpu nekih tvrdnji bez da ih necim potkrijepis (tipa koji je benefit kompajliranja vim-a, a ne mozes ga brze rijesiti bez kompjaliranja kroz config file, koje to network protokole usporava debianov kernel, kako si to testirao i na cemu i koje povecanje latencije si primijetio i zbog cega, kojeg kreleta si upoznao da na serveru koristi bleeding edge, a da to nije pojedina aplikacija gdje se to nikako ne moze izbjeci ili je aplikacija takva da jedino bleeding edge opravdava njeno postojanje tipa spam filtera) zbog cega to sve skupa zvuci kao cirkus, nhf.

nema veze sto si novi korisnik, ali neki ljudi ovdje imaju visegodisnjeg it iskustva i supostavljaju se iz te pozicije jer je ocigledno da ti to nemas obzirom da je sve sto si eventuano i naveo kao prednost jos lakse i brze izvedivo na paketnim distrama, ne zato sto si ti novi korisnik.

preporucam man dpkg* i man apt* ili kreni s ovim; http://www.debian.org/doc/manuals/debia ... 02.en.html sto je dobar start iako je cijela stvar jos prilicno mocnija.

glaskoncILLa je napisao/la:da ne ulazim u same detalje svacega posebno, mislim da je tvoj osnovni problem sto ne znas sto se sve moze sa distrama sa paketnim managerom (dakle ne moras rjesavati dependecy hellove cak i ako prekompjaliras iz sourcea, a dobivas puno vise optimizacije u smislu da je netko vec proucio sto se onak in general moze optimizirati, s cim se mozes sloziti ili ne ili samo dodatno optimizirati za sebe),

Ne, tvoj je problem sto ne znas sto se sve moze sa source based distrama, pa ono sto znas za binary distre mislis da je bolje.
Ne moras rijesavati dependency hellove, ko to kaze ali ako hoces optimizaciju moras optimizirati depse iz source pogotovo depse onoga cega zelis optimiziranost

Ajde ti sad meni elaboriraj primjerom kako ces u dva tri poteza na debianu optimizirati kompajlacijom aplikaciju i njenih par depsa (koji ti trebaju) brze i efikasnije nego u gentoo ??
O cemu ti pricas ?
Valjas gluposti frende i to velike.

glaskoncILLa je napisao/la:da ne ulazim u same detalje svacega posebno

A ovo je tvoj najveci problem

glaskoncILLa je napisao/la:a drugi problem je sto iznosis hrpu nekih tvrdnji bez da ih necim potkrijepis (tipa koji je benefit kompajliranja vim-a, a ne mozes ga brze rijesiti bez kompjaliranja kroz config file, koje to network protokole usporava debianov kernel, kako si to testirao i na cemu i koje povecanje latencije si primijetio i zbog cega, kojeg kreleta si upoznao da na serveru koristi bleeding edge, a da to nije pojedina aplikacija gdje se to nikako ne moze izbjeci ili je aplikacija takva da jedino bleeding edge opravdava njeno postojanje tipa spam filtera) zbog cega to sve skupa zvuci kao cirkus, nhf.

A da ti odgovoris na predhodno pitanje i podkrijepis svoje tvrdnje ?
Koje network protokole ubrzavas optimizacijom kernel source pitas ?
Pa sve protokole od a do z, pokusaj - /usr/src/linux make (menuconfig) -Networking options, citaj, eksperimentiraj i uci, pa testiraj startanje dhcpcd, dodjeljivanje ipe adrese, resetiranje konekcije, ...

glaskoncILLa je napisao/la:nema veze sto si novi korisnik, ali neki ljudi ovdje imaju visegodisnjeg it iskustva i supostavljaju se iz te pozicije jer je ocigledno da ti to nemas obzirom da je sve sto si eventuano i naveo kao prednost jos lakse i brze izvedivo na paketnim distrama, ne zato sto si ti novi korisnik.

ti sigurno nemas iskustava, dok ne testiras, probas i elaboriras, ne trolaj me nekim pitanjima na koja neces prihvatiti nikakav odgovor kakav god bio

glaskoncILLa je napisao/la:preporucam man dpkg* i man apt* ili kreni s ovim; http://www.debian.org/doc/manuals/debia ... 02.en.html sto je dobar start iako je cijela stvar jos prilicno mocnija.

Hvala.

Malo malo u kernelu se nadju security propusti sto ga cini otvorenim na exploitove, zadnji takav veci je bio nedavno onaj sa null pointersima i exploitanje low memory-a sto hakeru daje totalnu kontrolu nad kernelom.
Vrlo zanimljiv tekst o tome se moze procitati ovdje: http://blog.cr0.org/2009/06/bypassing-l ... inter.html
Ali kernel developeri su uvjek korak ispred zlobnih hakera zahvaljujuci velikom ulogu rada i vremena u svoj posao pa mozemo biti sigurni. Iako sigurno da je nekad neko nekome hakirao kernel ali to je toliko rijetko da se o tome niti ne govori i tezak je put od hakiranja kernela do preuzimanja podataka sto bi teoretski trajalo duze vremena nego sami developeri pronadju rupu i zakrpaju je

Zastita ovoga expolita vrsi se CONFIG_DEFAULT_MMAP_MIN_ADDR u konfiguraciji kernela, ali to rjesenje ima i softverski problem sa druge strane koji zna dovesti do raznih faulta.
Stoga developeri distribucija odaberu zlatnu sredinu izmedju sigurnosti i stabilnosti, malo vise prema sigurnosti.
(Pa, debian server admini, koja vam je velicina te memorije u kernelu ??)
To je jedan od security problema zasto postoje hardened projekti u linuxu jer u takvim stvarima, developer je presao granicu do koje je mogao razmisljati umjesto svoga korisnika.
Konkretnije samo sa hardened projektima se moze 100% osigurati od navedenoga exploita sa grsecurityom, tocnije konfiguracijom paxa http://pax.grsecurity.net/docs/PaXTeam- ... ection.pdf. da kernel stiti tu low-memory.
To developeri u defaultnim, pogotovo desktop distrama ne mogu napraviti jer bi pola stvari bilo nestabilno i vrlo sporo.
Zato se uvjek preporuca ugasiti SELinux prije reportanja ikakvih bugova.

To znaci da je kernel debiana siguran od tog exploita 99% (i manje ali dobro), Ali nekome poput google za njihov server tih 1+% znaci milijarde dolara rizika i zato mislim da koriste custom kernel na svojim serverima

misliš ili znaš? razlika je golema...

Zaključavam temu zbog opširnog trolanja.