fps-hero

Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads — around $165,000 at API pricing. By hand, I think this would've taken 3 engineers with full context on the codebase about a year, during which time we wouldn't be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features. We never would've done that. The realistic alternative was to do nothing and keep fixing the bugs at the top of this post forever.

THE SPINNER MESSAGE CAUSES 100% GPU USAGE ON AN MBP M5!!

One conspiratorial idea I had was that this isn't a bug, and that Codex was actually doing computation on users' hardware under the guise of "thinking". Like Folding@home, or bitcoin mining malware, involuntarily on paying customers. Your usage is being subsidized by your personal compute hardware that you can't take advantage of unless it was being applied at massive scale.

This would make even more sense when you consider that thinking and response time metrics aren't publicly being tracked. There is an assumption that LLM interaction is being processed as fast as possible, but this doesn't align with the reality of fixed hardware and oversubscription. Of course throttling is occurring. So, if you can take advantage of local compute, delay the responses and you have even more access compute!

I find it difficult to believe that given the scale, number of users, and money involved, that someone hasn't fixed this "bug".

People conflate the ideas of happiness, and comfort. Money buys access to increasing levels of comfort, but comfort becomes normalized very quickly. Once you've become accustomed to a certain level of comfort, the luxury of it wears off and it becomes a new norm. You also have an expectation to, at a minimum, maintain wealth so that you don't lose access to your current level of comfort.

When people with 1X see people with 10X or 100X and go hey! Why aren't you doing more? That gives me hope. When these people succeed, they are exactly the type of people who will give back and derive happiness from it. The right person who acquires wealth can do a lot of good in the world.

You've made me do even more digging and now I'm even more confused.

ATMega328P, data sheet specifically calls out using that it cannot represent full range, ADC = VIN * 1024 / VREF. The STM32F4 datasheet shows an idealised transfer function which is mid-tread, but the "actual transfer function" is sort of a shifted mid-tread (lowest code is larger than a single LSB, highest code is VREF and 1/4 LSB). Other STM32 references I found show that it should follow an ideal mid-tread, unless you are using VADC as your voltage reference. High resolution differential input ADCs are, as best as I can tell, always mid-tread with both end codes representing the positive and negative voltage reference.

The best data sheet I've found was for a PIC32, very detailed transfer characteristic diagram. This shows that each LSB is VREF/1024, but also why! The transfer function shows that is is still a mid-tread transfer, but the highest code is assigned to (1023/1024) * VREF, hence the divide by 1024, but it doesn't solve the 1/2LSB end bin problem.

This is different to the ideas presented the article, there is no reason a single ended ADC couldn't use mid-tread quantisation with VREF as the end code. What it does show is that by using divide by 256, you are truncating the range and arbitrarily deciding where the end points should be. This doesn't fix any inherent 1/2LSB quantisation uncertainty, which was the main argument against using divide by 255.

As you say, in ADCs it's a moot point with all of the other sources of error.

This was a genuinely thought provoking article. I had to challenge some personal assumptions.

Coming from an electrical engineering background, I disagree with how the author presented "Two types of quantizers". Mathematically rigorous, but not grounded in practical systems.

In ADCs, there is always an inherent +-1/2 LSB of quantisation uncertainty. The transfer characteristic is always mid-tread sampling, or at least I haven't come across any counter examples. This is true for bipolar or unipolar ADCs.

The lowest code is negative voltage reference, and the highest code the positive reference. The transfer characteristic plot will show what the author has demonstrated, that the highest and lowest bins will effectively be 1/2LSB in width.

In a unipolar system, this has the consequence of not being able to represent the midpoint voltage precisely, or in other words, the gray problem. In a bipolar system, 0V will be mid-tread N/2 value, but that doesn't mean it has "256 ranges".

So, I'll be sticking with (VREF+ - VREV-) * k / (2^N - 1). Or in other words I agree with the normalisation by 255. It's the fence post error all over again, you have N values, but N-1 ranges. If you have less ranges than you do values, you need to distribute 1 of those ranges between two values, hence the 1/2LSB range endpoints.

That’s the mental model that works for people, specifically those that come from VM workflow.

Ironically that’s how Docker works on every platform where it’s running a non-native OS. On macOS that’s how all images are run. Linux on Linux is the only Docker combination that is particularly problematic from a security perspective.

Virtualisation has advanced greatly since docker was introduced, if your running in local hardware that’s supports virtualisation, Docker should be running images fully virtualised. There is no good reason to use the OS kernel for most use cases as the performance impact is negligible. If you need kernel access there are better options, like systemd containers.

I have a wonderful book that explores this idea of an atlas of flavours that work together.

The flavor bible.

I can assure you that it does not contain 1800 ingredients in all of there combinations, but it does a remarkable job of covering a widely used selection of herbs spices vegetables and meats. I doubt a compressed version of the text would even be very large.

The trouble I find with LLM generated recipes is they miss the nuance of the technique. Often the success of a depends on a single step or ratio. For instance “fried chicken” has a million incarnations the world over, but you can’t just average out the recipes and end up with tasty fried chicken.

Well, we finally got to find out what an Apple car would have looked like.

I find it weird today that we are still fascinated by video wall papers.

This was literally my first hack I did in high school in 2005. Doing something I’d never seen done before, a video wallpaper.

Step one, grab a handle to the video memory serving the wall paper. My “game trainer cheats” experience served me well. That was easy.

I had to figure out the hard way that per pixel calculations are extremely CPU taxing, the YUV to RGB video color space conversion. With a pirated Intel compiler I could get the naive blit into memory videy background working.

But then I wondered how other video apps were working so efficiently?

They used a GPU overlay! How it worked is you’d designate a color on your screen as the overlay color, and, when the screen was rendered, any pixel that was the overlay color was swapped with the full screen rendered video. I forget the specifics, it was some directX api. So, set the wallpaper to the hottest hot pink, run the renderer, and bobs your uncle, video wallpaper.

Everyone I showed this to was amazed, I really though I was on to something! Trouble was, I couldn’t get the damn thing to run on other people’s computers!

Little did I know or understand about the dreaded VCruntime redistributable. It wasn’t until 10 years later when I started working in industry I learned about “software distribution”. Linux makes it too easy, windows makes it too hard, static linking everything that isn’t network facing is probably the right approach.

I was so annoyed when Vista had the video wallpaper feature. “Man I was doing this years ago!”.

Tailwind isn't just a framework; it's a design system.

The creators of Tailwind wrote the brilliant book "Refactoring UI" [0], which presents a systematic design system, introducing ideas such a type-scales, color-scales, spacing, and tactics to minimizes the cognitive burden on the designer by forcing design choices. The ideas presented in this book basically are tailwind classes!

When you build with Tailwind, everyone is speaking the same design language, and you end up with harmonious designs, even when components came from different projects or designers.

I disagree with the author's approach. It's basically just copying the utility classes from Tailwind and implementing them in an unergonomic way. Perhaps the best idea is component level CSS which is something that's been enabled by better tooling. I would implore anyone who doesn't really get Tailwind, to read the origin story [1].

[0] https://refactoringui.com/ [1] https://adamwathan.me/css-utility-classes-and-separation-of-...

I think you miss understood the challenge. They are using a 60Msps ADC with a parallel port interface. The challenge is capturing the 600Mbit/s of data and having enough CPU and memory bandwidth to do anything useful with it.

If your microcontroller has a parallel port interface, you would use the clock setup you described. This works, I've done it before, but there was very little CPU left to do anything useful with the data.

It's neat that they used the PIO, its demonstrating how that peripheral fills a niche where you things that might have been impossible without an FPGA, suddenly become doable on a microcontroller.

But nope, WebRTC has no buffering and renders based on arrival time. Like seriously, timestamps are just suggestions. It’s even more annoying when video enters the picture.

I felt that comment my bones. Why would anyone possibly have the need to know actual presentation timestamp and how that corresponds to actual realtime? Evidently, no one working on WebRTC has had to synchronise data streams from varying sources before with millisecond accuracy.

I was doing a demo for a video stabilisation using a webcam and IMU module in the browser. It turns out the latency between video->rtc->browser and sensor->websocket->browser are wildly different and not constant. The obvious solution would be to send UTC timestamps for the sensors data and synchronise in browser. Not possible, the video has no UTC timestamp reference. When you have control of both sides of the WebRTC pipe, you can do fun things like send the UTC timestamp of the start of the stream, but this won’t solve browser jitter. It worked well enough for a POC but the entire solution had to be reengineered.

I love your reverse psychology analogy. That does make me wonder, if a cap past its SRF is an inductor, and and inductor past its SRF is a cap, why not swap caps for inductors and vice versa, put an amplifier on the end and call it a day!

Loop inductance is what really matters with decoupling. Once you understand that, it becomes really easy to make good decisions. This article explains how you can approximate the inductance for a given layout, so it makes evaluating layouts much simpler. It actually used the data from the paper you referenced in example 3!

https://learnemc.com/estimating-connection-inductance

You can even use mutual inductance of vias improve performance, either by having vias spaced close together and in the right order (https://learnemc.com/decoupling-for-boards-with-widely-space...), or arranging capacitors in alternating or doublet layouts (https://incompliancemag.com/decoupling-capacitor-design-on-p...).

As you say, just having power planes and directly connecting to them is almost always going to be superior to using a trace, despite seeing this all the time, especially in datasheet example layouts. It made sense for 2 layer boards, but not today. Just think, the inductance of the planes is practically zero, and distance to the plane from the components is going to be on the order of 0.2mm, round trip 0.4mm. Is there any way I could place the capacitor 0.4mm away from the pins to achieve an equivalent inductance? And even if you could, you can't add extra vias to lower inductance, and you don't benefit from mutual inductance.

Am I so out of touch?

No! It’s the children who are wrong!

Or simply that Solvespace is a fantastic tool for 2D work? The sketcher is amazing and it has a straight forward workflow for laser cutting. Draw your panel, export to SVG, adjust in Inkscape (cut lines, etches, fills), send to cutter. I'd argue Solvespace is the best free and open source tool for the purpose.

This is exactly what I use it for and I love it. I even use it for front panel decals, not just the laser cut panels. Something about laying out graphics using a CAD tool is really appealing. I need the dimensions tools! I struggle getting things accurately placed using Inkscape.

Another 2D use case is a simple parametric sketch pad. If I need to draw something up quickly and pull measurements, this is the tool I'm reaching for.

It falls down a bit in 3D because unless you're making a very straight forward blocky shape, it's either too cumbersome, or literally impossible to make the geometry you need. If the geometry could be made on a 3-axis CNC, Solvespace should be capable of making it. Anything else, I'm reaching for Fusion360. I've been meaning to give Freecad another crack as the UX seems to finally be getting some priority.

Very interesting! Thanks for sharing.

It’s very frustrating that the tried and true method of sampling comparators has become prohibitively expensive due to niche parts.

I suspected that the ST HRTIMER would be a good candidate for replacing the delay line components, with the benefit of synchronisation for free. Good to see it works!

The diode bridge sampling and verification is the “hard part”. My motivation was for wanting to make a TDR was lack of equipment required to measure the signals required. Ironically, it’s the very equipment you need decent equipment to verify a TDR is working correctly. Most existing designs attempt to replicate old sampling bridges that use exotic unobtainable diodes. If you stray from the tried path, it’s up to you to verify performance, so there is some valuable insight here.

I liked reconstructing the signal using a spectrum analyser, very clever idea.

Did you miss the point of the article? JPEG-XL encoding doesn't rely on quantisation to achieve its performance goals. Its a bit like how GPU shaders use floating point arithmetic internally but output quantised values for the bit depth of the screen.

This would introduce a bias towards countries that are large and have extensive motorway networks. They would appear safer than countries that have a smaller portion of motorway miles.

If we look at the number of deaths per billion miles driven, we see that motorways are roughly four times safer than urban roads, and more than five times safer than rural roads. This is not specific to the UK: among 24 OECD countries, approximately 5% of road deaths occurred on motorways.5 In almost all countries, it was less than 10%.

I think you have a misunderstanding about the Ethernet standard they are discussing. This isn’t copper Ethernet, its fibre Ethernet standard. Copper Ethernet caps out at 25Gb/s with an impractically short 10 meter cable run.

Absolutely. Software encoders are constantly pushing the envelope in terms of quality, and they have tuneable knobs to allow you to pick the speed vs quality trade off.

Hardware encoders are much more restrictive. They will target a maximum resolution and frame rate, realtime encoding a possibly low latency as requirement.

The standards define the bitstream, but is lots of scope for cheating to allow for simpler hardware implementation. You could skip motion prediction and use simple quantisation, it would just contribute to the residual entropy that needs to be encoded. Then, you can use inefficient implementations of the entropy encoders. The end result is something that can be interpreted as a valid bitstream but threw out all the algorithmic tricks to give you high quality compressed video.

I think specifically in terms of YouTube, it’s not a hardware encoding issue but it’s a purposeful optimisation for storage and bandwidth.

Absolutely cringe worthy. The painful thing is it’s just a simple conversation factor but I couldn’t take the article seriously after that.

Speaking of reinventing, the article rediscovered the concept of bakers percentage, which is how bakers always describe recipes! Except baker’s percentage is unit agnostic and not susceptible to variations in volumetric measurement, ingredient density, and non-universal cup sizes.

Unless the virus derived from gain-of-function research, which is one of the likely hypothetical origins.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10234839/

Isn’t it funny that they decided that, of all episodes, was the one that crossed some sort of line decency. The episode was entirely on-brand, but I can see how someone might watch that one episode and be turned off.

The themes and ideas presented presented in later episodes left me far more shocked and moved. “San Junipero” and “Smithereens” were incredibly moving for me personally, while other episodes were absolutely fascinating because they took some aspects of our society and humanity and took them to their logical extreme.

The most shocking part of all is how true to reality most episodes are. What set S01E01 apart was it didn’t rely on sci-fi to tell its story, which is the only way in which it isn’t on brand.

Honestly it’s incredible that sending 12,000 satellites into space to provide internet coverage to multiple continents across the world is as cheaper than installing ground based infrastructure. The cost per satellite is reportedly $500k, so the star link constellation cost only $6 billion.

For comparison the Australian NBN (country wide internet infrastructure upgrade) cost over $50 billion, and it still relies on satellites to cover rural areas.

I bought a fake Nokia back in the day (18 years ago). The thing which gave away it was fake was the atrocious battery life (2ish run time hours), and otherwise clunky software. I can assure you faking a hologram was absolutely not problem.

Touring artist’s absolutely have a say in their ticket prices, after all it directly correlates to how much they will be paid. Once tickets are handed over to promoters and distributors then it becomes out of their control.

Festival appearance rates are agreed on in advance of ticket sales, so tickets prices are the responsibility of festival organisers.

Every action directed at making tickets more affordable will have the opposite effect of making scalping more profitable. Im amazed that a reverse auction style approach hasn’t caught on, when you are capacity limited it seems nearly optimal for extracting profit and kills the ticket scalping business model.

If you want to use a car analogy, Prusa is the Toyota of the 3D printing world. No-one is arguably what they offer isn’t high quality, it’s just it’s 5 years too late, and costs too much.

For a company that’s been leading the charge on hobbyist 3D printing, they completely missed the boat on the Voron style printers. If they had simply mass produced a voron style 250x250x250mm printer, right around the time they announced the XL, and actually delivered it, the world would be a different place, and you could talk about Bambu Labs and Prusa in the same sentence.

Prusa is getting destroyed at every price point in every measure of quality. You can get the same quality for cheaper, or better quality for the same price.

Prusa’s ideological purity in reprap style printers has held them back. No significant innovations in hardware, no economies of scale from mass production, using open source firmware but failing to take advantage of community innovations like input shaping. The only place they really had an edge in was the slicer, which turned out to be the most portable part of their ecosystem.

Bambu labs illustrates how glacially slow the 3D printing industry have been innovating. A Prusa MK4 isn’t that far detached from the I3 that came 10 years before it. If the list of improvements amounts to a couple of dot points, that’s a sorry state of affairs.

I can’t believe they just released the Gen 2 AirPods without updating the charge port to USB-C, especially given the iPhone changeover has been telegraphed for over a year. It’s like they learnt nothing from the MacBook USB-C transition.