eieio

if this isn’t a joke - new yorker style uses a diaresis when a word has a repeated vowel where the second vowel is part of a different syllable. coördinate, coöperate, and reëlect are probably the most common places where this comes up

https://www.newyorker.com/culture/culture-desk/the-curse-of-...

I made a little TUI last month for searching within a channel! It supports before: / after:, fuzzy/exact/regex matching, lets you order by upload date/views/duration, lets you search over just a video's titles or descriptions, etc: https://github.com/nolenroyalty/yt-browse

The vast majority of my youtube watching is "go to a specific channel and try to find a certain kind of video" so it drives me nuts that youtube channel search is so bad (and afaik you can't search a channel on mobile?). I end up using my tool to find a bunch of videos and get them into my history to watch on my ipad.

n.b. my tool downloads all video metadata for a channel and then searches over it locally, so it's pretty slow the first time you search a channel (results are cached for 24 hours though).

(the amen break is one of the most commonly-sampled drum breaks in popular music: https://en.wikipedia.org/wiki/Amen_break)

I'm so excited about this! And I expect the speed/bandwidth improvements in the new renderer to be very significant.

I spent a while hacking on my own fork of the Bubbletea renderer over the last few months in order to run a game over SSH[1]. It was a ton of work for a niche, simple game (snake) but it dropped bandwidth usage by a factor of 10. The new renderer has to be more general so it might not quite hit that for all applications, but I bet it's not that far off.

I could also see it being an even more significant gain for apps that use a lot of modern colors and styling, since escape sequences there can be very long / heavy weight.

Some of the comments here are annoyed about the website branding but FWIW I think bubbletea and lipgloss (and wish, if you want SSH stuff) are really excellent tools for building "boring" TUIs too.

[1] https://eieio.games/blog/secure-massively-multiplayer-snake/

Typically in this system you encode obligations - e.g. "eieio should review, or at least be aware of, all changes made to this library." I think that means you're unlikely in practice to have a problem like that, which (unless the team is not functioning well) requires two people who care deeply about the variable name and don't know that someone else is changing it.

The tool (iron) isn't open source, but there are a bunch of public talks and blogs about how it works, many of which are linked from the github repo[1].

It used to be "open source" in that some of the code was available, but afaik it wasn't ever possible to actually run it externally because of how tightly it integrated with other internal systems.

[1] https://github.com/janestreet/iron

Was that Jane Street?

yep

Yes, in the system I'm describing if a reviewer changed your code, you reviewed their change.

at my last job code review was done directly in your editor (with tooling to show you diffs as well).

What this meant was that instead of leaving nitpicky comments, people would just change things that were nitpicky but clear improvements. They'd only leave comments (which blocked release) for stuff that was interesting enough to discuss.

This was typically a big shock for new hires who were used to the "comment for every nitpick" system; I think it can feel insulting when someone changes your feature. But I quickly came to love it and can't imagine doing code review any other way now. It's so much faster!

I'm not sure how to tie this to AI code review tbh. Right now I don't think I'd trust a model's taste for when to change things and when to leave a comment. But maybe that'll change. I agree that if you automated away my taste for code it'd put me in a weird spot!

Eh, I was a little annoyed at the comment last night but read through the thread again today and you were clearly engaging in good faith.

I totally get being exhausted at LLMs. And I don't mind the nudge to be a little less lazy and install wireshark for next time.

hope I get you to play the game when it's out!

Hey! I'm the author.

My thinking was:

  * Yes, I clearly know what tcpdump is / how to capture network traffic
  * It has been several years since I have looked at a pcap
  * I don't have wireshark installed on this computer
  * I've done the thing where you decrypt TLS with wireshark exactly once, years ago, and I found it frustrating for reasons I can't remember[1]. Wasn't sure if I could do this with ssh
  * When I started investigating this, I didn't remotely think that ssh was the root cause. I thought it was a quirk of my game
  * I *did* make a client that printed out all the data it was receiving, but it was useless because it was operating at the wrong layer (e.g. it connected over SSH and logged the bytes SSH handed it)
  * I'm experimenting with Claude Code a lot because it has a lot of hype and I would like to form an opinion
  * Looking up flags is annoying
  * Being able to tell an agent "look at this pcap and tell me what you see" is *cool*

And the big leap here was realizing that this was my SSH client and not a quirk of my game. The time at which I would have read the SSH spec was after I captured traffic from a regular SSH session and observed the same pattern; before that I was thinking about the problem wrong.

I don't think that this is unfortunate. In fact, I think I got what I wanted here (a better sense of Claude Code's strengths and weaknesses). You're right that an alternative approach would have taught me different things, and that's a worthy goal too.

[1] I suspect this is because I was doing it for an old job and I had to figure out how to run some application with keys I controlled? It would have been easier here. I don't remember.

Or you could use anycasting to terminate SSH sessions on the moral equivalent of one of a number of geography based reverse proxies and then forward the packet over an internal network to the app server over a link tuned for low latency.

I've been thinking about some stuff like this! Not being able to put my game behind Cloudflare[1] is a bummer. Substantial architectural overhead though.

The idea of letting Claude loose on my crypto[graphy] implementation is about the most frightening thing I've heard of in a while [though libnss is so craptastic, I can't see how it would hurt in that case.]

I hear you, but FWIW the patch I was reverting was trivial (and it's also in the go crypto library, which is pretty easy to read). It's a couple-of-line change[2], and Claude did almost exactly what I would have done (I was tired and would have forgotten to shrink the handshake payload).

[1] This isn't strictly true, Cloudflare spectrum exists, but its pricing is an insane $1/GB last I checked.

[2] https://cs.opensource.google/go/x/crypto/+/833695f0a57b30373...

Claude is much faster at extracting fields from a pcap and processing them with awk than I am!

wow, I missed that comment, that's an incredible connection. Thank you!

TIL! I'll see if I can change that.

Is it possible that this is on your end?

The extension is "ping@openssh.com." It shows up in the blog reliably for me across several browsers and devices.

the obtuseness is the point! This is true of a lot of my work[1][2][3].

The problems you run into when doing things you shouldn't do are often really fun.

[1] https://news.ycombinator.com/item?id=42342382

[2] https://news.ycombinator.com/item?id=37810144

[3] https://news.ycombinator.com/item?id=42674116

Yes! While this post was written entirely by me, I wouldn't be surprised if I had "smoking gun" ready to go because I spent so much time debugging with Claude last night.

Oh wow - I've never heard of TCP_CORK before. Without disabling pings I'd still pay the cost of receiving way more packets, but maybe that'd be tolerable if I didn't have to send so many pongs. This is super handy; excited to play around with it.

I am aware of TCP_NODELAY (funny enough I recently posted about TCP_NODELAY to HN[1] when I was thinking about it for the same game that I wrote about here). But I think the latency hit from disabling it just doesn't work for me.

[1] https://news.ycombinator.com/item?id=46359120

This is an interesting question!

But no, the python output is correct (although I do round the values). It's counterintuitive but these are two different questions:

    1. What are the odds that both players lie? (4%)
    2. Given that both players say tails, what are the odds that the coin is heads (~6%)

The answer for question (2) is 0.02 / 0.34 = 6%

One way of expressing this is Bayes Rule: we want P(both say tails | coin is heads):

    * we can compute this as (P(coin is heads | both say tails) * P(coin is heads)) / P(both say tails)
    * P(coin is heads | both say tails) = 0.04 (both must lie)
    * P(coin is heads) = 0.5
    * P(both say tails) = 0.04 * 0.5 + 0.64 * 0.5 = 0.34

I think that might not be convincing to you, so we can also just look at the results for a hypothetical simulation with 2000 flips:

    * of those 2000 flips, 1000 are tails
    * 640 times both players tell the truth
    * 40 times both players lie
    * 680 times (640 + 40) both players *agree*
    * 320 times the players disagree

40 / 680 ~= 6%

We go from 4% to 6% because the denominator changes. For the "how often do they both lie" case, our denominator is "all of our coin flips." For the "given that they both said tails, what are the odds that the coin is heads" case, our denominator is "all of the cases where they agreed" - a substantially smaller denominator!

The three players example is just me rounding 89.6% to 90% to make the output shorter (all examples are rounded to two digits, otherwise I found that the output was too large to fit on many screens without horizontal scrolling).

Ah! Right after submitting 1000 Blank White Cards to HN I thought of Finchley Central[1] which (I think) is the game that Mornington Crescent comes from. I learned about Finchley Central a few years ago while reading about the history of The Game[2] (sorry).

I've had ideas off and on for the last 2 years about how to translate Finchley Central into something you could play over the internet with strangers but I've never quite figured out how to make it work; I think a key aspect of these games is having shared context with your friends and trying to make them laugh.

Anyway, fun that your mind went to the same place!

[1] https://en.wikipedia.org/wiki/Finchley_Central_(game) [2] https://en.wikipedia.org/wiki/The_Game_(mind_game)

(I'm the author)

I think there's an annoying thing where by saying "hey, here's this neat problem, what's the answer" I've made you much more likely to actually get the answer!

What I really wanted to do was transfer the experience of writing a simulation for a related problem, observing this result, assuming I had a bug in my code, and then being delighted when I did the math. But unfortunately I don't know how to transfer that experience over the internet :(

(to be clear, I'm totally happy you wrote out the probabilities and got it right! Just expressing something I was thinking about back when I wrote this blog)

I'd be worried that the chatroom would be filled with words that are not (ahem) in keeping with the christmas spirit!

I did spend some time thinking about how to let people leave "gifts" over folks could open, but wasn't sure how to make that work in a compelling way. Maybe next year...

ah this is great, thanks dan!

I've been playing with multiplayer games that run over SSH; right now I'm trying to push the framerate on the games as high as I can, which is what got me thinking about my networking stack.

I mostly use go these days for the backend for my multiplayer games, and in this case there's also some good tooling for terminal rendering and SSH stuff in go, so it's a nice choice.

(my games are often pretty weird, I understand that "high framerate multiplayer game over SSH" is a not a uhhh good idea, that's the point!)

Oh! Thank you for this! I love Julia’s writing but haven’t read this post.

I found this article while debugging some networking delays for a game that I'm working on.

It turns out that in my case it wasn't TCP_NODELAY - my backend is written in go, and go sets TCP_NODELAY by default!

But I still found the article - and in particular Nagle's acknowledgement of the issues! - to be interesting.

There's a discussion from two years ago here: https://news.ycombinator.com/item?id=40310896 - but I figured it'd been long enough that others might be interested in giving this a read too.

Yeah the big race here is that you've made a move (which might not be valid) and you're waiting on a response for that move - and you can receive other moves while you're waiting.

I don't think requesting a new snapshot really helps there. If you do that you're dramatically extending the amount of time that the user sees an invalid state, since you're adding a whole new server roundtrip to the reconciliation process.

FWIW (I'm the author) my creative output was ~0 while I was working a 'normal' job. I worked really hard and didn't have much energy for tech stuff outside of work (especially since I wanted to live a life that included non-tech things!)

I think it's totally fine to not make stuff outside of work, and it's so impressive to me that some of my friends manage to make creative stuff in their free time while working a day job.

One million radio buttons exists! https://omrb.olivia.website/

I think the research on progress bars and what makes users feel good is super interesting. But I also think "basically instant" is a good thing to aim for when you can.