And with good reason. I don't know where things are with his software and methods today but, last I heard, djb's software and methods are world class ideas that everyone should be using.
His software creates new top-level directories off root and this simply hasn't found wide acceptance among sysadmins. I've never seen eg daemontools used in the wild for this reason.
Netflix uses daemontools in their BaseAMI[1] for starting up core services such as Apache and Tomcat. I think this choice was originally made to ensure consistency in process startup methods across CentOS and Ubuntu. Support for automatically creating daemontools scripts is baked into nebula-ospackage-plugin[2].
It occurs to me that the configuration-time and maintenance-time "weirdness" of djb's software is a lot less of a big deal if you stick it in a Docker container. I've seen daemontools being used as a container-internal PID1 a number of times.
djb's software is principled and very well engineered, but a document that appeals to MIND-BURSTING POWER OF PURE REASON can't really then turn around and present a faith-based argument for doing something.
Please don't use his ideas about human-unreadable log files...
Look, djb is a damn good programmer and writes some amazing, reliable software. It's just not all that user or admin friendly. I'd go mad in a world where everyone used his 'world class' ideas on software...
I presume you're talking about the use of TAI64N timestamps. Making them human-readable is a pipe to tai64nlocal away.
djb's software is, in fact, quite user and admin-friendly. However, most people simply aren't used to the modular toolkit approach way of doing things beyond basic text processing. The djb philosophy is really the Unix philosophy, and so it comes off as quite shocking to see software written like that when you're used to monolithic blobs.
But there is so much insight to be gleaned that, unfortunately, most people ignore precisely because to them user friendliness means building inflexible kitchen sinks. I especially do not consider the latter to be admin-friendly in the slightest.
It's IMO the wrong way around. Logs should be human-readable without needing a separate program. Computer code can convert a human-friendly timestamp into a more CPU-friendly one with minimal effort. We have these processors that can do it, so why not let them? Why does djb choose to make life difficult for humans?
There are many format and human language you could write the date into. And many timezone.
By putting timestamps in log files, and requiring humans to type a few more keys to transform it when they need to, every one can choose its date format, timezone, and language. So, to me, djb's way is the human-friendly way.
I agree. Further, all kinds of tools use logs in different ways and often need decent CPU power anyway. Making logs efficient & machine-readable by default aids that. It also lets me use lower-cost components for services producing and storing them. This goes same for lightweight, high-performance services like we've seen show up in HTTP. So, instead of one bulky server for several grand I might have several, embedded boards in a H.A. configuration with plenty of memory and storage doing same workload.
So, efficiency still matters today if you're squeezing the most out of your systems or like physical isolation like I do. Easy, portable processing on arbitrary machines, too. Human readable logs can have an impact on that. A nice compromise, though, is stuff like JSON, s-expressions, or a TCL style with abbreviated keywords.
Because it lets the implementation be independently reusable as a filter. Furthermore, there are some caveats about converting TAI64N to localtime, so having the admin be aware is desirable.
Having to pipe a program isn't "making life difficult for humans," I have no idea how you came to that conclusion.
An odd choice of document to back up your argument. I can't think of any unix programs that use anything other than human readable dates and times in their outputs, for instance.
Further, nothing is stopping any implementation be independently reusable, whatever the choice of format. That's an irrelevance.
Essentially, it's not a technical decision. Trying to back up your preferences with tech reasons is besides the point. I just think that anything that makes it more difficult for a person to read the log files is a bad choice. If you can choose who has to do the extra work, human or computer, you should always let the computer do it.
> I can't think of any unix programs that use anything other than human readable dates and times in their outputs, for instance.
Maybe, but look at the date display code in the GNU core-utils for instance, it depends on the locale and everything, not quite minimalistic.
I understand your point but it is inconsistent with the rest of djb's way. It does not mean that it is invalid in general, but that this "human-unreadable" log files in djb's code are actually a good idea in the mindset/framework of djb's code.
Guess you haven't looked into how so much of Linux is migrating the opposite way lately? I get the irrational fear of losing plain text, I shared it too with HTTP/2 (as one example), but the fact of the matter is once you use it for a short duration, you realize it's just as simple and useable.
That's quite some hyperbole, but, well, you don't have to use it. Like the old saw, "Unix is user-friendly, it's just selective about who its friends are."
So in the space of four hours you've gone from "djb's software is, in fact, quite user and admin-friendly" to "[t]he term itself is devoid of meaning altogether?" Talk about moving the goalposts.
No, it's consistent. It's a meaningless dog whistle like "socialism". Depending on your ideological perspective, anyone from a hardened Maoist to a Chicago school economist could qualify, or anything to do with state control whatsoever.
Therefore I'm really flipping your buzzword and using it against you. There are no HIGs for system software, and more often than not "This is user friendly." is a codeword for "I'm biased into thinking this way." It's not a criticism, it's a thought-terminating cliche.
If you have technical criticisms of djbware, that'd be fine. You evidently do not.
(That said, I do think it's generally accepted that system software disobeying you by making policy decisions you have not authorized is not admin-friendly. djbware excels at being mechanism only.)
