19 December, 2025 11:54AM by Joseph Lee
Hello, Community!
Customers and holders of contributor subscriptions can now download VyOS 1.4.4 release images and the corresponding source tarball. This release adds TLS support for syslog, support for AWS gateway load balancer tunnel handler (on AWS only), an option to match BGP prefix origin validation extended communities in route maps, and more. It also fixes over fifty bugs. Additionally, there's now a proper validation to prevent manually assigned multicast addresses, which may break some old malformed configs, so pay attention to it. Last but not least, there's a deprecation warning for SSH DSA keys that will stop working in VyOS releases after 1.5 due to changes in OpenSSH, so make sure to update your user accounts to more secure algorithm keys while you still have the time.
19 December, 2025 09:22AM by Daniil Baturin (daniil@sentrium.io)
2025 has been a defining year for SKUDONET — not because of a single announcement or isolated launch, but due to sustained progress across product development, security reinforcement and strategic expansion.
Throughout the year, our focus has remained consistent: strengthening the core platform, improving the operational experience for administrators, and ensuring that security and reliability evolve in line with real-world infrastructure demands.
This approach has translated into continuous, incremental improvements rather than disruptive changes, allowing teams to adopt new capabilities without compromising stability in production environments.
Over the course of eight product releases, SKUDONET continued to mature as an application delivery and security platform designed for critical environments.
Across these updates, we introduced:
Rather than isolated enhancements, these updates reflect a continuous effort to simplify daily operations while reinforcing security and performance at scale.
Key areas of evolution included a renewed Web GUI, designed to be faster, more consistent and easier to navigate in complex environments, as well as meaningful progress in RBAC, enabling more precise and adaptable access control models.
Certificate management also saw significant improvements, with extended Let’s Encrypt automation, broader DNS provider support and fully automated renewal workflows. Alongside this, we reduced execution times for critical operations such as farm start/stop actions and API metric retrieval.
During the year, 31 CVEs were resolved, continuously hardening the platform’s attack surface. Beyond vulnerability remediation, SKUDONET focused on reinforcing internal consistency and predictability under load.
Key improvements were made across:
Several updates also introduced additional hardening measures, including:
Together, these enhancements contribute to a platform that behaves more predictably under pressure and is easier to audit and troubleshoot in production.
Reducing operational overhead for administrators was another consistent theme throughout 2025.
Several improvements were introduced to simplify day-to-day operations and reduce manual intervention, including:
Together, these enhancements allow teams to spend less time on routine maintenance tasks and more time on capacity planning, optimization and higher-level architectural decisions.
One of the most significant milestones of the year was the launch of SkudoCloud, SKUDONET’s fully managed SaaS platform for application delivery and security.
SkudoCloud introduces a new operational model in which teams can deploy secure application delivery infrastructure in minutes, without managing the underlying system lifecycle. From the first deployment, users benefit from:
This launch represents a strategic expansion of the SKUDONET ecosystem, complementing on-premise and self-managed deployments with a cloud-native option designed for teams that prioritize simplicity, speed and operational focus.
Alongside product evolution, SKUDONET continued to expand its international presence.
During 2025, seven new partners joined our ecosystem across Europe, Asia and Latin America, strengthening our ability to support customers globally while maintaining close technical collaboration at a regional level:
Virtual Cable (Spain)
Fortiva (Turkey)
SINUX (Indonesia) Secra Solutions (Spain)
Bluella (India)
Global OMC TECH Inc. (Taiwan)
BCloud Services SAC (Peru)This growth reflects increasing demand for open, transparent and flexible application delivery solutions across diverse markets.
2026 will begin with an important milestone: the launch of the SkudoManager, the SKUDONET Central Console.
This unified interface will enable teams to manage multiple nodes, services and products from a single control plane, providing global infrastructure visibility, centralized user and policy management, and integrated monitoring of farms, certificates, security and performance.
Alongside this, we will continue expanding SkudoCloud and reinforcing the Enterprise Edition’s core architecture, staying aligned with our principles of transparency, performance and security.
The progress achieved in 2025 has been possible thanks to our customers, partners and community. We look forward to continuing this journey together in 2026, building an application delivery and security platform that evolves with real operational needs.
19 December, 2025 09:13AM by Nieves Álvarez
19 December, 2025 03:27AM by xiaofei
Announcing Purism's Year End Sale. Offering 15% off your purchases through the end of the year. Just use YEAREND as your coupon code for hardware purchases through December 31, 2025!
Please note that orders placed after December 17th will not ship until January.
The post 2025 Year-End Sale appeared first on Purism.
16 December, 2025 09:17PM by Purism
16 December, 2025 09:11AM by Greenbone AG
Open-source software has been one of the most transformative forces in the technology sector. Operating systems, databases, web servers, and encryption libraries that we now consider essential exist thanks to thousands of developers who chose to release their code so that anyone could study it, modify it, and improve it.
This model has enabled companies and organizations to build advanced solutions without relying exclusively on proprietary software. However, this openness also introduces a recurring challenge: how to ensure the sustainability of open-source software in a world where software is no longer distributed, but consumed as a service.
In this context, recent discussions around well-known projects have brought renewed attention to licenses such as AGPL (Affero General Public License), specifically designed to respond to this shift in how software is delivered and consumed. Beyond individual cases, the underlying message is clear: open-source software requires a balance between those who contribute and those who use it.
When people talk about open-source software, it is often confused with “free software” in the sense of cost. In reality, the term refers to a set of fundamental freedoms:
These freedoms are defined and enforced through licenses. Some licenses prioritize maximum adoption, while others aim to ensure that the ecosystem remains collaborative and sustainable.
During the 1990s and early 2000s, the dominant model was traditional software distribution: installers, CDs, and packaged binaries. In that context, licenses such as GPL ensured that if you redistributed the software, you were required to release your modifications.
Today, this landscape has changed completely, most software is delivered as a service. Companies can benefit from open-source software without ever distributing it; they simply run it on their own infrastructure. This shift is precisely where modern licensing models come into play.
When discussing open-source licenses, we are not just talking about legal text, but about different collaboration models.
Broadly speaking, there are two major families of licenses:
Permissive licenses such as MIT, BSD, or Apache 2.0 allow organizations to take the code, modify it, integrate it into proprietary products, and redistribute it without any obligation to return improvements to the community. They are attractive to companies that want minimal legal constraints and maximum flexibility.
Their primary goal is typically to encourage widespread adoption, leaving the decision to contribute entirely up to each organization.
Copyleft licenses such as GPL, LGPL, and AGPL follow a different logic. If a project benefits from community-driven development, the improvements made on top of that code should remain accessible to the community. The intent is not to restrict commercial use, but to prevent open-source code from being absorbed into closed solutions without any return to the original project.
AGPL (Affero GPL) emerged to address a specific change in context: the transition from distributed software to software offered as a service. Traditional GPL licenses focused on redistribution—if you shipped a binary to a third party, you were required to provide the source code and your modifications.
In the SaaS model, many companies began using open-source software internally or as part of web services without ever “distributing” it. They simply ran it on their own servers and exposed functionality through APIs or web interfaces. In these cases, modifications could be made without being shared.
AGPL extends the scope of reciprocity: if you offer the software to users over a network, your modifications must be made accessible.
As open-source software has become deeply embedded in enterprise infrastructures, many projects have reached a point where usage grows faster than contributions. This is a natural outcome of how technology is consumed today, particularly in SaaS and cloud environments.
In recent years, several mature projects have adopted AGPL or dual-licensing models after observing recurring patterns:
The result is that, despite widespread adoption, the project lacks the resources required for long-term sustainability.
In this context, adopting reciprocal licenses such as AGPL is not a restrictive move, but a mechanism to preserve the continuity of the project.
The shift toward cloud and SaaS models has fundamentally transformed the software lifecycle. Many historical licenses were not designed for environments where software operates exclusively as a remote service.
Licenses such as AGPL introduce mechanisms intended to protect the integrity of open-source ecosystems in this new context. Their purpose is not to limit commercial use, but to ensure that significant improvements do not remain locked inside private implementations—especially when the software underpins critical infrastructure.
From a technical and organizational perspective, this approach provides several benefits:
As a result, more projects are adopting hybrid models that combine open foundations, reciprocity mechanisms, and commercial offerings that fund ongoing development. This is not an exception, but a natural response to how software is built and maintained today.
Open-source software remains a fundamental driver of innovation. Its sustainability, however, depends on maintaining a fair balance between those who create and those who rely on it.
As SaaS models continue to redefine software consumption, licensing frameworks evolve alongside them. AGPL and other reciprocal licenses do not aim to restrict adoption, but to ensure that critical projects can continue to grow, improve, and remain viable over time.
Ultimately, the goal is to protect the continuity of the open-source ecosystem in a technical landscape that is changing rapidly.
At SKUDONET, we work closely with open-source technologies in security and application delivery. Understanding how licensing models evolve is a key part of building sustainable infrastructure.
16 December, 2025 07:13AM by Nieves Álvarez
With our sights set on the beta release milestone, one key component still remains: a way to upgrade from Byzantium to Crimson.
If you're a Linux expert, you might already know how Debian handles release upgrades. Some eager individuals have already upgraded from Byzantium to the Crimson alpha this way. However, we need an easy, graphical upgrade procedure, so everyone with a Librem 5 can get the improvements coming in Crimson.
The post PureOS Crimson Development Report: November 2025 appeared first on Purism.
15 December, 2025 08:59PM by Purism
The integration combines efficient open source virtualization with high performance, enterprise-grade storage
We are pleased to announce a new, native integration between Canonical LXD and HPE Alletra. This integration brings together Canonical’s securely designed, open source virtualization platform with HPE’s enterprise-grade storage to deliver a simple, scalable, high-performance experience.
HPE Alletra is designed to deliver mission-critical storage at mid range economics, with a consistent data experience across various cloud environments. With this integration, Canonical LXD and MicroCloud users can now provision and manage Alletra block storage directly through the LXD interface, without the need for any third-party plugins or additional abstraction layers.
The integration enables users to seamlessly create, attach, snapshot, and manage thin-provisioned block volumes as easily as working with local storage, while retaining the full performance, resilience, and enterprise data services of HPE Alletra.
HPE Alletra NVMe-based architecture ensures sub-millisecond latency for demanding workloads, with built-in services such as thin-provisioning and data deduplication minimizing storage costs while maintaining consistent performance. Paired with LXD’s lightweight control plane and streamlined UI, users can easily operate their environments, combining the best of open source with enterprise storage functionality.
As demands grow, new volumes and storage capacity can be allocated on the fly. Alletra’s scale-out, modular architecture ensures the platform can expand without disrupting running workloads.
LXD provides a unified open source virtualization platform to run system containers and virtual machines with a focus on efficiency, security, and ease of management. With native support for HPE Alletra, enterprises can now build, deploy, and manage their workloads with enterprise storage guarantees, whether in private clouds, on-premises data centers, or edge environments.
The combined solution empowers teams to deliver predictable performance for critical and data-intensive workloads while reducing complexity and ensuring agility.
The integration between LXD and HPE Alletra is available starting with the LXD 6.6 feature release, and requires a HPE Alletra WSAPI version 1. LXD currently supports connecting to HPE Alletra storage through NVMe/TCP or iSCSI protocols. For detailed information, visit Canonical’s LXD documentation.
There are new SparkyLinux 2025.12 codenamed “Tiamat” ISO images available of the semi-rolling line. This new release is based on the Debian testing “Forky”. Main changes: – Packages updated from the Debian and Sparky testing repositories as of December 14, 2025. – Linux kernel 6.17.11 (6.18.1, 6.12.62-LTS & 6.6.119-LTS in Sparky repos) – Firefox 140.5.0esr (146.0 in Sparky repos) …
15 December, 2025 09:59AM by pavroo
15 December, 2025 06:38AM by xiaofei
In her book Cyberselfish: A Critical Romp Through the Terribly Libertarian Culture of Silicon Valley, published in 2000, Borsook who is based in Palo Alto, California and has previously written for Wired and a host of other industry publications, took aim at what she saw as disturbing trends among the tech industry.
The post A Quarter Century After Cyberselfish, Big Tech Proves Borsook Right appeared first on Purism.
15 December, 2025 05:10AM by Purism
When your organization first signed its Microsoft Azure Consumption Commitment (MACC), it was a strategic step to unlock better pricing and enable cloud growth. However, fulfilling that commitment efficiently requires planning. Organizations often look for ways to retire their MACC that drive strategic value, rather than simply increasing consumption to meet a deadline.
The goal is to meet your commitment while delivering long-term benefits to the business.
With Ubuntu Pro in the Azure Marketplace, you can retire your MACC at 100% of the pretax purchase amount. In practice, this allows you to meet consumption goals on your standard Azure invoice, while securing your open source supply chain and automating compliance.
Instead of simply increasing consumption to hit a target, effective IT and FinOps teams align their MACC with broader strategic goals. Open source support and security maintenance is a priority for enterprises, as a recent Linux Foundation report shows: 54% of enterprises want long-term guarantees, and 53% expect rapid security patching.
Ubuntu Pro offers both. By choosing software that strengthens your security and operations, you can retire your MACC while funding capabilities your organization prioritizes.
Allocating MACC to Ubuntu Pro is a direct investment in your open source estate:
By choosing Ubuntu Pro, you convert your MACC spend into a maintained open source foundation across the development lifecycle.
Retiring your commitment should be financially efficient and administratively simple. While standard Marketplace listings are MACC-eligible, many organizations use private offers to secure tailored commercial terms, like custom pricing or volume discounts, without sacrificing eligibility.
We support both standard private offers and multiparty private offers for rollouts involving resellers in the US/UK. In all cases, checking that your purchase counts toward your commitment is straightforward:
This approach guarantees that every dollar spent satisfies your financial goals while delivering the specific security coverage your organization needs.
Ready to align Ubuntu Pro with your MACC? Talk to our team.
We are proud to announce our new stable release 🚢 version 2025.12, code-named ‘Postwurfsendung’!
Grml is a bootable live system (Live CD) based on Debian. Grml 2025.12 brings you fresh software packages from Debian testing/forky, enhanced hardware support and addresses known bugs from previous releases.
Like in the previous release 2025.08, Live ISOs 📀 are available for 64-bit x86 (amd64) and 64-bit ARM CPUs (arm64).
Once again netcup contributed financially, this time specifically to this release. Thank you, netcup ❤️
12 December, 2025 03:10AM by xiaofei
A lot of people have asked us why Ubuntu Studio comes with a panel on top as the default. For that, it’s a simple answer: Legacy.
When Ubuntu Studio 12.04 LTS (Precise Pangolin) released over 13 years ago, it was released with a top panel by default as that was the default for our desktop envirionment: Xfce.
Fast-forward eight years to 20.10 and Xfce was no longer our default desktop environment: we had switched to KDE’s Plasma Desktop. Plasma has a bottom panel by default, similar to Windows. However, to ease the transition for our long-time users, we kept the panel on top by default, resizing it to be similar to the default top panel of Xfce.
With 25.10’s release, we included an additional layout: two panels. One panel is on top with a global menu, and the bottom contains some default applications, a trash can, and a full-screen application launcher. This is a way to feel familiar to those with a similar layout from where they may be coming from, being an operating system for creativity: macOS.
Starting with 26.04 LTS, we’ll also include one more layout: a bottom, Windows 10-like layout. This is to ease the transition for those coming from Windows, and due to popular request and reports.
It has been 13 years since we defaulted to a top panel, but is that the right idea anymore?
Right now, on the Ubuntu Discourse, we have a poll to decide if we should change the default layout starting with 26.04 LTS. This will not affect layouts for anyone upgrading from a prior release, but only new installations or new users going forward.
If you would like to participate in the poll, head on over to the Ubuntu Discourse and cast a vote!
[December 11, 2025] Today Canonical, the publisher of Ubuntu, announced the immediate availability of Java 25 across Google Cloud’s serverless portfolio, including Cloud Run, App Engine, and Cloud Functions.
This release is the result of a collaboration between Google Cloud and Canonical, and it will allow developers to access the latest Java features the moment they are released publicly. All three serverless products use Ubuntu 24.04 as the base image, with Canonical actively maintaining the runtime and ensuring timely security patches.
Deploying Java 25 is easy and fast thanks to Google Cloud Buildpacks. You do not need to create manual Dockerfiles or manage complex container configurations.
Buildpacks are designed to transform your source code into a production-ready container image automatically. When you deploy your application, the Buildpacks system detects your requested Java version and automatically provisions the Ubuntu-based Java 25 environment, which Canonical team continuously updates with security fixes. This “source-to-deploy” workflow allows you to focus entirely on writing code while Google Cloud and Canonical handle the underlying OS and runtime security.
To get started, simply use the GOOGLE_RUNTIME_VERSION environment variable to specify the JDK version to 25.
pack build java-app –builder=gcr.io/buildpacks/builder –env GOOGLE_RUNTIME_VERSION=25
To learn more about Canonical support on Java, please read our reference documentation.
Setting up a local Deep Learning environment can be a headache. Between managing CUDA drivers, resolving Python library conflicts, and ensuring you have enough GPU power, you often spend more time configuring than coding.
Google Cloud and Canonical work together to solve this with Deep Learning VM Images, which use Ubuntu Accelerator Optimized OS as the base OS. These are pre-configured virtual machines optimized for data science and machine learning tasks. They come pre-installed with popular frameworks, such as PyTorch, and the necessary NVIDIA drivers.
In this guide, I’ll walk you through how to launch a Deep Learning VM on GCP using the Console, and how to verify your software stack so you can start training immediately.
First, log in to your Google Cloud Console. Instead of creating a generic Compute Engine instance, we want to use a specialized image from the Marketplace.
Once you are on the Marketplace Deep Learning VM listing page, click Launch. This will take you to the deployment configuration screen. This is where you define the power behind your model.
Here are the key settings you need to pay attention to:
Configuring the VM instance in the Google Cloud Console.
Once you have made your selections, click Deploy.
After a minute or two, your VM will be deployed. You can find it listed in your Compute Engine > VM Instances page.
To access the machine, click the SSH button next to your new instance. This opens a terminal window directly in your browser.
Now, let’s make sure everything is working under the hood.
If you have attached a GPU, the most important check is to ensure the drivers have loaded correctly. Run the following command in your SSH terminal:
nvidia-smi
You should see a table listing your GPU (e.g., A100) and the CUDA version.
Google’s Deep Learning VMs usually come with PyTorch pre-configured. You can check the installed packages to ensure your favorite libraries are there:
pip show torch
And that’s it! In just a few minutes, you have built a fully configured Deep Learning environment. You can now start running training scripts directly from the terminal.
Don’t forget: Deep Learning VMs with GPUs can be expensive. Remember to stop your instance when you aren’t using it to avoid unexpected charges!
Learn more about Canonical’s offerings on GCP
Today, we are releasing 7.3.1 instead of 7.3 because a security vulnerability was fixed in a software library included in Tails while we were preparing 7.3. We started the release process again to include this fix.
For more details, read our changelog.
Automatic upgrades are available from Tails 7.0 or later to 7.3.1.
If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade.
Follow our installation instructions:
The Persistent Storage on the USB stick will be lost if you install instead of upgrading.
If you don't need installation or upgrade instructions, you can download Tails 7.3.1 directly:
Desta feita, raptámos…errr…recebemos um convidado muito especial: Artur Coelho. Professor de TIC, formador, apaixonado pela educação e criatividade com robótica, IA, 3D e programação de software, mantém uma visão crítica, actual e informada sobre o ensino das Tecnologias de Informação e Comunicação (TIC) nas escolas portuguesas - onde foi pioneiro na introdução de diversas tecnologias e construiu um percurso invejável, influenciando positivamente um grande número de alunos e professores. A conversa foi tão longa e interessante que vamos tentar rapt…convidá-lo outra vez no futuro.
Já sabem: oiçam, subscrevam e partilhem!
Este episódio foi produzido por Diogo Constantino, Miguel e Tiago Carrondo e editado pelo Senhor Podcast. O website é produzido por Tiago Carrondo e o código aberto está licenciado nos termos da Licença MIT. (https://creativecommons.org/licenses/by/4.0/). A música do genérico é: “Won’t see it comin’ (Feat Aequality & N’sorte d’autruche)”, por Alpha Hydrae e está licenciada nos termos da CC0 1.0 Universal License. Os separadores de péssima qualidade foram tocados ao vivo e sem rede pelo Miguel, pelo que pedimos desculpa pelos incómodos causados. Este episódio está licenciado nos termos da licença: Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0), cujo texto integral pode ser lido aqui. Estamos abertos a licenciar para permitir outros tipos de utilização, contactem-nos para validação e autorização. A arte de episódio foi criada pelo Luís Louro - a mascote Faruk - vencedora do terceiro lugar no concurso de mascote para o Software Freedom Day.
Telecommunications networks are undergoing a cloud-native revolution. 5G promises ultra-fast connectivity and real-time services, but achieving those benefits requires an infrastructure that is agile, low-latency, and highly reliable. Kubernetes has emerged as a cornerstone for telecom operators to meet 5G demands. In 2025, Canonical Kubernetes delivers a single, production-grade Kubernetes platform with long-term support (LTS) and telco-specific optimizations, deployable across clouds, data centers, and the far edge.
This blog explores how Canonical Kubernetes empowers 5G and cloud-native telco workloads with high performance, enhanced platform awareness (EPA), and robust security, while offering flexible deployment via snaps, Juju, or Cluster API. We’ll also highlight its integration into industry initiatives like Sylva, support for GPU/DPU acceleration, and synergy with MicroCloud for scalable edge infrastructure.
Telecom decision-makers face immense pressure to evolve their networks rapidly and cost-effectively. Traditional, hardware-centric architectures struggle to keep pace with 5G’s requirements for low latency, high throughput, and dynamic scaling. This is where Kubernetes – the de facto platform for cloud-native applications – comes in. Kubernetes brings powerful automation, scalability, and resiliency that allow telcos to manage network functions like software across data centers, public clouds, and far-edge deployments. The result is a more agile operational model: services can be rolled out faster, resources automatically optimized to demand, and updates applied continuously without disrupting critical services. In the 5G era, such agility is essential for delivering innovations like network slicing, multi-access edge computing (MEC), and AI-driven services.
At the same time, Kubernetes opens the door for telcos to refactor their network functions into microservices. Instead of relying on monolithic appliances or heavy virtual machines, operators can deploy cloud-native network functions (CNFs) – essentially containerized network services – that are lighter and faster to roll out than traditional virtual network functions (VNFs). By shifting to CNFs, new network features (whether a 5G core component or a firewall) can be introduced or updated in a fraction of the time, using automated CI/CD pipelines instead of lengthy manual upgrades. This approach helps telcos simplify the migration from legacy systems to a more agile, software-driven network model.
However, adopting Kubernetes for telecom workloads also means meeting rigorous performance and reliability standards. Carrier-grade services like voice, video, and core network functions can’t tolerate unpredictable delays or downtime. Telco leaders need a Kubernetes platform that combines cloud-native flexibility with telco-grade performance, security, and support. Canonical Kubernetes answers that call, providing a Kubernetes distribution specifically tuned for telecommunications needs.
Canonical’s Kubernetes distribution has been engineered from the ground up to address the unique challenges of 5G and cloud-native telco cloud deployments. It is a single, unified Kubernetes offering that blends the ease of use of lightweight deployments with the robustness of an enterprise-grade platform. Importantly, Canonical Kubernetes can be deployed and managed in whatever way best fits a telco’s environment – whether installed as a secure snap package or integrated with full automation tooling like Juju (model-driven operations) or Kubernetes Cluster API (CAPI). This flexibility means operators can start small at the network edge or scale up to carrier-core clusters, all using the same consistent platform. Notably, Canonical Kubernetes brings cloud-native telco-friendly capabilities in the areas of performance, networking, operations, and support:
Real-time linux kernel support ensures that high-priority network workloads execute with predictable, ultra-low latency, a critical requirement for functions like the 5G user plane function (UPF). In parallel, built-in support for advanced networking (including SR-IOV and DPDK) enables fast packet processing by giving containerized network functions direct access to hardware, dramatically reducing network I/O latency for high bandwidth 5G applications. Together, these features allow cloud-native network functions to meet stringent performance and determinism once only achievable on specialized telecom hardware.
Canonical Kubernetes integrates seamlessly with acceleration technologies to support emerging cloud-native telco workloads. It works with NVIDIA’s GPU and networking operators to leverage hardware accelerators (GPUs, SmartNICs, DPUs) for intensive tasks. It supports NVIDIA’s Multi-Instance GPU (MIG), which expands the performance and value of the NVIDIA’s data center GPUs, such as the latest GB200 and RTX PRO 6000 Blackwell Server Edition by partitioning the GPU into up to seven instances, each fully hardware isolated with its own high-bandwidth memory, cache, and streaming multiprocessors. The partitioned instances are transparent to workloads which greatly optimizes the use of resources and allows for serving workloads with guaranteed QoS.
This means telecom operators can run AI/ML analytics, media processing, or virtual RAN computations that take advantage of GPUs and DPU offloading within their Kubernetes clusters – all managed under the same platform. By tapping into hardware acceleration, telcos can deliver advanced services (like AI-driven network optimization or AR/VR streaming) with high performance, without needing separate siloed infrastructure.
Day-0 to Day-2 operations are streamlined through automation in Canonical’s stack. The distribution supports full lifecycle management – clusters can be deployed, scaled, and updated via one-step commands or integrated CI/CD pipelines, reducing manual effort and errors. Using Juju charms, Canonical’s model-driven operations further simplify complex orchestration, enabling teams to configure and update Kubernetes and related services in a repeatable, declarative way. Built-in self-healing and high availability features ensure that the platform can recover from failures automatically, keeping services running without intervention.
This high degree of automation translates into faster rollout of new network functions and updates (with minimal downtime), allowing telco teams to focus on innovation rather than routine ops tasks.
Canonical Kubernetes is designed to run from the core to the far edge with equal ease. Its lightweight, efficient design (delivered as a single snap package) results in a low resource footprint, making it viable even on a one- or two-node edge cluster in a remote site. At the same time, it scales up to multi-node deployments for central networks. The platform supports a variety of configurations – from a single node for an ultra-compact edge appliance, to a dual-node high-availability cluster, to large multi-node clusters for data centers – all with the same tooling and consistent experience.
This flexibility allows operators to extend cloud capabilities to edge locations (for ultra-low latency processing) while managing everything in a unified way. In practice, Canonical’s solution can power cloud-native telco IT workloads, 5G core functions, and edge applications under one umbrella, meeting the specific performance and latency needs of each environment.
Canonical backs its Kubernetes with long-term support options far exceeding the typical open-source release cycle. Each Canonical Kubernetes LTS version can receive security patches and maintenance for up to 15 years, ensuring a stable foundation for cloud-native telco services over the entire 5G rollout and beyond. (For comparison, upstream Kubernetes offers roughly 1 year of support per release).
This extended support window means carriers can avoid frequent, disruptive upgrades and rest assured that their infrastructure remains compliant over the long term. Such a commitment to stability is a key reason telecom operators choose Canonical – long-term maintenance provides confidence that critical network workloads will run on a hardened, well-maintained platform for many years.
As an open-source, upstream-aligned distribution, Canonical Kubernetes has no licensing costs and prevents vendor lock-in. Telcos are free to deploy it on their preferred hardware or cloud, and they benefit from a large ecosystem of Kubernetes-compatible tools and operators. The platform’s efficient resource usage and automation also help drive down operating costs – by improving hardware utilization and simplifying management, it enables operators to serve growing traffic loads without linear cost increases. In short, Canonical’s Kubernetes offers carrier-grade performance and features at a fraction of the cost of proprietary alternatives, all while keeping the operator in control of their technology roadmap.
Using Canonical Kubernetes, cloud-native telcos can position themselves to innovate faster and operate more efficiently in the 5G era. They can readily stand up cloud-native 5G Core functions, scale out Open RAN deployments, and push applications to the network edge – all on a consistent Kubernetes foundation. In fact, Kubernetes makes it feasible for telcos to transition from traditional VNFs on virtual machines to containerized CNFs, reducing resource overhead and speeding up deployment of network features. This means legacy network applications can be modernized step-by-step and run alongside new microservices on the same platform, avoiding risky “big bang” overhauls.
The result is not only technical efficiency but business agility: operators can launch new services (from enhanced mobile broadband to IoT analytics) in weeks instead of months, respond quickly to customer demand spikes, and streamline the integration of new network functions or vendors.
Early adopters in the industry are already seeing the benefits. For example, Canonical’s Kubernetes has been embraced in initiatives like the European Sylva open telco cloud project, in part due to its security, flexibility and long-term support advantages. This momentum underscores that a performant, open Kubernetes platform is becoming a strategic asset for telcos aiming to stay ahead in a competitive landscape. Perhaps most importantly, Canonical Kubernetes lets telcos focus on delivering value to subscribers – ultra-reliable connectivity, rich digital services, tailored enterprise solutions – rather than getting bogged down in infrastructure complexity. It abstracts away much of the heavy lifting of deploying and upgrading distributed systems, while providing the controls needed to meet strict cloud-native telco requirements. The combination of automation, performance tuning, and openness creates a powerful engine for telecom innovation.
At the edge, complexity is the enemy. That’s why Canonical Kubernetes pairs naturally with MicroCloud, our lightweight production-grade cloud infrastructure for distributed environments. MicroCloud fits the edge use case extremely well: it is easy to deploy, fully automated, and optimized for bare-metal and low-power sites. Drop it into a telco cabinet, regional hub, or remote data center, and you get a resilient control plane for running Kubernetes, virtualization, and storage with zero overhead.
In such deployments, MicroCloud and Canonical Kubernetes form a tightly integrated stack that brings cloud-native operations to the far edge. Need to orchestrate CNFs next to VMs? Spin up a single-node cluster with high availability? Scale to dozens of locations without rearchitecting? This combo makes it possible, with snaps for simple updates, Juju for full automation, and long-term support built in.
5G and edge computing are reshaping telecom networks, and Kubernetes has proven to be an essential technology powering this evolution. Industrial IoT, automotive applications , smart cities, robotics, remote health care, and the gaming industry rely on high data transfer, close to real time latency, very high availability and reliability. Canonical Kubernetes brings the best of cloud-native innovation to the telecom domain in a form that aligns with carriers’ operational realities and performance needs. It delivers a rare mix of benefits – agility and efficiency from automation, high performance for demanding workloads, freedom from lock-in, and assured long-term support – making it a compelling choice for any telco modernizing its infrastructure.
Telecommunications leaders looking to become cloud-native telcos should consider how an open-source platform like Canonical Kubernetes can serve as a foundation for growth. Whether the goal is to reduce operating costs in the core network, roll out programmable 5G services at the edge, or simply break free from proprietary constraints, Canonical’s Kubernetes distribution provides a proven path forward.
To dive deeper into how Canonical Kubernetes meets telco performance and reliability requirements, we invite you to read our detailed white paper: Addressing telco performance requirements with Canonical Kubernetes. It offers in-depth insights and benchmark results from real-world cloud-native telco scenarios. Additionally, visit our blogs on Ubuntu.com and Canonical.com for more success stories and technical guides – from 5G network modernization strategies to edge:
Visiting MWC 2026? Book a meeting with Canonical to find out more.
NBC News reports that Trump Mobile customers have been waiting months for a promised ‘Made in the USA’ smartphone, originally announced for August delivery. The T1 phone was marketed as domestically produced, but delays and vague updates have raised skepticism. References to ‘Made in the USA’ have been removed from the company’s site, and leaked images suggest the device resembles existing Chinese-made models. This situation underscores the complexity of building smartphones in America without established infrastructure.
The post Purism Liberty Phone Exists vs. Delayed T1 Phone appeared first on Purism.
10 December, 2025 03:36PM by Purism
In software engineering, we often talk about the “iron triangle” of constraints: time, resources, and features. You can rarely fix all three. At many companies, when scope creeps or resources get tight, the timeline is often the first element of the triangle to slip.
At Canonical, we take a different approach. For us, time is the fixed constraint.
This isn’t just about strict project management. It is a mechanism of trust. Our users, customers, and the open source community need to know exactly when the next Ubuntu release is coming. To deliver that reliability externally, we need a rigorous operational rhythm internally, and for over 20 years, we have honored this commitment.
Here is how we orchestrate the business of building software, from our six-month cycles to the daily pulse of engineering:
Fig. 1 Canonical’s Operating Cycle
Our entire engineering organization operates on a six-month cycle that aligns with the Ubuntu release cadence. This cycle is our heartbeat. It drives accountability and ensures we ship features on time.
To make this work, we rely on three critical control points:
This discipline ensures we stay agile, and that we can adjust our trajectory halfway through without derailing the entire delivery.
While the six-month cycle sets the destination, the “pulse” gets us there. A pulse is our version of a two-week agile sprint.
Crucially, these pulses are synchronized across the entire company, on a cross-functional basis. Marketing, Sales, and Support all operate on this same frequency. When a team member says, “we will do it next pulse,” everyone, regardless of department, knows exactly what that means. This creates a shared expectation of delivery that keeps the whole organization moving in lockstep.
We distinguish between a “pulse” (our virtual, two-week work iteration) and a “sprint.” For us, a sprint is a physical, one-week event where teams meet face-to-face.
We are a remote-first company, which makes these moments invaluable. Sprints provide the high-bandwidth communication and human connection needed to sustain us through months of remote execution.
We also stagger these sprints to separate context. Our Engineering Sprints happen in May and November (immediately after an Ubuntu release) so teams can focus purely on technical roadmapping. Commercial Sprints happen in January and July, aligning with our fiscal half-years to focus on business value. This “dual-clock” system ensures that commercial goals and technical realities are synchronized without overwhelming the teams.
Of course, market reality doesn’t always adhere to a six-month schedule. Customers have urgent needs, and high-value opportunities appear unexpectedly. To handle this without breaking our rhythm, we use the Commercial Review (CR) process.
The CR process protects our engineering teams from chaos while giving us the agility to say “yes” to the right opportunities.
This ensures that when we do deviate from the plan, it is a strategic choice, not an accident.
Underpinning this entire rhythm is a commitment to quality standards. We follow the Plan, Do, Check, Act (PDCA) cycle, a concept rooted in ISO 9001. While we align with these formal frameworks, it has become a natural habit for us at Canonical.
This operational discipline is what enables up to 15 years of LTS commitment on a vast portfolio of open source components, providing Long-Term Support for the entire, integrated collection of application software, libraries, and toolchains. Offering 15 years of security maintenance on our entire stack is only possible because we are operationally consistent. Long-term stability is the direct result of short-term discipline.
By sticking to this rhythm, we ensure that Canonical remains not just a source of great technology, but a reliable partner for the long haul.
10 December, 2025 09:07AM by xiaofei
We have published Qubes Canary 045. The text of this canary and its accompanying cryptographic signatures are reproduced below. For an explanation of this announcement and instructions for authenticating this canary, please see the end of this announcement.
---===[ Qubes Canary 045 ]===---
Statements
-----------
The Qubes security team members who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is December 10, 2025.
2. There have been 109 Qubes security bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
fourteen days of March 2026. Special note should be taken if no new
canary is published by that time or if the list of statements changes
without plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently compromised.
This means that we assume NO trust in any of the servers or services
which host or provide any Qubes-related data, in particular, software
updates, source code repositories, and Qubes ISO downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other means,
like blackmail or compromising the signers' laptops, to coerce us to
produce false declarations.
The proof of freshness provided below serves to demonstrate that this
canary could not have been created prior to the date stated. It shows
that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to anybody.
None of the signers should be ever held legally responsible for any of
the statements made here.
Proof of freshness
-------------------
Wed, 10 Dec 2025 01:14:56 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Confidential Conference on Ukraine Peace: "We Must Not Leave Ukraine and Volodymyr Alone with These Guys"
Project 2025 Author: "We Won't Let Anyone Stop US from Using Our Oil and Gas"
Remnants of the War: Syrians from Germany Helping with Reconstruction - But Remain Wary of Moving Back
Germany's Queen Mum: Nostalgia for the Merkel Era Alive and Well
Director Nadav Lapid on Israel after Gaza: It Was Our Duty to Scream
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Hundreds of Thousands of Thais and Cambodians Flee
Canada’s Northwest Territories Diamond Mines Are Closing
Another Front in the War in Ukraine: Who Gets to Claim a Famed Artist?
With Cheap Tickets and Lax Etiquette, a Theater Builds an Older Fan Base
Between Pakistan and Afghanistan, a Trade War With No End in Sight
Source: BBC News (https://feeds.bbci.co.uk/news/world/rss.xml)
Trump criticises 'decaying' European countries and 'weak' leaders
Nobel officials unsure when Peace Prize winner will arrive for ceremony
Congress ups pressure to release boat strike video with threat to Hegseth's travel budget
French feminists outraged by Brigitte Macron's comment about activists
'What's your name?' - Moment police confront Luigi Mangione at McDonald's
Source: Blockchain.info
0000000000000000000028650dc7d328ea9c1b7e2b5376ce14089586c8ca3041
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this canary
in the qubes-secpack.git repo, and (2) via digital signatures on the
corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures! Instructions for doing so are documented here:
https://www.qubes-os.org/security/pack/
--
The Qubes Security Team
https://www.qubes-os.org/security/
Source: canary-045-2025.txt
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmk4zrgACgkQ1lWk8hgw
4GpYrhAAiV6nfQk7dgKTljSSM2Bf22DFUl9+7eQOAV2ULbr+7G/CgRKMvezaYtgy
X/0s2NZIXsJDTulhh2j9yAujZqlHv3xbSJuoA7lqo91jrFUr2qYpCadL91uBWcxk
xkxBz5z01ApqHT8kgk/galfWqRj7f54A+YkmKHw3hynhMd+KaD10V3t2xBEW8a2X
7lsWRrhXGRVWsahDHgG5uZOA4spUlbRUiSlBkIo+ijeMQYxwu8CXQl3mwBeaI7jB
/D/J9dNz8denRDknD1Fr8NvRFbKchL9S0ntAt3yvZqDLhwGX5J0bnEDpS2fDWi15
mDjLe7RtGfI77P9yjwvv/XXb64Mhdta5v4nXeKD+IdnM3IAmPvlkXDWvrNHA9jiF
31sYC0J0K/8qHniIZ61tjtPbTAMF7uXS5FSMnSt2xlhVsZEBXBN+4wKwVrSTCvwL
7H5zKWY0eWllf1Va3ez5rM9lCSkvWZAC/yDIqDZ2ZclxlKUOOCdHNOqBzjR1+Nex
CyPrZ6wV/nDyVOpkZcMd+a7Q/brdT2zfELL39oeKDVv8w8+APC1wEbrTv56BvYVN
TgCG62gLIdN/RwtwjjDR9IHB0rIH/x7Rimhsu5gHBUBSNtyIwwK/vIS3hKv1qvZI
MxTVBDAZfZbJH1SwhioXChwTRsVXILZOFCTGgr3iltudNSn3uqY=
=JXd7
-----END PGP SIGNATURE-----
Source: canary-045-2025.txt.sig.marmarek
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmk5NNsACgkQSsGN4REu
FJCT3hAAn0C8K0+3573tTDIcXnZU0SClejmgkmmeY1wgYktMysQKjw/T9FtkOt1f
+e52uo2dwJ93Df+uJyQIvhd2UUA+p8yQtg8rA9svsOqiN6LfUO+hSTGPMUM63BSS
T3YuaFEsO9ll31iOssmm3CaQj5ERUMIiGdHDgHbOx0hAMDPKjBRfshTt1IJ6OOc6
q4DGOgeXNiv6wvlKIgByA/d41K9prkXm/DQ95PfV2cGBPk5fw2DrM0ISij2eyGHk
Z9r4BI15fj36OjtzfM+f1KMUeR/UDKtn4+tmVr/dLbEA9gRMcgy7Uzh1soKJcfyv
L8TK9GMSzypKk1oJTojvoLPjU0CikNnEhr4YzsOpeJ0tYRC+oSM7anh84QR4coyZ
jJxZLQnmIz3KUTOeJDoxuFguk2ItygRxxvYJuwMB3Y34dY1vP0TOOPHkEVhLllgK
HPi+78al3YkjPctZ04UpbqoI2wnRSCpQcd8JH8hBhi57LnPfOkYeKpBQX6Q8gqtG
RtwfB5cdrl7Y7EkZCbp/E+ieOt2MSzhwwyqAMsouQTnyuGcOdmZmu937Q03+kr9H
VMOFrwrmgzYXSw7oUzD3TLIScWxGf2ZLacU4ShWa0HGi0z/tg7a2F4xiVJPzRuQ7
8gBi69St+rZfCUdmywvtpH11htMZZSFHddtFWUl+EwQoO59fGqI=
=a3wa
-----END PGP SIGNATURE-----
Source: canary-045-2025.txt.sig.simon
The purpose of this announcement is to inform the Qubes community that a new Qubes canary has been published.
A Qubes canary is a security announcement periodically issued by the Qubes security team consisting of several statements to the effect that the signers of the canary have not been compromised. The idea is that, as long as signed canaries including such statements continue to be published, all is well. However, if the canaries should suddenly cease, if one or more signers begin declining to sign them, or if the included statements change significantly without plausible explanation, then this may indicate that something has gone wrong.
The name originates from the practice in which miners would bring caged canaries into coal mines. If the level of methane gas in the mine reached a dangerous level, the canary would die, indicating to miners that they should evacuate. (See the Wikipedia article on warrant canaries for more information, but bear in mind that Qubes Canaries are not strictly limited to legal warrants.)
Canaries provide an important indication about the security status of the project. If the canary is healthy, it’s a strong sign that things are running normally. However, if the canary is unhealthy, it could mean that the project or its members are being coerced in some way.
Here is a non-exhaustive list of examples:
No, there are many canary-related possibilities that should not worry you. Here is a non-exhaustive list of examples:
In general, it would not be realistic for an organization to exist that never changed, had zero turnover, and never made mistakes. Therefore, it would be reasonable to expect such events to occur periodically, and it would be unreasonable to regard every unusual or unexpected canary-related event as a sign of compromise. For example, if something usual happens with a canary, and we say it was a mistake and correct it (with valid signatures), you will have to decide for yourself whether it’s more likely that it really was just a mistake or that something is wrong and that this is how we chose to send you a subtle signal about it. This will require you to think carefully about which among many possible scenarios is most likely given the evidence available to you. Since this is fundamentally a matter of judgment, canaries are ultimately a social scheme, not a technical one.
A PGP signature is a cryptographic digital signature made in accordance with the OpenPGP standard. PGP signatures can be cryptographically verified with programs like GNU Privacy Guard (GPG). The Qubes security team cryptographically signs all canaries so that Qubes users have a reliable way to check whether canaries are genuine. The only way to be certain that a canary is authentic is by verifying its PGP signatures.
If you fail to notice that a canary is unhealthy or has died, you may continue to trust the Qubes security team even after they have signaled via the canary (or lack thereof) that they been compromised or coerced.
Alternatively, an adversary could fabricate a canary in an attempt to deceive the public. Such a canary would not be validly signed, but users who neglect to check the signatures on the fake canary would not be aware of this, so they may mistakenly believe it to be genuine, especially if it closely mimics the language of authentic canaries. Such falsified canaries could include manipulated text designed to sow fear, uncertainty, and doubt about the security of Qubes OS or the status of the Qubes OS Project.
The following command-line instructions assume a Linux system with git and gpg installed. (For Windows and Mac options, see OpenPGP software.)
Obtain the Qubes Master Signing Key (QMSK), e.g.:
$ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg: directory '/home/user/.gnupg' created
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: requesting key from 'https://keys.qubes-os.org/keys/qubes-master-signing-key.asc'
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key DDFA1A3E36879494: public key "Qubes Master Signing Key" imported
gpg: Total number processed: 1
gpg: imported: 1
(For more ways to obtain the QMSK, see How to import and authenticate the Qubes Master Signing Key.)
View the fingerprint of the PGP key you just imported. (Note: gpg> indicates a prompt inside of the GnuPG program. Type what appears after it when prompted.)
$ gpg --edit-key 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub rsa4096/DDFA1A3E36879494
created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key
gpg> fpr
pub rsa4096/DDFA1A3E36879494 2010-04-01 Qubes Master Signing Key
Primary key fingerprint: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. For more information, see How to import and authenticate the Qubes Master Signing Key.
Tip: After you have authenticated the QMSK out-of-band to your satisfaction, record the QMSK fingerprint in a safe place (or several) so that you don’t have to repeat this step in the future.
Once you are satisfied that you have the genuine QMSK, set its trust level to 5 (“ultimate”), then quit GnuPG with q.
gpg> trust
pub rsa4096/DDFA1A3E36879494
created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
pub rsa4096/DDFA1A3E36879494
created: 2010-04-01 expires: never usage: SC
trust: ultimate validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg> q
Use Git to clone the qubes-secpack repo.
$ git clone https://github.com/QubesOS/qubes-secpack.git
Cloning into 'qubes-secpack'...
remote: Enumerating objects: 4065, done.
remote: Counting objects: 100% (1474/1474), done.
remote: Compressing objects: 100% (742/742), done.
remote: Total 4065 (delta 743), reused 1413 (delta 731), pack-reused 2591
Receiving objects: 100% (4065/4065), 1.64 MiB | 2.53 MiB/s, done.
Resolving deltas: 100% (1910/1910), done.
Import the included PGP keys. (See our PGP key policies for important information about these keys.)
$ gpg --import qubes-secpack/keys/*/*
gpg: key 063938BA42CFA724: public key "Marek Marczykowski-Górecki (Qubes OS signing key)" imported
gpg: qubes-secpack/keys/core-devs/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 8C05216CE09C093C: 1 signature not checked due to a missing key
gpg: key 8C05216CE09C093C: public key "HW42 (Qubes Signing Key)" imported
gpg: key DA0434BC706E1FCF: public key "Simon Gaiser (Qubes OS signing key)" imported
gpg: key 8CE137352A019A17: 2 signatures not checked due to missing keys
gpg: key 8CE137352A019A17: public key "Andrew David Wong (Qubes Documentation Signing Key)" imported
gpg: key AAA743B42FBC07A9: public key "Brennan Novak (Qubes Website & Documentation Signing)" imported
gpg: key B6A0BB95CA74A5C3: public key "Joanna Rutkowska (Qubes Documentation Signing Key)" imported
gpg: key F32894BE9684938A: public key "Marek Marczykowski-Górecki (Qubes Documentation Signing Key)" imported
gpg: key 6E7A27B909DAFB92: public key "Hakisho Nukama (Qubes Documentation Signing Key)" imported
gpg: key 485C7504F27D0A72: 1 signature not checked due to a missing key
gpg: key 485C7504F27D0A72: public key "Sven Semmler (Qubes Documentation Signing Key)" imported
gpg: key BB52274595B71262: public key "unman (Qubes Documentation Signing Key)" imported
gpg: key DC2F3678D272F2A8: 1 signature not checked due to a missing key
gpg: key DC2F3678D272F2A8: public key "Wojtek Porczyk (Qubes OS documentation signing key)" imported
gpg: key FD64F4F9E9720C4D: 1 signature not checked due to a missing key
gpg: key FD64F4F9E9720C4D: public key "Zrubi (Qubes Documentation Signing Key)" imported
gpg: key DDFA1A3E36879494: "Qubes Master Signing Key" not changed
gpg: key 1848792F9E2795E9: public key "Qubes OS Release 4 Signing Key" imported
gpg: qubes-secpack/keys/release-keys/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key D655A4F21830E06A: public key "Marek Marczykowski-Górecki (Qubes security pack)" imported
gpg: key ACC2602F3F48CB21: public key "Qubes OS Security Team" imported
gpg: qubes-secpack/keys/security-team/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 4AC18DE1112E1490: public key "Simon Gaiser (Qubes Security Pack signing key)" imported
gpg: Total number processed: 17
gpg: imported: 16
gpg: unchanged: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 6 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 6 signed: 0 trust: 6-, 0q, 0n, 0m, 0f, 0u
Verify signed Git tags.
$ cd qubes-secpack/
$ git tag -v `git describe`
object 266e14a6fae57c9a91362c9ac784d3a891f4d351
type commit
tag marmarek_sec_266e14a6
tagger Marek Marczykowski-Górecki 1677757924 +0100
Tag for commit 266e14a6fae57c9a91362c9ac784d3a891f4d351
gpg: Signature made Thu 02 Mar 2023 03:52:04 AM PST
gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
The exact output will differ, but the final line should always start with gpg: Good signature from... followed by an appropriate key. The [full] indicates full trust, which this key inherits in virtue of being validly signed by the QMSK.
Verify PGP signatures, e.g.:
$ cd QSBs/
$ gpg --verify qsb-087-2022.txt.sig.marmarek qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 04:05:51 AM PST
gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify qsb-087-2022.txt.sig.simon qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 03:50:42 AM PST
gpg: using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]
$ cd ../canaries/
$ gpg --verify canary-034-2023.txt.sig.marmarek canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 03:51:48 AM PST
gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify canary-034-2023.txt.sig.simon canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 01:47:52 AM PST
gpg: using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]
Again, the exact output will differ, but the final line of output from each gpg --verify command should always start with gpg: Good signature from... followed by an appropriate key.
For this announcement (Qubes Canary 045), the commands are:
$ gpg --verify canary-045-2025.txt.sig.marmarek canary-045-2025.txt
$ gpg --verify canary-045-2025.txt.sig.simon canary-045-2025.txt
You can also verify the signatures directly from this announcement in addition to or instead of verifying the files from the qubes-secpack. Simply copy and paste the Qubes Canary 045 text into a plain text file and do the same for both signature files. Then, perform the same authentication steps as listed above, substituting the filenames above with the names of the files you just created.
Canonical is pleased to announce an expanded collaboration with AMD to package and maintain AMD ROCm™ software directly in Ubuntu. AMD ROCm is an open software ecosystem to enable hardware-accelerated AI/ML and HPC workloads on AMD Instinct™ and AMD Radeon™ GPUs, simplifying the deployment of AI infrastructure with long term support from Canonical.
Canonical has formed a dedicated team of engineers to package the AMD ROCm software libraries to streamline installation, support, and long-term maintenance on Ubuntu. Canonical will also submit these packages for consideration in Debian.
This work will simplify the delivery of AMD AI solutions in data centers, workstations, laptops, Windows Subsystem for Linux, and edge environments. AMD ROCm software will be available as a dependency for any Debian package, snap, or Docker image (OCI) build. Performance fixes and security patches will automatically be available to production systems.
This collaboration aims to make AMD ROCm software available in Ubuntu starting with Ubuntu 26.04 LTS, with updates available in every subsequent Ubuntu release.
Canonical works with silicon industry leaders to incorporate the software libraries and drivers that accelerate applications on their silicon directly into Ubuntu. Comprehensive support for the latest silicon dramatically accelerates developer adoption and production deployments.
For AMD, the software that enables hardware-accelerated AI processing is called ROCm. It is an open software platform that includes runtimes, compilers, libraries, kernel components, and drivers that together accelerate industry standard frameworks such as PyTorch, Tensorflow, Jax, and more on supported AMD GPUs and APUs.
“AMD ROCm software enables open, high-performance acceleration for AI and HPC on AMD hardware. Working with Canonical to package AMD ROCm for Ubuntu makes it easier for developers and enterprises to deploy AMD solutions on supported systems,” said Andrej Zdravkovic, Senior Vice President, GPU Technologies and Engineering Software and Chief Software Officer at AMD.
Packaging AMD ROCm in Ubuntu underscores the strong AMD commitment to developer experience and enterprise experience:
“We are delighted to work alongside AMD and the community to package AMD ROCm libraries directly into Ubuntu,” said Cindy Goldberg, SVP of Silicon and Cloud Alliances at Canonical. “This will simplify the use of AMD hardware and software for AI workloads, and enable organizations to meet security and maintenance requirements for production use at scale.”
Canonical works closely with hardware manufactures to test, optimize, and certify Ubuntu for their devices, and to integrate the required software drivers and kernel patches to support that hardware. Thanks to this extensive hardware program, Ubuntu runs equally well on laptops, workstations, servers, and IoT/edge devices, and developers have a seamless path from development through to deployment.
09 December, 2025 10:21AM by xiaofei
Hello, Community!
The update for November is here! There are two big features: TLS support for syslog and IPFIX support in VPP, good progress in replacing the old configuration backend, and multiple bug fixes.
08 December, 2025 01:03PM by Daniil Baturin (daniil@sentrium.io)
5G continues to transform the telecommunications landscape, enabling massive device density, edge computing, and new enterprise use cases. However, operators still face significant cost pressures: from accelerating RAN modernization and 5G SA rollouts to energy demands and the shift to cloud-native network functions (CNFs). As telcos redesign their infrastructure strategies, open source has become a key lever to reduce costs, increase flexibility, and accelerate innovation.
This blog outlines today’s primary 5G infrastructure challenges and highlights how modern open source cloud technologies from Canonical help operators address them.
With the advancements of 5G and more complex deployments, telcos face several challenges in building and maintaining 5G infrastructure, including:
Open source plays a central role in enabling telcos to modernise their networks: from VNF virtualization to full cloud-native CNF deployments. By standardizing on open platforms like Ubuntu, Kubernetes and OpenStack, operators reduce infrastructure licensing costs, improve interoperability, and accelerate innovation. Today, most large operators run the majority of their 5G core workloads on open source infrastructure.
Open source communities, including CNCF, O-RAN Alliance and Project Sylva, provide common frameworks that reduce integration effort. By adopting open standards, operators can more easily mix vendors and ensure long-term ecosystem interoperability.
In line with the development of shared standards, open source solutions can help avoid vendor lock-in by providing access to code that can be modified and adapted to meet specific needs. This means that telcos and ISVs can avoid being tied to a particular vendor or technology stack and choose the best solutions for their specific requirements instead.
Telcos have demanding requirements when it comes to performance, reliability, and security. Long-term support (LTS) is important in the telco industry, as telcos often have long cycles of release deployment. Open source solutions that are supported over the long term, with no API breaks or major changes that could disrupt telco operations (i.e. 12-month release at least, and a few years on average) are the foremost choice for telcos. This is usually a vendor-driven decision, but choosing the right open source with the right vendor is the key here. The reason is, it is difficult to have a telco-grade system after dealing with all the interoperability and fixing into the puzzle challenges, so it is reasonable for an operator to expect the support cycle to be as long as possible.
Performance, flexibility, and automation are key requirements in the telco industry, as they enable telcos to operate more efficiently and effectively. By leveraging the expertise of the wider community, telcos, and ISVs can build solutions that are optimised for telco environments and that can be easily customised to meet specific requirements.
Open source software offers cost savings compared to proprietary solutions, which can be especially beneficial for organizations with limited budgets. With open source software, organizations do not need to pay for licenses, and there are no vendor lock-ins. They can leverage the vast community of developers and users to troubleshoot issues and implement new features. In addition to removing licensing fees, open source automation frameworks significantly reduce operational costs by simplifying CNF lifecycle management, improving energy optimization, and enabling consistent operations across core, edge and RAN deployments.
The telecom sector handles a vast amount of sensitive information, including personal and financial data, making it a prime target for cyber-attacks. There are several data privacy and security concerns that the telecom sector faces, including data breaches, malware attacks, insider threats, lack of compliance, etc. In this regard, open source software vulnerabilities are often patched more quickly than with proprietary software. In addition, open source software is transparent and customisable, making it easier to meet the operator’s unique needs and implement security features that align with their security requirements.
In the sections that follow we provide example applications for open source solutions across the telco stack, with a focus on tooling supported by Canonical.
Canonical’s telco portfolio spans the entire network – from RAN compute nodes to edge clouds, MEC platforms, private clouds and public-cloud deployments. Ubuntu and our cloud-native infrastructure stack (MAAS, MicroCloud, OpenStack, Kubernetes and Juju) provide a consistent operational model across all layers of the 5G architecture.. This enables telcos to meet any current or future use cases – from OpenRAN to next-generation Core (5G and beyond) and AI at the edge. Ubuntu Pro is Canonical’s comprehensive subscription for enterprise security, compliance and support.
Open source solutions for telcos
vRAN and Open RAN deployments require high performance, low latency and hardware acceleration. Canonical works closely with Intel FlexRAN, NVIDIA Aerial and ARM ecosystem partners to optimize Ubuntu for RAN workloads.
Another major Canonical contribution for RANs edge use cases is MicroCloud, which reproduces the APIs and primitives of the big clouds at the scale of the edge. MicroClouds are typically targeted to easily deploy and lifecycle manage distributed micro clouds – bare metal compute clusters of between 3-100 nodes. A Canonical MicroCloud stack consists of certain building blocks. The details for each component are covered in our Telco 5G infrastructure whitepaper.
Most operators deploy their 5G Core on private clouds to maintain strict performance and security control. Canonical’s reference architecture – MAAS for bare metal, OpenStack for virtualised infrastructure, Kubernetes for CNFs, and Juju for automation – provides a proven, carrier-grade cloud foundation adopted by major network equipment providers (NEPs) and operators globally.
Canonical stack for private clouds
Ubuntu is known for its reliability, security, and versatility, making it a popular choice for telecom companies that require a stable and secure operating system to run Telco applications in the public cloud. A hybrid cloud architecture combines the usage of a private cloud and one or more public cloud services with a workload orchestration engine between the platforms. Using Juju, operators can orchestrate and lifecycle-manage the same CNF or VNF stack across private OpenStack, MicroCloud edge clusters, and hyperscalers. Juju automation provides a consistent approach that natively supports all major hyper scalers APIs and is a de-facto standard tool for MicroClouds in edge use cases. Additionally, Ubuntu Pro for Public Clouds provides telcos with capabilities based on their unique requirements. Details of these requirements and features from Ubuntu are given in this blog series: Amazon Web services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.
5G infrastructure modernization continues to introduce new operational and cost challenges. Open source cloud technologies, combined with Canonical’s automation and long-term support, help operators simplify their architectures, reduce OPEX, and accelerate the shift to cloud-native 5G.
To explore the latest best practices, speak with our telco specialists.
08 December, 2025 11:04AM by Greenbone AG
Let’s be honest. Dealing with broken updates is a nightmare. We’ve all experienced that moment of panic when you run an update, step away for coffee, and return to a terminal screen full of angry red error messages. That is exactly why uCareSystem exists, and today, it gets even better at preventing these issues.
Fix Broken Updates: uCareSystem New Release
I’m thrilled to announce the latest release of uCareSystem. As the sole developer, I feel the pain of broken updates personally. For this version, I spent a lot of time under the hood, focusing on making sure the tool doesn’t just work when everything is perfect, but proactively fixes issues before they break your system.
Here is why you should upgrade to the new version and say goodbye to broken updates for good:
The most frustrating broken updates are the ones that fail because of something that happened last week.
The new uCareSystem introduces automated pre-flight checks. Think of it as a bouncer for your update process. Before it lets any new packages in, it checks the ID of your system to prevent broken updates. It now automatically detects and attempts to fix:
dpkg locks that require a reboot.The goal is simple: You press the button, and it actually works.
While staring at scrolling walls of monochrome text makes us feel like hackers in a 90s movie, it’s not great for spotting errors.
I’ve given the uCareSystem terminal interface a significant makeover. With improved color coding, better progress indicators, and real-time output logging, you’ll now have a much clearer idea of the process, helping you catch potential issues that could lead to broken updates.
Linux runs everywhere now. To keep up, uCareSystem needs to be flexible.
systemd detection so the tool plays nicely even in environments like Docker containers and Windows Subsystem for Linux (WSL).dpkg process trips and falls midway, the software now has mechanisms to help pick it back up automatically.For the code-peepers out there who like to look under the hood: I did some massive spring cleaning. Extensive refactoring and complying with ShellCheck standards mean the codebase is now cleaner and safer. This ensures better maintainability and fewer bugs in the future.
Give the new version a spin. Hopefully, it makes your system maintenance totally boring—and completely free of broken updates.
This was a significant undertaking, reflected in the statistics for this release:
Please take a look to a comprehensive Release note in the repository: https://github.com/Utappia/uCareSystem/releases/tag/v25.12.04
This release is a testament to my commitment to quality and my vision for the future of uCareSystem as a one-stop system maintenance tool Debian Ubuntu. I am confident that I laid a stronger foundation that will allow for even more exciting features and faster development in the future.
I am deeply grateful to the community members who supported the previous development cycle through donations or code contributions:
Every version, has also a code name dedicated as a release honored to one of the contributors. For historical reference, you can check all previous honored releases.
As always, I want to express my gratitude for your support over the past 15 years. I have received countless messages from inside and outside Greece about how useful they found the application. I hope you find the new version useful as well.
If you’ve found uCareSystem to be valuable and it has saved you time, consider showing your appreciation with a donation. You can contribute via PayPal or Debit/Credit Card by clicking on the banner.
| Pay what you want | Maybe next time |
|---|---|
| Click the donate button and enter the amount you want to donate. Then you will be navigated to the page with the latest version to download the installer | If you don’t want to Donate this time, just click the download icon to be navigated to the page with the latest version to download the installer |
 |
 |
Once installed, the updates for new versions will be installed along with your regular system updates.
The post Fix Broken Updates: uCareSystem New Release uCareSystem v25.12 appeared first on Utappia.
We’re pleased to announce that the fourth release candidate (RC) for Qubes OS 4.3.0 is now available for testing. This minor release includes many new features and improvements over Qubes OS 4.2.
These are just a few highlights from the many changes included in this release. For a more comprehensive list of changes, see the Qubes OS 4.3 release notes.
That depends on the number of bugs discovered in this RC and their severity. As explained in our release schedule documentation, our usual process after issuing a new RC is to collect bug reports, triage the bugs, and fix them. If warranted, we then issue a new RC that includes the fixes and repeat the process. We continue this iterative procedure until we’re left with an RC that’s good enough to be declared the stable release. No one can predict, at the outset, how many iterations will be required (and hence how many RCs will be needed before a stable release), but we tend to get a clearer picture of this as testing progresses.
Barring any surprises uncovered by testing, we expect this fourth RC to be the final one, which means that we hope to declare this RC to be the stable 4.3.0 release at the conclusion of its testing period.
Thanks to those who tested earlier 4.3 RCs and reported bugs they encountered, 4.3.0-rc4 now includes fixes for several bugs that were present in those prior RCs!
If you’d like to help us test this RC, you can upgrade to Qubes 4.3.0-rc4 with either a clean installation or an in-place upgrade from Qubes 4.2. (Note for in-place upgrade testers: qubes-dist-upgrade now requires --releasever=4.3 and may require --enable-current-testing for testing releases like this RC.) As always, we strongly recommend making a full backup beforehand and updating Qubes OS immediately afterward in order to apply all available bug fixes.
If you’re currently using an earlier 4.3 RC and wish to update to 4.3.0-rc4, please update normally with current-testing enabled. If you use Whonix, please also upgrade from Whonix 17 to 18, if you have not already done so.
Please help us improve the eventual stable release by reporting any bugs you encounter. If you’re an experienced user, we encourage you to join the testing team.
It is possible that templates restored in 4.3.0-rc4 from a pre-4.3 backup may continue to target their original Qubes OS release repos. This does not affect fresh templates on a clean 4.3.0-rc4 installation. For more information, see issue #8701.
View the full list of known bugs affecting Qubes 4.3 in our issue tracker.
A release candidate (RC) is a software build that has the potential to become a stable release, unless significant bugs are discovered in testing. RCs are intended for more advanced (or adventurous!) users who are comfortable testing early versions of software that are potentially buggier than stable releases. You can read more about Qubes OS supported releases and the version scheme in our documentation.
The Qubes OS Project uses the semantic versioning standard. Version numbers are written as [major].[minor].[patch]. Hence, releases that increment the second value are known as “minor releases.” Minor releases generally include new features, improvements, and bug fixes that are backward-compatible with earlier versions of the same major release. See our supported releases for a comprehensive list of major and minor releases and our version scheme documentation for more information about how Qubes OS releases are versioned.
Some years ago I had mentioned some command line tools I used to analyze and find useful information on GStreamer logs. I’ve been using them consistently along all these years, but some weeks ago I thought about unifying them in a single tool that could provide more flexibility in the mid term, and also as an excuse to unrust my Rust knowledge a bit. That’s how I wrote Meow, a tool to make cat speak (that is, to provide meaningful information).
The idea is that you can cat a file through meow and apply the filters, like this:
cat /tmp/log.txt | meow appsinknewsample n:V0 n:video ht: \
ft:-0:00:21.466607596 's:#([A-za-z][A-Za-z]*/)*#'
which means “select those lines that contain appsinknewsample (with case insensitive matching), but don’t contain V0 nor video (that is, by exclusion, only that contain audio, probably because we’ve analyzed both and realized that we should focus on audio for our specific problem), highlight the different thread ids, only show those lines with timestamp lower than 21.46 sec, and change strings like Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp to become just AppendPipeline.cpp“, to get an output as shown in this terminal screenshot:
Cool, isn’t it? After all, I’m convinced that the answer to any GStreamer bug is always hidden in the logs (or will be, as soon as I add “just a couple of log lines more, bro” 
0 
0 
05 December, 2025 11:16AM by Enrique Ocaña González (eocanha@igalia.com)
Every year at CES, we try to go beyond showing technology; we want to give you an experience. This time, it’s the story of how in-vehicle infotainment development is transforming, and how developers can now build, test, and deploy immersive experiences faster than ever.
This year, we’re excited to show a demo that combines the strengths of both Anbox Cloud and Rightware’s Kanzi, the industry-leading software for creating rich, visually stunning infotainment interfaces. It demonstrates cloud-native development, automation, and how virtualization can open up completely new ways to design and test next-generation in-vehicle experiences.
Automotive software development has become incredibly complex. Teams are often focused on their own discipline, UI designers on immersive experiences, Android developers on building integrations, and validation engineers on reliability across hardware variants. These teams can’t always collaborate seamlessly.
Testing an infotainment system means being able to access specific hardware or prototypes, which makes iteration slow and collaboration difficult. Small design updates can take days to validate, and testing across different screen configurations or performance conditions is often limited by the availability of physical setups.
We wanted to change that by bringing agility and scalability to infotainment development.
In our demo, we’ll show how Anbox Cloud turns this traditionally hardware-bound process into a fully virtualized, cloud-native experience. By running Android in the cloud, developers can instantly deploy and test infotainment environments built using Kanzi, on demand, at any scale, from anywhere.
Widescreen 8K infotainment CES demo
Our setup fits perfectly with Rightware’s widescreen 8K infotainment and cluster bench, powered by Kanzi. Developers can stream the exact same 8K rendering using Anbox Cloud. The result is an impressive, interactive experience, generated and streamed entirely from the cloud.
8K virtual Android device running on Anbox Cloud
Thanks to Anbox Cloud, Android can be virtualized to any resolution, with pixel-perfect rendering and responsiveness. It can scale to dozens of Android instances running simultaneously, so teams can run automated testing, validate UI performance, and work on the system updates in parallel. Your development becomes faster, collaborative, and independent of physical limitations.
When moving your development testing to the cloud, designers and developers can collaborate in real time and can see their changes without waiting for hardware to be available. Validation teams can run automated tests on multiple Android instances, across different configurations. For OEMs and Tier 1 suppliers, this means shorter development cycles, meaning more efficient resource use, and faster results.
“Kanzi has always been about empowering designers and developers to bring exceptional in-vehicle experiences to life,” says Tero Koivu, Co-CEO at Rightware. “Seeing a Kanzi made UI streamed at 8K through Anbox Cloud shows how cloud-native workflows can dramatically accelerate iteration and collaboration. It opens a powerful new path for teams building the next generation of connected, visually stunning automotive user interfaces.”
Join us at LVCC, North Hall, Booth #10562, and check out the workflow for yourself. You’ll see how Kanzi and Anbox Cloud come together to deliver high-fidelity, scalable, cloud-native infotainment experiences, and how this is redefining the way developers can use Android in the cloud.
Come see the future of automotive software development, from cloud to dashboard.
In the meantime, learn more about Anbox Cloud, and Rightware.
Official documentation
Anbox Cloud Appliance
Learn more about Anbox Cloud
Android is a trademark of Google LLC. Anbox Cloud uses assets available through the Android Open Source Project.
My Debian contributions this month were all sponsored by Freexian. I had a bit less time than usual, because Freexian collaborators gathered in Marseille this month for our yearly sprint, doing some planning for next year.
You can also support my work directly via Liberapay or GitHub Sponsors.
I began preparing for the second stage of the GSS-API key exchange package split (some details have changed since that message). It seems that we’ll need to wait until Ubuntu 26.04 LTS has been released, but that’s close enough that it’s worth making sure we’re ready. This month I just did some packaging cleanups that would otherwise have been annoying to copy, such as removing support for direct upgrades from pre-bookworm. I’m considering some other package rearrangements to make the split easier to manage, but haven’t made any decisions here yet.
This also led me to start on a long-overdue bug triage pass, mainly consisting of applying usertags to lots of our open bugs to sort them by which program they apply to, and also closing a few that have been fixed, since some bugs will eventually need to be reassigned to GSS-API packages and it would be helpful to make them easier to find. At the time of writing, about 30% of the bug list remains to be categorized this way.
I upgraded these packages to new upstream versions:
I packaged django-pgtransaction and backported it to trixie, since we plan to use it in Debusine; and I adopted python-certifi for the Python team.
I fixed or helped to fix several other build/test failures:
I fixed a couple of other bugs:
04 December, 2025 11:49AM by t.lamprecht (invalid@example.com)
Weihnachten im Dezember – und das mit guter Bigband-Musik! 🎄
Am 12. Dezember 2025 laden wir euch zu einem Weihnachtskonzert der besonderen Art ein – mit der HTU Bigband im Mo.xx! Es gibt Jazz-Rock, Swing, Soul-Pop, Latin + Funk und natürlich jede Menge gute Stimmung. Einlass ist um 19 Uhr, Eintritt freiwillige Spende, und ab 19:30 Uhr gibt es dann feine Musik auf die Ohren. 🎶
🎵 Was: feine Bigband-Musik
⏰ Wann: Freitag, 12. Dezember 2025, ab 19:30 Uhr
📍 Wo: mo.xx, Moserhofgasse 34, Graz
Kommt vorbei, am Besten mit Familie und Freunden! 🎅
In the network security ecosystem, here is a common practice: WAF (Web Application Firewall) solutions that boast thousands of active rules. For an administrator evaluating products, that number may seem reassuring — more rules should theoretically mean more protection. But when you dig deeper, you quickly discover that many of those rules don’t apply to your infrastructure at all.
In several major solutions on the market, part of the rule catalog is dedicated to protecting highly specific technologies: particular PBX models, proprietary hardware, niche admin panels, or applications used by a tiny segment of the industry. If you don’t use those technologies — and most companies don’t — those rules don’t provide security. They simply add overhead to every inspection, increasing latency and operational noise.
To make things worse, in many solutions the WAF behaves like a black box the administrator cannot access.
You cannot see what each rule does, you cannot modify it, you cannot disable it, and you cannot add your own logic. You must rely on a set of policies you don’t control, performing checks you can’t always interpret, and consuming resources on every request.
This leads to a scenario many engineers will immediately recognize:
When the inspection chain is full of irrelevant signatures, three things happen:
Every irrelevant rule is still evaluated on each request, even if it will never trigger. This increases latency, consumes CPU unnecessarily, and adds load to the WAF pipeline without providing any real security. In high-traffic environments, this cumulative overhead can produce noticeable performance degradation.
If you cannot see what each rule does or what pattern it evaluates, you cannot diagnose why a request is blocked or allowed. This lack of visibility prevents you from tuning your policy, obscures the WAF’s behaviour, and forces you to build your security strategy around the vendor’s assumptions rather than the needs of your architecture.
If the security policy is a closed package, you cannot adapt it to your environment: you cannot fine-tune rules, disable those that don’t apply, or introduce your own logic. The only path to “improving” the system often ends up being additional proprietary modules, which add complexity but do not solve the underlying issue: the administrator has no real ability to design their own security posture.
This is why measuring a WAF by the number of rules it contains is an unreliable indicator. It says nothing about actual effectiveness and is often used more as a commercial argument than a technical benefit.
For an engineer evaluating a WAF seriously, the relevant criteria are very different:
Cross-cutting rules, not signatures tied to applications you don’t use. HTTP standards validation, universal attack patterns (SQLi, XSS, LFI), anomalies and protocol violations.
Full transparency. Visibility into each rule, its logic, its conditions, and its actions.
Real control. The ability to enable, disable, modify, or add rules based on your architecture.
A reduced but effective rule set. Less noise, fewer false positives, and lower CPU consumption.
Clear diagnostics. Readable logs, traceability, and visibility into the decision flow.
This is the type of design that allows an administrator to trust the system — not because the catalog is huge, but because the policy is clean, understandable, and aligned with real-world risk.
At SKUDONET we know that system administrators don’t need thousands of WAF rules — they need rules that make sense for their stack.
That’s why our WAF is built around a set of more than 700 universal rules, focused on two areas that affect any web application:
Administrators have full access to the policy: they can inspect each rule, understand what it evaluates, modify it, create new ones, or disable those they don’t need. The goal is to give engineers total control over WAF behaviour so they can tailor it precisely to their environment.
This approach avoids unnecessary overhead, reduces latency, and results in a policy that is more coherent, more traceable, and significantly easier to audit.
| “Thousands-of-rules” model | SKUDONET model |
|---|---|
| Many irrelevant signatures | Universal and meaningful rules |
| High processing cost | Low latency and optimized policy |
| Black-box behavior | Full visibility |
| Difficult troubleshooting | Clear auditing and real traceability |
A WAF’s rule count tells you nothing about its actual security effectiveness — nor about its real coverage. Volume-based approaches usually translate into higher latency, less visibility, and less control.
It’s not about having more rules, it’s about having the right rules — and the ability to adjust them to what is truly happening inside your infrastructure.
If you want to validate a WAF where every rule is visible, adjustable and built for real relevance—not volume—you can request a 30-day full-featured trial of SKUDONET Enterprise Edition.
03 December, 2025 01:21PM by Nieves Álvarez
03 December, 2025 11:25AM by Joseph Lee
03 December, 2025 07:48AM by xiaofei
03 December, 2025 06:48AM by xiaofei
Today, Canonical announced the general availability of Ubuntu Pro for WSL which can be installed from the Microsoft Store. Source and beta releases are also on GitHub.
Canonical and Microsoft have a fantastic partnership, building out the WSL experience. This work will benefit enterprise developers who use WSL to build production Linux solutions.
Craig Loewen, Product Manager for WSL at Microsoft
Ubuntu Pro delivers enterprise-grade security maintenance and support across desktops, servers, and IoT devices. Now, that same proven value proposition comes to WSL, addressing the security and compliance needs of IT managers and paving the way for broader enterprise adoption.
WSL provides developers, system administrators, and power users with a native Linux experience on Windows, without the overhead of a full virtual machine or dual boot. It allows users to run Linux command-line tools, utilities, and graphical Linux applications directly on Windows. In collaboration with NVIDIA, WSL 2 delivers near-native GPU-accelerated-performance, allowing applications in Ubuntu to access GPU drivers directly on the Windows host. With Ubuntu Pro, this developer-focused tool is transformed into a fully supported, enterprise-ready solution with up to 15 years of security maintenance.
For many enterprises, strict security and compliance policies have been a barrier to adopting WSL given the risks of unmonitored and unsupported open source software. Ubuntu Pro for WSL ensures Expanded Security Maintenance (ESM) is enabled, providing CVE security updates that can be applied subject to administrative policy. Canonical provides up to 15 years of CVE security patching for software packaged and published through Ubuntu’s repositories. Ubuntu Pro subscriptions also cover security maintenance for popular toolchains on WSL, such as Python, Go, Rust, and more. This turnkey solution ensures security vulnerabilities are patched quickly and reliably, making WSL a viable, compliant option for enterprise environments.
Ubuntu Pro for WSL will also enable system administrators to manage instances using Landscape, Canonical’s system management tool for Ubuntu. The WSL management feature of Landscape is in beta today, and customers interested in sharing feedback about the feature, and shaping its future, can do so in a self-hosted Landscape server, or by signing up for Landscape SaaS. Landscape will monitor all WSL instances that are deployed once Ubuntu Pro for WSL is configured, and identify which Windows hosts are compliant and which are non-compliant with your WSL provisioning and configuration policies.
Personal users benefit from a point-and-click installation of Ubuntu Pro for WSL from within the Microsoft Store. As a standard MSIX package, Ubuntu Pro for WSL integrates seamlessly into existing enterprise management workflows, allowing for easy installation and configuration using Microsoft’s enterprise tools. Ubuntu Pro for WSL can be installed and configured using cloud-based tools such as Microsoft Intune, or via Group Policies defined in Microsoft Active Directory.
In addition to being available in the Microsoft Store, images of Ubuntu on WSL are available for download and distribution behind a firewall, giving enterprises the option to host images internally, with centralized control over which WSL images are available to employees.
Beyond security and ease of deployment, Ubuntu Pro for WSL introduces a new support model for developers using WSL. Canonical provides an Ubuntu Pro subscription tier which includes comprehensive phone and ticket support (Ubuntu Pro + Support). This provides a clear and streamlined way for Windows-native developers to get expert help with their Linux environment.
Ubuntu Pro for WSL brings Canonical’s security and support capabilities into the Windows ecosystem. Free subscriptions for personal users and paid subscriptions are available through 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.
Learn more at canonical.com
The 11th monthly Sparky project and donate report of the 2025: – Linux kernel updated up to 6.16.9, 6.12.59-LTS, 6.6.117-LTS – Added to repos: Hyprland desktop – new repo server located in United Kingdom: UK1 – CDE desktop updated up to 2.5.3 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…
01 December, 2025 09:24PM by pavroo
December 1, 2025 – Canonical, the publisher of Ubuntu, today announced the availability of certified images for the Qualcomm Dragonwing™ IQ-9075 platform. This high-performance industrial platform is now fully supported with optimized images for Ubuntu 24.04 LTS. The certified images are available for both Ubuntu Server and Desktop, equipping developers with a robust and securely designed software foundation necessary for next-generation industrial automation, robotics, and edge AI applications.
This launch builds on the general availability of Ubuntu for the QCS6490 and QCS5430 processors, with today’s announcement being the latest instance of Canonical support for Qualcomm’s Dragonwing™ processors.
The Qualcomm Dragonwing™ IQ-9075 is designed for the next generation of industrial automation systems, handling everything from real-time analytics to on-device Generative AI. Designed for extreme edge AI, IQ-9075 combines high-performance with physical resilience. The platform can deliver up to 100 TOPS of on-device AI compute in thermal junction temperatures ranging from -40℃ to +115℃.
By certifying Ubuntu for the IQ-9075 platform, Canonical ensures that enterprises get a seamless out-of-the-box experience from development to production. Through Ubuntu Pro, Canonical’s subscription for open source security, developers benefit from up to 15 years of long term support. Combined with Qualcomm’s decade-long product lifecycle, developers on IQ-9075 benefit from stability on both the hardware and software level.
Here is a more detailed rundown of the features you can expect on the Qualcomm Dragonwing™ IQ-9075:
“We are delighted to deepen our collaboration with Canonical by bringing certified Ubuntu support to the Qualcomm Dragonwing™ IQ-9075 processor,” said Laxmi Rayapudi, VP of Product Management, Qualcomm Technologies, Inc. “The IQ-9075 is designed for the most compute-intensive industrial tasks. Providing certified Ubuntu images – optimized and supported by Canonical – gives our ODMs and customers an essential, trusted software layer to deliver security-focused, high-performance edge solutions to market faster.”
“Ubuntu on Qualcomm Dragonwing™ IQ-9075 will accelerate the launch of AI-ready industrial devices at scale. This partnership will ensure high performance and robust security at both the hardware and software level.” said Olivier Philippe, VP of Devices Engineering at Canonical. “Manufacturers using Qualcomm’s Dragonwing™ IQ-9075 platform will not only be ready for long term support and maintenance, but also benefit from the full power of open source AI software innovations optimized for the Dragonwing™ IQ-9075″.
To access the latest certified Ubuntu images for the Qualcomm Dragonwing™ IQ-9075 platform, please visit our Qualcomm IoT download page. If you have any questions about the platform or would like information about our certification program, then contact us by filling out our dedicated form.
The Incus team is pleased to announce the release of Incus 6.19!
This is a slightly less busy release than usual as we’ve recently been spending quite a bit of time smoothing some of the initial rough edges from the IncusOS release.
That said, it still contains quite a few nice improvements and quite a lot of bugfixes!
The highlights for this release are:
The full announcement and changelog can be found here.
And for those who prefer videos, here’s the release overview video:
You can take the latest release of Incus up for a spin through our online demo service at: https://linuxcontainers.org/incus/try-it/
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.
Enjoy!
01 December, 2025 12:35PM by Hace İbrahim Özbal
01 December, 2025 10:01AM by xiaofei
We have extended our webhooks capabilities to be able to trigger webhooks on successful and unsuccessful package uploads to Personal Package Archives (PPAs).
When a new source package is uploaded to one of your PPAs, the system can now send an instant webhook notification to an endpoint you control. This will make it easier to build automations around package uploads and binary package builds in your PPAs.
The webhook configuration includes scopes so you can configure to only trigger on successful use cases, or vice versa. Each webhook payload includes essential metadata about the upload – more details in the Webhooks page of our user documentation.
To try it out, you can add a webhook to your archive via the API (API reference), or via the UI by going to “Manage Webhooks” in your archive’s page.
If you have ideas or feedback, reach out to us!
Today we're happy to release OSMC's November 2025 update for all supported devices. The nights are drawing in and it's getting colder. So we want to keep your OSMC experience running smoothly. This update brings you Kodi v21.3 with a number of improvements.
The release notes for Kodi v21.3 are not yet officially available but we will update this post with a link when they are published.
From 29th August, there was an executive order stating that shipments to the USA would be subject to import tarrifs and we initially advised for customers to put their orders before this date.
We're now happy to announce that since early September, we have resumed shipments to the US. They remain tariff free and the price that you see on the website is the final price. There are no extra or hidden charges. It's business as usual.
In case you missed it, we are now happy to announce TV-led Dolby Vision support for Vero V devices. You can learn more about Dolby Vision here.
Nothing needs to be done to enable this functionality beyond updating to the latest version of OSMC.
Furthermore, we are now exploring Dolby Vision FEL support and we have started testing this internally.
We like to offer our customers the best possible price for our products, including our flagship Vero V. We didn't offer a Black Friday discount this year. We're already offering the best possible price and with the current insatiable demand for DRAM, we're doing our best to keep the price as it is while we can.
Technology usually operates in a deflationary environment but the AI boom is currently causing an extreme demand for memory. We are doing what we can to mitigate this, including purchasing memory in advance when we see price breaks.
On the OSMC side, we've made a number of changes to keep things running smoothly:
/etc/os-release to improve compatibilityTo get the latest and greatest version of OSMC, simply head to My OSMC -> Updater and check for updates manually on your exising OSMC set up. Of course — if you have updates scheduled automatically you should receive an update notification shortly.
If you enjoy OSMC, please follow us on X, like us on Facebook and consider making a donation if you would like to support further development.
You may also wish to check out our Store, which offers a wide variety of high quality products which will help you get the most out of OSMC.
Vero V is our latest and greatest flagship and the best way to enjoy OSMC and with Dolby Vision now supported, it's better than ever.
30 November, 2025 11:50PM by Sam Nazarko
28 November, 2025 10:55AM by Hace İbrahim Özbal
27 November, 2025 08:38AM by xiaofei
Nesta semana e seguintes, vamos apostar no Ubuntu Touch e trazer o Software Livre nos telefones para as massas! O Miguel resolveu problemas com a ajuda da comunidade, o Diogo vai ao Porto evangelizar à bruta com o Ruben Carneiro e o sol brilhará para todos nós. A Canonical promete suporte para 15 anos; o Xubuntu foi hackeado porque não usa Hugo (womp, womp); o Miguel agora usa mano e bro em cada frase por causa de impressoras e vai converter-se ao Debian com Plasma e MEU DEUS, AS MÁQUINAS DA STEAM SÃO LINDAS!! FUUUUYYYYYOOOOH!!!
Já sabem: oiçam, subscrevam e partilhem!
Este episódio foi produzido por Diogo Constantino, Miguel e Tiago Carrondo e editado pelo Senhor Podcast. O website é produzido por Tiago Carrondo e o código aberto está licenciado nos termos da Licença MIT. (https://creativecommons.org/licenses/by/4.0/). A música do genérico é: “Won’t see it comin’ (Feat Aequality & N’sorte d’autruche)”, por Alpha Hydrae e está licenciada nos termos da CC0 1.0 Universal License. Os separadores de péssima qualidade foram tocados ao vivo e sem rede pelo Miguel, pelo que pedimos desculpa pelos incómodos causados. Os efeitos sonoros têm os seguintes créditos: [patrons laughing.mp3 by pbrproductions] (https://freesound.org/s/418831/) – License: Attribution 3.0. Concurso: [01 WINNER.mp3 by jordanielmills] – (https://freesound.org/s/167535/) – License: Creative Commons 0. Este episódio e a imagem utilizada estão licenciados nos termos da licença: Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0), cujo texto integral pode ser lido aqui. Estamos abertos a licenciar para permitir outros tipos de utilização, contactem-nos para validação e autorização. A arte de episódio foi criada por encomenda pela Shizamura - artista, ilustradora e autora de BD. Podem ficar a conhecer melhor a Shizamura na Ciberlândia e no seu sítio web.
Community Edition is the open source load balancer from SKUDONET, designed for engineers and administrators who need traffic control without relying on costly or complex solutions.
Built on Debian 12.8, it provides a stable and secure operating system with performance far above what is typical in free software:
It is 100% free, fully open source, and compatible with Linux and Windows server environments.
For technical users looking for an open source load balancer with a Web GUI, easy to deploy and free of extra dependencies, this edition is an ideal starting point.
Most open source load balancers require manual configuration, editing text files, or navigating a steep learning curve. This is where SKUDONET Community Edition stands out.
The software includes a full Web GUI that allows you to:
This makes it highly accessible—even for small teams that need immediate results without spending hours reading advanced documentation.
From a technical perspective, SKUDONET CE includes features typically found only in commercial products:
Handles large volumes of TCP/UDP connections with minimal overhead.
Designed for web applications, APIs, and HTTP/HTTPS services.
Enables SSL termination directly in the load balancer.
Ensures traffic is sent only to available backend servers.
A visual interface for managing all components without CLI.
Full automation for CI/CD pipelines, hybrid infrastructures, or external integrations.
Suitable for modern and distributed network architectures.
Beyond traffic distribution, SKUDONET Community Edition includes fundamental security mechanisms:
It is not a deep-inspection system like the Enterprise Edition, but it provides an initial layer of protection useful for development environments and small deployments. And if your infrastructure later requires deeper traffic inspection, advanced clustering, or professional support, you can migrate to SKUDONET Enterprise Edition, designed for critical environments.
SKUDONET Community Edition is distributed for free through SourceForge, where you can download the ISO or installation packages for your test or development environment.
26 November, 2025 03:05PM by Nieves Álvarez
26 November, 2025 12:30PM by t.lamprecht (invalid@example.com)
26 November, 2025 02:12AM by xiaofei
25 November, 2025 07:40AM by xiaofei
24 November, 2025 03:38PM by Hace İbrahim Özbal
A complete feed is available in any of your favourite syndication formats linked by the buttons below.
![[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}
Last updated: 20 Dec 2025 02:31
All times are UTC.
Contact: Debian Planet Maintainers