Many say that, if you have a 2GB RAM, you should configure a 2GB or more swap. FWIK the hibernation may need the same size swap to persist memory when power off, but generally, if you got a big RAM, you even don't need swap at all, isn't it?
For Linux users, when you install Linux without swap, the installer will warn you that you didn't have swap mount. No I just don't need it because my RAM is just big enough, right?
The swap file is not simply a buffer to run into when you run out of physical RAM. That is an over-simplistic view of how the swap file operates. That said, you can operate without a swap file, as long as you're 100% confident that you'll never exceed your RAM's capacity, at any point in time. Because if you do, your system crashes.
IMO, better to keep the page file and also keep tabs on how often it's being used by the system. If you're never thrashing, it's not a problem, and if you are thrashing, you have an issue that'd probably be even more serious if you weren't running a page file at all.
It's true that we have more RAM now, and it's cheap. But that's also true of disk space. Unless you have a compelling disk space constraint, I'd recommend sticking with a decent size swap file.
If you feel things are being paged to disk too often, you can look at tweaking your swappiness to be less aggressive.
All of the so-called "rules" about swap size were never intended to be rules. They were simplifications, little guidelines that could help you guesstimate a decent number if you didn't know the RAM usage patterns of the box or just didn't care to optimize.
As time passed the simplifications became folklore and "rules" to be obeyed, and the relative cost & latency differences between RAM and disk gradually changed. Today most of these rules are at best meaningless.
However, note that the question isn't "I can keep all my apps in RAM, I don't need swap". The question is "I have x RAM. How do I best utilize it, for the needs of running apps, sleeping apps, and disk I/O buffering?".
OPs question is tagged "Linux", and I don't know that much about the Linux Virtual Memory Management (I know more about Windows and FreeBSD), so I will not offer up suggested new guidelines here. A good place to start reading would be this discussion thread between the Linux 2.6 kernel developers about the "swappiness" VM tuning parameter.
That's just hardcoded behaviour in the installer, because having swap is almost always a good idea. Many Linux distros may need the swap for Hibernation, but you can change that if you want to.
Wrong. Or correct for small amounts of "need", you strictly speaking don't need swap in this case, but your PC will be faster with it. Without swap, all your programs reside in RAM, including the ones that are inactive and are not going to execute any time soon. With swap, inactive programs can be swapped out, and the physical RAM be used for more productive things -- mainly disk buffering to masquerade how slow disk I/O (incl SSD) really is.
If you want to control the kernels balancing between de-allocating disk buffers and swapping out application code, then you want the "swappiness" tuning parameter, a discussion of which I linked to above.
The various swap size rules ("thou shalt have as much swap as you have RAM", "thou shalt have twice the swap as you have RAM") made more sense when we didn't have this insane amounts of RAM we today have.
In my opinion during typical usage having too much swap is completely unnecessary. If your typical usage pattern equals to typical desktop usage - web browsing, listening to music, watching movies etc, 2 GB RAM should be more than enough. On the other hand, if you occasionally do something very memory consuming, such as rendering very complex 3D scenes, having some swap around is a good idea. Linux kernel luckily supports file based swapping, so you can configure a lot of swap on-demand without need for repartitioning, should the need for swap be there for any reason. I haven't tried to resume from hibernate with a file based swap, though.
But it's hard to imagine a scenario where having 2 GB of RAM and 2 GB of swap running near its limits would be a good idea -- in that case most of the time will be spent waiting for OS to swap pages in and out from and to the disk and not any real work will be done.
And on the server side you don't want your server to never, ever, swap. It's ok if it transfers a not-so-commonly used process to swap, but if it needs to swap for the active processes to survive, then you're in a very deep trouble.
Here are some factors that contribute to the "maximum size of physical RAM supported by the motherboard, + 1MB" rule of thumb.
Full core dumps. If there isn't enough swap to handle a full core dump, you might not be able to diagnose certain system panics.
Some operating systems use your swap space to dump their core when the system panics. You (or the OS's developers) can use that core dump to diagnose why. Most modern operating systems do a "mini dump" that is significantly smaller than the total amount of RAM ... but if the problem is a tricky one, a full core dump may be required.
Core-dump metadata. There is also sometimes a small amount of metadata that goes along with the core dump. Adding an extra 1M to the swap size will cover this.
Preparing in advance for RAM upgrades. Systems without maximum RAM installed may be upgraded in the future. Set up swap to be ready for this, rather than trying to remember to add more swap months (or years) later.
It's less critical for servers than desktops, since you'll never want to hibernate a server.
However: allocating 2GB out of a 500GB drive is cheaper (a half-dozen cents per gigabyte) than buying more RAM. The difference between "big enough" and "too much" is when the architecture no longer supports it.
Note that since the 2.6 kernel you can also use a swap file, so you could avoid swap altogether until you have some usage analysis to justify it.
To spell it out from the FAQ, you need more swap than memory in order for suspend-to-disk to function correctly.
The release notes for Ubuntu/Lucid also mention this as the installer isn't bright enough to work it out for itself.
Otherwise you don't really need too much but HDD space is cheap and so aside of hitting the 2GB limit on 32-bit boxes it isn't anything much of a concern.