5 ms·

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 mor

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?

vezzy-fnord 11y ago
http://harmful.cat-v.org/cat-v/unix_prog_design.pdf http://harmful.cat-v.org/cat-v/unix_prog_design.pdf 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.
- joosters 11y ago
  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.
  - p4bl0 11y ago
    > 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.
p4bl0 11y ago
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.
- nickpsecurity 11y ago
  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.
jsjohnst 11y ago
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.

vezzy-fnord 11y ago

http://harmful.cat-v.org/cat-v/unix_prog_design.pdf http://harmful.cat-v.org/cat-v/unix_prog_design.pdf 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.

joosters 11y ago
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.
- p4bl0 11y ago
  > 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.

p4bl0 11y ago

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.

nickpsecurity 11y ago
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.

jsjohnst 11y ago

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.