Tuesday, November 25, 2008
The main deterrent in continuing to write a blog is that - there is no payoff. Since i do not run ads on my blog, there is no (even theoretical) chance of income from it. Also, I know that, I am not a great blogger so that, one day my blog will be big and famous and in turn, it will make me famous. In fact, a blog cannot become famous until it is focused on something (like for eg Om Malik's or Jeff Atwood's). This blog, on the contrary contains stuff about a super-wide variety of things - from computer viruses to evolution to classical music and even photos of my treks. Then why am i into writing this ? In the time i've spent writing all these 100 posts i could have finished reading 2 good books. The only reason i can spot is - the joy of creativity. However small and insignificant for the world, I am creating something which was not there before.
Hopefully, this joy of creativity will egg me on further.
Thanks for reading and, keep reading...
Sunday, November 23, 2008
Recently, i upgraded my home PC. Apart from many others, the one feature which i was waiting to have was the 'Wake up from S5' feature. 'S5' is the ACPI spec name for the powered off state of a computer.
What this feature makes possible is - in the BIOS settings, one can set a time at which the machine should power itself on and save the BIOS settings and poweroff the machine. The machine will wake up on its own at the specified time. This feature is present on all the newer(released in the last 6-8 months, at least) Intel motherboards. Don't know about Gigabyte and others though.
The use case for me is - I have BSNL's DataOne broadband which is free from 2-8 am. Instead of keeping the machine running from 10pm or so, i can have it start just before 2. Saves ~4 hours of power and machine usage for every night that i download. Quite useful...
Friday, November 21, 2008
I attached a new SATA hard disk drive to my office machine. But, it failed to perform. The disk bandwidth was capped to a meagre 3.54MB/s irrespective of the block size, reading patterns, amount of data read and the OS. Normally, one gets read speeds upto 70MB/s from such a drive.
I thought the HDD might be defective and so, we called our vendor. He said, change the disk data cable. That was a silly suggestion i thought. Had the cable been defective, the disk would not have worked at all. The performance metrics suggested that some mechanism(or absence of some) was capping the speed at precisely 3.54MB/s. After trying out a few disk utilities, BIOS options, DMA settings and a couple of different kernels from various linux live cds, I finally gave up and decided to live with the slow speed.
A couple of weeks after that, Ashutosh enquired whether the disk problem had been fixed. When i said no, he insisted on changing the cable as the vendor had suggested. I was sure that changing the cable won't help but, since everything else was had been tried, i agreed. As we booted up the machine after plugging in a new cable, i was dumbstruck! The disk returned to its normal speed!! I could hardly believe. My understanding that, disk cables are binary i.e either they work perfectly or they do not work at all, proved to be a total myth. Later, i switched the cable to the old one and as I'd expected, that worked too. The problem i guess, was a loose contact!
This was really strange and i've still not understood the exact reason behind this. From what little i know about hardware - i guess, the loose contact might have been on one of the trasmit/receive pins in the cable(rather than ground pins). The error correction mechanism might be doing a lot of work to get/send the data correctly(lots of retransmissions ?) which caused the throughput to reduce to a low. Of course, this is a wild guess, i would be happy to know the correct answer.
Thanks to Ashutosh for the inistence :)
Lesson learnt: Do not cling to your views and knowledge too much. Be open to evalute other's views however unconvincing they might seem at first.
Wednesday, November 19, 2008
For me, the trek was not the only attraction, more important was the fact that we were going to go on bikes! I love my bike and, am always waiting for a chance to drive it. Driving a Bullet is a wonderful experience! More on it sometime later...
Overall, it was fun. Rode the bikes hard. Although the weather was sunny, we enjoyed the trek quite a lot. This time, i did not make the mistake i made last time and wore light weight sport shoes to the trek :)
Here is snap of the statue of the great warrior Murar Baji Deshpande -
Here are some more snaps .
Monday, November 17, 2008
Wednesday, November 12, 2008
The story of WOM goes thus - An engineer at Signetics who, painstakingly wrote datasheets got frustrated because, the datasheets which he submitted for printing were not even read by the approving managers. They were forwarded without checking. So, he decided to play a prank and, wrote this datasheet of 'Fully-encoded, 9046 x N Random Access, Write Only Memory'. There is hardly any need to say that, WOM is utterly useless! Also, the entire datasheet is funny, including the block diagram which shows(among other things) a dripping faucet connected to the IC and, a clock signal which just comes and goes without driving any circuit :D Even then, the datasheet went through approvals, got printed and landed in stores. The management realized their foible only when customers asked for the product and its price(don't know who found it worth buying ?). The company later recalled the catalogs and removed WOM from them.
Thanks to Mangesh for introducing me to this novel technology :)
Tuesday, November 4, 2008
Some times we need to give output from multiple processes(commands) as input to another command. The common use case i used to come across was when, i needed to diff two config files located on two different servers, while i was logged into only my workstation.
For eg. if i need to diff say /etc/rc.local from server1 and server2, then the typical flow would be -
1) get rc.local from server1, store as say tmp1
2) get rc.local from server2, store as tmp2
3) diff the two and delete after use.
I wanted to find a slightly elegant solution for this. After some searching, i found about bash's 'process substitution' feature. Bash allows you to redirect to or, from multiple processes using the '<' and '>' operators. The '<' is more useful. The '>' is more like a pipe.
The command for the above use case would be:
diff <(ssh server1 cat /etc/rc.local) <(ssh server2 cat /etc/rc.local)
The substitutions can be nested, for eg -
sed 's/Nov/November/g' <(sort -r <(grep sshd /var/log/secure|tail) <(grep pppd /var/log/messages|tail))
This (rather useless) command greps for 'sshd' and 'pppd' in two different logs and collects twenty rows which are given to sort, by use of process substitution. The sorted output is then fed to sed via another substitution. Finally, sed replaces every occurrence of 'Nov' by November.
Not that process substitution makes any impossible things possible, its just that, the code can look better and intuitive. Theoretically speaking, it will perform better too(if implemented using the same logic, of course).
To know more about how process substitution works, let us do a
cat <(sleep 15m)
This will keep cat waiting for input for 15 mins, which will give us some time to experiment.
Then, on another terminal we can check out from where cat is trying to read the input from.
ps -ef|grep cat
Output is -
[root@pranav ~]# ps -ef|grep cat
root 6310 4448 0 12:11 pts/4 00:00:00 cat /proc/self/fd/63
So, cat is reading from /proc/self/fd/63. We won't be able to read /proc/self/fd/63 of cat, we'll have to refer it using cat's pid i.e via /proc/6310/fd/63
stat /proc/6310/fd/63 reveals interesting details -
[root@pranav ~]# stat /proc/6310/fd/63
File: `/proc/6310/fd/63' -> `pipe:'
Size: 64 Blocks: 0 IO Block: 1024 symbolic link
Device: 3h/3d Inode: 61746 Links: 1
Access: (0500/lr-x------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2008-11-01 12:21:02.860555104 +0530
Modify: 2008-11-01 12:17:10.310805099 +0530
Change: 2008-11-01 12:17:10.310805099 +0530
The /proc/self/fd/* entries are being used by the process to read the output of the other. 63 is a symlink to the pipe which is opened for writing by the subshell running sleep 15m. Cat reads from the reading end of that pipe which is aliased as /proc/6310/fd/63. Thus process substitution is accomplished using pipes. Since cat is reading from /proc/6310/fd/63, if we echo anything to /proc/6310/fd/63, it will be visible on the terminal we are running cat on.
Although the syntax is similar, process substitution is very different from the commonly used command substitution technique i.e -
cat <(ls) is much different from
cat `ls`. In the former, the parenthesized commands are replaced by the file descriptor pointing to the generated output, and in the later, the parenthesized commands are replaced directly by their own output.