This and that...

I actually got largely caught up today, work-wise, which is not bad generally speaking, but a less-than-optimum use of a Sunday. In any event, I:

• finished two of 7 outstanding jobs;
• scheduled the remaining five;
• finished despeckling 3 of 5 long-term items;
• am "85% complete" with despeckling one other long-term items.

I also spent some time dd-ing the 1.9-GB "wheezy" Debian destribution for the Raspberry Pi onto an 8-GB chip, but the operation would not complete successfully and until (and if) I do additional testing, the reason may well be faulty or out-of-spec memory. I later tried the same operation with a 4-GB chip, and it worked just fine.

I also learned a whole lot of new things about dd, including the following gem:

dd bs=4096 if=/dev/zero | pv -s 5G | dd bs=4096 of=/dev/sdb

which illustrates a rather creative use of "pipes" in Linux.

The first part of the command line (before the first vertical bar) invokes the dd program, specifying a block size of 4096 and (in this case) /dev/zero as the data source. The output of the program is sent ("piped") to the second part of the command line (between the vertical bars) which now acts as a stream of input to a program called pv, whose purpose is to show a progress bar of the amount of data received with respect to (in this command line) 5 gigabytes. The pv program then pipes the data—which has not been changed, only "inventoried"— to the third part of the command line (after the second vertical bar) where dd is invoked to package the data in blocks of 4096 and finally write the result to /dev/sdb.

I used a different method to track progress that first involves using one's favorite method to determine the ppid of the dd task—let's say it turns out to be 5536, for example—and then invoking the following command line:

kill -USR1 5536

This method employs the system's guts to interrupt the dd task and ask it to report the amount of data it's processed, after which dd returns to its business.

In any event, it took just about 40 minutes to complete the operation using a 4-GB chip. When I have some time, I plan to duplicate what I did the other day, and to experiment with a "lighter" web server (I've seen recommendations for something called Cherokee). The performance of my Sputnik installation is certainly no worse than most sites I go out to the cloud for, but there are times the wait becomes noticeable, and some of that may be due to Apache. (Fortunately, Sputnik doesn't require MySQL, as it appears to store page data in separate files.)

Time to hit the sack. Another week starts tomorrow.

Then again, tomorrow is always the start of another week. :^)