I recently upgraded to Kubuntu 26.04 from 25.10 and encountered several major issues. Note that Kubuntu 26.04 isn’t yet offered as an upgrade path yet, so I used the sudo do-release-upgrade -d method to test as an early adopter.

I use Home Assistant on a Raspberry Pi 400 (same as 4 hardware but with a keyboard case). When upgrading Home Assistant OS to version 17.2, I lost access to my Zigbee devices because I have a USB Connbee ii adapter. Per this GitHub issue, there is an incompatibility with old firmware that prevents USB from working at all. Since this is a bit of a specific issue, I thought I’d post this issue with a fix for visibility.

I found the ESP32-based ThingPulse Color Kit Grande and thought it would be a good way for my son (who is getting into robotics) and I to learn how to solder and put something like this together. It comes with a cool example project written in C using VSCode and PlatformIO. However, I’ve been teaching my son Python instead as his first programming language (after Scratch) and I don’t want to add C to the mix right now, so I thought to use CircuitPython as it supports ESP32. Unfortunately, there is not a out-of-the-box image for the ThingPulse, so in this post I explain how to get it working.

One note about CircuitPython support for this board: because it uses an ESP32 variant without have native USB support, you can only use the web-based environment over WiFi to work with it. Normally, CircuitPython boards export a CIRCUITPY folder where you can just copy code and libraries to the device. This also means the serial console (via USB) must be used to configure the wifi settings. Another caveat here is I used a board image with very similar hardware and I don’t know if there will be any potential issues with that (although I’ve found none so far).

I’ll first go over the steps I used to get it working then after provide some discussion on how I figured this out.

In this post I explore performance of a few ways to run services that can scale to zero in Azure. This can be useful to reduce costs in services with very low utilization such as a personal cloud learning environment or idle dev/test environments of an enterprise application. My previous post about Java startup performance focused on improving cold start times in the hopes to make scale-to-zero possible on a service like Azure Container Apps. Unfortunately, I was quite disappointed in container apps’ cold start performance and quite surprised with Azure Functions Flex Consumption. In this post I will detail my experience and compare to Azure Functions and Azure App Service.

The release of Java 25 (including GraalVM) and recent years of Java startup performance improvements inspired me to re-evaluate choices in Java web frameworks in low-usage scenarios such as scale-to-zero apps, where Java’s slow startup is a problem. The “industry standard” Spring Boot has improved considerably since I first started using it while alternative frameworks like Quarkus and Micronaut have also matured greatly. I want to check how fast these can start and how much memory they need as a baseline.

In this post I compare the startup time and memory usage for these 3 frameworks in a simple application using JDBC, Flyway, and Postgres. The database has a single table and the application serves both a JSON API and a server-side rendered HTML via a templating engine. I used what I felt are “typical” libraries for each framework based on its common tutorials and project generation tool defaults, aiming to capture “typical” usage rather than what is possible with targeted optimizing. For example, Spring Boot is usually lighter with Undertow instead of the Tomcat default, while Micronaut and Quarkus already default to lighter-weight engines (Netty and Vert.x). In Micronaut, I used Micronaut Data JDBC versus Hibernate in Spring Boot and Quarkus.

Full details are provided later in the post, but as it’s long I’ll start with the results as run on an M2 Pro Macbook with 16GB of memory and GraalVM 25: