In the first part of this blog journey (I’d call it a post, but it’s actually two posts) we explored what operational excellence looks like in public cloud deployments. And while I do not want to spoil it for you, the main takeaway was that it is not easy and can become resource-intensive. With this in mind, you might should be wondering what you can do to achieve excellence without focusing all your resources on operations.

You might be tempted to think that running an app on a public cloud means you don’t need to maintain it. While that would be wonderful, it would require help from the public cloud providers and app developers themselves, and possibly a range of mythological creatures with magic powers. This is because any app, regardless of the infrastructure on which it runs or its output, requires maintenance in order to yield accurate and reliable outputs.

‘Everything LTS’ – Canonical will build distroless Docker images to customer spec that include upstream components not packaged in Ubuntu, and fix critical CVEs within 24 hours, supported on RHEL, Ubuntu, VMware or public cloud K8s for 12+ years.

Like many other industries, organisations in the public sector have been keen to make use of the flexibility offered by cloud computing, but are now observing unpredictable and rising costs. Much of which can be mitigated through careful planning and on-premise infrastructure. Government guidance now recommends switching to a strategy of the most appropriate solution for a problem, rather than a one-size-fits-all or carte blanche approach of shifting all applications to the cloud.

Strong, wide-reaching regulation can bring safety to communities – but it can also bring uncertainty. The Cyber Resilience Act (CRA) has proven no exception to this universal rule. Across the open source community and the wider tech landscape, people have been greeting the news with the whole spectrum of reactions: concern, anxiety, hope. But is there anything to fear? Does the CRA really change things in open source? And how should your teams be preparing for this legislation?

For 20 years, Ubuntu has been at the cutting edge of technology. Pioneers looking to innovate new technologies and ideas choose Ubuntu as the medium to do it, whether they’re building devices for space, deploying a fleet of robots or building up financial infrastructure. The rise of machine learning is no exception and has encouraged people to develop their models on Ubuntu at different scales.

At our core, we believe in Ubuntu: “I am what I am because of who we all are.” This philosophy of interconnectedness is woven into everything we do, including how we approach software development. This belief in our interconnectedness extends to how we build software. Pair programming, a practice where two developers work side-by-side, isn’t just a reflection of our values—it’s a powerful driver of quality, innovation, and team cohesion.

Canonical is now issuing Ubuntu Security Notices (USNs) in the open source OSV format. Using the information provided, developers can identify known third-party, open source dependency vulnerabilities that pose a genuine risk to their application and its environment. This collaboration between Canonical and OSV aims to simplify vulnerability management and further enhance security for Ubuntu users.

Welcome to this blog series which explores innovative uses of Ubuntu Core. Throughout this series, Canonical’s Engineers will show what you can build with this Core 24 release, highlighting the features and tools available to you. In this third blog, Farshid Tavakolizadeh, engineering manager from our Industrial team, will show you how to build a Matter lighting device with a Raspberry Pi.