I have heard of several cases where Siemens technicians and support staff would use a well-known "crack" (actually more of a keygen combined with license file manager) or guide customers how to obtain and use it...

Remember, legally (usually), the really important part is the proof of contract and payment, not exact way the software was activated

DEC didn't try to parallelize the decoder further because it already could face 56 bytes for a single instruction, and the NVAX design was costly as hell. x86 in comparison has limit of max 15 bytes per instruction, and most instructions in x86 code fall in 4 bytes

[1] Not because of often-called "risc like" microcode engine, but because the most complex addressing mode on x86 usually decodes two microinstructions, and decodes in single cycle. In comparison VAX needed separate pipeline for instruction decoding.

It tries to optimize on disk footprint by deduplication and resulting in way more complex file format with many possible footguns leading to things like write amplification while also making it less robust for the actual use cases of a persistent log.

In a way, it's using a file format more useful for aggregation layer, except it doesn't do that well either, compromising immediate needs at local level.

On LKML you might get cursed out, but if your fix is solid fix, it has high chances of getting through. Regardless of how true it would be in reality, the atmosphere created by upstream is that I do not expect the same with journald unless you convince redhat management

Honestly, the few times I went into systemd source (to deal with how they didn't document some critical information without which I couldn't ensure coexistence of other software, software needed for functionality systemd didn't expose), I found it a total mess - combined with very loud and explicit ways the decision of the "stewards" were defended by the team, I would be frankly wary of trying to contribute anything non-trivial.

Might take more space on disk than theoretical best of journald storage format with its absurd hashtables, but it fulfills the job of system log better and more complex format should be done in log aggregation layer.

[1] Happened few times, I think RedHat as a whole even got banned from sending changes for a short while

Also, a lot of the problematic issues are related not to fixing the local code, but dealing with stuff like external systems or pre-existing legacy data that you need to be able to read back after 30 years from cold storage.

I am not again binary logs, or logs in a database. It's just yet another time I deal with good ideas implemented horribly, horribly badly when it comes to systemd.

Just like with the previous AI Winter.

(and all self-aware)

Sometimes the transponders will be faulty, sometimes you have to direct a broken aircraft safely to the ground with no transponder available.

And sometimes you are doing ATC for a zone that does not, in fact, require transponders (those are required only for the strictest controlled zones, not in general)