syslog doesn't have nearly the functionality that journald + journalctl does. Take a look at journalctl's man page: https://www.freedesktop.org/software/systemd/man/latest/jour...

See also the design rationale: https://docs.google.com/document/u/0/d/1IC9yOXj7j6cdLLxWEBAG...

It's basically comparing an append-only fixed-format text file with a queryable database. Of course the former is going to be more performant on writes.

▲ marginalia_nu 3 hours ago | parent | next [-]

What is the real-world use for these features? Who is this built for?

Modern drives will read data at 500MB/s, sometimes even more. Your log files are approaching tens if not hundreds of gigabytes before a sequential read stops being a viable option. Tinies modicum of partitioning by date and source basically makes it a complete nothingburger.

▲

otterley 2 hours ago | parent [-]

It feels like you didn't read the design rationale, because the use cases and issues are listed therein. Maybe you don't see the value, but that doesn't mean it's not there for others. I certainly find its query features useful.

▲

marginalia_nu 2 hours ago | parent | next [-]

I did, and I still don't get why you would want this monstrosity over a structured append-only log file. If you want to index the data, you can do that when you roll over the file. That way you get the exact same robustness guarantees, without the insane architecture.

Like ultimately it isn't even fast, journalctl is so bad at rendering text that it's approximately still as slow as seeking in a 400 MB .log-file using less.

Anyone with any sort of scale where you actually need indexing immediately drops journald and uses loki or elasticsearch instead. Journald is not even remotely a contender in that space.

	▲	otterley 2 hours ago \| parent [-]
		> Anyone with any sort of scale where you actually need indexing immediately drops journald and uses loki or elasticsearch instead. Journald is not even remotely a contender in that space. That I agree with. I don't personally use journalctl much these days, particularly now that practically everything's a container and all their logs are getting shipped off-host for indexing. But I get why, 14 years ago, it was considered a good idea.

▲

rcxdude 2 hours ago | parent | prev [-]

The point is that ripgrep will give you basically all the same query features just by being fast. A more structured format makes sense, but the indexing is not obviously adding value in most cases.

	▲	otterley 2 hours ago \| parent [-]
		The difference between grep/ripgrep and querying by field is the difference between a full table scan and an index query. Query performance is a very good reason to have databases. ripgrep is certainly fast, but it's still O(N). Doing complete file scans also trashes the OS's buffer cache.

▲ simoncion 3 hours ago | parent | prev [-]

> syslog doesn't have nearly the functionality that journald + journalctl does.

A huge feature list doesn't matter much if the software is bad. Given that journald still irrecoverably corrupts its logs even after all these years and -apparently- suffers from substantial write amplification, I'm gonna stick with my ordinary syslog implementations, thanks.

Also, in regards to your original comment:

> This issue report feels like it ought to be accompanied by a fix.

This smells a lot like the "Don't come to me with problems, come to me with fixes." order that a lot of mid-level and director-level management really loved to make five, ten years back. [0] While this sounds like a hard-charging order and gives the impression that it's bringing much-needed discipline to lazy-ass subordinates, the truth of the matter is that its actual effect [1] is to get people to shut the fuck up about the company's problems. The job of most mid-level and nearly all director-level management is to do inter-organization coordination. Most low-level folks don't come to mid- or director-level management with problems they can solve. After all, if they could solve them, they would... talking to folks in that layer of management is usually a huge drag. Most low-level folks only come to these sorts of folks with issues that require inter-organization coordination!

So, yeah... the only obligation of someone who's reporting a bug is to provide a reasonably well-written bug report accompanied with reproduction instructions and diagnostics that are as clearly written as is reasonably possible. Reporters of performance bugs are under no obligation to suggest how to eliminate the bug... especially not if the project they're reporting the bug against has both paid maintainers and claims it's the infrastructure on top of which all Linux systems should be built. Corporate-backed projects that make such grand claims put themselves in a radically different class than the one that covers hobby or small-time projects.

[0] AIUI, it came out of Google, but my understanding might be incorrect.

[1] ...regardless of whether or not that effect is intentional...

▲ otterley 2 hours ago | parent [-]

Nobody's talking about an obligation here. It's open source, and the maintainer owes non-paying users nothing. So if you want something fixed, it's now easier than ever to get involved in the fix. Nothing more, nothing less.

(Also, I'm not entirely sure this is a bug so much as an inefficiency report. Consumption of storage space isn't a documented or promised behavior, nor is the behavior technically incorrect. It's just wasteful.)

▲ simoncion an hour ago | parent [-]

You: [0]

  Nobody's talking about an obligation here.

Also you: [1]

  If you think you can do better than journald's existing format, propose a new one with tests to prove it.

The fact that you're personally powerless to enforce an obligation doesn't change the fact that you're talking about creating an obligation.

> I'm not entirely sure this is a bug so much as an inefficiency report.

Performance bugs absolutely are bugs... especially when they're in a long-running corporation-backed project that presents itself as the project atop which all Linux systems should be built.

[0] <https://news.ycombinator.com/item?id=49292944>

[1] <https://news.ycombinator.com/item?id=49291746>

▲

otterley an hour ago | parent [-]

Well, I didn't intend to suggest an obligation, more of a best practice or challenge. Please put more faith in my intentions over whatever interpretation of my words you want to make.

Per our Guidelines:

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

	▲	simoncion 36 minutes ago \| parent [-]
		> Please respond to the strongest plausible interpretation... Assume good faith. That's what I did. So, right back at you.