More than 5 years ago, i386 was dropped as an architecture in Ubuntu. Despite this, i386 has remained selected by default as an architecture to build when creating new PPAs, snap recipes, or OCI recipes.
Today, we have disabled building for i386 by default. From now on, only amd64 will be selected by default when creating new PPAs, snap recipes, or OCI recipes. This change only affects newly created PPAs, snap recipes, or OCI recipes. Existing PPAs and recipes remain unchanged.
It’s worth noting that, although we have disabled building for i386 by default, it’s still possible to select i386 as a target architecture when creating new PPAs, snap recipes, or OCI recipes. In future, we may yet decide to disable this altogether but for now, the ability to target i386 remains.
Because targeting i386 is still possible (but requires intervention to enable), we don’t anticipate that this change will affect users, but if you are affected, please log a bug.
And as always, if you have any feedback, please let us know!
CVE-2025-34028 (CVSS 10) is a maximum severity flaw in Commvault Command Center, a popular admin console for managing IT security services such as data protection and backups across enterprise environments. As of April 28th, CVE-2025-34028 has been flagged as actively exploited. CVE-2025-34028 also presents heightened risk due to the existence of publicly available proof-of-concept (PoC) […]
Canonical, the publisher of Ubuntu, and ESWIN Computing have partnered to enable DeepSeek LLM 7B on the EIC77 series, showcasing ESWIN Computing’s powerful NPU, GPU and DSP running on Ubuntu. This development is part of a community development effort between Canonical and ESWIN Computing to bring the latest and greatest RISC-V technology to Ubuntu. See the demo live at ESWIN Computing’s booth at the RISC-V Summit in Paris, where leaders from across the RISC-V ecosystem will gather to discuss the latest innovations.
Ubuntu users can now make use of DeepSeek’s powerful reasoning model on ESWIN Computing’s cutting edge EIC77 series
With ESWIN Computing’s hardware accelerators such as NPUs, GPUs and DSPs, Ubuntu users can now maximize the usage of hardware resources available to further enhance performance. With DeepSeek, the hardware resources available can enable rapid parameter transfers during processing, therefore significantly enhancing the model’s performance. Test results from ESWIN Computing show that the EIC7700X SoC EVB development board can run at 7 tokens per second.
The availability of Ubuntu developer images on the EIC 77 series, powered by SiFive’s P550 CPU, means that users can draw upon the latest open source tooling from the Ubuntu ecosystem, whilst at the same time benefit from the robustness and stability that Ubuntu brings to novel use cases. This expands the possibilities for creative projects in AI, robotics, IoT, education, and beyond.
This success is built on top of collaboration between ESWIN Computing, SiFive and Canonical, and serves as a testament to commitment to openness and collaboration within the RISC-V community.
See the demo at RISC-V Summit in Paris
The demo will be at ESWIN Computing’s booth at RISC-V SUmmit Europe.
Check out the event details below
Venue
La Cité des Science et de l’Industrie, 30
Av. Corentin Cariou, 75019
Paris, France
Dates
May 13 – 15, 2025
Booth #31
Canonical’s commitment to RISC-V
At Canonical, we believe that it’s important to do our part to help RISC-V succeed and gain acceptance as an open standard. Ubuntu’s availability on ESWIN Computing’s EIC77 series is a testament to the continued collaboration between Canonical and the broader RISC-V community.
The partnership brings all the ease of use, robust tooling and extensive packaging ecosystem that Ubuntu is known for to a new generation of RISC-V devices.
Join the community
We believe collaboration and community support drive innovation and we invite you to join the Ubuntu and ESWIN Computing communities to share your experiences, ask questions, and help shape the future of RISC-V.
Get in touch
If you have any questions about the platform or would like information about our certification program, contact us.
This week, the Armbian development team pushed several noteworthy enhancements, with improvements spanning user experience, bootloader upgrades, and broader system support. Notably, this week saw the debut of OpenMediaVault in Armbian’s software installer, a move that brings plug-and-play NAS functionality to supported boards.
OpenMediaVault is a feature-rich platform that enables users to turn single-board computers into fully-fledged network storage devices. Thanks to a contribution by Igor, the integration is now available through armbian-config interface, giving users a streamlined way to install and configure OpenMediaVault without needing to manually manage services or packages.
The usability of the software stack also saw a meaningful improvement. A previously persistent “Disable Wireless Hotspot?” prompt was eliminated when no hotspot had been enabled, reducing unnecessary friction during the setup process. This fix helps clarify Armbian’s default network behavior for users during first boot, particularly when configuring headless or appliance-style deployments.
On the hardware front, the Orange Pi 5 Max received a key upgrade: it now boots using mainline U-Boot. This transition replaces vendor-specific boot code with upstream-supported U-Boot, easing future updates and kernel integration. A related improvement was made to the PocketBeagle2, which migrated to extlinux for boot configuration—bringing it in line with Armbian’s broader standardization efforts.
Further enhancements came to the Rockchip64 platform. Previously missing Operating Performance Points (OPPs) were added to ensure proper voltage and frequency scaling across supported boards, which improves energy efficiency and stability under load. In addition, older workarounds for wireless firmware issues were removed, as upstream drivers have now resolved the compatibility concerns that necessitated them.
Finally, infrastructure refinement continued with the cleanup of unused or deprecated build artifacts, keeping the codebase lean and future-proof. The team also laid the groundwork for upcoming testing initiatives to ensure that new features like OpenMediaVault are validated across a wide array of supported devices.
For those interested in exploring OpenMediaVault or other curated software installations, the updated documentation is available in the Armbian Software User Guide.
There is a new application available for Sparkers: Meru What is Meru? Goals: – All your inboxes in one place – Never miss an important email – Enhanced protection against phishing – Privacy without compromise – Take back control of your inbox – Runs wherever you do There are 2 versions of your choice: – Free – For personal use and single account – Pro – For professional use and…
Canonical is excited to announce the launch of DeepComputing’s new 50 TOPS DC-ROMA RISC-V AI PC and AI PC Mini with Ubuntu Desktop 24.04 LTS pre-installed. The PC was launched in collaboration with Framework and is powered by ESWIN’s advanced RISC-V AI SoC EIC7702X—featuring 8 SiFive’s high-performance P550 CPU cores .
Built on the DC-ROMA RISC-V Mainboard II designed specifically for the Framework Laptop, this new AI PC is now available on the DeepComputing Store, with prices starting from $349.
DC-ROMA RISC-V AI PC
This launch marks a major milestone for the global developer community, offering the world’s first RISC-V-based AI PC with a chiplet dual-die connected AI SoC. Built for developers pioneering edge and AI-native applications, it delivers over 40 TOPS of local AI compute, enabling complex AI models—such as large language models (LLMs)—to run entirely on-device, without relying on the cloud.
DC-ROMA RISC-V AI PC Mini
At its core is a RISC-V 64-bit, 8-core out-of-order SiFive P550 out-of-order CPU, paired with:
A 40 TOPS NPU
A 512-bit-wide vector processor
Hardware support for 8K@50FPS video encoding
Support for up to 64GB LPDDR5 memory and NVMe SSD storage
This configuration provides ample power for advanced development, prototyping, and experimentation.
What sets the DC-ROMA AI PC apart is its commitment to local, secure, and private AI execution. Developers can run LLMs and other AI workloads through optimized APIs and open-source toolchains, enabling everything from on-device chatbots and AGI-driven media experiences to audio and video synthesis — all with full control over data, performance, and cost.
Canonical is excited to work with DeepComputing and its partners to build an open, modular, and future-ready developer ecosystem. The DC-ROMA AI PC represents the next evolution in sustainable and customizable RISC-V AI computing.
This achievement is the result of a collaboration across both hardware and software ecosystems. John Ronco, SiFive SVP of Product, remarked “This is a powerful product that demonstrates the power of RISC-V open-standard computing as both a development and commercial platform. With 8 of our flexible, high-performance P550 cores, and supported by a strong and growing RISC-V developer ecosystem, the DC-ROMA AI PC will help bring scalable, secure, and efficient AI solutions to life.”
Gordan Markuš, Director of Silicon Alliances at Canonical, added: “Canonical is proud to be part of this important step for the RISC-V ecosystem. Together with DeepComputing, Framework, ESWIN, and SiFive, we’re enabling developers to build next-generation AI solutions on RISC-V leveraging Ubuntu and open source software components. This collaboration highlights the strength of the RISC-V ecosystem in uniting companies to jointly shape the future of accessible and open innovation.”
“The DC-ROMA AI PC embodies the innovation and collaboration made possible by the RISC-V ecosystem. It will accelerate new applications, enabling engineers to natively develop code for RISC-V on RISC-V.” Andrea Gallo, CTO of RISC-V International, noted. “It’s about giving developers full-stack freedom, from hardware to AI applications.” Nirav Patel, Founder and CEO of Framework, said: “This launch is a powerful demonstration of what’s possible when modular design meets open architecture. We’re happy to see DeepComputing bringing a substantially more powerful RISC-V processor to developers worldwide through the Framework Laptop ecosystem.”
This milestone would not have been possible without the close collaboration of different hardware and software partners, the dedication of open-source contributors, and the growing global community supporting the RISC-V movement. Their collective efforts helped turn the vision of an open, local-first AI PC into a reality. Yuning Liang, Founder and CEO of DeepComputing, stated: “We built this AI PC to empower developers who believe in local-first AI, open innovation, and sustainable computing. It’s a foundational step toward a more open and privacy-respecting digital future.”
Availability
Pre-orders are now open, and prices start at $349. The DC-ROMA RISC-V AI PC will be showcased at the upcoming RISC-V Summit Europe and Computex Taipei 2025. Visit the DeepComputing booth for a hands-on experience with the AI PC!
We are pleased to announce that the Plasma 6.3.5 bugfix update is now available for Kubuntu 25.04 Plucky Puffin in our backports PPA.
As usual with our PPAs, there is the caveat that the PPA may receive additional updates and new releases of KDE Plasma, Gear (Apps), and Frameworks, plus other apps and required libraries. Users should always review proposed updates to decide whether they wish to receive them.
To upgrade:
Add the following repository to your software sources list:
ppa:kubuntu-ppa/backports
or if it is already added, the updates should become available via your preferred update method.
The PPA can be added manually in the Konsole terminal with the command:
sudo add-apt-repository ppa:kubuntu-ppa/backports
and packages then updated with
sudo apt full-upgrade
We hope you enjoy using Plasma 6.3.5!
Issues with Plasma itself can be reported on the KDE bugtracker [1]. In the case of packaging or other issues, please provide feedback on our mailing list [2], and/or file a bug against our PPA packages [3].
Pardus Projesi olarak,24-27 Mayıs 2025 tarihleri arasında Ankara ATO Congresium’da düzenlenen 7. Verimlilik ve Teknoloji Fuarı'nda, TÜBİTAK Ada Standı içerisinde yerimizi alarak ziyaretçilerimizle buluştuk.
Integrating security across all stages of the development cycle is no longer just a trend — it’s a necessity. In this context, the DevSecOps approach is gaining traction by promoting a model where Development (Dev), Security (Sec), and Operations (Ops) work together from the very beginning of a project. Within this model, solutions like the SKUDONET ADC are playing an increasingly relevant role.
1. What Is DevSecOps and Why Does It Matter?
DevSecOps is an approach that aims to integrate security practices into every phase of the software development lifecycle — from planning to production. Unlike traditional models, where security is added at the end, DevSecOps embeds it from the start, enabling:
Early detection of vulnerabilities
Lower remediation costs
Better collaboration across teams
More secure and agile deployments
To make this possible, teams need tools that not only support the process but also integrate seamlessly into pipelines, deployment environments, and monitoring systems.
2. The Role of the Application Delivery Controller (ADC) in DevSecOps
In a DevSecOps strategy, security is not a final step — it’s a continuous component throughout the application lifecycle. However, many threats only become visible when the application is live and exposed to real traffic. This is where the value of an ADC comes into play.
A modern Application Delivery Controller not only ensures that applications are available, responsive, and scalable. It also serves as a critical control point in production, helping enforce the security policies and standards defined earlier in the cycle.
For example, an ADC can:
Filter and inspect incoming requests by analyzing URLs, headers, payloads, or unusual patterns that may signal attacks (e.g., injections, scans, brute force).
Block malicious or unauthorized traffic, enforcing access policies and providing real-time protection.
Detect anomalies in expected behavior, supporting early identification of breaches or vulnerabilities missed during testing.
From this perspective, the ADC acts both as an active last line of defense and as an observability tool, offering visibility into what really happens when the application is exposed. This role is essential in DevSecOps, allowing teams to:
Validate that production deployments comply with defined security criteria
Dynamically adjust security policies without service interruption
Detect and respond to threats quickly, thanks to real-time traffic visibility
In short, ADCs strengthen the delivery phase in DevSecOps, becoming an integral part of a continuous security strategy without slowing down development cycles.
3. How SKUDONET Fits into DevSecOps Environments
SKUDONET provides an ideal platform for teams implementing DevSecOps practices, combining high performance, observability, and built-in security.
Automation and integration
SKUDONET can be managed through its RESTful API and skd-cli command-line tool, allowing smooth integration into CI/CD pipelines and orchestration systems.
Observability
Integration with platforms like Grafana and Nagios enables continuous monitoring of system health, application performance, and early detection of issues.
Integrated threat prevention and visibility
SKUDONET includes a built-in Intrusion Prevention and Detection System (IPDS), featuring a Web Application Firewall (WAF) that protects applications against threats such as SQL injection, cross-site scripting (XSS), and other OWASP Top 10 attacks. This module operates at the delivery layer, enabling real-time protection without modifying application code. It also generates detailed logs and attack reports, which can be used for auditing, compliance, or integration with external security analysis tools.
Secure performance and scalability
Designed for automated deployments across multiple environments, SKUDONET ensures a seamless user experience without compromising security.
4. Key Advantages for DevSecOps Teams
Integrating SKUDONET into the DevSecOps workflow brings concrete benefits:
Simplified management directly from the deployment server via skd-cli
Seamless integration with existing automation and monitoring tools
A solid security foundation for production environments, without sacrificing deployment speed
In a DevSecOps context, every tool matters. And modern ADCs like SKUDONET are no exception — they’ve become essential components in achieving continuous, secure delivery.
SKUDONET gives you full control over traffic, deep visibility into threats in production, and an architecture built for integration with advanced automated deployment practices.
See how SKUDONET fits into your DevSecOps strategy. Try SKUDONET Enterprise Edition free for 30 days and experience its ability to combine performance, security, and automation in real-world environments.
Position: Linux graphics stack developer Company:Invisible Things Lab Location: Fully remote Employment type: Full-time (part-time considered) Salary range: €70,000–€90,000/year (full-time base salary with potential for bonuses)
(Note: For part-time contracts, the full-time base salary will be scaled accordingly.)
Job description
We’re seeking a talented developer with a focus on the Linux graphics stack in a virtualized environment, specifically in Qubes OS. Qubes OS is a free and open-source security-oriented operating system that uses the Xen hypervisor to securely compartmentalize the user’s applications, data, and devices into isolated virtual machines called “qubes” so that the compromise of any one qube does not affect the rest of the system.
This role presents exciting challenges and the opportunity to work on pioneering solutions that have never been attempted before. As a key member of our team, you will lead the migration of the Qubes OS graphics stack from X11 to Wayland, as well as implement support for rendering hardware acceleration, all while maintaining the robust security properties for which Qubes OS is known.
Responsibilities
Lead the migration of the Qubes OS graphics stack from X11 to Wayland
Implement support for rendering hardware acceleration
Ensure the strong security properties of Qubes OS are preserved throughout the development process
Collaborate with team members and contribute to open-source projects
Requirements
Strong knowledge of the Linux graphics stack, especially Wayland (familiarity with X11 a plus)
Basic understanding of kernel drivers and virtualization
Proficiency in the C programming language
Previous contributions to an open-source project
Experience with Git
Ability to work independently, proactively solve problems, and seek assistance when needed
Preferred skills
Rust
Python
RPM packaging
DEB packaging
What we offer
Fully remote work with flexible hours
Long-term contract opportunities
A collaborative and innovative work environment
How to apply
If you’re passionate about pushing the boundaries of technology and want to be part of a groundbreaking project, we would love to hear from you! Please send your CV or résumé to jobs[at]invisiblethingslab[dot]com.
Join us in shaping the future of secure computing with Qubes OS!
A Canonical levou o Miguel a redescobrir o conforto da gama de sofás-cama do IKEA e entretanto, o Diogo trouxe um saco cheio de prendas, que incluem reflexões sobre direitos digitais e privacidade em tempo de eleições, uma obsessão acumuladora com arquivos, papéis, facturas, revistas velhas e jornais cheios de pó digital e ainda uma catrefada de extensões de Firefox para todos os usos e gostos - ou não fosse isto o Podcast Firefox Portugal, o podcast sobre Firefox, a Mozilla e outras cenas.
In today’s world, privacy and control over your digital life have become rare luxuries. Every tap, swipe, and click on most smartphones and PCs is tracked, analyzed, and monetized—usually without your explicit consent. That’s where PureOS comes in. So What Is PureOS? PureOS is a privacy-focused, secure, and open-source operating system developed by Purism. […]
I’ve written about the EU Cyber Resilience Act (CRA) on our Canonical blog a few times now, and I think now’s the perfect time to talk about the implications of this new regulation and what it means for IoT and device manufacturers on the practical level of how they design and build Products with Digital Elements (PDEs).
In this blog, I’ll give you a thorough overview of common IoT manufacturer and PDE developer practices that need immediate attention, and how to change or improve these practices so that your work and PDEs can keep their place on the EU market with full CRA compliance.
What you can’t do under the CRA (and what to do instead)
In general, the things you can and cannot do under that CRA depend on how you and your PDEs are classified or categorized under this new piece of legislation. If you’re not familiar with the CRA’s wording, classifications, and requirements, you can catch up on the specifics by reading the previous articles I wrote here:
A CISO’s comprehensive breakdown of the CRA: Catch up on what the EU Cyber Resilience Act is, what the CRA requirements are, and how it will broadly affect cybersecurity design, documentation, and long-term support and vulnerability management for devices.
How the CRA will affect open source software: Get an overarching insight into how the CRA came about, the community reaction to this regulation, and what it means for open source going forward.
However, outside of the category- and classification-specific requirements of the CRA, this regulation introduces an extremely broad set of changes to IoT and PDE cybersecurity and vulnerability management that will affect everyone, regardless of where they fall under the CRA’s specific wording.
Let’s take a closer look:
No more passing the buck
No more passing security responsibility to your downstream users or expecting that your upstream providers will take care of vulnerabilities. In fact, building and shipping things often means you will be categorized as a manufacturer, which means that you will be burdened with an increased level of compliance assessment and higher demands for PDE compliance.
If you don’t want to bear the brunt of Manufacturer compliance, you should find a supplier willing to assume that responsibility.
You can no longer hide behind documentation – or treat it as optional
You can no longer hide behind documentation. If there are vulnerabilities, limitations, or flaws in the PDE, or specific outlines for its use, you cannot simply expect users to have fully read your documentation and follow these hard-to-find instructions to use your product safely.
On a practical level, this means that instead of simply documenting vulnerabilities and communication – for example, telling users not to use the device on unsecured networks, to change the password before use, or to manually disable certain ports or features before use. It’s no longer enough to document vulnerabilities and then warn users about them: you need to patch them yourself.
And when it comes to documentation, the CRA outlines stricter requirements for how to approach your docs and make them accessible. In general, the CRA means you will have new documentation requirements, with more communication around where this documentation can be accessed, and you’ll need to produce a software supply chain and formal software bill of materials (SBOM) that is accessible and machine readable.
As a minimum, you need to have the following documented and available for the public and EU authorities:
A description of the design, development, and vulnerability handling process
An assessment of cybersecurity risks
A list of harmonised EU cybersecurity standards the product meets
A signed EU Declaration of Conformity that the above essential requirements have been met
A Software Bill of Materials (SBOM) documenting vulnerabilities and components in the product
You can no longer hide behind intention
It’s not just documentation that you can’t use as a crutch or shield – intention is out too.
This means that you can’t defend flaws, design issues, or vulnerabilities as intentional design choices. For example, if your device has ports, features, or functionality that could reasonably be used to access the device or connect to networks, you need to take steps to mitigate the risks and attack vectors that these elements pose.
In the next section, we’ll go through some of the practical steps you can take to address device cybersecurity.
The security basics are no longer optional
Many of the requirements of the CRA simply formalize cybersecurity practices and security features that should be considered as minimum standards. By this I’m referring to things like shipping with known vulnerabilities, expecting users and consumers to secure your devices after purchase, ignoring cybersecurity fundamentals like no default admin-password credentials, or hiding behind obscure or inadequate documentation.
Some of these cybersecurity essentials include:
Ensuring that whatever you’re building is as secure as it can be. It must have minimal attack surfaces.
Hardening your device or product. Its data must be encrypted or protected and it must prevent unauthorized access.
Preventing downtime. Your device must keep working, even under DDoS attack, and it mustn’t interrupt other devices, even when attacked with exploits.
Keeping track of activity. Your device needs to be able to provide security data by monitoring or logging changes in the device.
Proactive patching. Your product needs to be able to receive security updates or rollbacks. This includes direct or remote updates, user notifications about updates, and the ability to roll back updates or reset the product to a factory/default state.
Even without the CRA compelling you to meet higher cybersecurity standards, you should be meeting these basic standards in PDE security design. Here are some steps you could take to ensure your PDEs are as robust and secure as possible before they reach the market:
Implement a Zero Trust Architecture wherever possible
Ensure that your authentication, authorization, and access control are fully secure (and that you have control over your credentials)
Use Secure by Default configurations
Minimize your attack surface – if your device, system, or organization isn’t actively using something (whether it’s a port, component, or package), then disable it by default until it’s needed
Ensure proper use of cryptography to ensure data is protected at rest and in transfer, that traffic is encrypted, and that you avoid plaintext or cleartext data
Validate all input and handle all exceptions
Secure all individual components and their dependencies, not just the stack
Minimize the access permissions of apps and systems, and design your baseline to stop server-side request forgery from Day Zero
Use automated security patching software to ensure that validated and authenticated security updates, CVE fixes, and other patches are downloaded timeously and automatically
In short, the goldrush of taking unsafe IoT devices to market is over: consumers have higher expectations for the security and privacy of the devices they use, and if your products don’t meet them, it will lead only to disaster down the line. We understand the serious impacts that CVEs have on users and businesses alike, which is why we take such a strong commitment to patching critical CVEs within 24 hours through Ubuntu Pro.
Ubuntu Pro gives organizations a hands-free, automated way of receiving vital software packages and security updates for up to 12 years, ensuring that they’re covered no matter what new vulnerabilities or regulatory compliance comes up.
You can no longer ignore products after launch
Another priority you should focus on is patching and vulnerability management for your devices and software. One of the CRA’s primary requirements is to ensure that your devices can be securely updated against new vulnerabilities. Your updates must be free and sent out as soon as vulnerabilities are discovered, along with information to users about what actions they should take.
When this happens, you need to provide:
A description of the vulnerabilities and their severity
Information allowing users to identify the product with digital elements affected
The impacts of the vulnerabilities
Information helping users to remediate the vulnerabilities
What’s more, these patching and security update efforts must be long term, and cover the PDE’s entire lifecycle. You must regularly test the product, and fix vulnerabilities immediately – and once a fix has been applied, you need to publicly disclose what the fixed vulnerability was (in line with the new coordinated public disclosure policy you need to have, under the CRA).
And for a period of a maximum of 5 years (or the product lifespan, whichever is shorter) you’ll be required to recall or withdraw products that don’t meet conformity standards of the CRA.
Get vital CRA compliance insights in our CRA compliance guide video
No more hidden or gray dependencies
Whether you’re classified as a manufacturer or not, you still need to think about your software supply chain like a manufacturer does. This is because the CRA introduces new requirements for documentation, transparent software supply chains, and a software bill of materials to show your software is securely sourced. As a minimum, you should be consuming trusted open source only, or only sourcing packages from trusted suppliers.
If you’re unsure about your software supply chain and its ability to meet the CRA’s regulatory standards, documentation requirements, vulnerability disclosure demands and transparency expectations, you should evaluate your service and software providers to choose those who make it effortless to meet your CRA obligations.
Generally, this means picking a vendor who meets one of the following criteria:
Has a CE marking
Can provide supply chain certification
Has decided to take on the category of ‘Manufacturer’
Our recommendation is to consume packages or software updates from large and trusted suppliers who have taken on responsibility for CRA compliance. This means that you should be sourcing versions of your open source software, (or security patches for that software) directly from a vendor who has decided to take on the category of ‘Manufacturer’ in the software supply chain.
At Canonical we understand how important this is, which is why we’ve committed to meeting the manufacturer responsibilities for many of our products. The many, many tools and products we develop and maintain at Canonical – Ubuntu; our distributions of Kubernetes, MicroCloud, and OpenStack; and more – are designed with security in mind, supported through security maintenance and vulnerability patching, and aligned with the regulatory oversight in the CRA. On top of this, services like Ubuntu Pro for Devices ensure your devices will receive security maintenance for up to 12 years.
No more “market-first” approach
The days of “move fast and break things” are over. Under the CRA, you cannot hyperfocus on market timing or a launch date and ship an MVP that skimps on security design and long-term support. Instead, you need to build on a strong foundation for security and support for your packages and software that extends for many years past your launch date.
You should be reassessing your choices – of OS, development environment, and software vendors – to meet this new change. And the systems you do choose should give both the robust baseline of security and the long-term security support the CRA requires – as well as the minimized attack surface that reduces the number of attack vectors and vulnerabilities as much as possible.
Luckily, this has benefits that go beyond security: a minimized attack surface, device-optimized OS, or containerized build keeps everything to the smallest footprint possible – which means faster performance, lower device specification requirements, and cheaper manufacturing costs. In fact, Ubuntu Core (the embedded Linux OS for devices) takes these requirements and benefits to heart: it acts as a pared-down, strictly confined flavor of Ubuntu for embedded devices. Ubuntu Core has an optimized profile that’s perfect for devices that have limited specifications or hardware but which still demand robust security, long-term maintenance, and high levels of on-device performance.
Summary of what you need to change to meet CRA compliance
In conclusion, the CRA means that a lot of things have changed. Gone are the days of hiding behind obscure documentation, passing the buck to manufacturers or users, or launching market-first, “fire-and-forget” devices with unknown dependencies and no support. However, by intensifying the security of your PDEs with cybersecurity basic practices, consuming trusted packages and security updates from a manufacturer-category supplier with a long-term support program, and building a clear list of your software supply chain and dependencies, you can easily meet these new requirements head-on, and access the EU market for years to come.
To sum everything up, if you want to meet the new challenges and requirements of the CRA head-on, you need to follow these simple 6 steps:
Adopt best practices for PDE hardening and device security
Implement cybersecurity hardening to the greatest extent possible
Conduct your compliance assessment and testing as soon as you can
Document everything and make it publicly available, along with SBOMs that show your software composition and dependencies
Take a customer-first approach, and beware of rushing an MVP to market
Pick vendors who take on manufacturer responsibility for packages/software
Find out how you can design and support CRA-ready PDEs by bringing up to 12 years of automated security patching to your device by visiting www.ubuntu.com/pro
Learn how Ubuntu Core is ideal for your PDEs, IoT devices, and all embedded systems by visiting www.ubuntu.com/core
This release of Clonezilla live (20250504-plucky) includes major enhancements and bug fixes.
ENHANCEMENTS and CHANGES from 20250303-oracular
The underlying GNU/Linux operating system was upgraded. This release is based on the Ubuntu Plucky Puffin (25.04) repository (as of 2025/May/04).
Linux kernel was updated to 6.14.0-15.15.
Partclone was updated to 0.3.36.
Added packages libfsapfs-utils, usb-modeswitch and fscrypt in Clonezilla live system.
Added new program ocs-find-live-key & updated ocs-put-log-usb so that it can copy the log files even when Clonezilla live USB drive is used in "To RAM" mode. It will find the USB key that: (1) is vFAT file system and (2) contains the file "Clonezilla-Live-Version", then it will be treated as Clonezilla live USB drive.
ocs-live-repository: added dev=///OCS_LIVE_USB so that the Clonezilla live USB drive can be assigned as the image repo, especially when Clonezilla live USB drive is booted in "To RAM" mode. The Clonezilla live USB drive has to be vFAT file system since it's used to boot in both uEFI and MBR mode. Hence it is not a good choice for image repo since vFAT file system has many restrictions. Better to use UUID or LABEL to assign the image repo.
Improved the saving dialog menu and prompt.
Added a mechanism to mitigate the random order of block devices. It can be enabled by adding the boot parameter "ocs_1_cpu_udev", i.e., when udev is started in initramfs, only 1 CPU is online. After that, all CPUs will be enabled.
drbl-ocs.conf: enabled btrfs support in drbl-ocs.conf since Partclone has been updated to 0.3.36 which supports btrfs v6.13.
BUG FIXES
Disabled devices list cache mechanism since blkid is run too many times that makes program run slowly.
Early May brought another round of steady advancements to the Armbian project, with progress in U-Boot updates, board enablement, firmware fixes, and notable improvements to Armbian’s growing catalog of self-hosted applications.
Bootloader and Firmware Enhancements
Several platforms saw significant U-Boot improvements. The Cherryba-M1 now benefits from an upgraded U-Boot and reorganized patch structure, thanks to Igor‘s work on upgrading Cherryba-M1 to latest u-boot and moving patch to new folder. Andy bumped U-Boot to v2025.04 for the Lubancat2, keeping the board current. The Radxa Rock 4 SE also migrated to this version, where Niklasrefined its configuration and boot behavior.
Meanwhile, the Khadas VIM3 received a broader bootloader overhaul led by Ricardo, introducing SD-first boot order, squashfs and fileenv support, and enhanced compatibility with Home Assistant OS in a comprehensive update to U-Boot for Khadas VIM3.
Older configurations didn’t go unnoticed: Igor removed deprecated ATF tags for sun50iw9 / H61x, while Olaf pushed the sunxi64 platform to the latest LTS version of ATF.
Expanding Device Support
Armbian continues to grow its ecosystem. Rolf introduced official support for the Banana Pi M2+, making it easier for users to deploy on this compact board. On the RISC-V side, libiunc brought the kernel for the StarFive2 platform up to v6.6, ensuring ongoing support and compatibility.
Installer Improvements and Runtime Fixes
Improving install experience, Igor Velkov added Btrfs root subvolume support when installing to NVMe, paving the way for better snapshot and maintenance workflows. Igor also corrected missing Broadcom firmware for Raspberry Pi boards to fix wireless support and suppressed firmware warnings related to built-in Realtek USB network drivers, helping clean up logs and reduce confusion.
Self-Hosted App Catalog Grows
The list of installable apps during Armbian setup has expanded. Two powerful platforms are now just a selection away:
Immich, a self-hosted photo and video backup system, was added with the introduction of Immich to configNG.
NetBox, a leading infrastructure resource management solution, joined the roster in the addition of NetBox to Armbian configNG.
Both are available via the configNG provisioning interface.
Deprecations and Housekeeping
Support for legacy distributions has now ended: Debian Bullseye and Ubuntu Focal and Jammy will no longer receive repository updates, as noted in the userspace status change to EOS.
Elsewhere, dependency and CI maintenance continued. Automated tools like Dependabot bumped packages such as setuptools and GitHub actions for changed-files, while amazingfate restored support for the AIC8800 Wi-Fi driver by reverting a mistaken disable.
Today, IBM announced the launch of their latest server: the new IBM LinuxONE Emperor 5. This fifth generation redefines IBM’s LinuxONE system as their most secure and high-performing Linux computing platform for data, applications and trusted AI.
Canonical supports LinuxONE Emperor 5 with Ubuntu Server. Ubuntu is cost-efficient and easy to install and manage on the servers – all whilst enabling the most up-to-date LinuxONE hardware features. Ubuntu Server for IBM Z and LinuxONE is ready for deployment from day one.
This blog provides an overview of the IBM LinuxONE Emperor 5’s key features, and will demonstrate why Ubuntu Server is the right choice of software to install.
The new system was developed towards three main aspects and goals:
1. Industry-leading cyber security and privacy
IBM LinuxONE Emperor 5 lets users deploy confidential containers, and use quantum-safe encryption which can be scaled and unified across an enterprise.
Ubuntu Server for IBM Z and LinuxONE is also designed with security in mind, making the perfect fit for the security features of the IBM LinuxONE 5 generation hardware.
Canonical uses high security cryptography algorithms and disables weak cryptography algorithms by default. Ubuntu Server for IBM Z and LinuxONE is one of the very first Linux distributions that introduced Secure Execution support (since 20.04), and provides support for pervasive encryption in all dimensions, be it data at-rest, in-flight, or in-use. Ubuntu Server for IBM Z and LinuxONE supports quantum-safe cryptography, requiring only two commands to do so, and making use of the IBM LinuxONE 5 generation’s quantum-safe encryption becomes a transparent and easy process.
Canonical’s Kernel Livepatch service (Pro) delivers kernel patches for high or critical vulnerabilities that can be applied to a running kernel, without needing immediate downtime, so the system can continue running.
Ubuntu is built for compliance, and has various security certifications including FIPS.
IBM’s enterprise class of LinuxONE systems is renowned for its large-scale workload consolidation which can result in significant savings on energy, space, and operational costs.
These strengths improve with each new hardware generation, as overall resources and performance increase whilst maintaining the system’s maximum energy consumption at a steady level. IBM LinuxONE Emperor 5 includes up to 208 customer cores, up to 64TB of memory, and introduces a simplified system IO architecture.
By choosing Ubuntu Pro to run on the IBM servers, you can get Expanded Security Maintenance for open source at a transparent rate with our unique drawer-based pricing. Learn more about the benefits of an Ubuntu Pro subscription here.
3. Built-in AI, engineered for better outcomes
On the IBM LinuxONE Emperor 5, you can develop AI models in a hybrid cloud and run inference alongside data and applications within a trusted execution environment (TEE), enhancing prediction accuracy using a multiple model AI approach with the integration AI accelerator in Telum II, and scale AI while maximizing energy efficiency. In addition, the previously announced Spyre is expected to become available in 2025, and will enable Generative AI applications to be developed and run.
Ubuntu is a popular choice for most AI and machine learning researchers. Ubuntu balances ease of use, compatibility with the larger AI stacks and popular frameworks, and support from the open-source community or commercial support through Ubuntu Pro.
Canonical is working hard to ensure Telum II (of LinuxONE 5) and the upcoming Spyre Accelerator card are supported on Ubuntu Server, allowing users to deploy a multiple AI model approach in the future and as well as hardware-assisted generative AI.
After 9 years of LinuxONE and IBM Z (s390x) platform support, Canonical is proud that Ubuntu Server plays a central role in open source workloads, helping to make LinuxONE 5 generation easier to use, more secure, more reliable, and available to all at scale.
How do you build robust, performant edge AI infrastructure? This is the question organizations are asking themselves when looking to capitalize on the opportunity of edge AI.
Ubuntu IoT Day is your opportunity to find out – and it’s coming to Singapore! Join us on May 27 to discover how Canonical and our IoT partners are powering innovation in edge computing, AI, and secure IoT at scale.
Wondering what to expect? Here’s a quick rundown:
150+ attendees from Southeast Asia’s embedded and industrial tech community
Technical sessions, live demos, and real-world use cases
Expert speakers and partner showcases
The latest in regulation-ready open source solutions for IoT and Edge AI
This full-day event brings together system integrators, hardware manufacturers, and software architects to explore the latest advancements in embedded Linux, edge computing, and security.
Join us in shaping the future of edge AI with Ubuntu
Open source is already at the heart of AI – a 2025 report by McKinsey revealed that, across the board, more than half of organizations are already using open source AI tooling.
But why stop at tooling? As AI applications move closer to the edge, businesses need powerful, secure, and reliable platforms to stay ahead. Open source software provides you with the latest innovations, with the flexibility and control required to be both fast-moving and compliant. Ubuntu provides all the benefits of the open source ecosystem, wrapped up in enterprise-grade support.
So what does this look like in practice? Ubuntu IoT Day is your opportunity to engage with Canonical engineers, explore real-world use cases, and connect with partners building the next generation of smart, compliant devices.
We’ll be covering key topics like:
Implementing edge AI at scale with open-source solutions
Accelerating time-to-market with certified hardware and Ubuntu Core
Managing device fleets with real-time monitoring and long-term support
Reach CRA cybersecurity compliance
During the event, we will be available to help you navigate the requirements of the Cyber Resilience Act (CRA) and ensure your Ubuntu-based devices meet compliance standards. As the CRA introduces new cybersecurity regulations impacting device design, deployment, and maintenance – from secure software development to long-term vulnerability management – understanding these changes is crucial to maintaining market access.
Join us to learn how to:
Unlock additional security updates, hardening profiles, and get up to 10 years of security maintenance with Ubuntu Pro for Devices, our enterprise subscription.
Harness Landscape, Canonical’s systems management tool, to monitor fleets and track vulnerabilities in real-time.
Harden your Ubuntu-based devices by implementing security best practices, such as kernel hardening, access controls, and secure update mechanisms.
Explore how Ubuntu Core brings the benefits of Ubuntu to embedded devices through a minimal, strictly containerized architecture.
For those looking for complete security and industrial-grade deployments, Ubuntu Core is a reliable embedded Linux OS for the Internet of Things (IoT), devices, and edge systems. It encapsulates every system component, along with the system itself, into a set of containers. These containers operate with strict kernel-enforced confinement, ensuring security and stability. Ubuntu Core supports reliable over-the-air updates, minimizing disruptions. Additionally, failsafe rollbacks provide a safety net, making it ideal for intelligent edge and IoT applications.
Experience innovation first-hand from our partners
Ubuntu is at the heart of a well-established hardware ecosystem. We work directly with silicon vendors and ODMs to certify their devices, ensuring that innovators like you get the full, performant Ubuntu experience, out of the box.
But don’t just take our word for it. Join us at Ubuntu IoT Day and learn how Canonical works closely with partners to deliver devices that are optimized for performance, security, and regulatory compliance — ready for real-world deployment.
At the event, you’ll be able to:
Learn how Canonical’s IoT program bridges the gap from silicon vendors, ODMs to end customers and accelerate your IoT development
See live demos on devices running Ubuntu from Aaeon, Adlink, Advantech, ASUS IoT, Everfocus and Qualcomm.
Join key sessions covering topics such as AI and robotics development from Mediatek, ARM, Aaeon, Advantech and more.
Meet our silicon and ODM partners who are shaping the future of industrial AI.
Join us
Whether you’re building IoT gateways, deploying AI at the edge, or managing large fleets of devices with Ubuntu, we’re here to help you build smarter and ship faster.
Your learning journey doesn’t end at Ubuntu IoT Day. Discover more about defining your software stack for embedded devices in our latest whitepaper.
Which embedded Linux distribution should you choose? In this whitepaper, you can learn how to ensure your embedded devices meet the requirements of the Cyber Resilience Act (CRA). This whitepaper explores the critical considerations for device manufacturers, developers, and relevant stakeholders when choosing between custom-built Linux distributions using the Yocto Project and commercially supported solutions like Ubuntu Core.
Our newly developed product OPENVAS REPORT integrates the data from practically any number of Greenbone Enterprise Appliances and brings it into a clearly structured dashboard. The user-friendly and comprehensive interface considerably simplifies the protection and safeguarding of even large networks. Greenbone AG has been developing leading open source technologies for automated vulnerability management since 2008. […]
(This testers wanted announcement might in future be transformed into a stable release announcement if no major issues are found during the testing period.)
About 90% of my Debian contributions this month were
sponsored by Freexian.
You can also support my work directly via
Liberapay.
Request for OpenSSH debugging help
Following the OpenSSH work described below, I have an open
report about the sshd server sometimes
crashing when clients try to connect to it. I can’t reproduce this myself,
and arm’s-length debugging is very difficult, but three different users have
reported it. For the time being I can’t pass it upstream, as it’s entirely
possible it’s due to a Debian patch.
Is there anyone reading this who can reproduce this bug and is capable of
doing some independent debugging work, most likely involving bisecting
changes to OpenSSH? I’d suggest first seeing whether a build of the
unmodified upstream 10.0p2 release exhibits the same bug. If it does, then
bisect between 9.9p2 and 10.0p2; if not, then bisect the list of Debian
patches. This would be extremely helpful, since at the moment it’s a bit
like trying to look for a needle in a haystack from the next field over by
sending instructions to somebody with a magnifying glass.
I enabled the new --with-linux-memlock-onfault configure option to protect
sshd against being swapped out, but this turned out to cause test failures
on riscv64, so I disabled it again there. Debugging this took some time
since I needed to do it under emulation, and in the process of setting up a
testbed I added riscv64 support to
vmdb2.
In coordination with the wtmpdb
maintainer, I enabled the new Y2038-safe native wtmpdb support in OpenSSH,
so wtmpdb last now reports the correct tty.
Since we added dput-ng integration to
Debusine
recently, I wanted to make sure that it was in good condition in trixie, so
I fixed dput-ng: will FTBFS during trixie support
period. Previously a similar bug had been
fixed by just using different Ubuntu release names in tests; this time I
made the tests independent of the current supported release data returned by
distro_info, so this shouldn’t come up again.
We also ran into dput-ng: —override doesn’t override profile
parameters, which needed somewhat more
extensive changes since it turned out that that option had never worked. I
fixed this after some discussion with Paul Tagliamonte to make sure I
understood the background properly.
man-db
I released man-db
2.13.1. This just
included various small fixes and a number of translation updates, but I
wanted to get it into trixie in order to include a contribution to increase
the MAX_NAME constant,
since that was now causing problems for some pathological cases of manual
pages in the wild that documented a very large number of terms.
Before container technologies like Docker came into play, applications were typically run directly on the host operating system—either on bare metal hardware or inside virtual machines (VMs). While this method works, it often leads to frustrating issues, especially when trying to reproduce setups across different environments.
This becomes even more relevant in the amateur radio world, where we often experiment with digital tools, servers, logging software, APRS gateways, SDR applications, and more. Having a consistent and lightweight deployment method is key when tinkering with limited hardware like Raspberry Pi, small form factor PCs, or cloud VPS systems.
The Problem with Traditional Software Deployment
Let’s say you’ve set up an APRS iGate, or maybe you’re experimenting with WSJT-X for FT8, and everything runs flawlessly on your laptop. But the moment you try deploying the same setup on a Raspberry Pi or a remote server—suddenly things break.
Why?
Common culprits include:
Different versions of the operating system
Mismatched library versions
Varying configurations
Conflicting dependencies
These issues can be particularly painful in amateur radio projects, where specific software dependencies are critical, and stability matters for long-term operation.
You could solve this by running each setup inside a virtual machine, but VMs are often overkill—especially for ham radio gear with limited resources.
Enter Docker: The Ham’s Best Friend for Lightweight Deployment
Docker is an open-source platform that allows you to package applications along with everything they need—libraries, configurations, runtimes—into one neat, portable unit called a container.
Think of it like packaging up your entire ham radio setup (SDR software, packet tools, logging apps, etc.) into a container, then being able to deploy that same exact setup on:
A Raspberry Pi
A cloud server
A homelab NUC
Another ham’s machine
Why It’s Great for Hams:
Lightweight – great for Raspberry Pi or low-power servers
Fast startup – ideal for services that need to restart quickly
Reproducible environments – makes sharing setups with fellow hams easier
Isolation – keeps different radio tools from interfering with each other
Many amateur radio tools like Direwolf, Xastir, Pat (Winlink), and even JS8Call can be containerized, making experimentation safer and more efficient.
Virtual Machines: Still Relevant in the Shack
Virtual Machines (VMs) have been around much longer and still play a crucial role. Each VM acts like a complete computer, with its own OS and kernel, running on a hypervisor like:
VirtualBox
VMware
KVM
Hyper-V
With VMs, you can spin up an entire Windows or Linux machine, perfect for:
Running legacy ham radio software (e.g., old Windows-only apps)
Simulating different operating systems for testing
Isolating potentially unstable setups from your main system
However, VMs require more horsepower. They’re heavy, boot slowly, and take up more disk space—often not ideal for small ham radio PCs or low-powered nodes deployed in the field.
Quick Comparison: Docker vs Virtual Machines for Hams
Feature
Docker
Virtual Machine
OS
Shares host kernel
Full OS per VM
Boot Time
Seconds
Minutes
Resource Use
Low
High
Size
Lightweight
Heavy (GBs)
Ideal For
Modern ham tools, APRS bots, SDR apps
Legacy systems, OS testing
Portability
High
Moderate
Ham Radio Use Cases for Docker
Here’s how Docker fits into amateur radio workflows:
Run an APRS iGate with Direwolf and YAAC in isolated containers.
Deploy SDR receivers like rtl_433, OpenWebRX, or CubicSDR as containerized services.
Set up a Winlink gateway using Pat + ax25 tools, all in one container.
Automate and scale your APRS bot, or APRS gateway using Docker + cron + scripts.
Docker makes it easier to test and share these setups with other hams—just export your Docker Compose file or image.
When to Use Docker, When to Use a VM
Use Docker if:
You’re building or experimenting with modern ham radio apps
You want to deploy quickly and repeatably
You’re using Raspberry Pi, VPS, or low-power hardware
You’re setting up CI/CD pipelines for your scripts or bots
Use VMs if:
You need to run legacy apps (e.g., old Windows logging software)
You want to simulate full system environments
You’re working on something that could crash your main system
Final Thoughts
Both Docker and VMs are powerful tools that have a place in the modern ham shack. Docker offers speed, portability, and resource-efficiency—making it ideal for deploying SDR setups, APRS bots, or automation scripts. VMs, on the other hand, still shine when you need full system emulation or deeper isolation.
At the end of the day, being a ham means being an experimenter. And tools like Docker just give us more ways to explore, automate, and share our radio projects with the world.
Incus is a manager for virtual machines and system containers.
A virtual machine (VM) is an instance of an operating system that runs on a computer, along with the main operating system. A virtual machine uses hardware virtualization features for the separation from the main operating system. With virtual machines, the full operating system boots up in them. While in most cases you would run Linux on a VM without a desktop environment, you can also run Linux with a desktop environment (like in VirtualBox and VMWare).
A system with support for hardware virtualization so that it can run virtual machines.
A virtual machine image of your preferred Linux desktop distribution.
Cheat sheet
You should specify how much RAM memory you are giving to the VM. The default is only 1GiB of RAM, which is not enough for desktop VMs. The --console=vga launches for you the Remote Viewer GUI application to allow you to use the desktop in a window.
$ incus image list images:desktop # List all available desktop images
$ incus launch --vm images:ubuntu/jammy/desktop mydesktop -c limits.memory=3GiB --console=vga
$ incus console mydesktop --type=vga # Reconnect to already running instance
$ incus start mydesktop --console=vga # Start an existing desktop VM
Availability of images
Currently, Incus provides you with the following VM images of Linux desktop distributions. The architecture is x86_64.
Run the following command to list all available Linux desktop images. incus image is the section of Incus that deals with the management of images. The list command lists the available images of a remote/repository, the default being images: (run incus remote list for the full list of remotes). After the colon (:), you type filter keywords, and in this case we typed desktop to show images that have the word desktop in them (to show only Desktop images). We are interested in a few columns only, therefore -c ldt only shows the columns for the Alias, the Description and the Type.
These images have been generated with the utility distrobuilder, https://github.com/lxc/distrobuilder The purpose of the utility is to prepare the images so that when we launch them, we get immediately the desktop environment and do not perform any manual configuration. The configuration files for distrobuilder to create these images can be found at https://github.com/lxc/lxc-ci/tree/main/images For example, the archlinux.yaml configuration file has a section to create the desktop image, along with the container and other virtual machine images.
The full list of Incus images are also available on the Web, through the website https://images.linuxcontainers.org/ It is possible to generate more such desktop images by following the steps of the existing configuration files. Perhaps a Kali Linux desktop image would be very useful. In the https://images.linuxcontainers.org/ website you can also view the build logs that were generated while building the images, and figure out what parameters are needed for distrobuilder to build them (along with the actual configuration file). For example, here are the logs for the ArchLinux desktop image, https://images.linuxcontainers.org/images/archlinux/current/amd64/desktop-gnome/
Up to this point we got a list of the available virtual machine images that are provided by Incus. We are ready to boot them.
Booting a desktop Linux VM on Incus
When launching a VM, Incus provides by default 1GiB RAM and 10GiB of disk space. The disk space is generally OK, but the RAM is too little for a desktop image (it’s OK for non-desktop images). For example, for an Ubuntu desktop image, the instance requires about 1.2GB of memory to start up and obviously more to run other programs. Therefore, if we do not specify more RAM, then the VM would struggle to make do of the mere 1GiB of RAM.
Booting the Ubuntu desktop image on Incus
Here is the command to launch a desktop image. We use incus launch to launch the image. It’s a VM, hence --vm. We are using the image from the images: remote, the one called ubuntu/plucky/desktop (it’s the last from the list of the previous section). We configure a new limit for the memory usage, -c limits.memory=3GiB, so that the instance will be able to run successfully. Finally, the console is not textual but graphical. We specify that with --console=vga which means that Incus will launch the remote desktop utility for us.
I closed the desktop window but the VM is running. How do I get it back up?
If you closed the Remote Viewer window, you can get Incus to start it again with the following command. By doing so, you are actually reconnecting back to the VM and continue working from where you left off.
We are using the incus console action to connect to the running mydesktop instance and request access through the Remote Viewer (rather than a text console).
$ incus console mydesktop --type=vga
Error: This console is already connected. Force is required to take it over.
You are already connected to the desktop VM with the Remote Viewer and you are trying to connect again. Either go to the existing Remote Viewer window, or add the parameter --force to close the existing Remote Viewer window and open a new one.
Error: Instance is not running
You are trying to connect to a desktop VM with the Remote Viewer but the instance (which already exists) is not running. Use the action incus start to start the virtual machine, along with the --type=vga parameter to get Incus to launch the Remote Viewer for you.
$ incus start mydesktop --console=vga
I get no audio from the desktop VM! How do I get sound in the desktop VM?
This requires extra steps which I do not show yet. There are three options. The first is to use the QEMU device emulation to emulate a sound device in the VM. The second is to somehow push an audio device into the VM so that this audio device is used exclusively in the VM (have not tried this but I think it’s possible). The third and perhaps best option is to use network audio with PulseAudio/Pipewire. You enable network audio on your desktop and then configure the VM instance to connect to that network audio server. I have tried that and it worked well for me. The downside is that the Firefox snap package in the VM could not figure out that there is network audio there and I could not get audio in that application.
How do I shutdown the desktop VM?
Use the desktop UI to perform the shutdown. The VM will shut down cleanly.
Error: Failed instance creation: The image used by this instance is incompatible with secureboot. Please set security.secureboot=false on the instance
You tried to launch a virtual machine with SecureBoot enabled but the image does not support SecureBoot. You need to disable SecureBoot when you launch this image. The instance has been created but is unable to run unless you disable SecureBoot. You can either disable SecureBoot through an Incus configuration for this image, or just delete the instance, and try again with the parameter -c security.secureboot=false.
Here is how to disable SecureBoot, then try to incus start that instance.
$ incus config set mydesktop security.secureboot=true
Here is how you would enable that flag when you launch such a VM.
Note that official Ubuntu images can work with SecureBoot enabled, most others don’t. It has to do with the Linux kernel being digitally signed by some certification authority.
Error: Failed instance creation: Failed creating instance record: Add instance info to the database: Failed to create “instances” entry: UNIQUE constraint failed: instances.project_id, instances.name
This error message is a bit cryptic. It just means that you are trying to create or launch an instance while the instance already exists. Read as Error: The instance name already exists.
The 4th monthly Sparky project and donate report of the 2025: – Linux kernel updated up to 6.14.4, 6.12.25-LTS, 6.6.88-LTS – Sparky 7.7 of the stable line released – added to repos: ElecWhat Many thanks to all of you for supporting our open-source projects. Your donations help keeping them and us alive. Don’t forget to send a small tip in May too, please. * Keep in mind that some…
Remove firmware for the Wi-Fi interfaces based on the BCM4301 and BCM4306
chips. (#20887)
We believe that these interfaces are only available on computers that are too
old to start Tails. Please let us know if your Wi-Fi stopped
working in Tails 6.15.
The Unsafe Browser appears in the window list bar with the Tor Browser icon.
(#20934)
Additional software may initially
fail to install the first time you start Tails after upgrading. This should be
fixed shortly after you connect to Tor.
Connecting to the Internet with USB tethering is broken with some phones.
(#20940)
Get Tails 6.15
To upgrade your Tails USB stick and keep your Persistent Storage
Automatic upgrades are available from Tails 6.0 or later to 6.15.
If you cannot do an automatic upgrade or if Tails fails to start after an
automatic upgrade, please try to do a manual upgrade.
O Miguel abriu um terminal e escreveu sudo do-release-upgrade às 11h30 do dia 29 de Abril. E o país ficou às escuras. Coincidência? Revelamos todos os detalhes de uma investigação bombástica que revelará os segredos chocantes de uma sociedade secreta de GNU-Linux que governa o mundo e que envolve pessoas tão famosas como o Diogo, a Soficious, HatRat e o PewDiePie - uma sociedade que opera nas trevas (literalmente) e que é tão poderosa que obrigou o governo Federal Alemão a usar formatos abertos! Para além disso, ainda falámos sobre as últimas novidades compartimentadas de Firefox 138 e os próximos eventos da agenda: Raspberry Pi Jam, Open Lab no LCD Porto, Encontros Ubuntu, Encontros nacionais do Community Day de Home Assistant e datas para a Wikicon Portugal.
Some time in late April, Dropbox has been putting up this notification:
(Sorry, it's an image because that popup doesn't support copy/paste.)
It looks as if the traditional system tray icon will stop working on that date. Any BunsenLabs users who are running Dropbox will probably have these options:
1) Switch from tint2 to xfce4-panel, and install xfce4-indicator-plugin. Since xfce4-panel will become default on BunsenLabs Carbon anyway, that might be the path of least resistance.
2) Forget about the tray icon and control Dropbox via the CLI interface. Maybe someone will put in the time to develop a custom systemtray-icon frontend to the CLI.
3) Switch from Dropbox to some other cloud service.
This public beta enables the full Ubuntu Desktop experience on the Qualcomm Dragonwing™ QCS6490 and QCS5430 processors and complements existing Ubuntu Server support with significant enhancements. Together, these updates provide a powerful development environment for building next-generation AI-driven edge applications.
April 30, 2025 –
Canonical, the publisher of Ubuntu and provider of open source security, support and services, today announced the beta release of Ubuntu 24.04 Desktop and Server images for the Dragonwing QCS6490 and QCS5430 processors. This release marks a major milestone: the release of the first official Ubuntu Desktop image on Dragonwing processors, delivering the full Ubuntu Desktop experience at the edge.
This new beta image is designed for developers, ODMs/OEMs, and customers across industrial, and embedded IoT sectors. It unlocks powerful AI capabilities at the edge, combining advanced graphics, multimedia support, and on-device machine learning into a unified platform for next-generation applications. Certified versions of Ubuntu 24.04 Desktop and Server images will soon be available with long term support and maintenance.
This beta program is completely open to the public: developers will be able to download and flash the images on the Qualcomm Dragonwing™ RB3 Gen2 Vision and RB3 Gen2 Lite Vision kits by following the instructions on Canonical’s Qualcomm IoT Platforms portal.
“This release is a significant step towards delivering the full Ubuntu experience on our intelligent edge,” said Pragya Pathi, Director of Product Management at Qualcomm Technologies, Inc. “By enabling Ubuntu Desktop and Server on the Dragonwing reference boards hardware, we’re empowering developers to build and deploy next-generation IoT solutions across a wide range of edge use cases.”
Bringing the full Ubuntu experience to a broad spectrum of intelligent edge use cases
This announcement follows the beta release of Ubuntu Server 22.04, adding a completely new set of Ubuntu desktop and server features for edge AI applications.
Get the Full Ubuntu Desktop experience at the edge This release brings the complete Ubuntu Desktop environment to the Qualcomm Dragonwing QCS6490 and QCS5430 processors, with advanced UI capabilities and a seamless desktop-grade experience on edge and embedded systems. By combining the platform’s powerful AI acceleration with high-performance graphics, developers can now build rich, interactive user experiences on a wide range of display-enabled devices.
Optimized for intelligent edge applications The integration of Ubuntu Desktop with the Qualcomm Dragonwing QCS6490 and QCS5430 processors enables a new class of AI-powered edge devices and is ideal for smart kiosks, industrial monitoring stations, and on-device machine learning. This makes it easier to deploy complex applications with local processing, improved responsiveness, and enhanced privacy.
Expanded hardware support with Ubuntu 24.04 enhancements Canonical has also enhanced the Ubuntu 24.04 image with improved support for critical hardware components, including:
Enhanced camera and multimedia capabilities
Expanded sensor integration
Key performance improvements and bug fixes
With these enhancements, developers get access to the full power of Ubuntu Desktop and Server images on Canonical’s Qualcomm IoT platform in a security-focused and flexible Linux environment that is familiar to them.
For ODMs and OEMs, a validated Ubuntu stack on Qualcomm Dragonwing IoT hardware can reduce time to market and integration complexities. Canonical’s enterprise support offerings also ensure ODM/OEM partners can deliver production-grade solutions with confidence, backed by security updates and long-term maintenance.
Explore about our certification program
Canonical partners with silicon vendors, board manufacturers, and leading enterprises to shorten the average time to market. If you are deploying Ubuntu on Dragonwing platforms and want access to ongoing bug fixes and security maintenance, or if you wish to learn more about our solutions for custom board enablement and application development services, please reach out to Canonical.
If you have any questions about the platform or would like information about our certification program then simply contact us.
Canonical, the publisher of Ubuntu, provides open source security, support and services. Our portfolio covers critical systems, from the smallest devices to the largest clouds, from the kernel to containers, from databases to AI. With customers that include top tech brands, emerging startups, governments and home users, Canonical delivers trusted open source for everyone.
Qualcomm branded products are products of Qualcomm Technologies, Inc. and/or its subsidiaries. Qualcomm and Qualcomm Dragonwing are trademarks or registered trademarks of Qualcomm Incorporated.
Time is running out to be in full compliance with the EU Cyber Resilience Act, and we’re helping developers and manufacturers understand how to do just that. Here’s what we’ve been up to since March in helping the wider community understand how to meet the CRA head-on.
The EU Cyber Resilience Act (CRA) is in effect, and testing and certification are on the way. And while the Act is slated for full enforcement in 2027, it’s entirely possible that certification will be in effect as early as next June 2026 – which is just a year away. This ticking clock is understandably anxiety-inducing for lots of organizations, who are rushing to figure out how to meet the wide-ranging requirements of the CRA, while addressing the complexity and difficulty of managing their open source infrastructure and ecosystem.
At Canonical, we’ve been hard at work helping businesses figure this out. In just the last month alone, I attended three events: a Press Event with Mediatek, a partner event with IEI, and a panel on the impact of the CRA on open source during a conference held in Brussels about CRA. At all of these events, two challenges stood out: first, how to understand the Cyber Resilience Act requirements, and second, how to design open source stacks that meet them head on.
In this article, I’ll explore the key conversations taking place at these events, and examine the most pressing concerns I heard. I’ll also share how Ubuntu Pro is perhaps the most potent way to meet patching and long term support requirements needed to pass CRA requirements.
In March, I was honored to join the Embedded World stage during the official launch of Mediatek’s latest releases, the Genio 720 and 520 series. Embedded World is the go-to conference for everything related to embedded technologies and IoT devices, and Ubuntu is an integral part of development on these devices. Ubuntu is widely considered the de facto standard for durable, secured, and sustainable deployment on Mediatek platforms.
I joined Henri Parmentier (Senior Manager EPM Modules at ADLink) and Sameer Sharma (Associate VP of IoT at Mediatek) in a vibrant and direct discussion about how developers could meet the various challenges and requirements that the CRA is bringing to the IoT and devices table.
My focus was on how to meet CRA compliance on Mediatek platforms. During my talk, I emphasized the complexity of the open source environment in the context of CRA with one of my favorite slides:
Pictured: My Favourite Slide1
I love this slide: it really shines an inescapable spotlight on the complexity of open source supply chains and vulnerability management, and demonstrates the effort it takes to incorporate open source effectively and securely into your tech stack.
Open source is everywhere (a recent IDC study we commissioned shows that more than 70% of organizations use it extensively) but that ubiquity means that your adopted open source will inherit dependencies and vulnerabilities. When you consider how long it takes to fix a vulnerability, and the deep webs of interlinked dependencies that can exist in open source, you begin to understand why meeting the strict SLAs and cybersecurity requirements of the CRA is a major concern for developers and organizations.
In most cases, the CRA would mandate that you inform CSIRT of product vulnerabilities or security incidents within 24 hours of discovery. Details regarding the severity, impact, and suspected unlawful acts should be included, as well as information to users about the incident and possible mitigation measures they can take in response.
So, how do you manage this kind of issue?
I think the best way to do it is how we have been doing it: through partnerships.
Canonical works with ODMs and OEMs worldwide, across industries of all kinds, to help navigate and stay afloat of the rising tide of cybersecurity regulations. Our work with Mediatek is just one example of our expansive efforts to create devices and systems that work, securely, and which are maintained well beyond the support and security life cycle minimums of the CRA.
By working closely with Silicon vendors, manufacturers, and distributors, Canonical creates a continuum of security updates and support that enables secure open source across a rapidly expanding ecosystem on devices. What this means in real terms for developers who worry about the CRA is that many of the anxiety-inducing facts you saw in my above-mentioned Favourite Slide are much more streamlined: you get a trusted source to pull your open source with a set of commitments and depend on a partner to help you address those vulnerabilities and gain peace of mind.
IEI partner event
Shortly after the Embedded World trade show, we found ourselves in the beautiful Grand Hotel in Nuremberg for the Next-Gen Edge Intelligence 2025 Seminar, organised by our long-time ODM partner, IEI Integration group. With my colleague Joe Dulin, Canonical’s VP of Devices Sales, we presented how Canonical can shorten the time taken to secure products and get them to market – in part, by being CRA compliant from the get-go.
During this seminar, we shared some detailed insights into how Canonical products help manufacturers and developers navigate the increasingly complex world of producing secure and CRA-compliant devices for the EU market. It was relatively normal stuff at an event like this – but what was really interesting were the conversations I heard at the event: manufacturers, developers, suppliers, and providers alike all expressed anxieties around how they could meet the CRA’s vulnerability monitoring, disclosure, and patching requirements.
It’s easy to see why, given the extra pressure the CRA places on manufacturers to meet reporting obligations for vulnerabilities, even before being bound to its other numerous requirements. While manufacturers, importers, and distributors of hardware and software products have 36 months from the CRA’s official publication to adapt to the new requirements, there is only a 21-month grace period for manufacturers to adopt reporting obligations for incidents and vulnerabilities.
So, the pressure is on to build a robust framework for monitoring, disclosing, and reporting vulnerabilities and incidents.
Luckily, you have options.
How do you solve patching and support to meet CRA compliance?
In general, manufacturers and developers have two choices:
Meet all the compliance requirements of the CRA themselves, and manually manage the device patching and security updates for their entire fleet of devices made for the EU market, or,
Consume your software supply chain from a vendor who has taken on the manufacturer responsibility for CRA compliance – who can provide timely patches for you in an automated way.
Canonical has committed to make our OS – Ubuntu – a first-class CRA-compliant distro and to meet the manufacturer’s requirements for the software we produce and that is embedded into PDEs.
The heart of this commitment is Ubuntu itself. Its performant and security-centric design, open source nature, and consistent patching schedule make it the go-to OS for developers and IoT manufacturers. This is reinforced by Ubuntu Pro, which provides up to 12 years of support – far beyond the 5 year absolute minimum that the CRA requires.
Of course, managing vulnerabilities is one thing. Managing those vulnerabilities across thousands (or even millions!) of devices is an entirely different story – and Landscape is the hero of that tale. Landscape allows a secure and efficient fleet management, which is vital for managing security patching and package updates at scale across your entire fleet of devices that are in the EU market.
Of course, long term support is easier said than done. There’s a common misconception that it’s simply about fixing bugs in the latest versions of your devices and PDEs.
If only it were that simple! In reality, LTS is much harder and more demanding, because it’s about backporting every single CVE to all the previous versions of your software and devices for the entirety of their supported lifecycle.
Think about how we manage security patching for our Ubuntu operating system: in this context, providing long term support across the entire lifecycle of our product is about keeping all the releases which are less than 10 years old (e.g. 14.04, 16.04, 18.04, 20.04 and 22.04) secure by ensuring that the fixes we apply to 24.04 are available to those versions too.
It’s easier for us because we’ve been doing this for over 20 years, and have an incredibly talented security engineering team who created a process which allows us to backport a CVE fix created for Noble back to Trusty, aka Ubuntu 14.04! And not only are we doing this for the kernel, but for more than 36,000 libraries too.
For entrants to the devices market, managing the long-term lifecycle of their products is a steep task, because they won’t have these specialized teams or decades of experience. That’s why the most practical step is to consume your security updates through your device operating system, via Ubuntu Pro. All of the security patching work we do is all available under a single Ubuntu Pro licence. The benefits for a manufacturer are obvious, as it means that they do not need to “upgrade” their application for this entire lifecycle, as long as they apply our security updates – freeing them from manually patching packages themselves and simplifying their path to CRA compliance.
The short version of my talk is that CRA is raising the bar for the playing field: it will re-educate the market to be accountable for the software shipped along with a device.
My hot take on this very controversial topic is all about responsibility. Nobody would trust a car maker who tells you they don’t know where the brakes come from. Nobody would trust a cook who tells you they put mushrooms in your meal, but they’re not sure if they are safe to eat. Similarly, on the devices market in the EU, no one is going to trust some device manufacturer who doesn’t take their software supply chain security seriously.
If you plan to include an open source component to your product, you should feel entitled to make sure that the component will not break your entire product. For people who have been manufacturing products forever, and are more than acquainted with BOM, the “SBOM level-up” should come as no surprise.
Personally, I found the panel discussion very enlightening, and the follow-up questions clearly pointed to two key concerns from the market:
How are we going to certify? There’s still uncertainty around meeting which certification standards we will need to meet, which creates turmoil. While Common Criteria and 62443 have been used to benchmark products, we are all waiting on the Implementation Act to provide clarity.
What is the exact role and liability of a steward and how do I use it to waive my own liability? It’s interesting to see that the exact scope around the steward role is still subject to debate between people from different open source foundations and representatives of the EU! At Canonical, we will be taking the manufacturer role for our products, which means that people working with Ubuntu and other Canonical products will engage with us as a manufacturer.
In conclusion, March was an eye-opening month for understanding the depth and richness of conversation that’s happening now around the CRA requirements, even if that regulation is “still 2 years away” (spoilers, it’s much less than that).
Manufacturers, developers, and IoT providers are all understandably concerned about this new legislation, and most are already taking steps to ensure they’re not left on the back foot, come June next year. Vulnerability monitoring and disclosure, basic cybersecurity design standards, long term patching and support, and clearly defined and secure software supply chains are all top of mind for manufacturers – and that’s proof that our work in meeting the CRA requirements and offering comprehensive long term support and security patches is vital for the future of secure devices and a safe EU device marketplace.
To learn more about how we can help you meet your CRA requirements for vulnerability management, automated patching, and long term support for all your open source packages, visit our Ubuntu Pro for Devices page.
The April update is here — just at the end of April. We've been busy working on the VPP-based accelerated dataplane — you can watch that work in the repository and play with it in rolling release images. However, there are more features and bug fixes, and we are happy to see more active community contributors — there are quite a few community PRs that we merged lately, including DDNS update support for Kea, auto ignore prefixes for SLAAC, and more — read on for details!
The Department of Justice's (DOJ) current lawsuit against Meta spotlights a crucial discourse in the tech world, highlighting the fundamental right to privacy in the digital age.
Launchpad and the Open Documentation Academy Live in Málaga
Launchpad is a web-based platform to support collaborative software development for open source projects. It offers a comprehensive suite of tools including bug tracking, code hosting , translation management, and package building
Launchpad is tightly integrated with the Ubuntu ecosystem, serving as a central hub for Ubuntu development and community contributions. Its features are designed to streamline the process of managing, developing, and distributing software in a collaborative environment.
Launchpad aims to foster strong community engagement by providing features that support collaboration, community management, and user participation, positioning itself as a central hub for open source communities.
Canonical’s Open Documentation Academy is a collaboration between Canonical’s documentation team and open source newcomers, experts, and those in-between, to help us all improve documentation, become better writers, and better open source contributors.
A key aim of the project is to set the standard for inclusive and welcoming collaboration while providing real value for both the contributors and the projects involved in the programme.
Join us at OpenSouthCode in Málaga
Launchpad and the Open Documentation Academy will join forces at OpenSouthCode 2025 in the wonderful city of Málaga, Spain, on June 20 – 21 2025.
The Open Documentation Academy will have a hands-on documentation workshop at the conference, where the participants will learn how to do meaningful open source contributions with the help of the Diátaxis documentation framework.
Launchpad’s Jürgen Gmach will be on-site and help you to land your first open source contribution.
Identity management is vitally important in cybersecurity. Every time someone tries to access your networks, systems, or resources, it’s critical that you are verifying that these attempts are valid and legitimate, and that they match a real, authenticated user. The way that this tends to be handled in cyber security is through Identity and Access Management (IAM), most commonly by using third-party Identity Providers (IdPs). After all, these IdPs are highly effective at their job of verifying users, and offer robust security defenses against attempted attacks. However, just like all third-party tools, they still carry security risks – and the fact that they are managed by a third party means that these options seem somewhat incompatible with zero trust architecture (given that you’re handing over control of your IAM to an external organization).
In this article, I’ll explore an original and robust method for using third-party IdPs that allows you to maintain a zero trust security posture, thanks to Extra Factor Authentication. I’ll highlight the benefits of IdPs and explore the severe risks of ‘legitimate’ backdoors they pose, and give you a step-by-step framework that we used to implement an extra layer of control and authentication in our internal SSO (as a bonus, we’ll also share this implementation, which we offer to the community as a snap).
What is Identity and Access Management (IAM)?
IAM is a security framework that ensures that only legitimate and approved users, machines, or individuals can access resources. It verifies users and checks their credentials before allowing access to machines, networks, databases, or systems. Through this process, IAM prevents unauthorized access and reduces the risk of fraud, leaks, or breaches.
Why is IAM important?
The risks of poor IAM and access control are all too obvious.
In 2024, companies worldwide lost nearly $4.4 billion in fines for data breaches. Research from Verizon shows that 80% of data breaches stem from attackers guessing or stealing weak passwords; similarly, 61% of all breaches happen because a bad guy was tampering with credentials. In fact, data from CrowdStrike indicates that identity-based breaches account for 80% of cyberattacks. All in all, the numbers show that poor access control is often at the root of breaches.
For most use cases, third-party Identity Providers (IdP) offer an easy-to-implement, hands-free, and generally reliable way to manage your organization’s access control without needing to build it from the ground up yourself.
What is an IDP?
An Identity Provider (IdP) is a service that manages user authentication and access to applications, networks, or systems within a distributed network. IdPs create and manage all the information used in accessing systems belonging to an organization. Third-party IdPs, (for example Okta, or the Google Identity Platform) allow organizations to outsource and streamline their identity management to a trusted third party, who manages user identities and credentials, and authenticates requests to access organizational resources.
Typically, these work by:
Receiving an access request from a user or entity,
Checking that user’s credentials against a secure database of verified and authorized entities,
Assessing their permissions to access the requested network, system, or resource,
And then granting or denying access.
SSOs are a collection of technologies that allows network users to provide a single set of credentials for all network services (rather than having a different log-in for each), and today they’re widely used in IAM: roughly 70% of organizations have either implemented a Single Sign-On (SSO) solution or are planning to. You can read more about how they streamline IAM in our help knowledge base article about SSOs.
The benefits of third-party identity providers
Third-party IdPs are very popular with large organizations for a number of reasons.
IdPs are easy to use IdPs can be rolled out at scale to give organizations one single place to manage access to any number of websites, databases, or resources. This has two benefits: first, users no longer need to remember multiple passwords, reuse passwords, or create weak passwords; and second, it makes it easy to secure your systems and resources at scale.
IdPs enhance your security IdPs often come with features like multi-factor authentication (MFA), detailed events analysis, adaptive authentication, and powerful heuristics and attack detection capabilities, which makes it much harder for unauthorized users to get access.
IdPs free up developer resources IAM systems can be incredibly challenging to build by yourself, and time-consuming to manage at all hours of the day. By using these third-party IdPs, you no longer need dedicated internal resources to do it, allowing your developers to focus on mission-critical work.
The risks of third-party identity providers
As with all third-party tools you do not control, there are always risks.
Beyond the obvious risks of unseen gaps,flaws or attack vectors in these third-party tools, there’s a new and frightening risk of using them: a backdoor into your resources.
Backdoors into your resources, networks, or systems can happen in several ways.
An unauthorized account is added to your databases
An account’s credentials (username, password, access token, machine, etc) are stolen or spoofed
A rogue employee or IdP admin creates backdoor access
Seemingly “legitimate” users are added to access databases. For example, IdPs might create a backdoor of their own, or be forced by courts of governments to create a “legitimate” backdoor
Normally, audits and access controls exist in abundance to ensure that the first three attack points do not occur.
If a court order adds an “employee” to your database, or impersonates a privileged user, then your use of IdP is no longer a defense layer but instead an attack vector, and worse, an attack vector with privileged access, where even traditional additional layers like 2FA or MFA will not provide protection. Given this risk, you can see how many cybersecurity experts see third-party IdPs as incompatible with Zero Trust Security (ZTS).
What is Zero Trust Security
Zero Trust Security is a relatively new approach to cybersecurity. With ZTS, the system by default does not trust any user, application, service, request, or entity; Instead, every request for access is checked and authenticated when it happens, regardless of who made the request or where it came from. For this reason, ZTS is the growing gold standard in cybersecurity, as it offers the most robust security posture at all moments against attack attempts.
However, this onerous scrutiny and readiness comes at a cost: it may preclude the use of third-party tools (as these are outside of the organization’s full control) and may require intensive developer efforts to sustain, as if third-party tools are off the table, then the work is shifted in-house.
This means that ZTS often carries additional burdens in terms of time, cost, efforts, and resource requirements. As a result, a balanced approach that allows simultaneous use of third-party tools and zero trust systems is highly desirable for organizations looking to maximize their security and minimize the costs of doing so. In the next section, I will outline how we at Canonical implemented ZTS into our IdP usage to get the best of both worlds.
How to implement ZTS into your third-party IdP
Your typical IAM flow works like this:
Someone tries to log in to your service
Their request is passed to the IdP
They do their normal login
They pass some form of 2FA or MFA
They get a go/no-go response, and are allowed or blocked
In Canonical’s implementation of the IdP loop, we implement an extra step: a passkey stored by your organization (which we are referring to as ‘Extra Factor Authentication’). This happens outside of the IdP loop – and so the third-party provider isn’t even aware that it’s happening. The normal authentication flow happens, but when the go/no-go returns from the IdP, you prompt for this extra factor. If the user returns an enrolled passkey, we are able to verify that that person is legitimate, and give them access to the system.
You can do this in a number of ways, using multiple potential open source components. With our internal IAM solution, we made use of the following identity management projects:
This stack allows us to self-host our own SSO, which redirects to a third-party IdP, before coming back to us for the final passkey verification.
If you’d like to explore this tool for your own use, you can access it on our Charm hub, where we have packaged these tools into a set of Juju charms (Canonical‘s version of Kubernetes operators).
The benefits of Canonical’s hybrid Zero Trust IdP model
Our hybrid implementation of ZTS and IdPs comes with several benefits.
You get the benefits and protections of third-party IdPs. IdPs offer robust protections against the vast majority of attack attempts, and so you can enjoy these protections, combined with the ease-of-use and scalability of IdPs.
You retain full control over access permission. By retaining full control over the authorization decision, you effectively eliminate the risk of “legitimate” backdoors created by your IdP.
Extra Factor Authentication offers an additional security layer. Our implementation offers an additional layer of authentication and access control in your IAM, making it much harder for attackers or unauthorized users to access your systems, networks, or resources.
In conclusion, IAM is a tricky and time-consuming process, and modern third-party IdPs offer a powerful and reliable way to outsource this activity securely, for the most part. However, risks still exist with IdPs, meaning that if you want to implement Zero Trust Architecture into your IAM you need to take extra precautions so that you’re protected from both unwanted intruders and the third-party IdPs themselves. With just one simple additional verification step, you get the best of both worlds: all the benefits of third party IdPs, none of the potential black box back doors, and a solid Zero Trust outlook.
Today we are really excited to celebrate 20 years of Proxmox Server Solutions. When Dietmar and I founded Proxmox 20 years ago, our vision was clear: to create efficient and easy-to-manage Linux software solutions for everyone. Looking back, it's incredible to see how far we’ve come—from a small startup to a trusted provider for enterprises around the globe.
On April 29, 2005 we released the first stable version of Proxmox Mail Gateway. We had started development the year before and when...
I was just released from the hospital after a 3 day stay for my ( hopefully ) last surgery. There was concern with massive blood loss and low heart rate. I have stabilized and have come home. Unfortunately, they had to prescribe many medications this round and they are extremely expensive and used up all my funds. I need gas money to get to my post-op doctors appointments, and food would be cool. I would appreciate any help, even just a dollar!
I am already back to work, and continued work on the crashy KDE snaps in a non KDE env. ( Also affects anyone using kde-neon extensions such as FreeCAD) I hope to have a fix in the next day or so.
This summary highlights key updates to the Armbian build repository, including kernel adjustments, tooling fixes, and configuration changes. These contributions reflect ongoing efforts from the community to ensure system stability, compatibility, and enhanced performance across supported platforms.
“This doesn’t feel right. The package exists across all main distros. Probably not needed in every case… but it’s toolchain-related, so worth revisiting if merged.” Author: Werner View Commit ›
Armbian is a community-driven project maintained by a group of dedicated individuals in their limited free time. We provide the platform and tools for collaboration, but fixing every bug is beyond our capacity. Even large, well-funded teams face similar limits. That’s why we rely on the community—not just for reporting issues, but for actively helping to resolve them. View all commits and contribute at github.com/armbian/build Support Armbian development: Donate Today!
There is a new application available for Sparkers: ElecWhat What is ElecWhat? Features: – Desktop notifications – Tray icon with unread count (aka AppIndicator) – Custom keyboard shortcuts (default) – Spellcheck – CLI & D-Bus interface to show/hide/toggle window – Very stable, I have been running it for 6+ month without crash/freeze – Can be trusted: Code easy to review…
The Launchpad project is almost 21 years old! Many people have contributed to the project over this lifetime, and we are thankful for all of them. We understand the value of a strong community and we are taking steps to reinvigorate Launchpad’s once-thriving community.
There are two common suggestions for getting started in open source: fixing bugs and contributing to documentation. Early in 2024, Canonical launched the Canonical Open Documentation Academy; an initiative that aims to break down barriers to open source contribution, and work with the community to raise the bar for documentation practice. The Open Documentation Academy has been helping people get involved in open source and has also been helping projects achieve ever higher standards in documentation. Launchpad is one such project.
Today, we recognize and celebrate our community contributors. We hope they enjoyed contributing to Launchpad as much as we enjoyed working with them!
– gerryRcom
– Jared Nielsen
– Adriaan Van Niekerk
– Nathan Barbarick
Thank you for helping to make Launchpad great!
commit f980cfb3c78b72b464a054116eea9658ef906782
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Mon Oct 14 15:39:27 2024 -0400
Add debugging doc; fix broken links (#108)
* Add debugging doc; fix broken links
* fix broken links in debugging.rst
* fix spelling errors
* fix spelling errors
* fix spelling errors
* fix debugging link
* fix lots of formatting on recovered debugging.rst page
* add debugging.rst page into Launchpad development tips
---------
Co-authored-by: Alvaro Crespo <alvarocrespo.se@gmail.com>
commit c690ef5c7ed2d63d989c1f91b2883ed947904228
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Wed Oct 9 14:32:59 2024 -0400
Add database table page; fix broken link (#107)
* Add database table page; fix broken link
* add spell check errors to custom_wordlist
* add rename-database-table to how-to/index.rst
* fix reference link to rename-database-table page in live-patching.rst explanation doc
* format rename-database-table to show as sql code
---------
Co-authored-by: Jared Nielsen <nielsen.jared@gmail.com>
Co-authored-by: Alvaro Crespo <alvaro.crespo@canonical.com>
commit 5b319ab2899a326b7e96a5c001965e486a445448
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Wed Oct 9 12:20:24 2024 -0400
Add missing codehosting doc; fix broken link (#106)
* Add missing codehosting doc; fix broken link
* add codehosting-locally to index.rst
* add spell check errors to custom_wordlist
* fix reference link for codehosting-locally in code.rstexplanation section
---------
Co-authored-by: Jared Nielsen <nielsen.jared@gmail.com>
Co-authored-by: Alvaro Crespo <alvaro.crespo@canonical.com>
commit 1fcb3a9588bcb62132ce0004bb98f54e28c6561c
Author: Nathan Barbarick <nathanclaybarbarick@gmail.com>
Date: Mon Sep 30 11:08:39 2024 -0700
Group articles of the Explanation section into proper subsections (#97)
* Remove How to go about writing a web application, per jugmac00.
* Group articles in the Explanation section into subsections, add introductory text.
* Add new sections for remaining ToC headings.
* Add codehosting.png, fix broken link (#104)
* add codehosting.png, fix broken link
* delete linkcheck_ignore item
* remove accessibility, upstream, and schema links (#102)
* add concepts.rst, fix broken link in code.rst (#105)
* add concepts.rst, fix broken link in code.rst
* add spellcheck errors to custom_wordlist
* add concepts to index.rst
* Add descriptions in the explanation index and move new concepts page.
---------
Co-authored-by: Jared Nielsen <nielsen.jared@gmail.com>
commit ce5408a8ba919d22c5f5f01ff0396e1eb982d359
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Thu Sep 12 08:11:00 2024 -0400
add concepts.rst, fix broken link in code.rst (#105)
* add concepts.rst, fix broken link in code.rst
* add spellcheck errors to custom_wordlist
* add concepts to index.rst
commit eb5a0b185af6122720d44791aa8c98d52daf93e5
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Fri Sep 6 04:00:51 2024 -0400
remove accessibility, upstream, and schema links (#102)
commit 766dc568b06e49afbb831c25a6163be31ab5064a
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Thu Sep 5 03:09:19 2024 -0400
Add codehosting.png, fix broken link (#104)
* add codehosting.png, fix broken link
* delete linkcheck_ignore item
commit 317437262dd6d21bbb832e9603e4f84dbd4095b6
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Fri Aug 16 15:02:25 2024 -0400
add 'Soyuz' link (#103)
commit f238c1f4e2322d5ad31c9d86615108856c9f8dfc
Author: gerryRcom <gerryr@gerryr.com>
Date: Wed Jul 24 06:01:27 2024 +0100
oda spelling check on code doc (#90)
* oda spelling check on code doc
* oda spelling check on code doc
* Update .custom_wordlist.txt
---------
Co-authored-by: Jürgen Gmach <juergen.gmach@canonical.com>
commit ff237feec8ee9fd6530ccd0aa1f940939ddedee0
Author: Adriaan Van Niekerk <144734475+sfadriaan@users.noreply.github.com>
Date: Tue Jul 23 14:44:29 2024 +0200
Check Spelling errors (Storm migration guide) (#92)
* Remove Storm Migration Guide from exclusion list
* Update code inline formatting and correct spelling errors
* Add accepted words
commit 8500de5b96e4949b23d6c646c65272b9c8180424
Author: Adriaan Van Niekerk <144734475+sfadriaan@users.noreply.github.com>
Date: Tue Jul 23 11:05:04 2024 +0200
Check Spelling (Database Performance page) (#91)
* Remove database performance page from exclusion
* Add accepted words
* Correct spelling errors
commit 06401ea4f554bd8eff483a03c5dea2508f942bdd
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Wed Jul 17 11:13:05 2024 +0200
Correct spelling errors
commit 9eb17247c1100dc7c23dcb2a0275064ed1dc7a19
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Wed Jul 17 11:11:13 2024 +0200
Add accepted words
commit a539b047d012d5078b097041d9072937d2247704
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Wed Jul 17 11:10:59 2024 +0200
Remove "Security Policy" from exclusion list
commit 7708a5fa7b6ed6c0856fa2722f917228c9127eb0
Author: Adriaan Van Niekerk <144734475+sfadriaan@users.noreply.github.com>
Date: Wed Jul 17 08:13:34 2024 +0200
Spell check (URL traversal + Navigation Menus) (#87)
* Remove Navigation Menu page from exclusion
* Add words to be excluded from spell check
* Correct spelling errors
* Remove "url-traversal" from exclusion list
* Update list of accepted words
* Update formatting and correct errors
---------
Co-authored-by: Jürgen Gmach <juergen.gmach@canonical.com>
commit e952eb0aa98fe33a20517b82640d88c2c6a8fc5f
Author: gerryRcom <gerryr@gerryr.com>
Date: Mon Jul 15 20:17:36 2024 +0100
oda spelling check on branches doc
commit 46170ead6fe34fde518fe8848e3d321b57506875
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Mon Jul 15 11:02:57 2024 +0200
Update formatting of URLs
commit 124245b2b4b5699596e7039f09f6d1f3211b409f
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Mon Jul 15 11:00:22 2024 +0200
Remove Launchpad Mail page from exclusion list
commit 141aa07f62d47e7b25581c113fe222679ca9135d
Author: gerryRcom <gerryr@gerryr.com>
Date: Wed Jul 10 20:12:47 2024 +0100
oda spelling check on ppa doc
commit bdea1e1d11e88255eed19e335d840a278cefb134
Author: gerryRcom <gerryr@gerryr.com>
Date: Wed Jul 10 20:08:37 2024 +0100
oda spelling check on ppa doc
commit 7a960016415d32bae99bccac8e7ee634d7034ce7
Merge: 1c6506b 3e12837
Author: gerryRcom <gerryr@gerryr.com>
Date: Tue Jul 9 17:47:06 2024 +0100
Merge branch 'main' into spelling-feature-flags-doc
commit 1c6506b7e971fed802b3dfc85abc29bc0a075450
Author: gerryRcom <gerryr@gerryr.com>
Date: Fri Jul 5 20:06:05 2024 +0100
oda spelling check on feature-flags doc
commit 27b2aa62c48dde374d4e27fae671b061eb97a46f
Merge: acb3847 d32c826
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Fri Jul 5 16:03:01 2024 +0200
Merge branch 'main' of https://github.com/canonical/launchpad-manual into javascript-buildsystem-page
commit 3dc90949b0bd2136347916be1b4b05e0041b2d54
Merge: 053a960 f193109
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Fri Jul 5 14:07:59 2024 +0200
Merge branch 'main' of https://github.com/canonical/launchpad-manual into fix-spelling-issues
commit 053a96086a8e649f0b135aa6eeb942b858f7ba5b
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Fri Jul 5 13:59:34 2024 +0200
Add word to resolve conflict in pull request
commit f19310999278be18a3d92443a7b22cf1b0e7e441
Author: gerryRcom <gerryr@gerryr.com>
Date: Thu Jul 4 21:18:04 2024 +0100
oda spelling check on testing doc
commit 93e5fb8d8356b70b52401c69e7884a1dea2e8b46
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Thu Jul 4 18:44:24 2024 +0200
Remove exclusion added via rebase
commit d75ca31d26bd1731db6fad08c94c7d99bebc02c3
Merge: 54b74c2 5a2f090
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Thu Jul 4 18:09:04 2024 +0200
Merge branch 'fix-spelling-issues' of https://github.com/sfadriaan/launchpad-manual into fix-spelling-issues
commit 54b74c252952c5de24c0e232bbbe560f9c4c416e
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Thu Jul 4 10:50:08 2024 +0200
Correct spelling errors, verified by external documentation, converted to en-gb and corrected formatting
commit f1c66b1ce59f6af9a678f86f6b4fa637df91bcb3
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Thu Jul 4 10:48:48 2024 +0200
Add correctly spelled words picked up by spell checker
commit 73f12ca01f9cce4414702674cd24dc3d38e49304
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Thu Jul 4 10:47:42 2024 +0200
Remove javascript-integration-testing page from the exclusion list
commit acb384767214e3d432eafe062a2fb646f3c31938
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Thu Jul 4 16:07:25 2024 +0200
Update mailing list URL, spelling error correction
commit da06505e8a3431d50a815d16ca4f89a5d66c7a41
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Thu Jul 4 16:06:52 2024 +0200
Remove javascript-buildsystem from exclusion list
commit 2318addb0ea19de7813b5f6b16efc43d21584659
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Thu Jul 4 16:06:24 2024 +0200
Add words to exclusion list
commit 5a2f090a2da9083b3c3b658592ec43595e78eb0e
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Thu Jul 4 10:50:08 2024 +0200
Correct spelling errors, verified by external documentation, converted to en-gb and corrected formatting
commit ce333446e7c7501629d3ceab239183aed64af319
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Thu Jul 4 10:48:48 2024 +0200
Add correctly spelled words picked up by spell checker
commit 7649b104c9439dda5f938b2e0153e4d1c45f21b4
Author: Adriaan van Niekerk <adriaan.vanniekerk@canonical.com>
Date: Thu Jul 4 10:47:42 2024 +0200
Remove javascript-integration-testing page from the exclusion list
commit 017d19761d96d9c04a1ea61ac0e77bcf6a7b7cab
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Wed Jul 3 11:42:33 2024 -0400
Fix 'Loggerhead' link
commit fda0691919cd849ff4c6ee24e4dc1e3d5e6b1682
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Wed Jul 3 11:32:15 2024 -0400
Fix 'UI/CssSprites' link
commit f26faaef61e5ef48140bd2f84630c5d624041dad
Author: gerryRcom <gerryr@gerryr.com>
Date: Wed Jul 3 09:18:02 2024 +0100
oda spelling check on translations doc
commit 13cb12c45e1a5826d27eaf497b7e6a2605d7ec6d
Author: gerryRcom <gerryr@gerryr.com>
Date: Tue Jul 2 19:41:38 2024 +0100
oda spelling check on unittesting doc
commit cdab34e61a7c1009852a642e978b9027c2aad3d2
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Tue Jul 2 12:07:06 2024 -0400
Fix 'Running' link
commit dbe279acfef9eb736735b04ba474801d3f58a3f0
Author: Nathan Barbarick <nathanclaybarbarick@gmail.com>
Date: Fri Jun 28 19:55:08 2024 -0700
Restructure navigation menu using subsections in how-to.
commit 8592ed544881d50877f036073a6eec9de2e6356d
Author: gerryRcom <gerryr@gerryr.com>
Date: Sat Jun 29 09:49:34 2024 +0100
oda spelling check on css doc
commit 90608989d15cf2dbdf9a538a03517c03d87a3658
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Sat Jun 29 03:54:27 2024 -0400
Fix 'JavascriptUnitTesting' link (#72)
Co-authored-by: Jürgen Gmach <juergen.gmach@canonical.com>
commit 61ab3a36a51cb6ee40d6132cc1028779115b8efd
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Sat Jun 29 03:43:47 2024 -0400
Fix 'Help' link (#70)
Co-authored-by: Jürgen Gmach <juergen.gmach@canonical.com>
commit 89f08619f4c1cbb6e82bc95fd3cdc30b802e9c37
Author: gerryRcom <gerryr@gerryr.com>
Date: Fri Jun 28 19:52:32 2024 +0100
oda spelling check on live-patching doc
commit 96924bd1cf580875d76ed28afa3db83d0d642247
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Fri Jun 28 08:44:30 2024 -0400
Fix 'Getting'
commit be6124ff67fc89a604ebad566805e7e535a01377
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Fri Jun 28 09:00:41 2024 -0400
Fix 'JavaScriptIntegrationTesting' link
commit da7f6bfa597f2ea1e8df57dbbec7217fd746268f
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Fri Jun 28 07:46:05 2024 -0400
Fix 'FixBugs'
commit 2ca5b808797ccd2c24cfb65a06d98e1db844b1b1
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Thu Jun 27 11:02:31 2024 -0400
remove underscores
commit 7577f7674066d4e1d974e956ab2506e0d6f5a89b
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Tue Jun 25 13:22:07 2024 -0400
Fix '../Trunk'
commit deb42beb594b860356dfe11297516d26609d1018
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Thu Jun 27 11:52:33 2024 -0400
Fix 'Database/LivePatching'
commit ded351427d3f694d16855f3b4c44e085eb4e551c
Author: gerryRcom <gerryr@gerryr.com>
Date: Thu Jun 27 19:47:05 2024 +0100
oda spelling check on merge-reviews doc
commit c07847f039bc9414410ebf134d263174004a0a67
Author: gerryRcom <gerryr@gerryr.com>
Date: Thu Jun 27 08:22:23 2024 +0100
oda spelling check on db-devel doc
commit 6a54f46fedfcfdb3385dd8ff5c2f1d4a9ce45f15
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Tue Jun 25 12:32:41 2024 -0400
remove updated link from linkcheck_ignore
commit 6eedaa9f3d5eaee21242280b1ead71c376698c4e
Author: Jared Nielsen <nielsen.jared@gmail.com>
Date: Sat Jun 22 12:59:24 2024 -0400
Fix 'PolicyAndProcess/DatabaseSchemaChangesProcess'
commit 92d1b15eafc2a90a88e24afd5a6938f277314d8a
Author: gerryRcom <gerryr@gerryr.com>
Date: Wed Jun 26 19:30:14 2024 +0100
oda spelling check on css-sprites doc
commit aeb7e5c2d4186ba45cb3279e24c3716e7752b32c
Author: gerryRcom <gerryr@gerryr.com>
Date: Tue Jun 25 20:06:46 2024 +0100
oda spelling check on registry doc
commit 13eb716d534b41ee60ac6adbf8b9d8fb96ca96cd
Author: gerryRcom <gerryr@gerryr.com>
Date: Mon Jun 24 20:00:43 2024 +0100
oda spelling check on triage-bugs doc
commit b7ad120ca563e3a1ac82f5ec7c7742874b53d88b
Author: gerryRcom <gerryr@gerryr.com>
Date: Mon Jun 24 19:51:08 2024 +0100
oda spelling check on triage-bugs doc
commit a83419e47f21071ae53a7036210a7c650195e8ef
Author: gerryRcom <gerryr@gerryr.com>
Date: Fri Jun 21 21:54:21 2024 +0100
oda spelling check on schema-changes doc
commit 486b54241a46ec42f48a05a0081b238699c0557b
Author: gerryRcom <gerryr@gerryr.com>
Date: Thu Jun 20 20:36:01 2024 +0100
oda spelling check on submitting-a-patch doc
commit a890a576681258d647d20b8fdc5c80b14f490d94
Author: gerryRcom <gerryr@gerryr.com>
Date: Tue Jun 18 20:09:14 2024 +0100
oda spelling check on database-setup doc
commit b52d850a0d2456f7925a91cb3e2ff4a8c44711a5
Author: gerryRcom <gerryr@gerryr.com>
Date: Mon Jun 17 12:18:09 2024 +0100
oda spelling check on contribute-to doc
commit 074e13a662821ba17d1c99e2814ef38fe2206a01
Author: gerryRcom <gerryr@gerryr.com>
Date: Fri Jun 14 13:17:53 2024 +0100
oda spelling check on getting-help-hacking
commit 81b6f8025aecf35c48b6660510447e07910d4b8e
Author: gerryRcom <gerryr@gerryr.com>
Date: Thu Jun 13 20:58:20 2024 +0100
oda spelling check on explanation-hacking
The Incus team is pleased to announce the release of Incus 6.12!
This release comes with some very long awaited improvements such as online growth of virtual machine memory, network address sets for easier network ACLs, revamped logging support and more!
On top of the new features, this release also features quite a few welcome performance improvements, especially for systems with a lot of snapshots and with extra performance enhancements for those using ZFS.
The highlights for this release are:
Network address sets
Memory hotplug support in VMs
Reworked logging handling & remote syslog
SNAT support on complex network forwards
Authentication through access_token parameter
Improved server-side filtering in the CLI
More generated documentation
The full announcement and changelog can be found here. And for those who prefer videos, here’s the release overview video:
And as always, my company is offering commercial support on Incus, ranging from by-the-hour support contracts to one-off services on things like initial migration from LXD, review of your deployment to squeeze the most out of Incus or even feature sponsorship. You’ll find all details of that here: https://zabbly.com/incus
Donations towards my work on this and other open source projects is also always appreciated, you can find me on Github Sponsors, Patreon and Ko-fi.
One of my favourite authors, Douglas Adams, once said that “we are stuck with technology when what we really want is just stuff that works.” Whilst Adams is right about a lot of things, he got this one wrong – at least when it comes to infrastructure. As our Infra Masters 2025 event demonstrated, infrastructure is the technology that makes everything work – from managing a satellite in outer space, to, say, livestreaming an event.
Held at Canonical’s London office on March 31st, Infra Masters 2025 brought together operations leaders and architects to explain how to build infrastructure that transforms industries.
If you didn’t attend the event, don’t worry – and, naturally, “DON’T PANIC.” You’ve come to the right place to find out what you might have missed. You can watch the full talks on YouTube, or read this article for an overview of everything that took place, from key insights from ESA on modernizing infrastructure to BT’s network cloud transformation.
So, without further ado, what can we learn from Infra Masters 2025?
1. Choose a partner that helps you speed up innovation
Modernizing infrastructure isn’t just about choosing the right software. It’s also about who you choose to work with, and how you work with them. According to BT, it was a fundamental shift from vendor-consumer to partnership with Canonical that invigorated their efforts to modernize their infrastructure.
As their representatives disclosed in the first talk of the day, BT have worked with Canonical since 2019 on their ongoing infrastructure transformation. Despite the challenges posed by the transition, the collaboration between BT and Canonical has been marked by open communication, shared goals, and regular training sessions to upskill engineers. The secret to a successful partnership?
“It’s the collaborative approach, working together working on shared goals.”
– Curtis Haslam, Network Cloud Senior Manager, BT Group
BT was keen to emphasize that transparent collaboration requires willingness to offer and accept constructive feedback. Haslam explains, “we’re very honest”, because “acknowledging mistakes from both sides” is the best way to fix errors. Great collaboration becomes possible through this kind of mutual trust.
2. Double your output with Kubernetes
The European Space Agency (ESA) plans to double the number of missions they want to run by 2030 – no easy feat. With critical projects covering everything from searching for habitable worlds, to clearing the 130 million pieces of orbiting debris that threaten satellites, each mission had its own individual compute and infrastructure needs, making their goal a particularly ambitious one. For organizations interested in how to increase output by modernizing their infrastructure, ESA’s presentation may provide some helpful tips.
As Michael Hawkshaw, ESA Mission Operations Infrastructure IT Service Manager at ESOC (European Space Operations Centre) explains, with Canonical Kubernetes ESA has been able to automate the deployment of both infrastructure and “all the software needed for those missions as well.” Canonical Kubernetes readily plugs into Ceph and PostgreSQL for instance, which are part of ESA’s stack. These automations have, naturally, freed the team to work on other mission-critical tasks. Likewise, by increasing availability and reducing “wasted space” on database servers, Canonical Kubernetes have helped ESA to support more missions.
Want to try Kubernetes but don’t think you have the capacity? ESA was in the same position. Michael acknowledges that Kubernetes is fast-moving and has a steep learning curve. However, with Canonical managing the systems for them, on call “24/7, 7 days a week”, ESA can always “get the support” they need, “with active monitoring” of their setup.
For one thing, open source software gives organizations the flexibility to scale and adapt to shifting requirements. To return to our initial Adams quote, while it may be true that with proprietary solutions, you can become “stuck with technology”, you’re never stuck with open source.
For BT, open source was critical to building the Network Cloud, the infrastructure project that helped them to achieve their goal of bringing 5G to the UK. The Network Cloud replaced a variety of disparate, proprietary vertically-integrated stacks. These stacks each required individual management, oversight, compliance, authentication, and deployment, making them time- and cost-intensive. The challenge was to replace these with infrastructure that was highly dependable and automated, providing consistent high performance.
The answer was consolidating their infrastructure into a single, trusted open source stack – including MAAS for bare-metal provisioning, Ceph for storage, LXD for container management, and Juju for automation. James Cawte, BT Group’s Cloud Network Principal Engineer, noted that by streamlining their operations in this way, the app developers were free to ‘focus solely on their application development’, rather than trying to make the infrastructure work – which allowed BT to streamline its operations. For more details on BT’s partnership with Canonical, explore the case study.
As Canonical’s Thibaut Rouffineau noted, open source software helps organizations to scale resources whilst keeping costs down. Moving away from proprietary software reduces expensive licences and contracts, whilst enabling companies to optimize their infrastructure – rather than getting stuck with technology, it just works.
4. The future is in the clouds, on the edge, and managed by Kubernetes
…When it comes to infrastructure, that is.
Moving forward, BT’s focus is on enhancing edge computing capabilities for better 5G performance, optimizing infrastructure for containerized applications, and integrating serverless computing to improve developer workflows.
This shift to edge computing seems likely to become increasingly common as organizations choose to move away from the public cloud and data centers, and distribute their infrastructure across edge devices. Kubernetes, and the automations it makes possible, will form a key part of managing this infrastructure, offering a new approach to how we think about the future of technology.
Meanwhile, ESA’s plan to double the number of satellites it currently flies by 2030 relies on Kubernetes and cloud-native computing. AI tooling managed by Canonical Kubernetes has increased the amount of data that can be stored and retrieved, whilst Ceph and PostgreSQL support these cloud-based workloads. As space exploration continues to evolve, ESA can more easily scale its workloads thanks to these tools.
So, to take a final leaf from Adams, and “summarize the summary of the summary,” what can we learn from Infra Masters?
The relationship between vendor and client is critical, and moving towards a more collaborative partnership can improve innovation, efficiency, and in-house skillsets. Equally, the support provided by a company like Canonical to aid migration efforts, for example, can help to take the pressure off in-house engineers to avoid disrupting workflows.
The automations enabled by Canonical’s infrastructure portfolio improve efficiency, reduce costs and take the pressure off managing infrastructure. Choosing a managed solution can help organizations to get these benefits, without worrying about capacity or skill shortages.
Open source software is an increasingly important part of the stack for many companies, providing cost savings, the opportunity to scale, and even create a unified platform and integrate infrastructure seamlessly across different environments.
As the company behind Ubuntu, Canonical’s software is widely used, trusted, and provides a great option for organizations looking to explore open source options for their infrastructure – whether it’s to lower costs, gain architecture freedom or cloudify their data center. And that’s all, folks. So long, and thanks for all the fish – and by fish, I mean “humoring my … creative references.” See you at the next Infra Masters!
As organizations shift toward multi-cloud environments and real-time service delivery, edge computing is becoming central to modern application strategies. But this decentralization introduces new security challenges. With devices and data distributed across multiple locations, securing the edge is no longer optional.
What does edge security really mean?: It’s about protecting applications, data, and services that are processed and delivered outside traditional data centers—closer to users and devices. This requires securing each edge node against attacks, ensuring encrypted communication, and maintaining control over who and what accesses your infrastructure, even in highly distributed environments.
Modern Application Delivery Controllers (ADCs)—like SKUDONET—play a key role in building resilient and secure edge infrastructures.
What Is Edge Computing and Why It Matters
Edge computing is a distributed IT architecture where data processing takes place as close as possible to the data source—rather than relying exclusively on centralized cloud infrastructures.
This approach addresses critical needs in modern application delivery: real-time responsiveness, reduced latency, and local autonomy. By processing data at the edge of the network, organizations minimize the delay associated with long-distance data transmission and ensure better service continuity, even in scenarios where connectivity is limited or intermittent.
Key benefits of edge computing for secure and efficient application delivery:
Reduced latency: Critical in use cases that demand real-time data processing.
Optimized bandwidth: Only relevant data is transmitted to the cloud or data center.
Improved reliability: Applications can continue functioning even when the connection to the core network is disrupted.
Enhanced scalability: Distributes workloads more efficiently across edge and core environments.
Edge computing plays a fundamental role in modern IT strategies, particularly when combined with security, observability, and automation—areas where SKUDONET provides integrated support for robust application delivery.
Common Edge Security Threats
As edge infrastructure grows, so does its exposure to security risks. The combination of distributed endpoints, increased network complexity, and reliance on real-time connectivity makes the edge a prime target.
Key threats include:
DDoS attacks targeting edge nodes to degrade or halt local services.
Malware and ransomware infiltrating through unmanaged or poorly secured devices.
Compromised or unmonitored IoT devices can serve as entry points for broader network intrusions.
Data interception over insecure communication channels.
Securing the Edge with SKUDONET
SKUDONET Enterprise Edition provides an integrated ADC and load balancing solution built with security at its core—critical in edge environments.
Key features for edge security:
Secure Application Load Balancing
SKUDONET ensures that traffic distribution across nodes is not only efficient, but also resilient against malicious traffic patterns. Rate limiting, health checks, and session persistence features protect against overload and improve reliability.
Built-in Web Application Firewall (WAF)
The Enterprise Edition of SKUDONET includes an advanced WAF as a core feature, providing application-layer protection without requiring external modules. It mitigates common threats such as SQL injection, XSS, and OWASP Top 10 vulnerabilities.
DDoS Protection and Traffic Filtering
Advanced filtering mechanisms allow for early detection and blocking of suspicious traffic. When deployed at the edge, this helps stop attacks before they propagate deeper into the network. The SKUDONET IPDS module operates at the edge, providing a layered defense that includes IP reputation filtering, protocol-level protection, DDoS mitigation, real-time blocklists, and Web Application Firewall—all before traffic reaches the load balancing tier.
SSL/TLS Termination and Encryption
SKUDONET supports SSL offloading and re-encryption, ensuring data confidentiality across all connections. This reduces the load on backend services and improves response times.
Access Control and Authentication
Role-based access, IP whitelisting, and integration with identity providers support granular control over who accesses edge applications.
Edge computing is no longer a future trend—it’s a current reality. As organizations distribute their infrastructure to improve performance and user experience, edge security becomes a non-negotiable requirement.
SKUDONET enables secure application delivery at the edge by combining advanced load balancing with integrated threat protection, all managed from a centralized interface.
Discover SKUDONET Enterprise Edition or Try it for free for 30 days.
Voltámos da quadra pascal muito mais gordos, depois de enfardar toda a espécie de doçarias, ensopados e lançamentos de Ubuntu 25.04 Plucky Puffin, a.k.a.: Fradinho. A conversa andou à volta de rituais religiosos, como apanhar doenças com cuspo dos vizinhos, como construir emissores de Onda Média de trazer por casa, habilidades e jigajogas com leitores de livros electrónicos de tinta electrónica e ainda todas as novas funcionalidades do 25.04, terapias com Painel de Bem-Estar, perigosas expedições ao Berço e promessas de grande galhofa com jogos de bebidas, durante as eleições Legislativas..
Ampere and Canonical are pleased to celebrate new milestones in their ongoing partnership including the completion of Canonical’s System-on-Chip (SoC) certification on AmpereOne®, and the extension of the partnership into the AI Platform Alliance, a strategic group of full stack ecosystem partners that provide enterprise-grade curated solutions specifically developed for AI inference use cases.
The ongoing partnership between Ampere and Canonical will continue to drive AI compute and cloudification forward through efficient, scalable, and sustainable infrastructure. The AmpereOne family delivers excellent performance-per-watt, making these SoCs a strong choice for AI-driven applications where scalability and efficiency matter. Canonical’s software stack (which includes infrastructure solutions like Canonical OpenStack and MicroCloud) complements Ampere’s hardware by providing a securely designed, flexible, and optimized platform for deploying AI inferencing workloads on Arm architecture.
AmpereOne Ubuntu certification
Ensuring a consistent, performant, and reliable software stack is critical to accelerating cloud and enterprise datacenter adoption, and the Ubuntu certification of the AmpereOne SoC is an important milestone in this journey. The AmpereOne SoC is Ampere’s latest flagship processor designed for cloud-native workloads. Thanks to Canonical’s rigorous SoC certification program, the AmpereOne platform has undergone extensive validation to guarantee compatibility, and stability with the Ubuntu software stack.
Additionally, having Ampere-based platforms in Canonical’s certification labs ensures continuous integration and testing, providing customers with confidence that their infrastructure is optimized, certified, and ready for production. This certification is essential for Original Equipment Manufacturers (OEMs) and cloud providers looking to deploy AmpereOne-based servers at scale through Ubuntu server certification and long-term support.
“The certification of AmpereOne on Ubuntu is a significant milestone for our joint customers allowing them to proceed with confidence on platforms and services built on our products. The Ampere/Canonical partnership reflects our joint commitment to deliver energy-efficient, cloud-optimized solutions based on open source technology using the trusted Ubuntu software stack,” said Sean Varley, Chief Evangelist at Ampere.
AI Platform Alliance collaboration
The partnership between Ampere and Canonical also extends to a broader industry initiative – the AI Platform Alliance. As active members of the Alliance, both companies are committed to driving innovation and collaboration across the AI ecosystem. The Alliance fosters close cooperation between silicon providers, hardware accelerators, cloud and managed service providers, and system integrators to deliver optimized end-to-end AI platforms. Through this collaboration, Ampere and Canonical are working alongside ecosystem partners to simplify AI deployment, making it easier for developers and enterprises to unlock the full potential of AI on Arm-based platforms.
“Together, Ampere and Canonical are delivering the building blocks for a cloudified, AI-ready, and energy-efficient data center – setting the stage for the next generation of compute infrastructure,” said Youssef Eltoukhy, Silicon Alliances at Canonical.
Canonical, the publisher of Ubuntu, provides open source security, support and services. Our portfolio covers critical systems, from the smallest devices to the largest clouds, from the kernel to containers, from databases to AI. With customers that include top tech brands, emerging startups, governments and home users, Canonical delivers trusted open source for everyone.
Ampere is a modern semiconductor company designing the future of cloud computing with the world’s first Cloud Native Processors. Built for the sustainable Cloud with the highest performance and best performance per watt, Ampere processors accelerate the delivery of all cloud computing applications. Ampere Cloud Native Processors provide industry-leading cloud performance, power efficiency and scalability.
The AI Platform Alliance is a strategic group of full stack ecosystem partners that provide enterprise-grade curated solutions specifically developed for AI inference use cases, and optimized for the industry-leading AI platform from Ampere. The Alliance offers high performance, open, efficient and sustainable solutions including design-in and ready-to-use AI inference-enabled services that help end customers and digital enterprises overcome the challenges of adapting to a constantly evolving market. For more information, visit https://platformalliance.ai/.
Despite the NVD (National Vulnerability Database) outage of the NIST (National Institute of Standards and Technology), Greenbone’s detection engine remains fully operational, offering reliable, vulnerability scanning without relying on missing CVE enrichment data. Since 1999 The MITRE Corporation’s Common Vulnerabilities and Exposures (CVE) has provided free public vulnerability intelligence by publishing and managing information about […]
The dipole program is part of the Yagi-Uda project, a collection of tools designed for the analysis and optimization of Yagi-Uda antennas. This particular tool calculates the impedance of a single dipole, making it a useful utility for antenna engineers and amateur radio enthusiasts.
Installation on Ubuntu/Debian
To install the Yagi-Uda software suite, including dipole, run the following command:
sudo apt install yagiuda
This package includes several tools for Yagi-Uda antenna analysis and design, making it a valuable addition for those working with antennas.
Usage
To compute the impedance of a dipole, use the following command:
dipole <frequency> <length> <diameter>
For example, to calculate the impedance of a dipole at 7.1 MHz with a length of 20 meters and a diameter of 1.5 mm, run:
dipole 7.100mhz 20m 1.5mm
Example Output:
Self impedance of a dipole:
7.100000 MHz, length 20.000000 m, diameter 1.500000 mm, is
Z = 62.418686 -48.363233 jX Ohms
This output indicates:
Frequency: 7.1 MHz
Length: 20 meters
Diameter: 1.5 mm
Impedance (Z): 62.42 – j48.36 Ω
The negative reactance (-48.36 Ω) suggests the dipole is capacitive, meaning it is too long at this frequency. To achieve resonance (purely resistive impedance), the dipole length should be slightly reduced.
Related Tools
The Yagi-Uda project includes additional tools that help with various aspects of antenna design and optimization:
first – Initial calculations for antenna design
input – Processes input parameters for analysis
output – Displays calculated results
optimise – Helps refine antenna parameters for better performance
Each of these tools contributes to designing and analyzing Yagi-Uda antennas effectively.
Supported Platforms
The Yagi-Uda project was primarily developed for UNIX-based systems, including Linux distributions such as Ubuntu and Debian. While efforts were made to port it to other operating systems, its primary focus remains on UNIX environments.
Reporting Bugs
If you encounter any issues while using dipole or other Yagi-Uda tools, you can report them to Dr. David Kirkby (G8WRB) at david.kirkby@onetel.net. Providing clear, reproducible steps will help ensure that reported bugs are addressed efficiently.
Conclusion
For amateur radio operators and engineers working with Yagi-Uda antennas, the dipole program is a valuable tool for analyzing a single dipole’s impedance. With an easy installation process on Debian-based systems, it is an accessible and practical choice for antenna analysis.
Ubuntu MATE 25.04 is ready to soar! 🪽 Celebrating our 10th anniversary as an official Ubuntu flavour with the reliable MATE Desktop experience you love, built on the latest Ubuntu foundations. Read on to learn more 👓️
A Decade of MATE
This release marks the 10th anniversary of Ubuntu MATE becoming an official Ubuntu flavour. From our humble beginnings, we’ve developed a loyal following of users who value a traditional desktop experience with modern capabilities. Thanks to our amazing community, contributors, and users who have been with us throughout this journey. Here’s to many more years of Ubuntu MATE! 🥂
What changed in Ubuntu MATE 25.04?
Here are the highlights of what’s new in the Plucky Puffin release:
Celebrating 10 years as an official Ubuntu flavour! 🎂
Optional full disk encryption in the installer 🔐
Enhanced advanced partitioning options
Better interaction with existing BitLocker-enabled Windows installations
Improved experience when installing alongside other operating systems
Major Applications
Accompanying MATE Desktop 🧉 and Linux 6.14 🐧 are Firefox 137 🔥🦊,
Evolution 3.56 📧, LibreOffice 25.2.2 📚
See the Ubuntu 25.04 Release Notes
for details of all the changes and improvements that Ubuntu MATE benefits from.
There are no offline upgrade options for Ubuntu MATE. Please ensure you have
network connectivity to one of the official mirrors or to a locally accessible
mirror and follow the instructions above.
Welcome to this week’s Armbian Build Highlights! We’ve added support for the Qcom Robotics RB5 and delivered a stack of board-level fixes and improvements. Bootloaders are getting version upgrades, new device tree tweaks are live, and key driver updates are in. Whether you’re tuning SPI displays or tweaking governors, there’s something here for every dev. Let’s dive in!
New Board Support
Qcom Robotics RB5 Support Added View Commit » by FantasyGmm
sun55iw3-dev.config: Changed default CPU governor to ondemand View Commit »
Armbian is a community-driven project maintained by a group of dedicated individuals in their limited free time. We provide the platform and tools for collaboration, but fixing every bug is beyond our capacity. Even large, well-funded teams face similar limits. That’s why we rely on the community—not just for reporting issues, but for actively helping to resolve them. View all commits and contribute at github.com/armbian/build Support Armbian development: Donate Today!
Ubuntu 25.04, codenamed “Plucky Puffin”, is here. This release continues Ubuntu’s proud tradition of integrating the latest and greatest open-source technologies into a high-quality, easy-to-use Linux distribution. The team has been hard at work through this cycle, partnering with the community and our partners, to introduce new features and fix bugs.
Ubuntu 25.04 introduces GNOME 48 with triple buffering for smoother performance, HDR settings, and new features like a Wellbeing Panel and Preserve Battery Health mode. A new modern PDF reader, Papers, is now the default.
The installer now offers a smoother experience when installing alongside other operating systems, with better BitLocker support, and advanced partitioning.
Built on the Linux 6.14 kernel, this release brings a new scheduling system with sched_ext, enhanced Wine/Proton gaming support through the new NTSYNC driver, and better container tooling via decoupled bpftools and linux-perf.
Developer experience takes a leap forward with the introduction of devpacks. These snap bundles deliver the latest Go and Spring ecosystems, alongside updated toolchains for Python, Rust, .NET, LLVM, OpenJDK, and more.
Ubuntu 25.04 also expands confidential computing to on-premise environments with AMD SEV-SNP host support, and introduces a new ARM64 Desktop ISO for next-gen hardware.
Networking and identity management see continued improvements, including secure time sync with NTS, better Active Directory (AD) integration, cloud authentication against EntraID and Google identity, and DNS-aware wait-online logic with Netplan.
The newest Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity, and Xubuntu are also being released today. More details can be found for these at their individual release notes under the Official Flavours section:
Users of Ubuntu 24.10 will be offered an automatic upgrade to 25.04 if they have selected to be notified of all releases rather than just LTS upgrades. For further information about upgrading, see:
As always, upgrades to the latest version of Ubuntu are entirely free of charge.
We recommend that all users read the release notes, which document caveats, workarounds for known issues, as well as more in-depth notes on the release itself. They are available at:
Ubuntu is a full-featured Linux distribution for desktops, laptops, IoT, cloud, and servers, with a fast and easy installation and regular releases. A tightly-integrated selection of excellent applications is included, and an incredible variety of add-on software is just a few clicks away.
Professional services including support are available from Canonical and hundreds of other companies around the world. For more information about support, visit:
The Xubuntu team is happy to announce the immediate release of Xubuntu 25.04.
Xubuntu 25.04, codenamed Plucky Puffin, is a regular release and will be supported for 9 months, until January 2026.
Xubuntu 25.04, featuring the latest updates from Xfce 4.20 and GNOME 48.
Xubuntu 25.04 features the latest Xfce 4.20, GNOME 48, and MATE 1.26 updates. Xfce 4.20 features many bug fixes and minor improvements, modernizing the Xubuntu desktop while maintaining a familiar look and feel. GNOME 48 apps are tightly integrated and have full support for dark mode. Users of QEMU and KVM will be delighted to find new stability with the desktop session—the long-running X server crash has been resolved in Xubuntu 25.04 and backported to all supported Xubuntu releases.
The final release images for Xubuntu Desktop and Xubuntu Minimal are available as torrents and direct downloads from xubuntu.org/download/.
As the main server might be busy the first few days after the release, we recommend using the torrents if possible.
We want to thank everybody who contributed to this release of Xubuntu!
Highlights and Known Issues
Highlights
Xfce 4.20, released in December 2024, is included and contains many new features. Early Wayland support has been added, but is not available in Xubuntu.
GNOME 48 apps, including Font Viewer (gnome-font-viewer) and Mines (gnome-mines), include a refreshed appearance and usability improvements.
Known Issues
The shutdown prompt may not be displayed at the end of the installation. Instead, you might just see a Xubuntu logo, a black screen with an underscore in the upper left-hand corner, or a black screen. Press Enter, and the system will reboot into the installed environment. (LP: #1944519)
You may experience choppy audio or poor system performance while playing audio, but only in some virtual machines (observed in VMware and VirtualBox).
OEM installation options are not currently supported or available.
Please refer to the Xubuntu Release Notes for more obscure known issues, information on affecting bugs, bug fixes, and a list of new package versions.
The main Ubuntu Release Notes cover many other packages we carry and more generic issues.
Support
For support with the release, navigate to Help & Support for a complete list of methods to get help.
In addition to all the regular testing I am testing our snaps in a non KDE environment, so far it is not looking good in Xubuntu. We have kernel/glibc crashes on startup for some and for file open for others. I am working on a hopeful fix.
Next week I will have ( I hope ) my final surgery. If you can spare any change to help bring me over the finish line, I will be forever grateful
The Lubuntu Team is proud to announce Lubuntu 25.04, codenamed Plucky Puffin. Lubuntu 25.04 is the 28th release of Lubuntu, the 14th release of Lubuntu with LXQt as the default desktop environment. With 25.04 being an interim release, it will be supported until January of 2026. If you're a 24.10 user, please upgrade to 25.04 […]
DC-ROMA RISC-V AI PC
DC-ROMA RISC-V AI PC Mini
Lightweight – great for Raspberry Pi or low-power servers
Fast startup – ideal for services that need to restart quickly
Reproducible environments – makes sharing setups with fellow hams easier
Isolation – keeps different radio tools from interfering with each other
Deploy SDR receivers like rtl_433, OpenWebRX, or CubicSDR as containerized services.
Set up a Winlink gateway using Pat + ax25 tools, all in one container.
Automate and scale your APRS bot, or APRS gateway using Docker + cron + scripts.
Pictured: My Favourite Slide1
Rockchip: Fixing Broken EDGE Kernel Patch
Add “Out of Date” Notice to Example Config
UFS Devices: Add Sector Size Variable
Update 
Add New Host Build Dependency for Noble
rockchip64: Fix ATF Build & Bump to Latest
Allwinner: Bump to Latest
Fix ORAS Tooling Download – Add 
ZRAM Service Fix – mkfs Deprecation
Auto-Sync Board Config Status
Fix 
AIC Wi-Fi Driver Adjustment for Rockchip
BananaPi SM1: Fix Patch Naming
Btrfs Root on Subvolume Support
U-Boot v2025 for Sunxi: H616 Fixes, DTS Updates
Sunxi 6.13 Series
Switch from 
Improve Example Config Handling
We’ve added support for the Qcom Robotics RB5 and delivered a stack of board-level fixes and improvements. Bootloaders are getting version upgrades, new device tree tweaks are live, and key driver updates are in. Whether you’re tuning SPI displays or tweaking governors, there’s something here for every dev. Let’s dive in!
New Board Support
Board-Level Fixes & Enhancements
Bootloader & Kernel Updates
View all commits and contribute at 
Support Armbian development: 
Xubuntu 25.04, featuring the latest updates from Xfce 4.20 and GNOME 48.
![[RSS 1.0 Feed]](common/rss10.png){kind=small}
![[RSS 2.0 Feed]](common/rss20.png){kind=small}
![[Atom Feed]](common/atom.png){kind=small}
![[FOAF Subscriptions]](common/foaf.png){kind=small}
![[OPML Subscriptions]](common/opml.png){kind=small}
![[Hacker]](common/hacker.png){kind=small}
![[Planet]](common/planet.png){kind=small}