case-insensitive search inside vim

vim, by default, searches case sensitively. If you search for apple, you will find exactly that, but not Apple or APPLE.

In most situations, I want my searches to be case insensitive. To make search case sensitive, set the corresponding vimoption by typing :set ignorecase (and press the return key).

ignorecase has a shorter alias called ic. You can type :set icand it will have the same effect.

Now searching for apple will give you Apple, APPLE as well as apple.

But, what about the situations where you DO want case-sensitive searching?

You can always disable the ignorecase search, by typing the following and hit return:
:set noignorecase

Flipping between ignorecase and ignorecase can be tiresome for even the most patient. Luckily, vim has the smartcaseoption that you can use TOGETHER with ignorecase.

Type the following:
:set ignorecase (and hit return)
:set smartcase (and hit return)

With both ignorecase and smartcase turned on, a search is case-insensitive if you enter the search string in ALL lower case. For example, searching for apple will find Apple and APPLE.

However, if your search string has one or more characters in upper case, it will assume that you want a case-sensitive search. So, searching for Apple will only give you Apple but not apple or APPLE. It turns out to be quite satisfactory for most people (including yours truly).

While we are on the topic of vim search options, there is a third option that you should know:
:set incsearch (and hit return)

incsearch stands for incremental search. It means that you will see what vim matches as you type in each letter of your search string (without having to hit return before search is even attempted).

For example, you type / to initiate search, and right after you type the letter a, vim will highlight the a in apple. As you type the next letter p, vim will highlight ap in the word apple.

You can often find what you are looking for before you finish typing in the entire search string. It is also helpful if you are not quite sure of what you are searching for, and depending on the instant feedback as you type, you can make corrections to the search string by backspacing.

If you want to enable those options permanently, insert the following lines into your ~/.vimrc file.
set ignorecase
set smartcase
set incsearch

Happy searching!

Source #1 #2

Optimizing Apache for low memory usage

Optimizing Apache for low memory usage

The biggest problem with Apache is the amount of ram is uses. I’ll discuss the following techniques for speeding up Apache and lowering the ram used.

  • Loading Fewer Modules
  • Handle Fewer Simultaneous Requests
  • Recycle Apache Processes
  • Use KeepAlives, but not for too long
  • Lower your timeout
  • Log less
  • Don’t Resolve Hostnames
  • Don’t use .htaccess

Loading Fewer Modules

First things first, get rid of unnecessary modules. Look through your config files and see what modules you might be loading. Are you using CGI? Perl? If you’re not using modules, by all means, don’t load them. That will save you some ram, but the BIGGEST impact is in how Apache handles multiple requests.

Handle Fewer Simultaneous Requests

The more processes apache is allowed to run, the more simultaneous requests it can serve. As you increase that number, you increase the amount of ram that apache will take. Looking at TOP would suggest that each apache process takes up quite a bit of ram. However, there are a lot of shared libraries being used, so you can run some processes, you just can’t run a lot. With Debian 3.1 and Apache2, the following lines are the default:

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 20
MaxRequestsPerChild 0

I haven’t found documentation on this, but prefork.c seems to be the module that’s loaded to handle things w/ Apache2 and Debian 3.1. Other mechanisms could or could not be much more memory efficient, but I’m not digging that deep, yet. I’d like to know more, though, so post a comment and let me know. Anyway, the settings that have worked for me are:

StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5
MaxRequestsPerChild 300

What I’m basically saying is, “set the maximum amount of requests that this server can handle at any one time to 5.” This is pretty low, and I wouldn’t try to do this on a high volume server. However, there is something you can and should do on your webservers to get the most out of them, whether you’re going for low memory or not. That is tweak the keepalive timeout.

Recycle Apache Processes

If you noticed, I changed the MaxRequestsPerChild variable to 500, from 0. This variable tells Apache how many requests a given child process can handle before it should be killed. You want to kill processes, because different page requests will allocate more memory. If a script allocates a lot of memory, the Apache process under which it runs will allocate that memory, and it won’t let it go. If you’re bumping up against the memory limit of your system, this could cause you to have unnecessary swapping. Different people use different settings here. How to set this is probably a function of the traffic you receive and the nature of your site. Use your brain on this one.

Use KeepAlives, but not for too long

Keepalives are a way to have a persistent connection between a browser and a server. Originally, HTTP was envisioned as being “stateless.” Prior to keepalive, every image, javascript, frame, etc. on your pages had to be requested using a separate connection to the server. When keepalives came into wide use with HTTP/1.1, web browsers were able to keep a connection to a server open, in order to transfer multiple files across that same connection. Fewer connections, less overhead, more performance. There’s one thing wrong, though. Apache, by default, keeps the connections open for a bit too long. The default seems to be 15 seconds, but you can get by easily with 2 or 3 seconds.

This is saying, “when a browser stops requesting files, wait for X seconds before terminating the connection.” If you’re on a decent connection, 3 seconds is more than enough time to wait for the browser to make additional requests. The only reason I can think of for setting a higher KeepAliveTimeout is to keep a connection open for the NEXT page request. That is, user downloads page, renders completely, clicks another link. A timeout of 15 would be appropriate for a site that has people clicking from page to page, very often. If you’re running a low volume site where people click, read, click, etc., you probably don’t have this. You’re essentially taking 1 or more apache processes and saying, “for the next 15 seconds, don’t listen to anyone but this one guy, who may or may not actually ask for anything.” The server is optimizing one case at the expense of all the other people who are hopefully hitting your site.

Lower Your Timeout

Also, just in case, since you’re limiting the number of processes, you don’t want one to be “stuck” timing out for too long, so i suggest you lower your “normal” Timeout variable as well.

Log Less

If you’re trying to maximize performance, you can definitely log less. Modules such as Mod_Rewrite will log debugging info. If you don’t need the debugging info, get rid of it. The Rewrite log is set with the RewriteLog command. Also, if you don’t care about looking at certain statistics, you can choose to not log certain things, like theUser-Agent or the Http-Referer. I like seeing those things, but it’s up to you.
Don’t Resolve Hostnames

This one’s easy. Don’t do reverse lookups inside Apache. I can’t think of a good reason to do it. Any self respecting log parser can do this offline, in the background.

HostnameLookups Off

Don’t Use .htaccess

You’ve probably seen the AllowOverride None command. This says, “don’t look for .htaccess files” Using .htaccess will cause Apache to 1) look for files frequently and 2) parse the .htaccess file for each request. If you need per-directory changes, make the changes inside your main Apache configuration file, not in .htaccess.
Well, that’s it for Part 1, I’ll be back soon with Part 2, where I’ll talk about MySQL optimization & possibly a few other things that crop up.


apache performance tuning

Linus torvalds about PAE

PAE really really sucks.

The biggest single reason to go 64-bit is exactly because of physical address space. Your virtual address space needs to bea multiple of the physical one: when you hit 1GB of RAM, 32-bit virtual memory is no longer acceptable. You literally do need more virtual memory than physical.

PAE turned that very simple fact on its head, and screwed things up royally. Whoever came up with the idea was totally incompetent, and had forgotten all the DOS HIGHMEM pains. There’s a damn good reason why we left the 286 behind, and started using 386′s, instead of having HIGHMEM crap with windows into a bigger physical space.

Repeat after me:

virtual space needs to be bigger than physical space. Not “as big”. Not “smaller”. It needs to be bigger, by a factor of at least two, and that’s quite frankly pushing it, and you’re much better off having a factor of ten or more.

Anybody who doesn’t get that is a moron. End of discussion.

Reasons for why you need a bigger virtual space:

– you need to map that physical memory somehow, and no, tiny windows into the physical memory simply do not cut it! If you cannot have normal pointers to the physical space, it immediately means that you need to jump through serious hoops to get there.

– you additionally need to be able to remap things in alternate ways (ie user space) or make space for non-memory issues (virtual page tables, IO, you name it)

Ergo, a factor-of-two is a requirement. PAE was a total and utter disaster.

Yes, Linux supported it, and probably did so better than anybody else. But “better than anybody else” still wasn’t very good. Because you couldn’t use normal pointers to point to arbitrary physical memory, all the memory that couldn’t be accessed directly (ie anythign that didn’t fit in the virtual address map, which also had the user space memory in it) was basically limited to “special uses only”.

So you could allocate user pages in it, but you had huge problems with things like internal kernel data structures, which can be the bulk of your memory needs under some (not that unusual) loads. Directory caches, inodes, etc couldn’t use it, and in general it meant that under Linux, if you had more than 4GB of physical memory, you generally ran into problems (since only 25% of memory was available for normal kernel stuff – the rest had to be addressed through small holes in the tiny virtual address space).

I’m not at all surprised that Windows didn’t push PAE either. It was a total braindamage. I bet they supported it in the server offerings just because they had to, and I bet they did a much worse job of it than Linux did, and the reason you can do that with servers is that the loads are much easier, and you can expect maintainers to set magic config entries to tweak it to make it appear to work well for any particular load, when in reality it is fragile as hell and works only with duct-tape and prayers.

That kind of “duct-tape and prayers and lots of specialized knowledge about the load” is simply not possible in a desktop environment. Yeah, users have prayers, but they lack the duct-tape and the knowledge to work around the problems.

And dammit, in this age and date when almost everybody has a gigabyte of RAM in any new machine, anybody who still thinks that “not that many people need 64-bits” is simply not aware of what he’s speaking of.

Go back and play with HIGHMEM.SYS on a 286, and stop blathering crap. When you’ve spent the last ten years of your life working with HIGHMEM.SYS, then you can come back and tell me that we still don’t need 64 bits. Until that is the case, anybody who still doesn’t get why 64 bits is a requirement should just shut up rather than make a total fool of himself.

So repeat after me: PAE didn’t ever really fix anything. It was a mistake. It was just a total failure, and the result of hw engineers not understanding software.

So no, PAE does not mean that you can use more than 4GB of RAM. Even before PAE, the practical limit was around 1GB, and PAE didn’t move that post a fraction of an inch!



hidden gnome fish

  1. Open the Run Application dialog (Alt + F2)
  2. Enter “free the fish” (without the quotes)
  3. Press Enter

Another way to invoke it:

  1. Right-click your Gnome panel
  2. Click About Panels
  3. Press the “F” key three times

And another easter egg (really lame, but this one is easy to quit):

  1. Open the Run Application dialog (Alt + F2)
  2. Enter “gegls from outer space” (without the quotes)
  3. Press Enter

CPanel: permanent whitelist static IPs/hosts using antirelayd/relayhosts

If you are using CPanel you already know that its mail server (exim) uses a mechanism to allow pop-before-smtp relaying for sending outgoing emails. The IPs allowed to relay on the server are added dynamically to the file /etc/relayhosts by the antirelayd daemon.

The exim configuration for this:

/etc/exim.conf: hostlist relay_hosts = lsearch;/etc/relayhosts : localhost

What is antirelaydantirelayd is a daemon that checks /var/log/maillog for pop3/imap logins and keeps track of valid ones for use with smtp relaying. It manages the /etc/relayhosts file automatically so if you are trying to add a static IP in that file it will be cleaned up by antirelayd.
So how can we whitelist some IP and add it permanently to the allowed hosts to relay mail using the server? Well this is very simple but not documented properly (you can easily see this if you are looking into the file /usr/sbin/antirelayd that is just a perl script). So all you have to do is create a file (if no such file exists) called alwaysrelay in /etc and add the IPs you always want to be allowed to relay outgoing mails on the server. Normally /etc/alwaysrelay will not exist, but if it does just edit the file and append the needed IPs.


and add each IP on a separate line. After this either restart antirelayd or wait for a little while and it will automatically include these IPs in /etc/relayhosts and they will not be cleaned any more (permanent relay).

The same result can be achieved by creating a different file (for ex. /etc/staticrelay) and including it in the exim configuration (in the relay_hosts config similar to /etc/relayhosts). This file will be manually maintained and not cleaned up by antirelayd so the result is the same. Choose the method that you prefer (either antirelayd or exim.conf)


dircolors -p > ~/.dircolors  – Creates a .dircoloirs file inside the home directory with color codes and some additional stuff (basically there is the output of dircolors -p :-D)  To make this work we need to execute following command eval $(dircolors ~/.dircolors) thats it.

My dircolor

Vim syntax coloring centos

First you need to install yum install following:

vim-common vim-enhanced vim-minimal

If you still don’t have syntax coloring open this file /etc/vim/vimrc and add following line: syntax on If this line already exist just uncomment it.