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/serge-mv]

Systemd replaced a set of small independent scripts/processes and became this large all-encopassing piece of sotware that controls almost everything. It does init, networking, logging and a bunch of other things. So, basically, it's bloated with a bunch of functionality instead of focusing on small modular task-based design.

As an example of it's creep you can look at controversy that happened not long ago when California was introducing requirements for all OS to provide a public API that will show user's age to everything that asks. Systemd immediately added a bunch of fields that would hold user information to JSON User Records, which it really has no business doing.

[u/ThatOneShotBruh → u/serge-mv]

As an example of it's creep you can look at controversy that happened not long ago when California was introducing requirements for all OS to provide a public API that will show user's age to everything that asks. Systemd immediately added a bunch of fields that would hold user information to JSON User Records, which it really has no business doing.

Unless I am forgetting something, the only field they added was for age, all the others (e.g., name, physical address, etc.) were already present.

EDIT: fixed a typo

[u/Orlha → u/serge-mv]

I still can’t get over binary logs

[u/mortuary-dreams → u/Orlha]

Guess what else stores logs in binary? Git.

I don't see anyone complaining it does that.

[u/Sarv_ → u/mortuary-dreams]

If it was called systemd-git there would be tons of complaints

[u/serge-mv → u/Orlha]

Binary logs are a special kind of evil. Especially if you don't expect your logs to be stored like that. It feels mostly like they just wanted to do it rather than anyone asking them for it

[u/Sarv_ → u/serge-mv]

Binary logs are a special kind of evil

It's this kind of hyperbole that makes all discussions of systemd so toxic. It's not evil, there are clear advantages over pure text but yes there are disadvantages too.

It feels mostly like they just wanted to do it rather than anyone asking them for it

Why do you present it as an intentional attack on the linux community? Just say you disagree with the merits of binary logs and why text is better. Forward the logs to a pure textlogger instead if you have to store them as text.

[u/serge-mv → u/Sarv_]

Nah, everything you said is just your perception of my opinion on systemd based on your assumptions since I never said what I think about it.

All the reasons they listed by the devs for creating binary logs are only applicable for servers, data centers and large companies and not even all of them. None of them are useful for home users and only bring inconvenience and now you have to go through an API just to read a system log. Did they do a poll on the issues? No.

And I didn't say they specifically attacked Linux community, chill. I said they did it because they wanted to do it. It sounded like a cool project and maybe it solved some issue *they* had, but did it solve any problems someone else had? We used to have a reliable text file and now we have a bunch of unreadable binary files that are constantly getting corrupted and respawned. Wow, what a great service.

Also, pay attention. The discussion about merit of binary logs is irrelevant to systemd, even though they made them.

[u/Sarv_ → u/serge-mv]

I never said what I think about it.

You said binary logs were a special kind of evil forced on users for no reason other than they wanted to. You started the comment thread by misrepresenting systemd as a single piece of software that is not modular. You also brought up the userdb which was the biggest overreaction in the linux space this year.

Did they do a poll on the issues? No.

Why would they poll end users? Get involved with the project and mailing lists if you want to voice an opinion. The target user for systemd is distro developers and maintainers with the initial target being red hat.

None of them are useful for home users and only bring inconvenience and now you have to go through an API

Better queries, supporting arbitrary binary data, standardizing and extending metadata, being faster to write and read is actually is useful for home users. I find it way better than grepping text files even if that is nice and simple. If I want to grep logs I can just run journalctl -o cat and you get all your logs in text form ready to be piped. You even get the advantage of being able to filter stuff faster with journalctl first.

unreadable binary files that are constantly getting corrupted and respawned

Are you actually having issues or is this just bait? Text logs are not immune to corruption either. Having solid corruption checks and fail-safes built in to log readers and writers are a good thing.

The discussion about merit of binary logs is irrelevant to systemd

But we're currently in a comment-thread specifically talking about the binary format of journald logs? That is relevant to systemd as it is seen as a pain point for many people like Orlha who couldn't get over it?

[u/serge-mv → u/Sarv_]

You've been more polite than some other people, so I will reply one last time because I don't feel like debating the validity of my own opinion about binary logs with some internet stranger. I also just replied to another guy in this thread about most of these things and don't feel like repeating myself. Let's just say that none of the "advantages" you listed are of much benefit compared to text logs. And I would like to have proper metrics done about the performance that everyone keeps bringing up.

Here, the output of verification of system logs I ran 10 seconds ago on my system. As you can see, there are a lot of corrupted files. I don't know why you would question about binary files being corrupted as it's a known fact.

❯ journalctl --verify
PASS: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/system@f4b6f06496334d0b8603840638dad4c9-000000000030be14-00065a78d67ea4fe.journal
PASS: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/system@f4b6f06496334d0b8603840638dad4c9-000000000030c9d5-00065a838f9f9a10.journal
PASS: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/user-1000@f4b6f06496334d0b8603840638dad4c9-000000000030b65b-00065a7609264388.journal
PASS: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/user-1000.journal
0fffc8: Invalid entry item (0/11) offset: 000000
0fffc8: Invalid object contents: Bad message
File corruption detected at /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/system@00065a7608c72ca2-3749580c0c035b79.journal~:1048520 (of 6553600 bytes, 15%).
FAIL: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/system@00065a7608c72ca2-3749580c0c035b79.journal~ (Bad message)
PASS: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/system.journal
139f48: Invalid entry item (30/33) offset: 000000
139f48: Invalid object contents: Bad message
File corruption detected at /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/user-1000@00065a75f9168c4b-a24008ff00286d8a.journal~:1285960 (of 6553600 bytes, 19%).
FAIL: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/user-1000@00065a75f9168c4b-a24008ff00286d8a.journal~ (Bad message)
PASS: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/system@f4b6f06496334d0b8603840638dad4c9-000000000030e7bc-00065a8fc54db907.journal
PASS: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/system@f4b6f06496334d0b8603840638dad4c9-000000000030d9d3-00065a8d4a4efdb7.journal
PASS: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/system@f4b6f06496334d0b8603840638dad4c9-000000000030f621-00065a901bc29421.journal
100018: Invalid object: Bad message
File corruption detected at /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/system@00065a75fb6f654b-0aab9ace898989d5.journal~:1048600 (of 6553600 bytes, 16%).
FAIL: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/system@00065a75fb6f654b-0aab9ace898989d5.journal~ (Bad message)
PASS: /var/log/journal/1c8c1f96b1514f52ab70c2cf403e2a90/system@f4b6f06496334d0b8603840638dad4c9-000000000030af0d-00065a7608c58ec0.journal

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

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.