Thanks for the suggestion. I know little about BSD other than running some specialized distribution on a short lived file server I put together from spare parts.

To be honest, OpenBSD is the one that grabs my attention the most, and probably my first refuge if the seas of Linux ever get tainted enough to become unnavigable.

The solution here is JSON formatting, which is a popular convention for structured logs (and makes ElasticSearch integration a snap). This allows for arbitrarily complex encodings, while still being human-readable, and there is a diverse and open ecosystem of tools available for formatting / filtering / transforming / searching JSON (ranging from good old grep, head/tail to jq, json2json, ES, etc).

There is no good reason for binary logs.

1 members found this post helpful.

Text logs are meant to be simple, and I really haven't seen many that were unreadable by either a human, or some sort of parsing mechanism. There are exceptions for unnecessary use of the carriage return escape sequence, emitting DOS style line terminators, or using stdout instead of stderr, or vice versa. I think those are oversights by the programmers, and their responsibility to fix.

As I've said, I'm mostly speculating as I haven't had to implement this for anything important, but I don't quite see any good reason for binary logs, or binary configuration files. To the best of my knowledge, this has primarily been used to obfuscate things, or make them unreachable. Much like the Torx screw.

I'm sure this does not apply here, since the code is all Open Source (c), and must be trustworthy.

Better get rid of the kernel, hardware and the future; all fear the binary!

01100110 01100001 01100010 01100101 01110010 00100000 01100101 01110011 01110100 00100000 01110011 01110101 01100001 01100101 00100000 01110001 01110101 01101001 01110011 01110001 01110101 01100101 00100000 01100110 01101111 01110010 01110100 01110101 01101110 01100001 01100101

Add: or, https://www.crowdsupply.com/sutajio-kosagi/novena

I wasn't talking about binary code/executable code/executable files/shared libraries/etc, I'm talking about binary logs and I agree with ttk. Binary log files are not human readable, full stop.

Which character set? UTF-8 or bust!

No 7th bit in any of the values, so probably not.

Nah, I'm not gonna look that up, lol. Must not... I refuse to...

Quote:

People tend to forget that text files ARE A BINARY FORMAT.

End the data-base, smash your computers... maybe use "Ray's Rule of Precision:"

Better yet a tinfoil hat!

That statement is accurate, but if you would like to claim otherwise, be my guest.

Alright, I've gotten a few comments about the binary string, so I'm going to elaborate on this:

My point, albeit tongue-in-cheek, was that each character set, by necessity, assigns different values to its characters. Some can have different values for a given alphanumeric character, and some can have characters that are not even in alphabetical order.

I am fully aware that the message posted was in ASCII, which, if you are using Ubuntu or Fedora, or just about any modern distribution, is *not* the default character set installed on your system, ironically enough.

Say you have a file with the executable bit unset. You could interpret any byte within as a character, as an integer, as part of an integer, as a floating point value, as an opcode, as a pseudo-opcode meant to be run inside a virtual machine as part of a DRM scheme, etc. 0x30 might be '0'. It might be something else entirely.