3 ms·

This style of argumentation is annoying because you're not even participating, you're looking for reasons to dismiss. A sane system doesn't need a whole lot ju

This style of argumentation is annoying because you're not even participating, you're looking for reasons to dismiss. A sane system doesn't need a whole lot just to check logs. LVM and LUKS are different due to cryptographic needs. systemd meanwhile has little reason to store logs in binary format. The promises that are alleged are not concerns to anyone except enterprise.

dale_glass 3y ago
> This style of argumentation is annoying because you're not even participating, you're looking for reasons to dismiss. I just don't buy the problem as legitimate. It's an aesthetic problem, not a real problem. Sysadmins clearly have no problem with the fact that XFS is not a human readable format, or I don't recall anybody making a stink about using Berkeley DB for a whole bunch of stuff. > systemd meanwhile has little reason to store logs in binary format. Quite a few actually. Indexing, transparent compression, clear storage of arbitrary amounts of data with well delimited fields, quick seeking. Makes for a compact and very well performing system. You can't quickly seek a .gz text file, while journald will tell you what happened a week ago at 3 AM in a few ms. > The promises that are alleged are not concerns to anyone except enterprise. Or people who realize there's a bit more to logs than 'tail' and 'grep'. Eg, journald trivially will give you a log from a given timeframe that interleaves the logs of a proxy, httpd, database and application server, actually producing a log in which a request can be logically followed through the different services it went through, with timestamps in microseconds. In an application that's designed for it, you can actually ask for logs regarding to a given host, user, etc. If you've ever done log parsing, well, now you don't need to ever write a regex to split a .log by fields, because that was already done for you, and you can have UNIX timestamps directly instead of doing date parsing.

dale_glass 3y ago

> This style of argumentation is annoying because you're not even participating, you're looking for reasons to dismiss. I just don't buy the problem as legitimate. It's an aesthetic problem, not a real problem. Sysadmins clearly have no problem with the fact that XFS is not a human readable format, or I don't recall anybody making a stink about using Berkeley DB for a whole bunch of stuff. > systemd meanwhile has little reason to store logs in binary format. Quite a few actually. Indexing, transparent compression, clear storage of arbitrary amounts of data with well delimited fields, quick seeking. Makes for a compact and very well performing system. You can't quickly seek a .gz text file, while journald will tell you what happened a week ago at 3 AM in a few ms. > The promises that are alleged are not concerns to anyone except enterprise. Or people who realize there's a bit more to logs than 'tail' and 'grep'. Eg, journald trivially will give you a log from a given timeframe that interleaves the logs of a proxy, httpd, database and application server, actually producing a log in which a request can be logically followed through the different services it went through, with timestamps in microseconds. In an application that's designed for it, you can actually ask for logs regarding to a given host, user, etc. If you've ever done log parsing, well, now you don't need to ever write a regex to split a .log by fields, because that was already done for you, and you can have UNIX timestamps directly instead of doing date parsing.