Possibly Useful

an occasional series of items
too large to be throwaway
too small to be projects
whimsically described
freely licensed
unlikely to be revised

A simple ritual for laying to rest domestic ghosts

In honor of the feast of All Souls, I thought I might put on a costume, as it were, and write a blog post as if I were an old English cunning man and you, my readers, came to me for advice on supernatural problems, rather than computational ones.

So your house is haunted. You don’t know who the ghosts were in life, and you’re maybe a bit scared to find out, but you would like to gently encourage them to let go of their troubles and move on. I have for you a simple ritual involving a little of the old rune-magic.


Using GPG2 with a read-only .gnupg directory

Another bulletin funded by the I Just Blew An Entire Morning On This Foundation:

Suppose you want to encrypt and sign files using gpg, but without giving it ownership or write access to its own keystore. For instance, this might be necessary if the gpg process is going to be run from a low-privilege CGI user and you don’t have root privileges on the webserver. This is relatively straightforward with the classic version 1, although there’s an error message that’s harmless but impossible to suppress, but version 2 made some architectural changes that make it harder, and does not document the necessary tricks. Below the fold, how you do it.


Do not do business with Northwest Talent Search

A depressing number of computer industry recruiters cannot be bothered to read the very first paragraph of the contact information page of this very website, or else they think they are ~special snowflakes~ and it does not apply to them. For reference, this paragraph reads


I get unwanted solicitations about once a month, and I reply with a polite but acerbic note about how they should’ve noticed the paragraph in ALL CAPS that says don’t contact me, and usually that’s the end of it. Not this time.


Operating system selection for $PROJECT, mid-2015

Presented without context, for amusement purposes only, a page from my notes:

FreeBSD NetBSD Linux
Per-process default route Poorly documented,
possibly incomplete
Probably not Poorly documented,
Can compile PhantomJS Probably Probably Yes
Jails Yes No Not really
Xen paravirtual guest Incomplete Yes Yes
System call tracing truss None? strace
pipe2 Yes Yes Yes
closefrom Yes Yes No
sysctl Yes Yes No
getauxval No No Yes
signalfd No No Yes
execvpe No Yes Yes
Reference documentation Acceptable (YMMV1) Acceptable (YMMV) Major gaps
Tutorial documentation Terrible Terrible Terrible
Package management Broken as designed Broken as designed Good
System maintenance automation I can’t find any I can’t find any Acceptable
QA reputation Excellent Good Good
Security reputation Good Good Debatable
Development community Unknown to me Unknown to me Full of assholes

1 It makes sense to me, but then, I taught myself Unix system programming and administration by reading the SunOS 4 manpages.

Programming languages and transportation

Last week there was a gag listicle making the rounds entitled If programming languages were vehicles and I lol’d along with the rest of them, but then I kept thinking about it and a bunch of the entries just seemed to miss the mark. And I’m in a silly sort of mood, so here is MY version: slightly different language selection, just as opinionated, 100% more Truth™.


flex: input scanner rules are too complicated

If you get this error message, the Internets may lead you to believe that you have no option but to change magic numbers in the source code and recompile flex. Reader, it is not so. Try the -Ca option, before doing anything else.

No, I don’t know why an option that’s documented to be all about size/speed tradeoffs in the generated, DFA, scanner also has the effect of raising the hard limit on the number of NFA states (from 32000 to about 231), but I already feel dirty just having looked at the code enough to discover this, so I’m going to stop digging while I’m ahead.

More Notes on the Cross-Platform Availability of Header Files

You may recall a month and a half ago I posted Notes on the Cross-Platform Availability of Header Files and then promptly had to take most of it down because it was insufficiently researched. Well, the research is ongoing, but I’ve got a shiny new set of results, some high-level conclusions, and several ways Viewers Like You can help!

First, the high-level conclusions:

  • Except perhaps in deeply-embedded environments, all of C89’s library is universally available.
  • Code not intended to run on Windows can also assume most of C99 and much of POSIX. The less-ubiquitous headers from these categories are also the less-useful headers.
  • Code that is intended to run on Windows should only use C89 headers and <stdint.h>. If MSVC 2008 support is required, not even <stdint.h> can be used. (Windows compilers do provide a small handful of POSIX headers, but they do not contain the expected set of declarations!)
  • Many different Unix variants ship a similar set of nonstandard headers. We don’t yet know whether the contents of these headers are reliable cross-platform.
  • There is a large set of obsolete headers that are still widespread but should not be used in new code. This is underdocumented.

The full results may be seen here: https://research.owlfolio.org/header-survey/
The raw data is here: https://github.com/zackw/header-survey/

If you want to help, we need more inventories (especially for OSes further from the beaten path), and I’m also very interested in improvements to the giant generated HTML table. Y’all on Planet Mozilla can probably tell I’m not a Web designer. If you are an old beard, there are also places where I’m not entirely sure of my methodology – see the README in the source repo.

Notes on the Cross-Platform Availability of Header Files

These header files are guaranteed to be available in a C89 hosted environment. All interesting portability targets nowadays are C89 hosted environments (bare-metal environments are still relevant, but not as portability targets).


Beyond C89, interesting portability targets divide into three classes. Complete Unix environments are always compliant with C99 and POSIX.1-2001 nowadays, but not necessarily with all of the optional modules of the latter, nor with any more recent standard. Windows has several different competing C runtimes, some of which offer more C99 support than others, and none of which are at all conformant with POSIX. Finally, the major embedded environments are presently all cut-down versions of a specific identifiable complete Unix or of Windows. Those that are derived from Unix usually have most of the POSIX headers but may be missing a few.

EDIT: Everything after this point in the original version of this post was insufficiently thoroughly researched and may be wrong. Corrected tables will appear Real Soon. If you are interested in helping me with that, please see https://github.com/zackw/header-survey.

Making OSX Emacs less broken

If you find that Emacs on OSX fails to pick up the same $PATH setting that you get in command line shells, instead defaulting to an impoverished default that doesn’t include (for instance) anything installed via MacPorts:

(add-hook 'after-init-hook
         #'(lambda ()
             (setenv "PATH"
                 (call-process "/bin/bash"
                               (list (current-buffer) nil)
                               "-l" "-c" "printf %s \"$PATH\"")

I am only embarrassed that I put up with the brokenness for as long as I did.

test your file locking


Do you suffer from mysteriously hanging autotools processes? Or perhaps other mysteriously hanging processes? If so, you may have a problem with your file locking, and the IJWAHOT Foundation recommends you compile and run this program on the computer with the problem, preferably under strace or equivalent. If it, too, hangs, then you do indeed have a problem with your file locking. The Foundation does not presently know the cause of this problem, but we suspect that it is NFS’s fault somehow. If you do know the cause of this problem, we would love to hear about it in the comments.