After having used CVS, Subversion, and Perforce, I’ve recently been using Git for all of my version control. The two things I like about above the others mentioned are its speed and trivial and intuitive branching. Though I can’t say I was ever a fan of CVS branches, I always found that the subversion/perforce approach of just creating another directory when you want to branch to somewhat ignore the semantics of being a branch. Why shouldn’t every version be a new directory? Obviously that would get cluttered and confusing. Why would you not expect the same of branches? Yes, I understand that directory copying is cheap in Subversion and Perforce, and I understand they do preserve history, but I expect branches to split and merge and though directories do represent the splitting very well, they unfortunately don’t represent the concept of a merge very well. Git on the otherhand, has explicit branches that are separate from the concept of a directory. Plus, it has many powerful tools for managing those branches, not to mention GitHub.
I just discovered this very cool tip. If you want a colored man pages, adding the following to your environment does it:
export LESS_TERMCAP_mb=$'\E[01;31m'
export LESS_TERMCAP_md=$'\E[01;31m'
export LESS_TERMCAP_me=$'\E[0m'
export LESS_TERMCAP_se=$'\E[0m'
export LESS_TERMCAP_so=$'\E[01;44;33m'
export LESS_TERMCAP_ue=$'\E[0m'
export LESS_TERMCAP_us=$'\E[01;32m'
I found the tip while searching for a way to preserve the colored output of grep after it has been piped into less. ‘less -r’ preserves the terminal escape sequences from the input. The following will get preserve the colors:
grep --color=always <search_term> | less -r
Origin of Wealth
is a very entertaining and captivating survey of recent developments in economics. He repeatedly takes traditional economic theories to task for failing to match real world empirical data while painting a picture of the economy as a complex, adaptive, and evolutionary system rather than the traditional overly simplistic system of market equilibrium. This is definitely worthwhile read.
I recently added a new hard drive to my desktop and reorganized the partition structure. In doing so I wanted my /home partition to be mirrored for safety, but I also wanted to use lvm to make managing my multiple partitions less painful. In my research, I found there are basically two ways to do this. One is to create a linux RAID1 device from the two drives and then use that device as a physical extent in a lvm volume group (here is a basic tutorial). The other method is to us LVM2′s mirroring capabilities. I personally would rather use the latter solution if there is no performance impact since moving the partitions around later would be much easier, however what I read gave the impression that LVM2 mirroring would be slower.
To test this, I setup a quick informal benchmark. I created 2 partitions on each of two drives and set one up as plain raid1 (no lvm) and the other as lvm with a mirror. I then ran bonnie++ on each of the partitions. The results were surprising. MD RAID1 gave about 25MB/sec write and 50MB/sec read. However LVM2 mirrored gave about 50MB/sec write and 55MB/sec read. Since the test was not perfectly sterile (there were other processes running at the same time) I would be willing to give these number +/- 10MB/sec. However still, LVM write was considerably faster than MD RAID1. I so far have no explanation for this, but will test further. If anyone has an explanation, I’d be happy to hear.