Navedite bar jednu manu: a)m$-a i b)windows-a

A sta ti je sudo? :D



Naravno da me pita, svaku promenu vitalnih konfiguracionih fajlova uredno prijavi, cak sta vise u vecini slucajeva ne zeli sam da edituje nego meni izbaci string-ove koje je potrebno uneti u taj i taj konfiguracioni fajl, pr:

"To load virtualbox modules during startup, edit rc.conf and add vboxdrv and vboxnetflt to your MODULES array"

Dobro, ja ne radim sudo apt-get install virtualbox nego pacman -S virtualbox (sto mu dodje isto :))

---

Performanse: Brzi je pristup registryju od vremena pristupa tekst fajlovima
Stabilnost: A restore points? Nisu moguci sa conf fajlovima! Kako bi sa conf fajlovima napravio restore point za ceo sistem, ako ne znas ni gde su ni koje treba da ukljucis?
Bezbednost: Taj malware bi mogao promeniti podatke i u conf fajlovima, kako bi se to razlikovalo?

Potpisujem. Jos nijedan reg. cleaner nisam pokrenuo a da posle toga nisam imao nekakvih problema. Cak i sa famoznim CCleaner-om. 'Bes kravu koja da 10L mleka i onda ritne nogom i sve prolije.

---

Nego koju vi to kompulziju imate da "cistite" registry od "nepotrebnih" podataka? Jedino sto zaista moze da se desi je da napravite problem. I ne zamarajte se sa registry i da li je "cist" ili nije.

UAC je kao sudo ili gksu.

Taj primer iz arhlinuksa koji i ja imam instaliran je prilično neozbiljan. Nije te sistem tu ništa pitao, već ti je rekao da ćeš morati module da dodaš ručno u rc.conf. Pakman te ništa ne pita osim ako ti to ne tražiš eksplicitno. Kada instaliraš nešto iz AURa je druga stvar.

Pazi, nisam doktor za Registry, ali... Registry ti vidis kao jedan file. I to binarni file. Medjutim, fizicki je i on razbijen na delove, pa tako snimljen na disk. Grubo mozemo reci da je prikaz Registry-a kao jednog binarnog file-a i prateci API zapravo "fasada", da se posluzim terminologijom Design Pattern-a. :) Tako da, pristup Registry bazi jeste istovremeno pristup nekom file-u na disku. Da ovo bude malo jasnije, ako se ne varam, kada se ucitava Registry, OS ne trpa ceo sadrzaj registrya sa diska u memoriju. Sto znaci da ce po potrebi da se obraca disku da ucitava podatke. E sada, stos je da on ne drzi logicki povezane podatke istovremeno i fizicki povezanim. Da bi opet ostvario neke untrasnje veze, postoje tu i neki untrasnji mehanizmi za mapiranje i indeksiranje da bi se ubrzao pristup itd. Povrh svega, mislim da je "engine" koji se svim tim bavi u kernelu sto je dodatni performance hit (to je, kako je meni objasnjeno, razlog zasto su npr. mutexi na Windowsu uzasno spori).

Sve ovo bi lepo funkcionisalo, da Registry nije opterecen zaista svim i svacim i da nije neizleciv od djubreta. Meni se npr. digla kosa na glavi kada sam prvi put ugledao razne Recently Used Documents liste u Registry-u, posebno one koje su zapisale MS Office aplikacije. Zamisli uzas indeksiranja i reindeksiranja prilikom tako cestih upisa i brisanja unosa. Siguran sam ja da su u MS-u dali sve od sebe da optimizuju ove operacije, ali nije ni optimizacija svemocan lek.

Znaci, glavna caka glede performansi je sto svi settings-i u Registry-u dele "istu sudbinu" (da se tako izrazim), odn.da u pogledu performansi uticu jedni na druge. Jos vise i jos dalje, svi uticu na razlicite postavke sistema koje su od vaznosti za opsti rad i konkretno za podizanje sistema. Efekat gomilanja djubreta u Registry-u se lepo primeti posle duze upotrebe, kada podizanje sistema postaje sve sporije i sporije. To i jeste problem sa ovim centralizovanim pristupom u pogledu performansi.

Ako bi pristupio conf file-u, pristupas samo onom koji te interesuje. Takodje, postavke koje se generalno cuvaju u conf file-ovima obicno se ucitavaju se prilikom startovanja aplikacije i cuvaju u nekim njenim globalnim promenljivim. Takodje, aplikacije koje podrazumevaju postojanje prave baze podataka i rad sa njom, obicno ovakve conf file-ove vole da cuvaju u bazi. No, obzirom da se ti setinzi citaju prilikom starta aplikacije, Performance hit ne dolazi do izrazaja jer podrazumeva obracanje disku u samo tom jednom trenutku. Takodje, podaci koji se odnose na jednu aplikaciju "ne maltretiraju" neku drugu aplikaciju ako za to nema potrebe. Junk koji bi se stvarao na ovaj nacin ne tretira se odvojeno, vec kao jedinstveni problem kao i svaki drugi junk na disku.


Restore Points nisu bas znak stabilnosti vec vise rescue opcija. Kada govorim o stabilnosti sistema, onda pre mislim na one situacije kada greske u integritetu registry-a dovode do pucanja aplikacija u sred rada. Jos su tezi slucajevi kada dodje do takvih gresaka u Registry koje dovode do nemogucnosti podizanja sistema. Tada krece Restore itd...
Ova vrsta nestabilnosti, po mom misljenju, upravo dolazi iz cinjenice da je Registry jedan centralizovan repository za razlicite postavke i podatke koje aplikacije koriste i cuvaju. Pristup je lak, i moze doci da razlicitih povreda integriteta Registry-a. Sa druge strane, odrzavanje tog integriteta je veoma komplikovano, pa je stabilnost time dodatno ugrozena.

Kod conf file-ova (eh, ne zelim da pomislis kako zastupam misljenje da su conf file-ovi superiorno resenje, ovo je samo odgovor na tvoju pricu), stabilnost dobijas time sto je smanjena odn. nepostojeca je korelacija izmedju postavki i onoga sto pisu/brisu razlicite aplikacije.


Kada govorimo o bezbednosti conf file-ova, imamo u stvari opste pitanje bezbednosti osnovnih I/O operacija na disku i sigurnosti file sistema. Medjutim, kod Registry-a imamo dodatno pitanje bezbednosti samog API-a i mogucnosti eksploatacije slozenog sistema odrzavanja Registry-a. Takodje, Registry je (opet da spomenemo) "opste dobro", odnosno od njega zavise svi koji ga koriste (aplikacije, servisi itd.). U stvari, koliko malware primera znas da su se pokretali time sto su upisali neki unos u neki conf file, a koliko njih se pokretalo kada bi se upisali u start - up (ili kako se vec zove) sekciju Registry-a ili neki drugi deo Registry-a.

Kao ilustracija slozenosti "lecenja" od ovakvih slucajeva jesu razne instrukcije za uklanjanje malware-a. Dakle, kada se dijagnostifikuje ko je problem, onda ide lista Registry unosa koje treba obrisati ili izmeniti. To je jako tesko prethodno valjano otkriti. Citanje tekstualnih file-ova je nesto ipak mnogo lakse...

Da zakljucim: Registry je jedinstven u sistemu. Svi koji zavise od njega su potencijalno ugrozeni problemima koji mogu da ga pogode, bez obzira ko je uzrokovao te probleme: nepazljivi korisnik racunara, (neodgovorni) programer ili cyber kriminalac.

E vidis, ne vidi se kao binarni file (kako bi se video u hex editoru ili u programu da ga otvoris), vec zaista kao neki fs, imas stablo kljuceva i vrednosti koje su u tim kljucevima. I za svaki od njih sopstveni ACL, bas kao file system.



Cak i da je tako, da ga ne drzi celog u memoriji to je ne vise od desetak megabajta. Koliko gigabajta RAM imas u kompjuteru?



Pa ista bi bila i implementacija mutexa za obican file system? Ili ja gresim?



E vidis nema djubreta u njemu! Ako mislis da nije tako eto ti registry cleaneri, pa "cisti" registry do mile volje ali nemoj onda kukati ako nesto krene naopako.
I sta ako i ostane neka lista dokumenata u registry nakon sto uklonis word procesor, to je ne vise od kilobajta-dva, i ne moze uticati na rad sistema. Mada sta ja znam, ti si verovatno od onih koji "ciste" registry non-stop.



A jesi li siguran da to dugo startovanje sistema nije zbog puno programa koji se startuju sa Windowsom, pa nekih antivirusa i ostalih gluposti? Nego bas do registry? Mozda znas i kako to da izmerimo, da je bas do registry?



Koristio sam vise godina razne Unixe koji koriste samo conf fajlove. Tragova nakon deinstalacije aplikacija ima i tamo! A kako ces pristupiti fajlu ako ne znas da li aplikacija koristi nesto.conf ili nestodrugo.ini, jer programer moze da odredi kako mu se svidi, jer recimo zelis system restore point da napravis? Objasni ti meni to prvo. Dalje, na prethodnoj strani imas, sta ako trebas conf fajl da zamenis bazom jer ti treba neka hijerarhija, brzi pristup podacima i sl. recimo za recent documents listu? Hoces li da menjas sopstveni program ili da koristis vec gotov API za registry?

A sta cemo sa rpm/deb/whatever bazom instaliranih paketa? A sta cemo sa dependencies? Gde se to cuva? I sta kada, sto sam video svojim ocima, paket ima dependencies koje mu nisu neophodne za rad?
Da samo moze tako jednostavno kako mislis.



Izvini, lakse se odrzava registry (uz Technet i MSDN) od conf fajlova, za koje mozda i nemas dokumentaciju. Sta ti vredi kratki komentar u conf fajlu ako ne znas o cemu se radi? I ako imas npr. rpm dependency hell sta ces da radis?

@Illlron



Pacman te pita za sve za sta package maintainer's misle da treba da te pita, da li ti je ikada pacman sam nesto strpao u rc.conf? Da li ti je ikada nesto strpao sam u modprobe.conf? Dakle nijedan jedini vitalni sistemski konfiguracioni fajl ti pacman nece izmeniti bez prijave ili obavestenja ili uputstva kako to sam da odradis, pa cak i kada su u pitanju izmene u smislu putanja samih konfiguracionih fajlova on ti pruzi mogucnost da izmeni sam (naravno ostavlja predjasnje conf fajlove sa extenzijom pacsave pa da mozes da pogledas sta se tacno izmenilo u medjuvremenu) ili ako zelis a ti sam odradi izmene a ostavice ti konfiguracione fajlove koje treba da izmenis i kako kao pacnew.

Buduci da koristis archlinux ovo si garant iskusio do sad pa reci - jesam li slagao?

A naravno da ti nece prijavljivati izmene konfiguracije userlevel app-ova - to za integritet sistema nije toliko ni bitno (dok god app ne trci kao root :)) a to i nema veze sa pacman-om - konfiguracione fajlove u home direktorijumu postavljaju sami app-ovi pri prvom pokretanju i pri izmenama.


Po meni sve je ovo mnogo bolja varijanta nego registry..

---

Ne znam sta sada da kazem...

Point nije bio u velicini, vec u brzini pristupa jer podrazumeva obracanje disku vise puta, obzirom da se ne ucitava ceo Registry odjednom da stoji residentan u memoriji.


Mutexi na Windowsu su veoma spori. Zbog toga se preporucuje koriscenje kriticnih sekcija. Po onome sto sam cuo od starijih i iskusnijih, razlog je taj sto su tu mutexi u kernelu, a kriticne sekcije van, pa su zato i brze. To je bio primer kojim sam hteo da kazem da je u smislu performansi, "tamo neki" manager koji je zaduzen za odrzavanje registrya, a takodje je u Windows kernelu, takodje opterecen i usporen iz istog razloga iz kojeg i mutexi.


Opet ne znam sta da kazem. Nemam pojma da li je umesno da sada iznosim licna iskustva, ali evo:
Zahvaljujuci ciscenju registry-a, moj stari racunar je radio sa Win98 SE 6 godina bez formatiranja diska. Ne znam za slican slucaj. A to je bila ona neiskusna upotreba sa gomilom shareware-a i citavim nizom gresaka i lose prakse u upotrebi sistema.


Hvala Bogu, umem da koristim process viewere i sl. i da vidim da li radi neko ko ne treba... Nije bilo takvih aplikacija i servisa, sem onoga sto je trebalo da radi.


Izvini, ovo nisam razumeo, da li mozes da mi pojasnis ?


Meni se cini da to o cemu ti pricas sa jedne strane moze pre da se poredi sa dll hell, a sa druge strane da se postavi pitanje zasto u centralnom repository-u cuvati tu vrstu podataka zajedno sa Recently Used Documents ? Takodje ima vise veze sa instalacijama software-a i nekim drugim pitanjima. Ako hoces da naglasis medjusobnu zavisnost, to je neka druga zavisnost od one o kojoj ja pricam. Ne znam, mozda sam te lose shvatio.
---------------------
U finalu, mozda je Registry zaista sjajno resenje. Moguce je da ja ne kapiram celu tu stvar ili je gledam iz pogresnog ugla. Mozda nisam sposoban da razumem argumentaciju koja predstavlja isprepletane argumente sa stanovista krajnjeg korisnika i sa stanovista developera. Mozda je moje iskustvo kao i informacije o uticaju Registry na performanse sistema kompletno pogresno. U tom slucaju (slucajevima) ostaje mi da se izvinim zbog svega navedenog.

Koriscenje Mutexa je relativno sporo jer je potreban context-switch u kernel mod zato sto je Mutex system-wide objekat. Sporost ne dolazi iz fakta da je Mutex objekat u kernelu, vec zbog relativno sporog prelaza iz user u kernel mod kod Intel arhitekture.

Kriticne sekcije su brze jer rade u user-modu u vecini slucajeva osim kada nije potrebno upotrebiti spinlock kada se opet mora ici u kernel. Sa druge strane, to ogranicava koriscenje kriticnih sekcija samo na jedan proces, ne mozes ih koristiti ako treba da sinhronizujes 2 thread-a koja se vrte u razlicitim procesima.

Medjutim TO poredjenje je potpuno neprimereno za ovaj slucaj - Mutexi su neophodni bilo gde gde je potrebna sinhronizacija IZMEDJU procesa i jednostavno nema drugog nacina.

U slucaju fajl-sistema i registry-ja nema razlike - svi radovi na kraju moraju biti system-wide (jer fajlu ili podatku u registry-ju moze pristupiti bilo koji proces / thread), prema tome doci ce do kernel context-switcheva na kraju kako god - tvoj fajl je system-wide objekat, bas kao i registry handle - i jedan i drugi se u user-spaceu mapiraju na kernel objekte i konacne operacije se uvek zavrsavaju context-switchom u kernel.

Dakle, tvoje vidjenje "opterecenosti" je potpuno pogresno - u slucaju fajl-sistem / registry radova i ovako i onako moras imati kernel objekte jer su i fajlovi i registry system-wide objekti koji se dele izmedju procesa.

Opet se svodi na isto - i u ovom slucaju nema prakticne razlike izmedju registry-a i fajlova. Kolicina "kernel" posla ce biti priblizno ista i u jednom i u drugom slucaju je sam handle na objekat u stvari u kernelu.

---

Mozda, ali kako bi cuvao recimo recent documents u tekst fajlu? U svojoj sekciji negde ko zna gde, gde podaci nisu ni sortirani za brzi pristup? Ili u bazi? Ili imas registry API da ne moras sam da se mucis? Da li bi ti tekst fajlovi bili brzi od registry ili baze?



Moja iskustva sa registry cleanerima su sve samo ne pozitivna.



Hocu. Prvo, kako ces da implementiras system restore u OS kada svaka aplikacija koristi svoji conf fajl (Odgovor je da ih ne mozes ukljuciti ako prethodno nisi upoznat gde smestaju podesavanja) i pod dva, posto je sql baza previse za vecinu programa da u njoj drze konfiguraciju, sta ces uraditi ako ti baza ipak ustreba, konfiguraciju pocnes drzati u njoj i napustis conf fajl? Moras promeniti svoj program. Registry API to apstrahuje, bar delimicno.



Zasto da registry backup da ne obuhvati i recent documents listu u nekom Wordu? Zasto je to lose? Drugo, ne mogu se svi podaci lepo drzati u tekst fajlovima, i ja sam package managere poput rpm naveo kao primer. Govorio si o idealizovanom sistemu kod koga postoje samo podaci potrebni pojedinim aplikacijama i sistemski u koje niko ne dira, izvini, svi rpm paketi imaju zajednicku bazu u kojoj pise koji od njih je instaliran i koje druge zahteva. Ko pise package manager ne bi pogresio ni sql bazu da koristi za spremanje konfiguracije, a ne obican conf fajl. Pretpostavljam da znas sta bi znacilo citati po tekst fajlu sa desetak hiljada recorda u njemu, ne sortiranih. Uz registry bar znas da su podaci lepo sortirani za brz pristup, i naravno, bas kao sa pravom bazom, to je neko vec uradio za tebe.

Ma jeste to sto ti pricas tacno. Ali kazem, odrzavanje registry-a obavlja neki manager iz kernela. Jbg. nemam pojma kako se zove i celu tu pricu vadim iz nekog secanja kada me je Boga pitaj sta interesovalo u vezi Registry baze. Dakle, nije pitanje handle-a, neko eto tog managera koji je u kernelu. I sada, taj manager vrsi sve neka mapiranja, indeksiranja... Znaci, kada vrsis promenu na Registry, nije samo pitanje dobijanja handle-a i upisivanje, brisanje itd. kao kod file-a, vec se istovrmeno "iscima" i taj manager koji odrzava celu stvar. Mozda sam nesto i pobrkao posle toliko vremena, posebno sto nikada nisam imao neku potrebu da tu informaciju primenim u stvarnosti. Ako neko ima preciznijeg pojma o tom manageru, neka izlozi...

Pa NIJE izvrsavanje u Kernelu sporo samo po sebi - stavise moze biti i brze jer postoje drugi nivoi prioriteta i moguce je spreciti kernel thread da bude pre-emptovan dok ne zavrsi svoj posao a postoje i jos laksi metodi sinhronizacije jer onda ne moras da skaces iz user moda u kernel mod.

U slucaju mutexa u korisnickoj (user-mode) aplikaciji se radi o PRELAZU iz user u kernel mod koji donosi usporenje - a ne o tome da je kernel mod sporiji (nije, stavise upravo je suprotno).

Isto tako, pogodi gde se nalazi fajl sistem menadzer, koji odrzava tabele i fajl sistem uopste? Pa naravno, u kernelu. Sta mislis gde se nalaze tabele lock-ova za fajlove? Sta mislis gde se nalaze tabele blokova na disku? U kernel modu, a gde drugde :)

ntfs.sys - ono sys znaci drajver, a file system drajveri se u Windowsu izvrsavaju u kernel modu :-)

---

Mana Microsofta je njegova veličina, jednostavno je preglomazan za efikasan management. Kako firma raste tako se povećava broj raznih managera koji usporavaju "decision making".

Sve odluke su podređene zadovoljavanju kvartalnih rezultata deoničara, tako da dugoročno isplative ideje teško prođu ako nisu isplative "in the short term". Svakom manageru je u stvari prioritet da sačuva svoje du*e.

Posledica je da na firma postaje statična i više liči na državne firme iz socijalizma.

Microsoft mora da se restruktuira u više gotovo nezavisnih entiteta. Ovo su već pokušali ali separacija nije bila potpuna nego su samo povećali broj managera koji nešto kao koordiniše između. Decision making mora da bude u rukama ljudi koji nisu tu zato što igraju golf.
Sve ostalo su posledice.

_{[Ovu poruku je menjao Daniel Mauric dana 06.09.2009. u 00:28 GMT+1]}

E sada i ti mene zezas. :) Pa cak i ja bar toliko znam. :D

Elem, naterao si me da proverim da li sam ja kojim cudnim slucajem napisao da je sporo izvrsavanje u Kernelu. Hvala Bogu nisam, ali priznajem da sam se dovoljno neprecizno izrazio, te da si mogao steci taj utisak. Posebno zato sto sam prevideo da si ti vec shvatio da "cimanje" Registry-a zahteva context switch.

Hajde da probam da tu pricu iznesem malo sredjenije, mada je vec postala i malo naporna.
Dakle, kada otvaras neki file zarad dobijanja/menjanja konfiguracije, ti u principu imas samo taj I/O sa diskom. Posle ga zatvoris itd. Sve je to OK. Ako nesto menjas, mozda to radis u nekom baferu u memoriji, sve zavisi kako je config koncipiran, kako ga koristis itd...

Sta se desava kada radis sa Registry-em. Hajde da to gledamo na nacin kako ti to predlazes, dakle kao opet obracanje nekom file sistemu. Dakle, pozoves neku od funkcija kojom se kreira/otvara neki unos u Registry. To je analogno otvaranju file-a, (sa sve pricama o kernelu). Sada odlucis da promenis neku vrednost. To bi bilo analogno intervencijama na config file-u. Zatvoris handle, slicna je stvar i sa fileom. I do sada nemamo problem u tome da je stvar ista. Medjutim, sada menadzer zaduzen za odrzavanje Registry-a, kojeg si pozivao onim funkcijama za otvaranje, menjanje, zatvaranje se opet anagazuje zahvaljujuci tvojim prethodnim akcijama. To je sada prica o odrzavanju, jer ovaj mora da mapira promene i naravno, da reindeksira zarad brzog pristupa. Nakon nekog vremena, posto je Registry ipak file kojeg valja drzati na disku, on sve promene snima na disk - dakle I/O operacija prema disku. Ako se ne varam, sada se nesto prisecam da on to naravno ne radi istog momenta kada ti izvrsis promenu, vec periodicno snima file. Kada ljudi ne bi non stop nesto piskarali po registry-u, stvar bi bila ok, ali ga ovako non stop teraju da radi sve ovo. Onaj deo sa mapiranjem i reindeksiranjem nemas obavezno kod config file-ova, mada nije iskljuceno da tvoja aplikacija to radi. Ipak i tada, jedna aplikacija ne vrsi ove operacije nad svim config file-ovima na sistemu, vec samo nad podskupom koji nju konkretno zanima. Manager zaduzen za Registry mora sa svoje strane, da vodi racuna o celom Registry-u kojeg mogu menjati vise aplikacija u isto vreme.

Naravno, mozemo biti sigurni da su MS inzenjeri ucnili sve da maksimalno optimizuju navedene operacije. I sigurno sve te stvari koje se odvijaju u pozadini, ne bi imale nikakav bitan uticaj na performanse da se nije desilo ono sto inzenjeri MS-a nisu predvideli: najsiru (zlo)upotrebu Registry-a, za sve i svasta, pa cak i za stvari za koje nije zamisljen. Ako se ne varam, ljudi su ga koristili umesto globalnih promenljivih u aplikaciji (?!?), a neki i za inter procesnu komunikaciju. Ovo poslednje jos mogu i da razumem, jer im je bilo lakse tako nego da se bave pipe-ovima, mapiranjima i cime sve ne. Konacna posledica koja je nastala kao zlo je sav onaj junk i fragmentacija. A pri svemu tome, manager je morao da obavlja mnogo vise operacija i to na mnogo vecem Registry-u nego sto bi bilo normalno. Kakav god algoritam da primenjujes, uvek ce O(n) biti rastuca funkcija.

Uf... nemam pojma jesam li sada bio bar malo jasniji i precizniji.
-------------------------------------------------------------------
Inzenjeri MS-a su hteli Registry-em da se rese problema config file-ova i da olaksaju razne druge stvari. Sve njihove procene su dovele do Registry-a ovakvog kakav je. Nije im na pamet palo da ce programeri zloupotrebljavati Registry i da ce se (prilicno) neodgovorno odnositi prema njemu. I to ne samo autori kojekakvih smrdljivih & sumnjivih shareware aplikacija, vec i takvih brendova kao sto je Norton System Works (sa akcentom na Antivirusu), npr. Sa druge strane, dogodilo im se to da zarad vertikalne kompatibilnosti ne smeju ni da izbace Registry, niti da ga bitno modifikuju.

@Vladimir,



Ono sto ti propustas je da i fajl sistem menadzer mora da radi dodatne operacije - znaci ako ti upises fajl, radi se gomila operacija koje nisu usko vezane za taj fajl - moraju se osveziti tabele, ubaciti log u zurnal (NTFS je zurnalski fajl sistem, da se podsetimo ;-) ukoliko si kreirao nesto novo, mora se alocirati blok u alokacionim tabelama, mora se apdejtovati bitmapa, osveziti B+ stablo kako bi se lakse stizalo do fajla (NTFS)...

Naravno i ove operacije su maksimalno optimizovane, koristi se kesiranje, lazy-write za manje vazne operacije, pre-alocira se slobodan prostor - isto kao i u pitanju Registry-a... ipak je ta ekipa koja je pisala sistemski deo Windows OS-eva (NT branse) jako dobra ;-)

Sto se samog sistemskog opterecenja tice.. sta znam evo kako to izgleda kod mene:



Kao sto vidis, sistem vecinu vremena (91%) provede u najnizem P-stateu, sto znaci da nema bas nekog preteranog opterecenja po sistem - to je 800 MHz kod mene, i koliko vidim load je izmedju 0%-5% iliti 0-40 MHz se koristi za ceo OS u pozadini, sto je poprilicno nisko.

---

VladimirCDT, imaš ti neke konkretne dokaze za to da registri ovakav kakav jeste (pogotovo u Visti gde je izvršena virtuelizacija --- te ne znam kako onda kažeš da ne smeju (MS) da rade promene nad istim, kad su ih fakat uradili i to više puta) dovodi do usporenja sistema?

Razne cleanere odavno ne koristim, po mom iskustvu to je nepotrebno, a samo prave probleme. Skoro uvek sam dobio suprotan efekat, zato sam davnih dana rekao doviđenja istim i pazi kad mi sve radi okej.

Ima li neko ovde da je poterao neki reg cleaner pa je sistem posle radio brže, bio stabilniji?


Poznata priča: treba mi cleaner za registry, pa mi treba ovaj đavo, pa onaj, malo onaj crack.. pa onda Windows ne valja na kraju :)

---

Virusi mogu da uspore sistem (bar neki). Mislim da ljudi koji imaju problema sa usporenjem obično imaju problema i sa virusima. A moguće je i da gomila nepotrebnog softvera usporava sistem. Ovde svaka šuša ima PhotoShop, CorelDRAW! i ko zna koje sve ne programe koje ne umeju da koriste. Ja instaliram samo ono što mi treba.

---

+1

Kod mene sistem sa instaliranim Visual C++ Ehpressom, tri-četiri Internet Browsera, i još par sitnica (Regex generator, InfraRecorder, Microsoft Math, Gimp + dva-tri plejera) radi bez problema bar deset do dvadeset puta duže (tamo negde od 2007./08., ne sećam se) od nekadašnjih kada sam imao gadne navike - instaliraj sve, ne koristi ništa.


"Posebno sam srećna, od kad moj muž spava na njemu, on više ne hrče."

Procitao sam celu temu i mislim da nemam sta da dodam sto se tice mana widnowsa i Microsofta. Ali zato imam nesto da kazem o onoj prici o OpenOffice i Microsoft Office.
Koliko je meni poznato, .doc format uopste nije dokumentovan, tj. zatvoren je potpuno, tako da OpenOffice programeri moraju da nagadjaju, pa zato i nije toliko dobra podrska za otvaranje .doc fajlova koji imaju neko naprednije formatiranje teksta, naprednije tabele ili formule. Sa druge strane, .odt je potpuno dokumentovan i otvoren format, tako da je Microsoftu veoma lako da implementira ucitavanje i pamcenje tog formata.

Slicna stvar je i sa .docx formatom, koji je delimicno dokumentovan i otvoren, ali opet nije dovoljno (potpuno) otvoren. I zbog tog zatvorenog dela, OpenOffice i drugi Office paketi ne mogu da prikazu dokument kako treba. Mada, sa OO 3.1.1 je situacije verovatno drugacija, tako sam barem cuo (nemam sada nijedan .docx fajl pa da probam).

Znam isto da, kada je prvi put napravljena podrska za .odt u Microsoft Office-u, taj fajl nije lepo prikazivan u OpenOfficeu, jer ovi iz Microsofta nisu ispratili skroz standard .odt formata, a i takodje su "nadogradili" taj format, tako je to moglo jedino u Microsoft Officeu da se otvori kako treba. Ne znam kakva je stvar sada u tom novom Officeu 2010.

Sto se Linuxa tice, meni sve radi kako treba. Instalirao sam ga na raznim konfiguracijama i nigde nisam naisao na problem, osim na jednom veoma starom IBM laptopu na kome nije hteo da se pokrene X preko LiveCD-a (mislim da je u pitanju SiS ili VIA grafika).

Setio sam se jedne zajednicke mane Microsofta i Windowsa koju niko nije dosad napisao. :)
Ta mana je sto im je softver mnogo zatvoren, mogli bi malo da se otvore i postanu slobodni. :)
Moje misljenje je da, ako bi windows i ostali Microsoft proizovodi, nekim cudom, postali slobodni i otvorenog koda, da bi to bilo zaista dobro za sam Microsoft, a i Windows. :)