Jeremy Mates’s Blog

In my continued reading of the most excellent Light: Science and Magic: An Introduction to Photographic Lighting book, and continued lack of lighting equipment beyond a SB-600 and various household lights of annoyingly different color temperatures, North facing windows provide excellent lighting, reproducing the effect of a large softbox.

• North facing window, plus diffuse reflection off the white table, plus random background light from the rest of the room:

  

• A different set of North facing windows, plus diffuse reflection off various pieces of white paper that fill in shadows opposite the windows. This lighting is best revealed by inspecting the helmet in the lower right. The white paper provided perhaps too much reflection, as the lemon and helmets are a bit too bright; grey paper might have worked better (coat cardboard in tinfoil if more light is required).

  

• For comparison, mostly direct morning sunlight (harder shadows, sharper highlights) through an East facing window. One shot backlit by an opened moleskin; otherwise, the pictures share the same exposure and B&W conversion:

  

Finding good lighting requires looking around, experimenting with moving things closer or away from the light source: what does the subject look like close to the window versus near it versus farther away? Does changing the camera position with respect to the subject at these different locations improve the image? Do reflected or other light sources help fill in shadows appropriately? Outside, the time of day, season, and weather might require months to line up just right…

Posted by Jeremy Mates at 04:49 | Permalink

$ df; df -i; sudo lsof | grep deleted

On unix systems, when disk space runs low, the first three commands to run are df, which shows how much space file contents occupy; df -i, whether available inodes have been consumed; and sudo lsof | grep deleted, what deleted files remain held open by a running process. Using this information, partitions can then be investigated for the source of the problem, or processes holding a large file open restarted.

Note that some file systems will never run out of inodes, as they use B+ tree or other solutions instead of a count set when the filesystem was created.

Monitoring

Disk space usage should be monitored with software such as Nagios. Alarming is best done at two levels: a non-paging ticket when disk space reaches warning levels, and a paging ticket when disk space is critically short. Using this model, runaway disk space use will quickly cause a page, while slow consumption of space can be acted on well before a page is necessary.

Different alarm levels must be set for different classes of systems: database servers might well run certain partitions up to 99% full under normal use, while other systems may require a warning ticket well before 90% usage.

Remediation

In my experience, logging causes the majority of disk space problems. Eliminate verbose and debug logging in production, as these messages hardly justify the disk space and I/O operations required. Where possible, eliminate stack trace spam: a remote connection failure warning never needs 100 lines saying where in the code the failure took place; a single line suffices, as the problem has nothing to do with the code.

Estimate disk space consumption: the amount of data logging per transaction or request in production should be known, and can be multiplied by the anticipated traffic levels, plus the duration logs must remain around, plus padding for growth and filesystem overhead. This should be done before the service launches, not afterwards!

Use proper log file handling, not problematic logrotate implementations. messages.1 to messages.2 rotation thwarts rsync style archival, and does not divide the logs into time-based buckets as better solutions do.

Technorati Tags: logging, Unix

Posted by Jeremy Mates at 17:25 | Permalink

Rollei Scanfilm CN 400 is interesting:

Holga, minus the square plastic insert. Film warping took place during either the photograph, scanning, or both. I like the results better than from comparable Fuji color films, and this film provides for different applications than super-saturated Velvia.

Posted by Jeremy Mates at 04:46 | Permalink

The War on Photography by Bruce Schneier: fear mongering, and the general insanity of the human race.

Posted by Jeremy Mates at 14:42 | Permalink

Perforce supports RCS keyword expansion, as do CVS, Subversion, and others. What these expand to, and the exact keywords supported vary: CVS supports the keywords $RCSfile$ or $Source$ for filenames, while Perforce instead expands the keyword $File$.

Now, the bug that prompted this post:

#!/usr/bin/perl -w use strict; use File::Find qw(find); find( sub { print "$File::Find::name, pid=$$\n"; $File::Find::prune = 1; }, q{.} );

In Perforce, the $File::Find::name, pid=$ string looks like a $File$ expansion, and is treated as such. This causes the code to break following a commit, but only if keyword expansion is enabled on the file. The workaround ${File::Find::name}, pid=$ avoids the problem by segregating File: from the dollar sign.

I do not consider turning off keyword expansion an acceptable workaround. Knowing where the file came from, who edited it, and how long ago greatly benefits debugging and fixing problems.

Technorati Tags: Perl

Posted by Jeremy Mates at 03:49 | Permalink

www.rogerandfrances.com offers "The Photo School" among other very useful resources.

Posted by Jeremy Mates at 15:18 | Permalink

The random things one sees at bus stops…

Posted by Jeremy Mates at 02:57 | Permalink