Mirandola's is the oldest source for the ranking of being that I can recall off the top of my head, but the idea is almost certainly even older.

> On man when he came into life the Father conferred the seeds of all kinds and the germs of every way of life. Whatever seeds each man cultivates will grow to maturity and bear in him their own fruit. If they be vegetative, he will be like a plant. If sensitive, he will become brutish. If rational, he will grow into a heavenly being. If intellectual, he will be an angel and the son of God.

- Oration on the Dignity of Man

The reads from /tmp/all.log are almost certainly cached since you just wrote the file, and will basically boil down to a memcpy call, rather than actual disk I/O. Speed difference isn't as big as you would think on a modern SSD, but it isn't nothing either.

Running this between calls should flush the changes to disk and then drop the page cache, making for a fairer test.

$ sudo sync

$ echo 3 | sudo tee /proc/sys/vm/drop_caches

$ man systemd.exec

Though reading the question again, I should have probably linked to the equivalent of

$ man systemd-system.conf

as well, that's where you can set the default behavior across systemd, not per-service as the first man page is.

From a SynthID (or analogous) perspective, it makes a lot of sense you'd see something like this especially in something like a code comment where there's a finite amount of things to say, and it should be said in a terse manner using well defined language. The room for poetic flourish is very small, so you get... 'substrate' or 'verdict' or 'firmament' or whatever else it's using these days.

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.

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.

Had a process quietly in a crash loop for a solid month on my workstation until I figured out what was causing my random network outages.

You can read them with DuckDB, but you don't end up with O(log n) writes -- which is, to speak plain English, batshit fucking insane for a system logger.

What those cursed writes buys you is O(log n) reads, but there's just no scenario that is necessary. If you have literally any time or subsystem constraints, parquet's predicate pushdowns means you get plenty fast access even with a full scan.

See StandardOutput= and StandardError=.

> Performance: journal operations for appending and browsing should be fast in terms of complexity. O(log n) or better is highly advisable, in order to provide for organization-wide log monitoring with good performance

> Minimal Footprint: journal data files should be small in disk size, especially in the light that the amount of data generated might be substantially bigger than on classic syslog.

This is a bit idealized. In practice copying data is not quite accurate (especially in bulk) and bit-rot is a very real phenomenon, both in flight and in storage.

You sometimes encounter it when dealing with files from the early '00s, it's very common to discover a few of them are corrupt, even if they've only ever been copied between harddrives.

In the same circumstances a light beam stops producing an interference pattern in the Young experiment, quantum wave functions do as well. This is pretty easy to derive, just introduce a random phase shift term, and average across it, and the interference pattern disappears and a bell curve emerges instead.

Almost anyone can put together a basic search engine in a few thousand lines of code, it's just not very hard to make a program that will index a few million documents better than Confluence.

Then, between that first ansatz and a working scalable internet search engine, you have a pile of interesting problems touching every aspect of computer science and computer hardware and networking, enough so that hundreds of people will have gotten PhDs in narrow sub-problems of those problems you'll be facing.

It's great because you can just tackle the stuff you feel comfortable approaching and leave the rest for later.