recent chrome versions actually throttle these reports down to 60hz max, checked this on several systems and mice

I see, but the path from hardware to userspace app should remain unchange, right ?

You actually should not, usual (non-gaming) mice still do the same (most touchpads in cheap laptops even slower, they share already slow i2c bus with several other endpoints), and the article ignores drivers and the UI stack altogether.

I could not find anything about google or other browser vendors in the article.

My take is that you should trust provider (developer, hoster) of said encryption app to send you actual implementation, not something that looks like the real deal, but does not encrypt anything. From a regular user's point of view: you can not inspect what you run (due to technical reasons, that on the web anything can be downloaded and executed at any moment, swapping implementation on the fly. And due to skills needed to actually read and understand executed scripts), so you can only believe and trust. At which point usual TLS is surely enough.

Like I said I'm confused, genuinely trying to figure the article out.

"A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against."

What is the cryptosystem then on the Web? Who is the entity? It's not the server or the Website so I don't see what's left except the browser and browser vendor.

There's also a long list of government (or subpeonable) entities on your certificate trust list.

Without which TLS is not gonna work.

The article is arguing that in practice you could just send your "encrypted" communications to the browser vendor, or one of the governments on the certificate root list, or someone else in the distribution chain, and have them be the middle man. The security properties of your communications would be the same. Hence "snake oil".

Things like stapling don't change this much, or reduce to TOFU.

But we are talking about protecting data at rest on the vendor's servers. Unless the vendor stores no user data at, how does TLS protect that data?

Your argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.

Seems like 3.4.2 was already vibe-maintained: https://github.com/RsyncProject/rsync/commits/v3.4.2

It's pretty shitty to accuse someone of vibe-coding without having any idea what their LLM-assisted development process is. Let's do better, please.

So? May main point is: Which commits actually broke the functionality? Going from 3.4.3 to 3.4.2 to test should be easy for anyone affected and would have been more helpful than this rant.

I'm not defending bad slop commits, especially for such a long running project but the tribal Fediverse outrage whenever LLMs are involved is often just lazy and uninformed.

To quote this PR: https://github.com/RsyncProject/rsync/issues/928

> NOTE: This also affects backported rsync versions when they're used on the Receiver: > Debian: 3.4.1+ds1-5+deb13u3 / 3.2.7-1+deb12u5 / 3.2.3-4+deb11u3 > Ubuntu: 3.2.7-1ubuntu1.4

Figuring out which commit broke what functionality is not something you can expect users to do.

No, but that's probably a required skill to have before you initiate claims as to what the cause of the loss of functionality was.

If you're willing to build from source it's not particularly difficult with git bisect

any c245 will do (JBC is the best and original, but clones are close)

I would not call 2nd video "skillful", that SOIC was molested, not soldered :(

Fair enough, perhaps I'm easily impressed. :)

I'm scratching my own itch: building a yet another audio signal generator for smartphone. I need some extra functionality that is not available elsewhere, and impose some limitations "just because": it must be bare minimal PWA.

But actual app does not matter, the main take away for me is: it is easy and fast to write bloatware (esp. with AI), but not that easy to distill to what is really needed. And what looked like a weekend project, a couple of hours max (with help of AI), now lingers for 2+ weeks on-and-off on evenings (of manual effort).

I'd recommend a spoon-style tip* instead of using a fresh drop of solder each time.

[*] like these https://www.jbctools.com/cartridges-category-4-design-Spoon-...

Looks kind of like a fountain pen for solder!

And works like one ;)

This pic is quite unsettling, I didn't understand why at first, but this blue wire pinched under the bolt...

Mechanical stress relief is my guess !