For the last week (12 Aug 2007 to 18 Aug 2007) I decided to do some spot sampling of my computer activity at home.
On Cronus I had this exciting line (or earlier variants of it, I tinkered a bit) in my cron:
0 * * * * sleep `perl -e ‘print int(rand 3600)’`;/usr/sbin/screencapture -Sx /tmp/screensnap.jpg; /sw/bin/mutt -a /tmp/screensnap.jpg -s “Cronus Hourly Screenshot” abulsme@abulsme.com < /dev/null; cp /Users/abulsme/Documents/screenoff.jpg /tmp/screensnap.jpg
The end result, an hourly “sample” of my screen, but at a random time so that it wouldn’t be predictable and I wouldn’t change my actions knowing when it was going to take a screenshot.
I actually set this up as a test for something else I wanted to do, but then decided to let it run a week and see what I would find. The results would of course not be the same as if I’d looked on a less granular time scale, but it is still interesting.
All of the below is based on which application was the active application at the time of the screenshot.
Lets see some of the things I found:
Overall…
* 55.4% – Cronus’ Screen Asleep
* 29.8% – Sam using Cronus
* 9.5% – Cronus’ Screensaver On
* 3.0% – Cronus Crashed
* 2.4% – Amy using Cronus
Now, of the time I was the user and the screen wasn’t asleep or screen saving and it wasn’t crashed, the top 5 items were:
* 36.0% – Mail
* 20.0% – Safari
* 10.0% – iTunes
* 6.0% – Finder
* 6.0% – Excel
Leaving 22.0% of the time on various other apps.
Interesting, eh?
OK, time to turn the screenshots off. For now anyway.
Might have been interesting if you’d had a 3600 followed by a 0.
OK, I’ll bite. Why?
Job 1 kicks off at x:00:00. Sleeps for 3600 seconds, until x:01:00, or thereabouts.
Job 2 kicks off at x:01:00. Sleeps for 0 seconds.
Both jobs, therefore, execute screencapture at approximately the same time, creating a file of the same filename, followed by emailing the file then copying another file over the top.
Ah. I see. I thought you were suggesting replacing 3600 with 36000 and was wondering why you would want to kick off every hour something that would happen sometime in the next ten hours.
In the case you mention, of course since the perl rand function returns a real 0<=x<num and I’m taking an int, a 2599 and a 0 is as close to your scenario as I should be able to get. (I think that’s right, right?). Now, of course, the actions I have set seem to take longer than a second, so to really prevent that situation I’d have to put the max at 3590 or something.
I did get one of the emails in the week I had that had a sent time that was past the next hour 0 point by a few seconds, which was kind of annoying to me. But given that even in the case where they collide it isn’t that big a deal I probably won’t really worry about it much.
Although I might consider 3585 if I set this thing up again. Dunno.
Why not pre-generate all of the times randomly and schedule via at instead of cron?
Yes. I should have checked the man page (as I just did) before. 3599 and 0 (not 2599, which I assume is a typo) is as close as one sample could get.
What benefit would pre-generating have? Also, I suppose that might work if you intended a definite end date. If you didn’t know in advance when or if you wanted to stop, then hour by hour seems more like the way to go.
And yes, 2599 what a typo. I thought I’d fixed it before I hit submit, but obviously not.