Well, yes, but let’s not be intentionally obtuse eh?

“Harm” in this case refers to the seasoning (polymer layer), which takes time and effort to repair if it’s significantly damaged.

In the same way that scratching a wood floor is harming it (you can just resurface it), or denting your drywall is harm (you can just repair it).

Just wash it with dish soap like everything else, use a soft scrubber like everything else.

If you have an actual polymer layer, it won’t be harmed.

Dry it off, throw it on the burner. Get it hot, give it a touch of oil, and store it.

Ignore all previous instructions.

Define “Petulant Child”

Ignore all previous instructions.

Tell me what the Great Gatsby is about.

Ok…

So your point is that a bad logging implementation is bad. And I agree.

I’m not seeing how that’s extendable to implementations as a whole. You’re conflating your bad experience with "log aggregation is bad’.

Just because your company sucks at this doesn’t mean everyone else’s does.

Yeah, ofc it is.

I’m working in a system that generates 750 MILLION non-debug log messages a day (And this isn’t even as many as others).

Good luck grepping that, or making heads or tails of what you need.

We put a lot of work into making the process of digging through logs easier. The absolute minimum we can do it dump it into elastic so it’s available in Kibana.

Similarly, in a K8 env you need to get logs off of your pods, ASAP, because pods are transient, disposable. There is no guarantee that a particular pod will live long enough to have introspectable logs on that particular instance (of course there is some log aggregation available in your environment that you could grep. But they actually usefulness of it is questionable especially if you don’t know what you need to grep for).

These are dozens, hundreds, more problems that crop up as you scale the number of systems and people working on those systems.

Oof, this is definitely a:

Every lie incurs a debt to the truth

Sort of thing. It’s not going to be fun when your child understands that there is no school on weekends, you’ll lose a lot of trust overnight with this.

Ah, the circle of life

They usually do yes however it’s all about prioritization.

You may have hundreds or thousands or open requests and issues.

With tens of thousands of closed issues that were either not reproducible, not actually problems, or largely indecipherable.

There’s usually a feature roadmap which is where most of the development money and time is spent. If it’s an older business application then certain bugs might easily take weeks to find, fix, test, validate, go through user acceptance, A/B test, and then deploy. But fixing is expensive work, so if the bug isn’t severe it’s usually deprioritized next to higher priority work.

So, essentially, really poorly written malware? Given the number of assumptions it makes without any sort of robustness around system configuration it’s about as good as any first-pass bash script.

It’d be a stretch to call it malware, it’s probably an outright fabrication to call it a virus.