diffuse_l

I'm describing what I got from 20x Codex vs Claude 5x. Codex is just not worth the money, at least for me. What's flipped is the value you get for each of those

OpenAI 20x wasn't 20x even before that change. I got a lot more from Claude 5x than Codex 20x...

Seems like weekly allowance got reset back to 0%, pretty usual when they deploy new models.

For short strings (probably most of them) - use a byte for the length (at the string/symbol definition site, alongside the offset) (adds 1 byte * symbols, use high bit if necessary to add bytes for longer strings). You need the offset into the table anyway. It isn't strictly better, but it isn't strictly worse, and it gives you the option to reuse sub-strings.

Nothing prevents you from using a shared pool of strings that don't have null terminator. It can even be more efficient, since you don't have the null byte to handle at string end. Depending on the maximum string length you want to support, it doesn't even have to take more space.

Complete assembly. Wouldn't call it trivial, but not super hard either. I wouldn't dream of doing this without the complete assembly, not worth the hassle. You run the risk of ruining something, but for me the reasoning was that worst case I'd still have a conputer I can attach to an external monitor. Replacement itself is mostly removing screws and cables carefully - followed the ifixit guide.

Had a similar issue - some of the display was garbled for more than a year. Had a replacement screen from aliexpress lying around that cost 126$ two and half years ago, got to do the replacement a few weeks ago, as the kid needed a laptop for school. Turns out the replacement screen resolution was not the same as the original, but it still works fine, took ~1 hour for the replacement.

So for me it did make sense to repair - it costs less than a new laptop, at least

That's if you parse the into a DOM and work on that. If you use SAX parsing, it makes it much better regarding the memory footprint.

But of course, working with SAX parsing is yet another, very different, bag of snakes.

I still hope that json parsing had the same support for stream processing as XML (I know that there are existing solutions for that, but it's much less common than in the XML world)

Some minor nitpicks, but hey, we're counting registers, it's already quite nitpicky :)

Add far as I van remember, you can't access the high/low 8 bits of si, di, sp. ip isn't accessible directly at all.

The ancestry of x86 can actually be traced back to 8 bit cpus - the high/low bits of registers are remenants of an even older arch - but I'm not sure about that from the top of my head.

I think most of the "weird" choices mentioned there boil down to limitations that seem absurd right now, but were real constraints - x87 stack can probably traced back to exposing minimal interface to the host processor - 1 register instead of 8 can save quite a few data line - although a multiplexer can probably solve this - so just a wild guess. MMX probably reused the register file of x87 to save die space.

Too bad, but I managed to watch about 30 seconds of the video before getting motion sickness.

Seems like a really cool technology, though.

I wonder if anyone else got the same response, or it's just me.

Really enjoyed the article, thanks! A small nit - I think you have a small mistake in the value range at the start - 136000 should probably be 13600?

It was pretty clear towards the middle of the piece that an ai was involved writing this piece, which was unfortunate, since it distracted me so much from the subject that I couldn't complete reading it...

At least it's ACID compliant

Well, at least the first half was somewhat useful...