“…for the time being I gave up writing- there is already too much truth in the world- an overproduction which cannot be consumed!” –Otto Rank

His disciples said to him: On what day will the kingdom come? [jesus said:] It will not come while people watch for it; they will not say: Look, here it is, or: Look, there it is; but the kingdom of the father is spread out over the earth, and men do not see it. –Gospel of Thomas Saying 113

“Real poetry doesn’t say anything, it just ticks off the possibilities.” –Jim Morrison

i was getting this error repeatedly on boxes in my home domain. i would set up a system and then, seemingly at random, i would try to ssh to it and it would spout several “/dev/null: Permission Denied” as i tried to fire up an ssh-agent. looking at /dev/null, it showed a file mode of (if i remember correctly,) 600 and owned by root. i had no idea what was even *accessing* /dev/null – i certainly didn’t have any cron jobs set up to alter it. googling the problem didn’t really enlighten me, but i did check my .bashrc scripts and noted that i had set MYSQL_HISTFILE to /dev/null. a-ha! some reports on the web showed that various apps like to set files’ permissions in a sneaky sort of way, so i theorized that perhaps mysql sets the perms on that file to something sensible for a history file (to the detriment of other apps, of course, but mysql isn’t really expecting to write to a file other people will need, anyway. and mysql isn’t suid root, so this is still just a guess.) removing this line seems to work, for now, so hopefully i will have solved this. and hopefully this will have helped you, too!

check out Rising Phoenix Design and the Blackback Web Theory.

i promise i won’t say “i told you so”.

or, check out ecoIron, with their textual analysis of how a Black Google Would Save 750 Megawatt-hours a Year:

As noted, an all white web page uses about 74 watts to display, while an all black page uses only 59 watts. I thought I would do a little math and see what could be saved by moving a high volume site to the black format.

Take at look at Google, who gets about 200 million queries a day. Let’s assume each query is displayed for about 10 seconds; that means Google is running for about 550,000 hours every day on some desktop. Assuming that users run Google in full screen mode, the shift to a black background [on a CRT monitor! mjo] will save a total of 15 (74-59) watts. That turns into a global savings of 8.3 Megawatt-hours per day, or about 3000 Megawatt-hours a year. Now take into account that about 25 percent of the monitors in the world are CRTs, and at 10 cents a kilowatt-hour, that’s $75,000, a goodly amount of energy and dollars for changing a few color codes.

this is something that had been bothering me for ages. i am one of those who keeps virtually all my info in one notes.txt file – no fancy GTD system, just a bunch of text that i noodle with on an ad hoc basis. i use vim to manage it, and it stays open 24×7 on multiple machines (via screen – something i’ll go into another time.)

but, the problem with keeping the window open is that, at least on my fedora boxes, a system cron script comes along once a week and cleans out the /tmp directory — including the temp files that vim is using to keep state in my editing session. this makes me have to save/close/reopen vim, usually when i try to launch some external command like sort.

the solution i found was to touch vim’s temp file daily, making it look like a “new” file to the system cleanup script. vim makes temp file directories in a format like this:

/tmp/v\d??????

so, in my personal crontabs, i use this to ferret these out and touch them up-to-date:

find /tmp -follow -type d -name v?????? -exec touch {} \; 2>/dev/null

works like a charm.

here are snippets from my .muttrc file which allow me to bounce messages to my zimbra server spam / ham mailboxes, for the purposes of training spamassassin. this was taken from Lucas Nussbaum, but his link appears to be down at the moment. i’m including these here in case anyone elses googles “mutt zimbra spam macro“, like i did for a few weeks to no avail.


macro index S "<bounce-message>spambox@mijit.com\nyd" "Learn as spam"
macro pager S "<bounce-message>spambox@mijit.com\nyd" "Learn as spam"
macro index H "<bounce-message>hambox@mijit.com\nyj" "Learn as ham"
macro pager H "<bounce-message>hambox@mijit.com\nyj" "Learn as ham"


these allow you to highlight a message in the index or pager, hit “S” for spam (or “H” for ham,) and the message bounces away to the appropriate zimbra mailbox for automated spamassassin learning. (additionally, the “S” for spam macro marks the message for deletion; the “H” for ham macro simply moves to the next message.) the tricky bit for me was understanding that mutt allows the “\n” newline character to simulate <return> at the end of the <bounce-message> command.

note that you must change “spambox” and “hambox” to the appropriately named mailboxes for your domain. to see what your current spam mailboxes are, issue the following command as the zimbra user:


zmprov gacf | grep SpamAccount


to change these values to something more appropriate to your domain, use zmprov again:


zmprov mcf zimbraSpamIsNotSpamAccount <your ham account>@example.com
zmprov mcf zimbraSpamIsSpamAccount <your spam account>@example.com