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.
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.
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.
you can remap individual LEDs - it's awkward but there's a community firmware that you can use without ever leaving the web editor. the layout language is also pretty raw but it's doable.
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?
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.
most of the users of those third party harnesses care just as much about hitting cache and getting more usage.