ledauphin

I think this is basically true, but there's a different way of saying this.

LLMs are not aligned _for_ humans in a very similar way to the way that humans themselves are not aligned _for_ humans.

We have not yet solved "alignment" for humans - I don't know why anyone thinks _we're_ going to be able to solve it for inhuman things.

because humans lie, cheat, and coordinate...?

do these automatically copy over git config and/or installed hooks?

I'm surprised the article doesn't address the Occam's Razor probability that... _most people_ hold ideas that the (a?) majority does not... and that increased media attention is likely to "discover" these beliefs.

Or rather, I see no attempt to make an argument that Nobel laureates are statistically _more_ likely than other "well-known" non-politicians to hold non-majoritarian ideas... nor any attempt to argue that the ideas followed rather than preceded the award.

nah this doesn't explain it.

most of the users of those third party harnesses care just as much about hitting cache and getting more usage.

this doesn't seem like it allows multiple writers?

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.

I just don't buy this. It is not what I observe with these things. They are not at all "thoughtful".

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.

then this will get filed by every corporation against every lawsuit

this is often a sign that the design/solution you've chosen is an unfruitful path.

know when to cut your losses and try something different.

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.

notably, the paper uses the capitalization XAI.

average, yes, but living to 70 was reasonably common if you made it past childhood.

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.

it's not, though. sometimes you need actual active logs to tell you that something is progressing.

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!

because of your existing mortgage rate

start on a postdoc :)

here's a dumb question:

she's starting her Ph.D. this fall - hasn't she already achieved it? What is the theory behind expecting someone who has solved a decades-old problem to do some "second" thing to prove that they have extended the bounds of human knowledge?

I mean... a thought experiment like "medical emergency in remote location" would seem a useful place to start.

this is kind of what Ars Technica does these days. :(

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.

this would be a silly argument - surely the customers buying the devices should be paying directly for the operating system?