Hacker News new | ask | show | jobs
by gatlin 371 days ago
> good tooling

My completely oblique, binary logs disagree. It won because it solved problems companies with money needed solved. There is no indication that it succeeded on merit.

3 comments

There are pros and con with binary logs. One isn't magically better.

The tools they have for their logs are pretty good, and its incredibly easy to disable, if you do, you will never notice a difference.

Helping engineers solve technical problems is not 'success'? Its only 'success' if open source nerds use it in their basement to run on an old sun workstation? What kind of dumb logic is that?

Why do you think Linux sees so much development?

Logs that I can read are objectively better. I must assert that point because it is true.
Ths only issue that non-human readable log storage has caused is the endless nagging on forums. Literally never been an issue besides.
literally has, or there would be no "nagging". I have yet to experience a benefit for those binary logs
I'm interested in your idea that "merit" is some sort of objective measure.

If it works for me but not for you, does it have more merit?

Some anecdotical evidence of mine. I tend to kill -9 Firefox or derivatives before system, or browser updates, to reliably get my tabs and cookies (for selected sites) back, without the need for any extensions.

Usually I'm doing that from within htop, or btop++. Under systemd that is slow, the process-tree of FF takes several seconds to vanish.

That felt very wrong. I increased the update frequency of htop and btop++ to 200ms (usually they poll/actualize/redraw at 2 seconds only) to investigate.

Then I retested that with Runit/S6(6) on the same systems.

Magic! The process-tree is instantly gone! And if you only SigHup it, it instantly reappears. BAM! BAM! BAM!

This applies to all sorts of process-trees also, not only FF.

Compared to that systemd feels like a sloth.

Yes, Yes, I did that under several different distros, initially AntiX, recently "init diversity edition"(Debian derivative optimized for 'live-booting', running from RAM, in all sorts of 'Frugal' installs), some Arch-derivatives, sometimes 'riced' to the max, and default Debian, just to be sure.

Over several years. Initially on a Core-i7 640LM with only 8GB RAM, more recently on Core-i5 7500t, and Core-i7 7700t with 32GB RAM.

Verdict: systematically slo(w)thified.

Do you think this is any different on more modern systems? Fear not, it gets worse with more cores!1!!