Most distributions can be easily tweaked to function this way. I've done the following on my netbook (running Ubuntu 9.04):
/tmp as a tmpfs (RAM based) filesystem
/var/tmp as tmpfs too
~/.mozilla/firefox as tmpfs and copy the real content (kept in
~/.mozilla/firefox.ssd) to it, rsyncing back to
~/.mozilla/firefox.ssd every now and then (and explicitly in the shutdown scripts). This makes a big difference as FFs writing to the URL classifier DB and its cache is very noticable on the slow SSD.
- remove all swap (the machine only has 8Gb of fixed storage and 1.5Gb of RAM, so there is little need for swap and having the extra free drive space it more important and having enough swap around to enable suspend-to-disk is definitely not an option!)
Things I plan to do, but haven't got around to yet:
/var/log as tmpfs, but syncing regularly with an on-disk copy, like I do my main user account's FF profile. Other parts of /var may benefit from this too, or maybe the whole of
/var, but there is only a fixed amount of RAM to go around in this machine
I don't know of any distributions specifically set to do this sort of thing by default (though there are several designed to run entirely from RAM, but this is probably not suitable for what you are looking to do).
Be careful when mounting
/tmp as a tmpfs filesystem to make sure you know how much space your apps are going to use there. For instance if you run VMWare VMs with certain options they will create large files there as RAM backing store (and for suspending to) - see this page for more info on that. Also make sure no badly designed/configured apps/scripts assume that the content of
/tmp survives a reboot.
With modern flash drives you don't have to worry about the number of writes so much in terms of drive life-span. The combination of improved "expected write cycles before failure" per cell and the wear-levelling algorithms used means this is a much smaller concern than it once was - you have to be running some very IO intensive operations for a long period of time before it becomes a major issue. The main reason to keep things in RAM on a flash based system is to work around poor write performance (especially with many small writes) rather than to extend drive life.