Ha! just looked up the video, seems it’s another practical engineering video I was thinking of

https://youtu.be/0olpSN6_TCc?si=8woq9mRHNpWrwCKi

Fun fact. Lack of parking is not a legitimate reason to attempt to drive past this region. I was once flagged crossing into canada on a day they were interviewing a lot of travelers. I spotted parking in what looked to me like an overflow lot on the other side of a fence, and when I slowly drove that direction sirens blasted and guns were drawn. Nothing gives you clarity like a gun pointed at you.

This is generally true. What I find fascinating is the application of information that is not present in the data but that can be confirmed by the data. I’m thinking specifically of deblurring algorithms people use to recover text. If you can guess what font is being used in a screengrab with, say, someone’s bank account blurred out, you can take the i formation contained in the downloaded font and try combinations until you match the blur algorithm that may also be information not contained in the image.

What’s also crazy, is that even if all you do is black out the text, kerning alone can still be used to guess the correct text with some degree of accuracy. I worked on redaction software at one point, and these were very much the types of things we thought about when dealing with text.

There was a good keynote on the topic 5 years ago By Timothy Roscoe

https://www.usenix.org/conference/osdi21/presentation/fri-ke...

https://www.youtube.com/watch?v=0z5ixJIqbGY&t=267s

He's an odd guy who likes to investigate some really dodgy stuff. And I suspect many here on HN would appreciate him.

That led to 7-OH showing up in my feed at some point. In a nutshell, it's the strongest of the active compounds in the kratom plant, that binds to opioid receptors. 7-OH is the marketing name for the alkaloid 7-hydroxymitragynine that is being refined from kratom. It's not clear to me if it's simply extracted, or as some quick research suggests, it might also be a chemical alteration of the more commonly occurring compound in kratom mitragynine.

Anyway, this stuff looks super habit forming, and, of course, the refined version is that much more addictive.

I know it’s stupid, but I’m genuinely curious now.

There is one truth I have come to know, said by someone far wiser tha me: A queue is either empty or full. Which is to say a queue can either handle all the data coming in, or it can’t. When it can’t it will fill to capacity. This is a probabilistic thing, and you can only decide how many nines to plan for. And it’s worse than it looks at first, because queuing theory is very non intuitive with non linearities that make it very hard to reason about wothout having your nose rubbed in it.

So that means, that yes, you can keep doubling the size of your queue. And no, you can’t ever make it big enough to deal with a poisson distribution. And while you’re at it you will likely need to add workers. And you’re still back to capacity planning and deciding how much money to throw at the problem.

What you may be getting at, and what the article sort of failed at, is that queues are still super valuable for smoothing small spikes, or even large predictable ones. But a queue alone, without backpressure, or overflow will likely cause systems to fall over. Sometimes in ways that are hard to recover from, especially if you have some kind of microservices inspired architecture, where one thing going offline causes another queue elsewhere to fill. Or worse, bringing a failed service back online stresses another system causing it to fall offline. (not meant to be a dig on microservices by the way)

This, of course, makes on boarding and new user acquisition harder, and can severely limit product growth. And this also leaves space for simpler products to come along and cater to the novice market. Or, companies can fight this tendency, and remove features, or make them harder to use, in order to cater to less demanding demographics.

What I'd be curious about is what spotify looks like as their market share levels off. Do they keep catering to the automatic playlist crowd, or does their average user get more sophisticated over time?

Contains FCC ID: 2AC7Z-ESP32WROVERE.

So when I say "there is no way", what I'm referring to, are the functions that configure drivers don't accept out of bounds values. And functions that ultimately drive the antenna can't drive them hard enough to be in violation. The main reason I know any of this, was that I found a function when working on firmware for the ESP32 on a commercial device, and I thought I could set the power to a level that I thought was too high. Well, that's when I learned what the binary blob that Espressif supplies was for. The guardrails are baked into the API for that blob.

So, does that mean you can't go out of your way to subvert those guardrails? No, but you would be incredibly foolish to knowingly create a device that will get the attention of the FCC. Similarly, there's nothing stopping you from building a circuit that amplifies the signal the device sends to the antenna. But when you're potentially talking about fines per event, and fines per device, it's wise to make sure you play nice.

If the wi-fi chip you're using has free firmware, where none of it is obfuscated, it's very likely that the limitations are baked directly into the chip, such that there is no register combination that would allow it to be out of compliance. Also, I'm not sure that all chips have transitive FCC licensing, so it might be wise to look into that before releasing the device commercially.

And keep in mind, I'm not even talking about creating accidental radios from poorly designed analog circuits, or unshielded high frequency digital circuits. That's a whole other can of worms.

I agree there is not much of a clear call to action. As a firmware engineer who has worked with bluetooth amd wifi, this is a key phrase. It’s also a big fantasy. FCC compliance is a big headache, and part of why people buy a given chip is the FCC certification comes with it. For instance, if I throw an ESP32 into a product and use wifi, I don’t need further certification. That can only happen if “there is no way” you can make the radio do what the FCC doesn’t allow. A general stategy for this is for the company to give a binary blob for radio related functions that limits the radio capabilities that you need to link to in your final build.

So that means there is almost zero chance the chip makers will ever publicly move away from binary blobs. At best they might quietly support reverse engineering efforts by open source driver projects.

That said, I would love it if all the chips I worked with had a battle hardened non vendor alternative. One major downside to these binary blobs is that they can be buggy. We were recently able ro rewrite our Bluetooth firmware to use an opensource version which greatly sped up the data throughput since it didn’t have a bug that killed byte transfer. But we don’t use this code lightly. FCC violations are crazy expensive and not something you take lightly.