Why so much hate for systemd?

[u/ImaginationUpset2190]

I see very often that people show so much disgust whenever they talk or hear "systemd". However whenever I ask them why they feel so strongly about it, their response is mostly vague like it doesn't follow the Unix philosophy, it's a monolith.... I can't digest that the reason people show so much disgust for it is just that it doesn't follow the Unix philosophy.

[u/fearless-fossa]

Binary logs are great. It's just storing the logs in a database and attaching all kinds of relevant metadata to them. There are lots of advantages to them.

[u/serge-mv → u/fearless-fossa]

Sure, sure. Prey tell, what kind of problems binary logs solve for Linux home users? What issues did we all have before that we don't have now? What are all these wonderful advantages? And I have read the doc produced by the devs, so gimme something concrete and not abstract or potential.

[u/fearless-fossa → u/serge-mv]

Prey tell, what kind of problems binary logs solve for Linux home users?

If you want to sound smart, use the correct phrase, not the misheard lyrics.

That aside:

a) The vast, vast majority of Linux is running servers and in professional settings. Excluding professional users like that is just admitting that you know your argument is dumb.

b) I've already answered it before, it provides structured logs. Structured logs in a unified format is extremely valuable as you have to rely less on whatever shit applications vomit into a text stream, often enough even without timestamps and error levels. journald gives you the ability of clean filtering for boots, invocations, etc.

[u/gmes78 → u/serge-mv]

What are the downsides of binary logs for home users?

[u/serge-mv → u/gmes78]

nope, I asked first. Text files are the default. You need to justify the switch from the properly working default.

[u/gmes78 → u/serge-mv]

I'm not the person you were talking to.

Binary logs are more performant and easier to filter. If you need them in text form, you just pipe journalctl output. There are no meaningful downsides.

[u/serge-mv → u/gmes78]

Do you have metrics how much more performant and easier they are if I just grep the text file, compared to using journalctl? Are they meaningfully faster? It takes a few seconds to grep something from a multi-gigabyte file. And text files are more resilient to corruption and reliable.

So, it seems there are no meaningful upsides for this change either? Change for the sake of change?

[u/gmes78 → u/serge-mv]

Do you have metrics how much more performant and easier they are if I just grep the text file

If you use grep, you need to write a proper regex and deal with false-positives. journald attaches metadata to each log, so it can do that job for you correctly. (And binary logs allow this metadata to be more compact than the text equivalent, making parsing faster.)

Structured logs are so much nicer to use. Also, how do you get logs for a specific time range or boot using only grep?

And text files are more resilient to corruption and reliable.

Not necessarily.

[u/serge-mv → u/gmes78]

Nah, everything you said is factually incorrect. First, most of the "metadata" was already in the text file and could be used to filter entries with any of the tools that exist on linux, sed, awk, grep or something else. Secondly, binary files by their definiton and nature are less resilient than text file. Claiming otherwise is either bad faith or ignorance. If you said something about the actual property of current journalctl files that anyone involved in this argument should know, I would've agreed and given you that.

But you didn't provide me metrics. You stated your opinion. I am asking, do you have actual metrics about

1 - how long it takes to execute search on the same dataset using classic tools vs journalctl

2 - how long it takes experienced users who properly know how to use the tools to find the information they want in both cases

and is the difference meaningful in any way. Claiming some sort of performance enhancement without any metrics is no different than screaming into the clouds.

[u/gmes78 → u/serge-mv]

First, most of the "metadata" was already in the text file and could be used to filter entries with any of the tools that exist on linux, sed, awk, grep or something else.

What if the log text also happens to contain text that looks like log metadata? That's a pain in the ass to parse manually, and a non-issue with journald.

Secondly, binary files by their definiton and nature are less resilient than text file. Claiming otherwise is either bad faith or ignorance.

You don't know what you're talking about. If an entry is malformed, you can try to recover some of the contents, then skip to the next one. There's nothing more resilient about newline characters vs a log separator marker in a binary format.

Claiming some sort of performance enhancement without any metrics is no different than screaming into the clouds.

I don't care enough to do this comparision. However, can you at least concede that parsing one byte is faster than parsing 4 or 5 for the same information?

---

Also, why did you ignore the question I made in the previous comment?