please allow me to clarify that the following snide, grumpy article discusses “daemontools,” DJB‘s free-software utilities for managing unattended processes, aka “daemons”, under UNIX environments.
It’s not at all about “DAEMON Tools Lite” which is some kind of DVD-ROM emulator for Windows sufferers. I, having never used “DAEMON Tools Lite”, am unfit to pass judgment, except maybe upon the name “DAEMON Tools Lite,” which does actually suck a lot. In three words the authors have managed to combine a tacky spelling, a capitalization crime and a copyright infringement, while neglecting to describe their product even slightly. I suggest a re-name to “SNUGGLER Ultra Supreme Cock Matrix DVDMAX!!!” for at least some slight improvement.
anyway, on with the snide grumpiness ….)
msl runs on free software. one of our main sources of free software has been Daniel J. Bernstein, the obsessively secure author of our favorite MTA, qmail, and our favorite domain name server, djbdns.
if you follow djb’s instructions for installing djbdns, you’ll be led almost automatically to install the third major piece of djb technology, daemontools. daemontools is djb’s answer to various bugs and complaints with time-tested Unix components such as init and inetd. it includes a system for running daemons and other always-available services under Unix.
you can read what’s good about daemontools here. to read what sucks about daemontools, you’ve come to the right place.
things that suck about daemontools:
1) needing to be in a certain directory to run the command? user-interface error of the first degree.
2) no command-line help? no man pages? no coherence to any well-known online documentation system. clearly, djb hates them all and plans to write something better, but he hasn’t yet, but he’s suggesting people use his software blind, without docs. not a problem if you have a web browser. i didn’t. my whole network was down due to dns failures, and i had console-only access to a server with no x-window interface, just a single screen. this made bugs #1 and #2 extremely severe bugs; like putting a bag over my head and shackling my leg to a tree.
apparently DJB endorses HTML docs over man pages; he says web browsers are more evolved than ROFF readers, although one of those standards is twenty years older than the other.
if the interface to the software is command-line, then the interface to the documentation should be too. if ‘svc –help’ just listed the cryptic argument options of svc, i’d be an hour younger.
3) assumes a lot of low-level knowledge of unix file management. it requires shell commands for administration, instead of its own administration interface. djb says this is easier to automate;
editing config files is hard to automate. perhaps so. but if it’s so easy to automate, why isn’t it automatic?
4) envdir falls over with a confusing, useless error message when a directory is accidentally created in an env directory. since daemontools invites, requires even, users to be creating both files and directories within its labarinthine directory structures, it should tolerate exactly this kind of user error, and explain its own errors clearly and humbly.
5) then there’s the difficult to search nature of his documentation itself, but clearly that’s not his strong point. i mean, i enjoy the terseness and the smugness, but it’s just not welcoming to the reader. his headings in the djbdns section are a random list of thoughts.
6 ) his departure from unix logging is pointless. put your logs in a file, in a log directory. rotate that log however you like. give it a human readable name, not some hex code. likewise, put the date in a human-readable form. i have no problem with being y10k compliant, but do it in a human-readable way. log files are read by humans. nobody wants to go hunt for a special log file decoder ring just to read djb’s log files, esp given bugs like #4 (unclear error messages.)
tho i must admit i was stoned at the time. but what i’m looking for is an error message like:
“envdir is trying to read all the files in DIR, but one of those files is a directory, which is not allowed, and, though perhaps i should just try to ignore this problem as best i can, i refuse to do so on principle. ergo, i must die. farewell.”
9) in general: djb desires that sysadmins twiddle around in his maze, but his maze is full of twisty, turny passages, all different. the advantages of a single configuration file become painfully obvious; humans navigate documents more easily than filesystems.
he demands that they learn a new command for every single way they used to do something before. the ui compatability with initscripts or any other comparable system is nil.
really the ideal interface to manage a daemontools/djbdns/qmail installation is a windows file explorer. and that just ain’t right. bind has horrible config files, but just a few of them.
(now, having said all that, i really don’t mean to be complaining about daniel j. bernstein. he’s a great guy. my complaint is with this sofware. alas, his personality and his software are so deeply related in my mind that i began with technical complaints and now i have all but accused djb of plotting to kill my cat. sorry. sometimes i just get upset.)
just about all of these complaints come down to a central user interface problem: daemontools hasn’t got one. this is a classic example of what unix-haters hate about unix. the integration of the technology with the user is left as an exercise for the user. what’s odd to me is that qmail and djbdns are both, along with their other advantages, much easier for a sysadmin to grok, configure and live with than the respective dinosaurs they set out to slay. (sendmail and bind, respectively.) their UIs are chief among my reasons for using them.
however, the technologies that daemontools hope to usurp (initscripts. inittab, inetd, etc.) aren’t dinosaurs at all — they’ve been evolving as UNIX has evolved, and these days can answer most of djb’s complaints about them.