Adding to this: while certs are indeed well-supported by OpenSSH, it's not always the SSH daemon used on alternate or embedded platforms.

For example, OpenWRT used Dropbear [1] instead, which does not support certs. Also, Java programs that implement SSH stuff, like Jenkins, may be doing so using Apache Mina [2] which, though the underlying library supports certs, it is buggy [3] and requires the application to add the UX to also support it.

[1] https://matt.ucc.asn.au/dropbear/dropbear.html

[2] https://mina.apache.org/sshd-project/

[3] I've been dealing for years with NullPointerExceptions causing the connection to crash when presented with certain ed25519 certificates.

You can just replace dropbear with openssh on OpenWRT. That was one of the first things I did, since DropBear also doesn't support hardware backed (sk) keys. Just move it to 2222 and disable the service.

I reenabled DB on that alt port when I did the recent major update, just in case, but it wasn't necessary. After the upgrade, OpenSSH was alive and ready.

I downvoted this comment for sounding like a summarizing LLM, not adding anything substantial beyond the title of the post, before realizing you were the poster and author.

I didn’t know that “subtitle” would appear as first comment.

huh, i didn't realise that's what that does either

> it's basically a cost optimization masquerading as a feature

Cost optimization in the user's favor.

Remember that every time you send a new message to the LLM, you are actually sending the entire conversation again with that added last message to the LLM.

Remember that LLMs are fixed functions, the only variable is the context input (and temperature, sure).

Naively, this would lead to quadratic consumption of your token quota, which would get ridiculously expensive as conversations stretch into current 100k-1M context windows.

To solve this, AI providers cache the context on the GPU, and only charge you for the delta in the conversation/context. But they're not going to keep that GPU cache warm for you forever, so it'll time out after some inactivity.

So the microcompaction-on-idle happens to soften the token consumption blow after you've stepped away for lunch, your context cache has been flushed by the AI provider, and you basically have to spend tokens to restart your conversation from scratch.

They lost me at "our conductors are coax!". USB is designed around differential signaling, which is what twisted pair excels at.

Twisted pair is good but it only gets your losses so low at these speeds. Keep in mind that USB cables have a very small budget for signal loss, and at 40Gbps they're carrying frequencies 25x higher than 10gig ethernet.

> Not to mention that WindowServer seems to take 100+% cpu since the upgrade

That's because some app is spamming window updates.

It's been an ongoing problem for many releases. AFAICT, WindowServer 100% CPU is a symptom, not a cause.

But apps shouldn't be able to hammer WindowServer in the first place. If your app is misbehaving, your app should hang, not the OS window compositor!

FWIU there's really no backpressure mechanism for apps delegating compositing (via CoreAnimation / CALayers) to WindowServer which is the real problem IMO.

And I could imagine SwiftUI only makes this worse, because it's quite easy to trigger tons of unnecessary redraws.

People don't really like apps that stutter.

And maybe that would get enough users to leave or complain that managers might allow some dev time to fix bad behavior.

Symptoms with no way to understand why.

If Apple would give insight about this, the developers wold get bug reports and complaints

Similar to the electron shit

I can't tell what's supposed to be disgusting about this unless you stopped reading past the inflammatory headline.

> It is really weird not to care about the first impression that your manual makes on a curious reader.

On the contrary, I think this is an all-too-familiar pitfall for the, er... technically minded.

"I've implemented it in the code. My work here is done. The rest is window dressing."

That's worth making a separate post! (and I recommend rendering it to HTML)

But "bare" is part of the value of Cohen's post, I think. When you want to publicize a paradigm shift, it helps to make it in small, digestible chunks.

Eh. It's a matter of visible pain vs invisible pain.

Developers are quite familiar with Merge Conflicts and the confusing UI that git (and SVN before it, in my experience) gives you about them. The "ours vs theirs" nomenclature which doesn't help, etc. This is something that VCSs can improve on, QED this post.

Vs the scenario you're describing (what I call Logical Conflicts), where two changes touching different parts of the code (so it doesn't emerge as a Merge Conflict) but still breaking each other. Like one change adding a function call in one file but another change changing the API in a different file.

These are painful in a different way, and not something that a simple text-based version control (which is all of the big ones) can even see.

Indeed, CRDTs do not help with Logical Conflicts.

Thank you for the clarification. I agree that the current state of the art to show conflicts _in the same part of the code_ is not sufficient, so any improvement with regard to that is welcome. Still, I'm more looking for solutions with the Logical Conflicts.

no no don't worry! They have courts! They're following due process, you see!

24 years of the Patriot Act, and counting...