Nytro

Nu e chiar atat de mare nici functia mea, as putea scapa de // Daca nu, cream un nou sir, fara prima cifra (pentru transport) char *final; int k, lungime = lun_1 > lun_2 ? lun_1 : lun_2; final = new char[lungime]; for(k = 1; k < lungime; k++) final[k - 1] = suma_s[k]; final[k - 1] = '\0'; delete[] suma_s; return final; Am vrut sa returnez un pointer frumos la char. Oricum, scoateti comentariile de la mine si o sa vedeti ca nu mai e atat de infricosatoare.

PHP LFI to Arbitrary Code Execution via rfc1867 File Upload Temporary Files by Gynvael Coldwind 18 March 2011 Prologue This article describes a method of taking advantage of a .php script Local File Inclusion vulnerability. It does not describe any vulnerability in the PHP engine itself, nor does it describe any new vulnerability class. Download: http://www.exploit-db.com/download_pdf/17010 L-am citit, e scurt dar prezinta o idee interesanta. Vi-l recomand.

Oddities of PHP file access in Windows Abstract Notorious web development language, PHP, is under constant watch of the hackers, security researchers and other persons who just love to tinker around some stuff. Numerous vulnerabilities and bugs of PHP interpreter regularly highlights bug-tracks, wakes up administrators and burdens the minds of web site owners. And we never can know what nifty tricks PHP interpreter had reserved for our next day. In this paper we will describe details about how PHP treats file names on Windows operating systems, regarding the presence of different fuzzy characters. Contents 1. The prologue of current research...........................................................................................................4 2. Investigating our fuzzing results............................................................................................................5 3. Collecting together all the known tricks to access files in Windows.....................................................9 4. More exploitation variations................................................................................................................13 5. Conclusion..........................................................................................................................................14 6. References...........................................................................................................................................15 Download: http://onsec.ru/onsec.whitepaper-02.eng.pdf

http://www.linuxfromscratch.org/lfs/downloads/stable/LFS-BOOK-6.8.pdf

Gata, avetit toti 3 statusurile schimbate din "Registered users" in "Banned". Cate un avertisment pentru fiecare a fost de ajuns. Nu va convine, va dati cu fundul de pamant. Bafta.

Pe 22 martie. Acum 2 zile a fost.

Bun venit.

Daca mai vad astfel de atacuri va dau ban la toti.

Suntem misogini in general. Si aici nu esti fata sau baiat, esti un utilizator ca oricare altul. Ar fi de preferat sa iti faci un alt cont si sa nu oferi prea multe informatii despre tine. http://poyovl.wordpress.com/2010/02/21/spargerea-parolelor-de-messenger/

Dar halba are 0,5 litri, e o mare diferenta intre 0,5 si 1,0. De la 0,3 la 0,5 incepi sa te imbeti, dupa 0,5 e mai urat. Conteaza greutatea corporala, ce anume a mancat persoana in cauza inainte, daca alimentele sunt mai usor sau mai greu (de preferat) digerabile pentru ca alcoolul sa intre mai greu in sange, frigul de afara poate fi util... Conteaza multi factori, mai putin importanta e "experienta".

SEO Myths, Mistakes & The Madness Of Crowds And we are back in action! I hear this session is mostly Q&A, so should be a good time. Up on stage we have Greg Boser, Stephan Spencer, Shari Thurow, and Jill Whalen. Ready to get your learning on? I guess that means I have to stop singing and chair dancing to the music, eh? You people ruin all my fun! Matt McGee is up moderating and explaining how things are going to work. The panelists don’t have separate presentations. There’s one slide deck filled with myths we’re going to debunk or given validity to. Matt encourages the panelists to fight quickly because we only have an hour. Heh. SEO Myth 1: PageRank = Rankings Shari: False. I don’t look at Page Rank. If someone walks into my office and says the word “Page Rank”, I squirt them in the face with a water bottle. Stephan: Page Rank coming out of the toolbar is mythology. The true Page Rank score is hidden in the Page Rank score. Bear in mind, the PR numbers you get are months out of date. Greg: I don’t look at it for ranking, I do think paying attention to how toolbar PR degrades on your site is a good sign to see which pages are poor quality. We look at it to do correct what we’re doing on a site. When everything degrades as you think it should, things tend to work a little better. SEO Myth 2: PageRank Sculpting helps with rankings Stephan: Conceptually, it’s still a cool thing, but not using nofollow. Google made an important change where they didn’t give the remaining credit to the rest of the links, so you’d be passing double the juice. It used to work but Google changed it. Greg: It used to be a good way to better channel stuff. But now, you can tell Google not to pass juice to a page, but you don’t get to keep the juice. It’s like voting during an election. You can decide not to vote for certain categories, but you can’t use your extra votes on the guy you want. Jill: It’s important to remember that the site architecture and how you channel Page Rank is important, but just because you put a nofollow on a privacy page isn’t going to do anything. Shari: If you architect your site well in the first place, Page Rank sculpting is BS. Don’t link to something you don’t want people to click on. She mentions shopping cart pages, as an example SEO Myth 3: Site speed impacts ranking? Greg: It’s not dramatic, but it is important. Even if they weren’t scoring it, it impacts user behavior (aww!) and they’re clearly looking at far more data about how users interact with your site. It’s bad to have a slow site. Stephan: A slow site kills conversion. SEO Myth 4: Tweets and likes impact rankings Greg: Yes. Jill: They do to a certain extent, I don’t know how measurable it is. It would make sense that if someone with authority is tweeting certain things that they’re going to give it some impact. It’s a tricky one to know for sure. Stephan: This is one I’d definitely want to build my reputation on just for future-proofing purposes. It’s not necessarily that you’re going to be able to hire people in India to click on thinks and impact rankings, but it works for corroboration of quality. Shari: It depends on the industry. There are plenty of sites that don’t need them. SEO Myth 5: Flash kills SEO; don’t use it Shari: That’s an over-generalization. It depends on how you use it. Sometimes Flash is exactly what the user wants. There are ways to work around it and it works just fine. I wouldn’t do a site entirely in Flash. Stephan: I wouldn’t use Flash for your primary navigation. I would use it as a way to increase interactivity. Greg: Don’t ever rely on Flash to deliver your textual content. Just keep your textual content separate and use Flash to enhance the user experience and do cool, pretty neat things. Stephan: You’re losing the semantic markup when you put content in Flash. You can’t tell Google it’s bold, a headline, etc. You lose those signals. Jill: This myth is more for the people who have heard Flash is bad so they’re afraid to make a banner at the top. SEO Myth 6: Must use H1, H2, H3, etc Jill: Absolutely not. Stephan: These are all great things to test on your own to see if they work. Greg: I’ m a big fan of proper semantic structure. He uses them and uses them in the proper order. When you’re doing things that headers are actually links, he thinks its an important thing. Shari: She’s been testing since 1995 and she hasn’t seen any difference. It’s more where the page is and it’s a signal to the search engines. SEO Myth 7: Keyword Density (250 words) Jill: She made up that number years ago because it was a good amount of words to get on a page. The engines don’t care how long your pages are, there’s no specific number. Same with keyword density. You have to use your judgment and use however many words on the page and how ever many times without making your page look stupid. Shari: It’s important your page is focused. When people land on the page, they expect to see the keywords they searched for. It’s about information scent. If they don’t see it get stronger, they’ll abandon your Web site. To a degree, your pages need to be keyword-focused but there’s not a specific number. Stephan: When you’re measuring keyword density we’re talking about the edge – where you haven’t used the words at all or your keyword stuffing. Greg: He looks at ratio of text to links to a page. Pages with a lot of links and no text don’t rank very well. You also want to look at pages that semantically-related words. If you only use the phrase your want to rank for and you don’t have related terms than that can be a problem. But the overall percentage is not. SEO Myth 8: XML Sitemaps = Rankings Stephan: No. Where do you get the signal that this is an important page vs non-important page. It affects the spidering, but certainly not the importance or trust. You should have a spiderable site without an XML sitemap. Greg: In a lot of cases XML sitemaps hurt your rankings because clients don’t understand that how your content ranks is based on connectivity. Sitemaps do not create structure or creativity. XML sitemaps make Google crawl more crap. Build a site first and get it indexed properly and then add sitemaps last. Jill: The question is whether XML sitemaps help indexing or not, but even that is questionable. Greg: Crawling and ranking are different. We’re in an era where lots of low quality pages is a bad thing. It’s a bad signal. SEO Myth 9: Inbound links & TLDs (links from edus are better than other links) Jill: She strongly believes they’re not better. People believe they are because they tend to have more authority. Edus SHOULD have more authority, but they’re also the most spammed. She doesn’t believe they have a special weighting. Greg: It’s a byproduct. There’s not an algorithm bump because it’s a .edu link, but an authoritative algorithm where there are sites at the top of the chain that are better connected will include a lot of edus. Stephan: It’s a factor of it being a more pristine link neighborhood. He actually asked Matt Cutts this question a few years ago on his blog and he said it wasn’t a signal. Not that you should always trust a Google engineer, but he concurs with Matt on this one. SEO Myth 10: Buying links = Banned Matt: Only if the NYT writes about it. Heh. Jill: Do a search for any halfway competitive product and you’ll find people buying links. Stephan: You can also buy links for your competitor and get them banned Greg: He agrees and says more so now than ever. We have to separate out banning and filtering. We see more automated filtering now which will remove pages from search results without banning the entire site when abnormal anchor stuff happens. It doesn’t matter if you pay for links or not, it’s about not being stupid. Google will filter pages with abnormal links. Stephan: Thinking it like you’re creating a rap sheet for yourself. Everything can add up to a penalty. SEO Myth 11: Competitors can’t harm you Stephan: They can torture you. Hee. Greg: No comment. [stephan says that Greg, specifically, can torture you ] The idea that it can’t happen is a myth. He’ll just leave it at that. Shari: Oh, they can. It’s why she’s not a fan of social media. People can write fake reviews, post BS tweets, etc. Yes, they can. Jill: But that stuff shouldn’t affect ranking and that’s a big flaw in Google’s algo if they let that happen. Greg: Thanks to the filtering, it’s far more expensive to do now. He can buy a bunch of links to try and filter out a competitors page…but Google will just replace that page with another page. You’d have to engage in that activity for a lot of individual phrases. If you’re engaging in competitive sabotage, sometimes you make them more money. Stephan: He knows someone who’s a blackhat and it works like a charm. Greg: Be nice to people. SEO Myth 12: To what degree does linking out help your SEO? Stephan: If you’re not linking to anybody that looks abnormal. Greg: It’s all about modeling. It you read the stuff about Farmer, the idea about asking customers what they like and looking at footprints to create a model. There are common things that “trusted” sites have that you want to emulate. You will never find a good site that doesn’t link out. Linking out is your ability to tell Google what neighborhoods you want to be part of. Jill: But there’s an old myth that if they linked to Google that Google would like them better. SEO Myth 13: Google endorses SEO Stephan: It’s a dirty trick where you’d see some really dodgy firms try to do. Greg: He remembers seeing stuff where sites are being aggressive about stuff and then make badges about where they rank for stuff. Jill: You sometimes see people who are AdWords certified pretend that that has something to do with organic SEO. And many people outside the industry don’t realize there’s a difference. SEO Myth 14: SERP clicks affect rankings Shari: In personalized search. Jill: For sites that are getting a lot of real clicks, they’re probably looking at that to some extent. Greg: They’ve been tracking front side clicks since the dawn of search engines. The idea that they don’t look at engagement to determine where it ranks is just silly. Shari: Bounce rate is a myth in SEO. People think a high bounce rate is really bad, but it depends on the query. A high bounce rate on a quick fact page is actually a good sign. Greg: Its your bounce related compared to the bounce rate of the sites around you. SEO Myth 15: The goal of SEO = Ranking Jill: No. You don’t even know where you rank anymore. Everyone sees a different set of search results [stephan chime in that that's a myth. Heh]. You never know. Greg: Rankings are obviously important because if people can’t see you, you’re not going to get the traffic. But the bigger answer is that search marketing is about conversion and engagement and getting people to do what they want to do. Shari: It’s also true that people who don’t rank well get their traffic from people who DO rank well. It’s not about ranking, it’s about conversion. Stephan: The goal of SEO is ranking money. And that’s it. We’ll be back in a bit! Sursa: http://outspokenmedia.com/internet-marketing-conferences/seo-myths-2/

Arhiva SFX, unul dintre fisiere (.reg) contine: [HKEY_LOCAL_MACHINE\SYSTEM\[B]RAdmin\v2.0\Server[/B]\Parameters] "AskUser"=hex:00,00,00,00 Link scos, mutat la gunoi. O sa consider ca cel care a postat e o victima si nu ii voi da ban. Edit: Nu stau sa il analizez, daca l-ati rulat, vedeti ca se pune la StartUp in "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" cred, ca sa il scoateti descarcati "Autoruns" de la SysInternals.

"Reverse Engineering of Object Oriented Code.pdf" m-ar interesa in mod special, daca e vorba de cereri. Am cautat si cred ca asta e: Reverse Engineering of Object Oriented Code.pdf - 4shared.com - document sharing - download

Un mare c?cat.

Mersi, link scos si mutat la Gunoi.

Interesant, desi e foarte stufoasa, cred ca poate fi citita si doar partial. E bine structurata si prezinta si notiuni avansate. Mersi.

Si functiona bine pentru cazurile ca: 3888 + 333 sau 9988 + 444 sau 64 + 36 care depaseau? As fi curios sa vad o alta implementare.

E o diferenta intre a injura, ceea ce eu clasific ca "Insultare membru" si a folosi un limbaj vulgar pe care eu il clasific ca "Limbaj inadecvat". Ambele sunt motive pentru care "ofer" avertismente, care precedeaza banul. Desigur, nu aplic aceste criterii la toate categoriile. Totul tine de bun simt si de educatia fiecaruia. Acesta e un topic unde doar "trend-ul" ii moralizeaza pe cei care posteaza sa foloseasca un limbaj inadecvat, doar pentru a nu se simti exteriorizati. Dar in general limbajul nu e o problema, este oarecum decent date fiind persoanele implicate in discutii. Stiu, aparent un astfel de limbaj poate duce la diverse probleme, dar e o cale de comunicare perfecta pentru a realiza un fel de legaturi morale intre membrii acestei comunitati. Sincer, nu ma deranjeaza, decat cand se ajunge la diverse probleme. Si, ce-i drept, sunt multe momente in care imi vine sa imi bag pula. De multe ori ma abtin, imi iau in serios rolul de administrator si vreau sa fiu un exemplu pentru comunitate, dar uneori nu poti rezista tentatiei de a ofensa pe cineva intr-un mod "clasic".

O parte a unui mic proiect pentru scoala presupunea sa adun niste numere mari. Am decis sa folosesc siruri de caractere pentru memorarea acestor numere si sa scriu o functie care sa le adune, returnand un sir constand in suma celor doua. Ma gandesc ca poate fi utila, cine stie cand. // (c) Ionut Gabriel Popescu 2015 // Functie ce preia ca parametri 2 siruri de caractere, NUMERE si returneaza suma lor ca sir char* aduna_siruri(const char *sir1, const char *sir2) { // Determinam rapid lungimile sirurilor int lun_1 = 0, lun_2 = 0, ultim; while(sir1[lun_1++]); while(sir2[lun_2++]); // Pozitia ultimei cifre ultim = lun_1 > lun_2 ? lun_1 : lun_2; ultim++; // Alocam spatiu pentru noul sir char *suma_s = new char[ultim]; suma_s[(--ultim)--] = '\0'; int transport = 0, i, j; i = lun_1 - 1; j = lun_2 - 1; // Facem adunarea cat timp avem acelasi nr. de cifre int mic = i < j ? i : j; i--; j--; while(mic--) { // Daca suma e 0-9 if(sir1[i] + sir2[j] + transport < 106) { suma_s[ultim--] = sir1[i] + sir2[j] + transport - 48; // Cifra din suma celor 2 cifre transport = 0; } // Daca depaseste 9 else { suma_s[ultim--] = sir1[i] + sir2[j] + transport - 58; // Cifra din suma celor 2 cifre transport = 1; } i--; j--; } i++; j++; // Pentru numar egal de cifre, daca avem sau nu transport if(i == 0 && j == 0) { if(transport) suma_s[0] = '1'; else { // Daca nu, cream un nou sir, fara prima cifra (pentru transport) char *final; int k, lungime = lun_1 > lun_2 ? lun_1 : lun_2; final = new char[lungime]; for(k = 1; k < lungime; k++) final[k - 1] = suma_s[k]; final[k - 1] = '\0'; delete[] suma_s; return final; } } //Completam cu cifrele numarului cu mai multe cifre if(i) { // Parcurgem sirul ` si nu uitam de transport while(i) { i--; // Daca e 0 if(sir1[i] + transport == 58) { suma_s[ultim--] = sir1[i] + transport - 10; transport = 1; } else { suma_s[ultim--] = sir1[i] + transport; transport = 0; } } // Daca avem transport, pe prima pozitie avem 1 if(transport) suma_s[0] = '1'; else { // Daca nu, cream un nou sir, fara prima cifra (pentru transport) char *final; int k, lungime = lun_1 > lun_2 ? lun_1 : lun_2; final = new char[lungime]; for(k = 1; k < lungime; k++) final[k - 1] = suma_s[k]; final[k - 1] = '\0'; delete[] suma_s; return final; } } else if(j) { // Parcurgem sirul 2 si nu uitam de transport while(j) { j--; // Daca e 0 if(sir2[j] + transport == 58) { suma_s[ultim--] = sir2[j] + transport - 10; transport = 1; } else { suma_s[ultim--] = sir2[j] + transport; transport = 0; } } // Daca avem transport, pe prima pozitie avem 1 if(transport) suma_s[0] = '1'; else { // Daca nu, cream un nou sir, fara prima cifra (pentru transport) char *final; int k, lungime = lun_1 > lun_2 ? lun_1 : lun_2; final = new char[lungime]; for(k = 1; k < lungime; k++) final[k - 1] = suma_s[k]; final[k - 1] = '\0'; delete[] suma_s; return final; } } // Returnam suma return suma_s; } Codul mai lizibil aici: [C++] Nytro - Pastebin.com Mi-a luat vreo 2-3 ore sa scap de o gramada de probleme stupide. Ex. cout<<aduna_siruri("88", "999")<<endl; Ar trebui sa functioneze corect pentru toate cazurile posibile, daca ai incerca sa faci o astfel de functie ai vedea cate batai de cap poate sa iti dea, sunt multe cazuri posibile. Nu cred ca e cea mai optima si cea mai bine scrisa, dar isi face treaba, indiferent de lungimea sirurilor de caractere. Doar ca e necesar ca sirurile sa contina numai cifre.

Linux Swap Space Mar 01, 2011 By Tony Kay Swap space isn't important, is it? Swap space just slows you down—or does it? Discover some little-known facts about your operating system's virtual memory that may change the way you think about swap. When it comes to system administration, one of the earliest decisions to be made is how to configure swap space. Many readers already are thinking they know what to do: throw in as much RAM as you can afford and configure little or no swap space. For many systems with a lot of RAM, this works great; however, very few people realize that Linux makes this possible by using a form of memory accounting that can lead to system instabilities that are unacceptable for production environments. In this article, I explain the fundamentals of Linux's swap system and show how to configure swap space for optimal stability and performance. Linux is a demand-paged virtual memory system: all memory is broken up into pages—small equal-size chunks of a few kilobytes—and most of these chunks can be swapped (or “paged”) in or out of RAM as demand dictates (some pages are locked and can't be swapped). When a running process requires more RAM than is available, one or more pages of RAM that have not been used recently are “swapped out” to make RAM available. Similarly, if a running process requires access to RAM that previously has been “swapped out”, one or more pages of RAM are swapped out and the previously swapped-out RAM is swapped in. All of this happens behind the scenes without the programmer having to worry about it. The filesystem cache, program code and shared libraries have a filesystem source, so the RAM associated with any of them can be reused for another purpose at any time. Should they be needed again, Linux can just read them back in from disk. Program data and stack space are a different story. These are placed in anonymous pages, so named because they have no named filesystem source. Once modified, an anonymous page must remain in RAM for the duration of the program unless there is secondary storage to write it to. The secondary storage used for these modified anonymous pages is what we call swap space. Figure 1 shows a typical process' address space. Figure 1. A typical process address space, broken into pages. Some of the pages have no valid mapping to virtual memory. Of the ones that do, many of them (shown with a yellow background) are not given RAM until the program tries to use them. This immediately should clear up some common myths: 1. Swap space does not inherently slow down your system. In fact, not having swap space doesn't mean you won't swap pages. It merely means that Linux has fewer choices about what RAM can be reused when a demand hits. Thus, it is possible for the throughput of a system that has no swap space to be lower than that of a system that has some. 2. Swap space is used for modified anonymous pages only. Your programs, shared libraries and filesystem cache are never written there under any circumstances. 3. Given items 1 and 2 above, the philosophy of “minimization of swap space” is really just a concern about wasted disk space. In some demand-paged virtual memory systems, the operating system refuses to hand out anonymous pages to programs unless there is sufficient swap space on which to store modified versions of those pages (so the RAM can be reused while the program remains active). The accounting roughly says that VM size = swap size. This provides two guarantees: that programs have access to every byte of virtual memory they allocate and that the OS always will be able to make progress because it can swap out one process' pages for another. The problem with this is twofold. First, programs often ask for more memory than they use. The most common case is during a process fork, where an entire process is duplicated using copy-on-write anonymous pages. (Copy-on-write is a mechanism by which two processes can “share” a private writable page of RAM. Either of the processes can read the page, but the OS is required to resolve write conflicts by giving the writer a new copy of the page so as not to conflict with the other. This prevents the kernel from having to copy data unnecessarily.) Second, being able to write all of the anonymous pages to a swap device implies you are never willing to swap out pages that came from the filesystem (that is, you're not willing to allocate a filesystem page to an anonymous page such that the filesystem page may have to be swapped in later). Such systems typically require an over-provisioning of swap space in order to work properly. Solaris relaxed this by allowing a certain amount of RAM to be considered in the allocation accounting for anonymous pages (VM size = swap size + percentage of RAM size). This reduced the need for swap space while still maintaining stability. If there wasn't sufficient swap space for modified anonymous pages, the ones currently in RAM simply could stay there while code and filesystem cache pages were reused instead. Linux took this one step further and relaxed the accounting rules themselves, so that it tries to track memory “in use” (the non-yellow pages in Figure 1), as opposed to memory that has been promised via allocation requests. This works reasonably well because: 1. Many anonymous pages never get used, particularly the rarely copied copy-on-write pages generated during a fork. 2. Filesystem-based pages can be swapped when memory gets low. 3. The natural slowdown due to swapping of program code and shared library pages will discourage users from starting more than the system can handle. It's not unlike airlines handing out reservations for seats. On average, a certain percentage of customers don't show for flights. So, overcommitting on reservations ensures that they will fly with a full plane and maximize their profit. Similarly, Linux overcommits the available virtual memory in an attempt to maximize your return on investment in RAM and disk space. Unfortunately, if the overcommmitment turns out to have been a mistake, it kills a (seemingly) random process. To be fair, the algorithm is careful when it knows it is running low on memory, but this is effective only if the growth in VM allocation roughly matches VM use. In other words, if a program allocates a lot of memory and immediately starts writing to the allocated pages, the algorithm is pretty good about keeping things in check. If a process allocates a lot of virtual memory but does not immediately use it (which is a common case with Java Virtual machines, databases and other production systems), the algorithm may hand out dramatically more virtual memory than it can back up with real resources. Additionally, many programs can handle a refusal for more memory gracefully, for example, databases have tunable parameters that tell them how much RAM to use for specific tasks. Other programs might contain something like: buffer = allocate_some_memory(10 MB) if buffer allocation ok sort_using(buffer) else do_a_slower_thing_that_uses_less_memory But, Linux may tell such a program that it can have the requested memory, only to kill something in order to fulfill that commitment. Fortunately, there is a kernel-tuning parameter that can be used to switch the memory accounting mode. This parameter is vm.overcommit_memory, and it indicates which algorithm is used to track available memory. The default (0), uses the heuristic method and overcommits the virtual memory system. If you want your programs to receive appropriate out-of-memory errors on allocation instead of subjecting your processes to random killings, you should set this parameter to 2. Most Linux systems allow for tuning this parameter via the sysctl command (which does not survive reboot) or by placing it in a file that is applied when the system boots (typically /etc/sysctl.conf). To make the parameter permanent, add this to /etc/sysctl.conf: vm.overcommit_memory=2 Now for the slightly harder part. With vm.overcommit_memory set to 2, Linux will no longer hand out anonymous pages unless it knows it has a place to store them in RAM or on swap space. So, you'll have to configure enough swap to cover it, or you won't fully utilize your RAM, because it will get reserved for things that never end up being used. The amount is the tough part. You either have to estimate the anonymous page space requirements for your system's common load, or you need to be conservative and configure a lot of it. The classic recommendation on systems that do strict VM accounting vary, but most of them hover around a “twice the amount of RAM” figure. That number assumes your memory mostly will be filled with a bunch of small interactive programs (where their stack space is possibly their largest memory demand). Say you're running a Web server with 500 threads, each with 8MB of stack space. That stack space alone is going to require that you have 4GB of swap space configured for the memory accountant to be happy. Disk is cheap, so I typically start with the “twice RAM” figure. A 16GB box gets 32GB of swap. I fully expect this is overkill for my load, but disk performance considerations (lots of separate heads) mean I usually have more space than I can use anyway. Next, I monitor system behavior. Remember, the swap space is for accounting; I don't want to see much I/O happening to it. A small amount of I/O on the swap partition(s) of a busy system is not a problem until overall throughput decreases, at which point you need more RAM or fewer programs. Too little swap space definitely can be a problem, either because Linux denies requests for memory that can be served easily, or because idle dirty anonymous pages end up effectively locked in memory and might remain so for a very long time. Performance indicators: * Superb: no swap space even has been allocated (the free command shows 0 swap in use), and RAM usage is low. Unless you benefit from a huge filesystem cache, you may have spent too much on RAM. Run more stuff. * Great: swap space is allocated, but there is almost no I/O on the swap partition. * OK: swap space is allocated, and there is some I/O on the swap partition. System throughput is still OK. For example, the CPUs are busy, and most of that is in the User or Nice categories. If you see CPU Wait, it indicates a disk bottleneck (possibly on swapping), and system time could mean the OS is frantically looking for memory to reuse (page scanning). * Not OK (too much swapping): lots of I/O on the swap partition. CPU is spending a lot of time in Sys or Wait, and swap disk service times exceed the average disk access times. * Not OK (too little swap space): system is running very well, but new programs refuse to start due to lack of virtual memory. I typically have the sysstat package installed on my CentOS systems and configure the /usr/lib64/sa/sa1 script to collect all system data (including disk I/O) so I can analyze it over time. My crontab entry for this is: */5 * * * * root /usr/lib64/sa/sa1 -d 240 1 which gathers data over a four-minute time span every five minutes. You can analyze the resulting data using a utility called kSar (ksar.atomique.net) or at the command line. kSar has the advantage of making graphs that compare one metric to another. You can check your historical usage by running sar against one of these data collection files. For example, to view data from the 2nd of this month: # sar -f /var/log/sa/sa02 The most direct measure of swapping is reported from sar -W: # sar -W -f /var/log/sa/sa02 00:00:01 pswpin/s pswpout/s 00:10:01 0.00 0.00 ... The raw page numbers are a good start. If nonzero, you're doing some swapping. How much is acceptable is more difficult to judge. You'll need to examine the I/O on your swap partition. To do this, you may need to figure out the device major/minor numbers of your swap device. For example, if you swap to /dev/sdb1, use: # ls -l /dev/hdb1 brw-r----- 1 root disk 8, 17 Dec 1 14:24 /dev/sdb1 to find that your device numbers are 8/17. Many versions of sar will report disk I/O by major/minor number. The command to look at the gathered disk data is: # sar -d -f /var/log/sa/sa02 23:15:01 DEV \ tps rd_sec/s \ wr_sec/s avgrq-sz avgqu-sz \ await svctm %util 23:15:01 dev8-17 \ 0.00 0.00 \ 0.00 0.00 0.00 \ 0.00 0.00 0.00 If you have a lot of disks, use egrep to see only the header and device: # sar -d -f /var/log/sa/sa02 | egrep '(DEV|dev8-17)' ... Any swapping could be bad, but if you're seeing the avgrq-sz (average size in sectors of the requests that were issued to the device) below 1 and an await time that roughly matches svctm (average service time in milliseconds for I/O requests that were issued to the device), you may be okay. Check other indicators of system performance, such as CPU waiting for I/O and high system CPU times. Figures 2 and 3 show some custom graphs generated with kSar that make it easy to see things more clearly. Figure 2 is a graph comparing the amount of swap space used to the amount of time the CPU spent waiting on I/O. There are spikes of I/O wait, but they don't follow any sort of pattern with the swap use. However, this system deserves more attention because there is an I/O bottleneck of some sort. It is likely that this system is underperforming, but it probably is not a swapping issue (in this case, the I/O waits were heavy database request loads). Figure 2. This graph of swap use vs. CPU I/O wait contains no real correlation between a nonzero use of swap and a performance degradation. Figure 3 shows a graph comparing writes to the swap device vs. I/O wait (over a daytime time interval). It is a bit hard to see, but the red line for I/O is actually zero across the whole of the time span. This indicates that the I/O wait had nothing to do with swapping. Note that this does not mean no swapping of any sort occurred. Non-anonymous pages could have been reclaimed and reloaded. Figure 3. A Graph of I/O Writes vs. CPU I/O Wait If you are lucky enough to have all of your data on one partition and all of your code on another, you can analyze this sort of paging by watching the reads on your “code” partition. The reads will indicate program loading at startup (which may be infrequent on your systems) and also paging due to memory pressure. If the reads correspond to large I/O waits, you may benefit from more RAM. The final parameter I want to talk about can affect the responsiveness of certain loads. Have you ever left your system idle for a few hours, only to return to find that it takes a long time to start responding again? Here is probably what is happening: while you were gone, a cron job (like updatedb) scanned the filesystem, and because you weren't using the computer, all of the code pages for your “inactive” programs were thrown out in favor of disk cache! There is a kernel parameter called vm.swappiness that will affect the tendency of the system to throw out code pages instead of others. The default value of vm.swappiness is 60 on most systems. Changing this parameter to 0 will prevent the kernel from throwing out code pages for filesystem caching and will prevent your desktop from becoming zombie-like due to an unmonitored filesystem scan. The default value is fine for production systems, because any services that are heavily used will be kept in memory due to their activity. This allows the file cache to expand over anything that is truly unused and generally will work better. It may be advantageous to tune this if you are pretty certain that the majority of memory for programs should be kept (for example, you run a database that does most of its own caching). It might also help to increase this parameter to 100 on systems that have a set of very active programs. As with any performance parameter, it helps to have some benchmarks that simulate your real workload so you can measure the effects. Tuning these parameters will lead to a virtual memory system that provides a more stable foundation, particularly for production systems running programs that consume large amounts of memory. Tony Kay has been working with UNIX and Linux systems for more than 20 years. He lives in Bend, Oregon, where he manages large Linux systems and develops mobile applications. Sursa (LinuxJournal): http://www.linuxjournal.com/article/10678

Linux Kernel Development How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It: An August 2009 Update Greg Kroah-Hartman, SuSE Labs / Novell Inc. Jonathan Corbet, LWN.net Amanda McPherson, The Linux Foundation Descarca: http://www.linuxfoundation.org/sites/main/files/publications/whowriteslinux.pdf L-am citit si eu acum 5 minute, e interesant. Contine statistici foarte detaliate legate de ciclul de dezvoltare al nucleului Linux, firmele care contribuie, cateva informatii interesante pentru cei pasionati de Linux.

Tocmai am citit un articol, legat de aceste distributii si de distributiile pe care se bazeaza ele. Ma intereseaza care sunt diferentele intre ele. Stiu ca ele stau la baza multor distributii, mai ales Debian, dar ce presupune aceasta "baza", managementul fisierelor probabil, .deb (Debian) vs .rpm (RedHat Package Manager), e diferenta de baza, alte diferente care ar mai fi? Cred ca ar mai fi si sistemul de "startup", System V vs BSD, dar ce alte diferente ar mai putea fi? In articol mai era subliniat faptul ca RedHat e un contribuitor important la kernel, lucru de care de asemenea tin cont. Nu am folosit aceste distributii, doar distributii bazate pe ele. Astept opiniile voastre despre ele, si diferente intre o Debian si o dstributie bazata pe Debian de exemplu. De asemenea as vrea sa stiu ce alte diferente sunt intre ele. E doar o curiozitate a mea, daca puteti ma puteti ajuta si cu niste link-uri.

Tocmai pe asta care nu stie sa zica decat "Cica bum" l-ai ales?

Manelele este si ea o gena muzicala. Cum sa spun, voua nu va plac manelele, mie poate nu imi place muzica pe care o preferati voi. Insa eu nu fac nici o discriminare, nu am nimic impotriva genurilor muzicale preferate de voi, in schimb voi aveti o atitudine ofensiva fata de manele. Ca gen muzical se poate studia, manelele se remarca prin ritm, nu prin versurile de 2 lei ale anumitor melodii. A, sa fim seriosi, pe langa faptul ca nu toate manelele au versuri stupide, dimpotriva, sunt destul de rare greselile gramaticale, deci nu implica analfabetism, si in plus, multe dintre ele transmit un mesaj, spre deosebire de house-urile sau trance-urile sau alte genuri muzicale, ale caror melodii au 2-4 versuri, exista si alte melodii de-a dreptul stupide, prima care imi vine in minte: "Veta, mi-ai stricat chiuveta", si multe, foarte multe altele. Priviti si voi obiectiv situatia.

http://i55.tinypic.com/2vhx94g.png :->