They did! I didn't actually think we were going to make it into one of the launch videos for this. That was a very pleasant surprise.

And they've been lovely to work with as we got this put together.

I’ve seen this a couple of times recently. Including right after compact. I’ll /feedback it next time I see it

I'll have you know that I'm Matt's top contributor to Ghost Pepper and I'm nearly fifty

But I did it because I wanted it to work exactly the way I wanted it.

Also, for kicks, I (codex) ported it to Linux. But because my Linux laptop isn't as fast, I've had to use a few tricks to make it fast. https://github.com/obra/pepper-x

I'll look at this, thank you. I haven't yet gotten around to vibe coding my own itch yet so maybe your scratching will do.

And indeed, Ghost Pepper supports parakeet v3

I mean, we're a two person company. I can assure you that all that writing wasn't about content marketing.

But, just for completeness sake, the list of people who got blindsided by the con artist who was ultimately behind a lot of the crazy included both our experienced local on-the-ground project manager and the factory owner.

Then I do have a cpuple of honest questions:

Why did you go to China, as a two men shop? And not choosing a local company nearby?

And how much experience do both of you have on the hardware / manufacturing aide of things? And running global supply chains (because that's what you have, regardless of production volume)?

Historically, at least, USB networking was pretty straightforward to enable on a jailbroken Kindle.

Author here: This was indeed a quick hack. And Perl is still my fastest language for banging out a quick prototype. (I used to be the Perl 5 project lead. I’ve spent a lot of time with Perl.)

And indeed, that's what Perl was built for!

That’s correct.

Yup! It’s basically a glorified shell script. Sometimes the old ways are useful.

(I’m the author)

A tool like this is a fantastic way to help it to become second nature

All you have to do is read the datasheet and multiply a few numbers to calculate worst-case power. Remembering to do that should be second nature, like remembering to close any parentheses you open. It's a great tool for understanding in greater detail, but it's not the way to avoid breaking stuff.

"You won't make mistakes if you remember not to make mistakes" is nice in theory, but just not how people work in real world. Just like trivial syntax errors are very common while you're doing things. It's better to embrace the common human failures and have a second layer of protection.

I explained in my other comment how it's a great tool for other jobs, but the wrong tool for this job. You won't learn how not to break things by ignoring the proper tool.

You're not going to learn how not to break things this way, but it will help you spot non-critical mistakes while you're learning in different ways.

That's exactly what I'm saying.

if I was to give a kid a breadboard and a bag of components I wouldn't want them to avoid breaking stuff; what I would want is for the child to be able to interpret the event and gain knowledge from the mistake.

This idea can shift the paradigm from "oh, the LED doesn't work", to "Oh, the LED doesn't work, the color around that rectifier area has shifted; why?" , and I think that can help to build intuition.

So teach them to check the power and the paint will help them realize when they forget to do so.

what precisely is wrong with visual feedback?

Nothing. It's great. But it's the wrong tool for the job. Like teaching someone to stop a car by using the speedometer to estimate when to let go of the accelerator pedal, instead of introducing them to the brake pedal.

You are supposed to study datasheets before you start a car?

Please. There's nothing wrong with "hands-on first" approach. And the tortured metaphors completely kill your argument...

It's too late to edit my original comment. I was responding to the part about when you're breaking a lot of stuff all the time.

Checking limits is for preventing breaks. Visualizing heat is for troubleshooting when they happen anyway. You should do both.

> All you have to do is read the datasheet

Have you read many datasheets? Parsing a datasheet can be pretty complex, even if it’s well written (of which many are not). There’s quite a few figures spread across many sections, and a beginner might not even realize they should be looking for the absolute maximums section. Sometimes datasheets aren’t even that explicit about certain failure modes, you could lock up a logic chip by accidentally leaving a pin floating, for example.

I can certainly see some value in a breadboard with instant feedback for when you’ve fucked up. Ideally you’re using a power supply with an adjustable current limit to begin with but this is a cool way to quickly draw your attention to an issue.

It takes 5 minutes to show someone how to read maximum values off a datasheet, and it makes the visualization 100x more useful.

> All you have to do is read the datasheet and multiply a few numbers to calculate worst-case power.

True story: When I was in college the lab mate I had reversed unknowingly reversed power and ground on a chip on a breadboard. I turned off the circuit and reached for the chip and got a blister on my finger.

Maximum power is infinite in that case (well not infinite, but pretty damn high!) I don't recall seeing a data sheet on power consumption when power and ground is reversed...

No offense, but this comes across as "This was the way I was forced to learn it, and dang it everyone else should do the same." But my experience says, I wouldn't have got a blister on my finger if I had that.

Current was flowing through the "body diode" which is intrinsic to the construction of ICs (it's normally reverse biased). The forward voltage was likely around 0.6v, maybe a little higher with a lot of current flowing through it. So roughly that times however many amps the power supply could supply with the resistance of the leads/rails. It doesn't actually take that much power to make a DIP package extremely hot though, lacking any sort of heat sink.

I can't edit the comment now, but I worded it wrong. The quote only applies to exceeding maximum values. The visualization is much more useful if you've calculated worst-case. I use a thermal camera all the time.