Also, in this context, security.

It really feels to me like there’s some low hanging fruit with voice that no one is capitalizing on: filler words and pacing. When the llm notices a silence, it fills it with a contextually aware filler word while the real response generates. Just an “mhmm” or a “right, right”. It’d go so far to make the back and forth feel more like a conversation, and if the speaker wasn’t done speaking; there’s no talking over the user garbage. (Say the filler word, then continue listening.)

It was chrome, downloading a multi GB file without any sort of UI hints that it was doing so. A generative AI file.

Is this why chrome uses so much ram? They’ve just been pushing up the memory usage in preparation for this day, hoping I wouldn’t notice the extra software now running on my (old, outdated) system?

Oooh I like this idea!

The result is a very interruptible grocery list process, where I know I haven’t forgotten anything.

https://supperstock.ca/

- In 1969 (8 years after the wall was erected): You'd calculate that there's a 50% chance that the wall will fall between 1972 (8x4/3=11 years) and 1993 (8x4=32 years)

- In 1989 (28 years after the wall was erected): You'd calculate that there's a 50% chance that the wall will fall between 1998 (28x4/3=37 years) and 2073 (28x4=112 years)

- In 1961 (when the wall was, say, 6 months old): You'd calculate that there's a 50% chance that the wall will fall between 1961 (0.5x4/3=0.667 years) and 1963 (0.5x4=2 years)

I found doing the math helped to point out how wide of a range the estimate provides. And 50% of the times you use this estimation method; your estimate will correctly be within this estimated range. It's also worth pointing out that, if your visit was at a random moment between 1961 and 1989, there's only a 3.6% chance that you visited in the final year of its 28 year span, and 1.8% chance that you visited in the first 6 months.

I would’ve preferred starting off in an empty room, an experience more like using signal.

With your approach, the burden is on the post office to update their handling process.

With the implemented approach, nothing changes about the postal process, and the burden of work is shifted to the sender, who must look up the code for the recipient’s current address.

Based on this assumption, it wouldn’t be necessary for any of your friends to search for the topic during an evening together.. it would simply be enough that one of the friends showed some interest in the topic prior to the hangout (searched for something, read a blog, stopped for too long on an instagram reel).

Then, during an evening together, your phones all share the same location (and possibly movement). That’s enough for advertisers to suspect there’s some relationship there. Enough of an association to attempt an ad placement (or instagram reel) for a particular obscure topic.

- User 1 shows an interest in .

- User 1 visits the same location, for the same period of time, as user 2.

- So I show an ad for to user 2.

> “ To address this limitation, we turned to data augmentation, artificially creating new versions of each image by modifying colors, adding noise, applying distortion, or rotating images. By the end, we had generated 600 augmented images per car.”

I gather that you’d supply the same “seed” during both compression and decompression, and this would reduce the amount of information embedded into the compressed result.

Which is basically what he’s done here. He’s cheating by marking the location of the repeating sequence using unique files, rather than some other actually more efficient location system.

This is a fun discussion! I think it helps to make compression feel more approachable for armchair enthusiasts.

- How did this bug make it to production? Where’s the missing unit test? Code review?

- Could the error have been handled automatically? Or more gracefully?