HN user

ledauphin

1,794 karma
Posts6
Comments508
View on HN

can you elaborate on this? diversifying compute doesn't create more compute - is it that the different LLM vendors have different peak times and so spreading themselves over more compute vendors spreads peak load?

yes, what we need is for charities to operate on a quarterly reporting cycle, so that their administrative overhead increase, and (like public companies) they can be myopically focused on short-term performance.

have you gotten a terminal interface on your phone to be acceptably usable? I haven't - not without a real keyboard attached in any case. too many parts of the UX are designed for a true keyboard.

Agent Skills 6 months ago

how is it different or better than maintaining an index page for your docs? Or a folder full of docs and giving Claude an instruction to `ls` the folder on startup?

this is likely in reference to the fact that dicts have maintained insertion order since Python ~3.6 as property of the language. Mathematically there's no defined order to a set, and a dict is really just a set in disguise, but it's very convenient for determinism to "add" this invariant to the language.

as an aside on Nimony aka Nim 3:

can somebody provide a reference explaining/demonstrating the ergonomics of ORC/ARC and in particular .cyclic? This is with a view toward imagining how developers who have never written anything in a non-garbage-collected language would adapt to Nimony.

thanks! I'm not convinced I really care about the concavity - I got the Glove80 because it was cheaper for wireless and ZMK seemed like a safer bet than the Dygma custom layout engine. You're happy with that side of things?

I have had literally this exact same experience with the Glove80.

I like everything about it except for the thumb cluster. it is, amazingly, worse than the Ergodox EZ.

I wish the author would spring for a wireless Dygma Defy and tell us how that thumb cluster compares :)

One way to reframe this is: "as a user [of the logs], what might I want to know?"

In my experience, this post is often right (and the logs are often wrong). There's a tendency to either log too much or log too little - if only a few items are getting processed, it's fine and maybe even good to log all 7 of them.

But if many, many are getting processed - you'll experience semantic overload as a reader of the logs. What you want is a compressed form

Logging per time interval can be a very handy approach. In my work, we've settled on a hybrid approach - calculate in real time how often things are happening and then log the number of things that have happened, but at a rate that is roughly one log every N seconds.

This takes some more engineering up front but is remarkably often what a log reader actually wants.

it would presumably require quite a large rework of what you have, but you could imagine a version of this where the client was talking to the APIs, so that people could input their own API keys without sending them anywhere.

the core idea here is really cool, and the UX is (or seems like it would be) impressive - no need to select a language, for instance.

Good luck getting it back on its feet!

the one does actually sound worse because... it's actually worse. it clarifies that the companies themselves were playing games with people's livelihoods because of the potential for profit.

whereas "AI" is intuitively an external force; it's much harder to assign blame to company leadership.

yeah, this just feels like one of those things that's begging for a lazy (on first use) initialization. if you can't share or transfer the socket between threads in the first place, then your code will definitionally not be planning to use the object in the main thread.