Blog

A few days ago, the post Upcoming Changes to the AWX Project came across my feed. An innocuous title, but sometimes community-impacting changes are buried in posts like this. So, as an interested Ansible user, I read through the post.

In 1,610 words, almost nothing of substance was written.

A lot about how it's not 2014 anymore, so 2014-era architecture doesn't suit AWX. Then a big bold disclaimer at the bottom:

Before we conclude, we should be clear about what will not happen.

• We are not changing the Ansible project
• We are not adjusting our OSS license structure

Ultimately, we need to make some changes to the way our systems work and our projects are structured. Not a rewrite but a refactoring and restructuring of how some of the core components connect and communicate with each other.

In the past, I've booted LibreELEC on the Raspberry Pi Compute Module 4 in my "This is not a TV" Sharp NEC display.

According to LibreELEC's Pi 5 blog post, the new BCM2712 SoC decodes 4K and 1080p content just fine in H.264, and supports HEVC 4K60 hardware decoding.

And they've tested AV1, VC1, and VP9 at 1080p with no issue, though 4K in non-native formats does encounter frame dropping.

I wanted to put the Pi through some testing of my own, now that the Pi 5's been out for months, and LibreELEC version 12 is stable.

Besides the Pi 5 being approximately 2.5x faster for general compute, the addition of other blocks of the Arm architecture in the Pi 5's upgrade to A76 cores promises to speed up other tasks, too.

On the Pi 4, popular image processing models for object detection, pose detection, etc. would top out at 2-5 fps using the built-in CPU. Accessories like the Google Coral TPU speed things up considerably (and are eminently useful in builds like my Frigate NVR), but a Coral adds on $60 to the cost of your Pi project.

With the Pi 5, if I can double or triple inference speed—even at the expense of maxing out CPU usage—it could be worth it for some things.

LattePanda's been building Intel-based SBCs for almost a decade, but until now, they've never attempted to unite an Intel x86 chip with the popular SoM-style form factor Raspberry Pi's dominated with their Compute Module boards.

This year they've introduced the LattePanda Mu, a SoM that marries an Intel N100 SoC with a new edge connector standard they've designed, using a DDR4 SODIMM form factor.

Right now they offer two carrier boards: a lite version with basic interfaces and a couple 2230-size M.2 slots for SSDs and wireless, and a full evaluation carrier that breaks out every hardware interface in a Mini ITX-sized motherboard.

There are annual cicadas. Then there are 13-year cicadas. And 17-year cicadas. Then there are days like today when 13 and 17 year cicadas emerge from the ground around the same time, creating a fairly odd event in our backyard.

My daughters are helpfully pointing out a few of the thousands of holes in the ground around our yard—sites where cicadas have been emerging for the past two weeks.

Almost every day there's a new batch that starts climbing up the garden, the trees, the house, the barbecue grill, the kids toy box, the toys the kids leave in the yard... pretty much everything.

And then for a day or two you see them shedding their old skin, emerging, walking around a bit drunkenly, then eventually flying up into the trees.

For years, SBCs that aren't Raspberry Pis experimented with eMMC and M.2 storage interfaces. While the Raspberry Pi went from full-size SD card in the first generation to microSD in every generation following (Compute Modules excluded), other vendors like Radxa, Orange Pi, Banana Pi, etc. have been all over the place.

Still, most of the time a fallback microSD card slot remains.

But microSD cards—even the fastest UHS-II/A2/V90/etc. ones that advertise hundreds of MB/sec—are laggards when it comes to any kind of SBC workflow.

The two main reasons they're used are cost and size. They're tiny, and they don't cost much, especially if you don't shell out for industrial-rated microSD cards.