UEFI was not designed with security as a priority (that is, in UEFI, security is an advertising point, not a security point). Compare the design methodology to OpenBSD software.

The result is that there are guaranteed to be other high severity vulnerabilities, not yet found, in UEFI. Your network/system design should take that into consideration, and not rely on UEFI being secure.

If your system does rely on EUFI being secure, then it's not secure.

Good point.

But if any two issues are related in some way, I would suggest that by force, those issues have more than one dimension.

Oh, along those lines, it's well reported that Hyundai used systemd in recent models of their Tuscon braking system, Samsung used systemd in the Galaxy Note 7, that Toyota used systemd in their 2009-2011 accelerator systems. In addition, GM is rumored to be using system in their recent models of Cadillac, Chevy, and GMC; especially in the braking system.

Systemd makes an explosion everywhere it is used. It keeps the old rust off the tires.

Because it is a tool aimed at distro builders. It does the things they want. That doesn't mean it's good design, and it doesn't follow the Unix way.

Lennart Poettering kissed distro builder's asses until they included his tool. Once he got it in, he did whatever he wanted.

Literally every monolith ever is a collection of smaller parts.

Your example proves you don't understand monoliths. For example, it is perfectly possible to use Google Maps without using Google search, even though they are both part of the same monolith. "using" and "not using" aren't what determine a monolith. What determines a monolith is improper separation of concerns, and that is a design mistake made by systemd.

Systemd is a monolith.

It is illogical to try to fit everything into a single-dimensional left/right framework.

Literally every issue has its own dimension, and probably more than one dimension.

You can copyright the prompt.

That's why...if you are thinking of sending me an AI email, please just send me the prompt. It's protected.

Ok, you have a hypothesis, that the AI made your code faster.

Did you collect any evidence to back this up? Or did you approach it from a 'faith' perspective?

I didn't understand the summary.

This is the example that helped me understand what they built. It's a framework for benchmarking different configurations. If you want to know whether Claude or ChatGPT works better, this will help you. IF you want to know if adding a skill is worth it, then this will help you determine and keep track.

Then it will put it into a pretty graph that will make CEOs think you've done something useful.

That quote is fairly benign.

Since it bothered you so much, I can only assume that you inflict breaking changes on end-users merely because you are lazy, without consideration for the problems it will cause them.

"Breaking changes are an act of violence." Douglas Crockford.

Oh yeah? What kind of performance gain did you get?

Did you measure the performance gain, or did you leave your hypothesis untested?

Good point.

I'll add that to my prompt: "Dont' make it annoying."

ok, so you are making up reasons.

I had the head of accounting personally come to my cubicle for a $200 expense.