AHXproject

KDE Frameworks 6.27 Is Out to Improve KRunner, Breeze Icons, and More



KDE Frameworks 6.27 open-source software suite is out now with various improvements and bug fixes for KDE apps and the Plasma desktop environment. Here's what's new!

The post KDE Frameworks 6.27 Is Out to Improve KRunner, Breeze Icons, and More  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Apps, News, KDE, KDE Frameworks, software suite
Source: https://9to5linux.com/kde-frameworks-6-27-is-out-to-improve-krunner-breeze-icons-and-more Jun 12, 2026, 03:35 AM

Audacity 3.7.8 Audio Editor Improves Support for HiDPI Displays on Linux



Audacity 3.7.8 open-source digital audio editor and recording software is now available for download with improves support for HiDPI displays on Linux, new options to choose where silence is truncated, and more.

The post Audacity 3.7.8 Audio Editor Improves Support for HiDPI Displays on Linux  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Apps, News, Audacity, audio editor, audio recording
Source: https://9to5linux.com/audacity-3-7-8-audio-editor-improves-support-for-hidpi-displays-on-linux Jun 11, 2026, 05:55 PM

COSMIC 1.0.16 Desktop Adds OpenRC Support for Bluetooth Service Management



COSMIC 1.0.16 desktop environment is now available with improvements across COSMIC Files, COSMIC Panel, COSMIC Settings, COSMIC Player, COSMIC Greeter, and COSMIC Launcher.

The post COSMIC 1.0.16 Desktop Adds OpenRC Support for Bluetooth Service Management  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Desktops, News, COSMIC, desktop environment
Source: https://9to5linux.com/cosmic-1-0-16-desktop-adds-openrc-support-for-bluetooth-service-management Jun 10, 2026, 10:23 PM

Fwupd 2.1.5 Linux Firmware Updater Released with Support for Elan Touchscreens



Fwupd 2.1.5 Linux firmware updater is now available for download with support for Elan touchscreens, support for installing the database updates on broken hardware with new firmware, as well as various other improvements.

The post Fwupd 2.1.5 Linux Firmware Updater Released with Support for Elan Touchscreens  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Apps, News, firmware update, firmware upgrade, fwupd, Linux firmware
Source: https://9to5linux.com/fwupd-2-1-5-linux-firmware-updater-released-with-support-for-elan-touchscreens Jun 10, 2026, 06:18 PM

Alpine Linux 3.24 Released with GNOME 50, KDE Plasma 6.6, and COSMIC Desktops



Alpine Linux 3.24 distribution is now available for download with GNOME 50, KDE Plasma 6.6, COSMIC desktop, and Linux kernel 6.18 LTS. Here's what's new!

The post Alpine Linux 3.24 Released with GNOME 50, KDE Plasma 6.6, and COSMIC Desktops  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Distros, News, Alpine Linux, independent distro, Linux distribution
Source: https://9to5linux.com/alpine-linux-3-24-released-with-gnome-50-kde-plasma-6-6-and-cosmic-desktops Jun 10, 2026, 12:51 AM

digiKam 9.1 Photo Manager Released with Support for Pixel Motion Photos



digiKam 9.1 open-source professional photo manager is now available for download with support for Pixel motion photos, timezone support with registered item time-stamps, and more. Here's what's new!

The post digiKam 9.1 Photo Manager Released with Support for Pixel Motion Photos  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Apps, News, digiKam, photo editor, photo management, photo manager, photo organizer
Source: https://9to5linux.com/digikam-9-1-photo-manager-released-with-support-for-pixel-motion-photos Jun 09, 2026, 07:54 AM

AI at the edge: simplifying infrastructure with Cisco and Canonical

Legacy infrastructure was not designed for the requirements of the AI era. While large-scale model training remains centralized in data centers, test-time inference is rapidly shifting to the edge to reduce latency and bandwidth consumption. This shift creates a new frontier for enterprise AI, but deploying at the edge introduces significant manual complexity, interoperability issues, and security vulnerabilities.

To address these challenges, Cisco and Canonical have developed a new Cisco Validated Design (CVD). This guide details how to leverage the Canonical portfolio on the Cisco Unified Edge system to deliver scalable, secure, and cost-efficient AI-ready infrastructure. In this article, we'll whet your appetite by highlighting the key challenges, technologies, and solutions explored in the guide.

The challenges of legacy infrastructure for AI

Enterprises attempting to deploy AI use cases on traditional edge infrastructure typically face five critical bottlenecks:

• Hardware Limitations: Lack of specialized acceleration (GPUs) and high-density compute in small form factors.
• Architectural Rigidity: Static environments that cannot easily pivot between virtualized and containerized workloads.
• Scaling Inefficiency: Difficulty in managing thousands of geographically dispersed sites consistently.
• Cost Prohibitions: High CapEx for "rip-and-replace" cycles and high OpEx for manual site maintenance.
• Software Fragmentation: Version lag, lack of security patching (CVEs), and vendor lock-in.

Let's dig into how our joint solution with Cisco addresses these challenges.

The software layer: A unified open source stack

The solution begins with a hardened software foundation provided by Canonical. By decoupling the application layer from the underlying hardware, enterprises can modernize legacy operations without manual rebuilds.

• Ubuntu Pro: Provides a stable, 15-year security maintenance lifecycle, backporting of critical fixes, and seamless public cloud integration.
• Data Science Stack (DSS): A ready-to-use environment for data scientists to develop and deploy models without worrying about underlying library dependencies.
• Charmed Operators: Automated operations for popular AI/ML toolkits (e.g., Kubeflow, MLflow), enabling consistent deployment and "Day 2" operations across the fleet.

The hardware layer: Converged infrastructure for AI

AI at the edge requires hardware that is both rugged and high-performing. The Cisco Unified Edge is a purpose-built system that converges compute, networking, storage, and security into a compact footprint.

Hardware certification

A key advantage of this partnership is the Canonical certification program. The Cisco UCS hardware is Ubuntu Certified, meaning Canonical works directly with Cisco to ensure the OS kernel is optimized for this specific platform. Running on this hardware, Ubuntu Server 24.04.3 LTS provides a stable, trusted open source foundation for edge applications.

The design guide we've developed with Cisco utilizes the Cisco UCS XE9305 chassis, which provides a variety of features to support inference at the edge:

• Form Factor: A 3-Rack-Unit (3RU) short-depth platform designed for space-constrained edge environments.
• Compute Nodes: Hosts up to five Cisco UCS XE130c nodes.
• Processing: 6th Gen Intel Xeon SoC processors (up to 32 cores per node).
• Memory: Up to 768GB DDR5 for high-throughput data processing.
• Acceleration: Dedicated NVIDIA L4 Tensor Core GPUs, providing energy-efficient AI inference.

Deployment flexibility: From VMs to Kubernetes

Edge environments often require a mix of legacy and modern workloads. The Cisco and Canonical solution supports multiple deployment models on a single platform, solving the architectural rigidity challenge:

• System containers and VMs with LXD : LXD treats containers like lightweight virtual machines, offering a VM-like experience with the efficiency of containers. It is ideal for hosting full Linux distributions or infrastructure services with minimal overhead.
• Canonical Kubernetes : For orchestrated, cloud-native applications, Canonical Kubernetes delivers an enterprise-grade distribution that is fully upstream-aligned.
• Canonical MicroCloud : This lightweight, automated private cloud solution is purpose-built for resource-constrained environments. It combines LXD, MicroCeph for storage, and MicroOVN for networking into a self-managing stack.

Zero-Touch operations and security

Managing thousands of edge locations is an operational bottleneck. This solution utilizes Cisco Intersight, a cloud-based management platform, to enable Zero-Touch Provisioning (ZTP).

By using curated Blueprints, administrators can automate the deployment of the entire stack, from hardware firmware to the OS and Kubernetes layers. This eliminates manual configuration errors and ensures site-to-site consistency.

This foundation is reinforced by multi-layered protection, utilizing Ubuntu Pro for continuous CVE patching and MicroOVN to ensure network isolation for sensitive AI models and data.

Conclusion

The shift to edge AI demands a departure from traditional infrastructure silos. By combining Cisco's modular, high-performance hardware with Canonical's automated open source software stack, enterprises can build a future-ready platform that scales without the need for constant "rip-and-replace" cycles.

Would you like to explore the full technical specifications and deployment steps?

Read the full Cisco Unified Edge and Canonical Design Guide

If you have any questions, you can contact us directly:

Enrico Panetta, Alliance Field Engineer – [email protected]

Further reading:

Ubuntu Server documentation  

Canonical MicroCloud documentation

Legacy infrastructure was not designed for the requirements of the AI era. While large-scale model training remains centralized in data centers, test-time inference is rapidly shifting to the edge to reduce latency and bandwidth consumption. This shift creates a new frontier for enterprise AI, but deploying at the edge introduces significant manual complexity, interoperability issues, [...]


Categories: AI, AI/ML Infrastructure, Cisco, Edge AI, Partner
Source: https://ubuntu.com//blog/ai-at-the-edge-simplifying-infrastructure-with-cisco-and-canonical Jun 11, 2026, 10:25 PM

The next era of telco clouds: get open infrastructure choice with Sylva and Canonical Kubernetes

The telco industry is undergoing a fundamental change. Over the past few years, the increasing maturity of cloud-native infrastructure has accelerated the movement from manually operated and hardware-centric systems to automated, software-defined platforms. 

Underpinning this change are open source initiatives such as the Sylva project . Sylva is hosted by Linux Foundation Europe and heavily backed by major telecom operators and vendors. It provides a standardized, declarative cloud-native software framework for building and operating telco infrastructures. The project aims to reduce fragmentation in telco clouds and to help telco operators break free from proprietary vendor lock-in. 

However, achieving vendor neutrality requires an infrastructure layer that respects open standards, without wrapping them in rigid platform layers. By combining upstream alignment with up to 15 years of support longevity, Canonical's approach to Sylva is built around a requirement that matters deeply to telcos: follow upstream cloud-native innovation when developing and evolving platforms, then rely on long-term support to keep production environments stable, trusted, and operationally predictable.

How does using open source benefit telcos specifically?

Open source architectures serve as engines for accelerated innovation, thanks to global developer ecosystems that collaboratively debug, optimize, and expand software capabilities. Upstream alignment removes proprietary forks and hidden dependencies, giving organizations the flexibility to inspect, modify, and integrate code dynamically.

This is particularly relevant for telcos, which have been historically burdened by rigid, vertically integrated legacy systems and vendor lock-in. In addition, telco networks span highly diverse hardware environments, ranging from centralized core data centers to resource-constrained far-edge cell towers and open RAN distributed units (DUs). As a result, telcos typically face massive capital and operational costs when scaling or updating networks. Moreover, telcos have to navigate a matrix of global and regional regulations, including those around security and data sovereignty. In such complex deployments, even minor software updates or compliance adjustments introduce significant operational overhead.

Open source software allows operators to more easily swap underlying infrastructure blocks, as it provides modular blueprints which enable a composable platform architecture.  Likewise, through open source software, prototyping next-generation features is faster due to the global community of developers. Finally, open source software does not require specialized, expensive proprietary hardware and can be deployed directly onto general-purpose hardware which reduces total cost of ownership. These factors mean the open source model reduces time-to-market for new services, simplifies regulatory compliance across fragmented infrastructures, and shifts the industry's focus from navigating proprietary vendor restrictions to innovating with over-the-top value-added services.

The benefits of using Canonical Kubernetes in Sylva

By using Canonical Kubernetes within Sylva, enterprises benefit from Canonical's focus on upstream consistency, long lifecycle maintenance, and decoupled architecture. Canonical Kubernetes provides a trusted out of the box approach, while avoiding locking users into a restrictive stack. Instead, the platform remains completely open for downstream customization and architectural extension. This transparency ensures that the underlying infrastructure conforms cleanly to the base Ubuntu Linux layers without hiding behind custom forks or proprietary management wrappers.

The modular architecture of Canonical Kubernetes  allows systems to seamlessly align with Sylva's default cloud-native units. Standard Sylva software units  deploy onto Canonical Kubernetes out of the box, without requiring custom application wrappers, keeping the GitOps pipeline clean and predictable. In addition, Canonical Kubernetes natively supports enhanced platform awareness (EPA) features like SR-IOV, DPDK, and PTP synchronization required for 5G without needing proprietary operators. This decoupled, modular architecture allows operators to scale efficiently from raw hardware to complex 5G application workflows. 

Because telco environments often demand unique customizations, Canonical directly supports customers through this integration process, as demonstrated by its contributions within Sylva. For telcos requiring custom component tailoring or specific upstream modifications, Canonical can extend this support through its large open source software catalog of containers. This ensures that customized telco containers are built, validated, and maintained with the same strict trusted, regulatory and operational principles as the core distribution itself.

The principles of improved operational predictability and reduced risk also apply beyond initial integration. Telcos need platforms that can be adapted to their network requirements, then operated safely for many years. Their clouds are built to match long physical infrastructure lifespans, not rapid upstream software deprecation cycles. Canonical offers up to 15 years of Long Term Support (LTS) for its Kubernetes distributions via Ubuntu Pro . This long-term stability is a particular benefit to telcos, where upgrading core networks (like 5G Core or O-RAN) carries massive operational risk. LTS Kubernetes enables operators to build once and receive maintenance for a longer operational window, without undergoing forced, disruptive platform migrations. This offers telcos a stable platform foundation that frees engineering teams from recurring upgrade cycles, allowing them to focus on upper-layer network application performance.

Declarative cluster lifecycle management with Canonical Kubernetes

While the telco ecosystem agrees on the necessity of cloud-native standardization, the way Kubernetes platforms are packaged and operated can either reinforce or weaken Sylva's open model. Approaches that rely on highly integrated, specialized platform stacks or heavily modified Kubernetes distributions may end up tying cluster functionality to proprietary management utilities and tightly coupled operating system dependencies. While this may offer a high degree of curation out of the box, the underlying infrastructure becomes highly opinionated, introducing an architectural paradox for telcos seeking greater vendor neutrality. Over time, this subtly introduces a new form of platform-specific lock-in, restricting an operator's ability to swap out software components or straightforwardly migrate workloads to alternate infrastructures. 

Canonical offers a different approach.  By aligning with Sylva's open infrastructure standards, Canonical Kubernetes allows Sylva's declarative model to operate without an additional proprietary control layer. 

Within a Sylva-managed telco cloud, Cluster API (CAPI) and FluxCD provide the declarative lifecycle and GitOps control framework used to orchestrate management and workload clusters. Cluster definitions, infrastructure provider selections, and platform configuration are maintained declaratively in Git through the sylva-units deployment model, which generates FluxCD Kustomizations and HelmReleases to orchestrate platform components and dependencies. FluxCD continuously reconciles the desired state from Git into the management cluster, where Cluster API controllers interpret the resulting custom resources and coordinate cluster provisioning, scaling, upgrades, and remediation workflows.

To execute these declarative specifications natively without the abstraction layers that typically drive vendor lock-in, CAPI coordinates the deployment across multiple provider layers. Sylva integrates CAPI providers (such as the CAPI bootstrap provider for Canonical Kubernetes and the Canonical Kubernetes control plane provider) to translate high-level CAPI specifications into Canonical Kubernetes node and control-plane configurations. These providers automate node bootstrap, control-plane initialization, and cluster joining using Canonical Kubernetes installation and configuration mechanisms, including snap-based package delivery where applicable. Once operational, Canonical Kubernetes clusters remain under continuous reconciliation through FluxCD and Cluster API control loops, enabling declarative upgrades, configuration drift correction, and infrastructure remediation workflows.

Conclusion

Project Sylva standardizes how telco clouds are built using open, non-fragmented declarative blueprints. The integration of Canonical Kubernetes demonstrates that open standards can be maintained without adding heavy, opinionated software bundles. 

However, in an industry where upgrading a core network runtime carries significant operational and compliance risks, frequent forced updates present a major vulnerability. Canonical delivers a clean separation of concerns, while supporting the footprint with long-term maintenance through Ubuntu Pro. Further, through custom integration support and thanks to our extensive LTS open source software catalog, Canonical ensures that telcos can customize, validate, and maintain their specific runtime components within a trusted framework over these extended lifecycles. With Canonical, telcos can deploy for Day 1, operate for the long run, and keep their network future open.

Next steps

Learn how Canonical solutions provide a stable, validated, and open foundation for telco workloads.

• Learn about Canonical's solutions for telco
• Unlock the full potential of Kubernetes for telco performance
• Transform your 5G infrastructure with Canonical

Get in touch with Canonical's telco team

Achieving vendor neutrality in telco clouds requires an infrastructure layer that respects open standards, without wrapping them in rigid platform layers. By combining upstream alignment with up to 15 years of support longevity, Canonical's approach to Sylva is built around a requirement that matters deeply to telcos: follow upstream cloud-native innovation when developing and evolving platforms, then rely on long-term support to keep production environments stable, trusted, and operationally predictable.


Categories: canonical kubernetes, Sylva, Telco, Telco 5G, telco edge cloud
Source: https://ubuntu.com//blog/the-next-era-of-telco-clouds-get-open-infrastructure-choice-with-sylva-and-canonical-kubernetes Jun 11, 2026, 01:34 PM

What is RDMA over Converged Ethernet (RoCE)?

Previous articles walked through RDMA (Remote Direct Memory Access)  as a programming model and InfiniBand as the fabric that was built around it. Both led to the same conclusion, even if it was never stated outright: moving data, not compute, becomes the bottleneck once systems scale.

So what happens when you want RDMA, but you're already running an Ethernet network you're not keen to replace? That's usually where RDMA over Converged Ethernet (RoCE) enters the conversation.

At first, it sounds straightforward. Keep the RDMA semantics, keep the verbs model (the low-level RDMA API used to post send/receive and memory operations), just run it over Ethernet. In reality, it works a bit like fitting a racing engine into a standard road car. You can do it, but the rest of the system has to be able to keep up. In this article, we'll explore what RoCE is, how it works, and when to use it.

What is RoCE?

RDMA over Converged Ethernet (RoCE) runs the RDMA programming model over standard Ethernet networks. Applications use the same verbs interface to read and write directly to remote memory, bypassing the kernel and minimizing CPU involvement. The change is in the transport: instead of a purpose-built InfiniBand fabric, RDMA operations are carried over Ethernet.

RoCE exists in two variants. RoCEv1 operates within a single Layer 2 broadcast domain. RoCEv2 encapsulates RDMA traffic in UDP/IP, which makes it routable across Layer 3 networks. In practice, deployments standardize on RoCEv2 because it fits leaf–spine designs, network segmentation, and multi-rack scale.

While the programming model does not change, the network behavior does. Ethernet does not guarantee lossless delivery by default, so RoCE relies on additional mechanisms to control congestion and avoid drops. That design choice shifts responsibility from the application to the network. Performance and predictability now depend on how the Ethernet fabric is designed, configured, and operated.

This is the key idea to keep in mind. RDMA is the model. RoCE is one way to implement it on top of Ethernet.

Where RoCE fits

RoCE is most relevant in environments where Ethernet is already the dominant networking model and introducing a separate fabric would increase operational complexity, not only because it introduces additional infrastructure, but also because it brings a different networking model, tooling, and operational expertise that teams may not already have in place. It allows RDMA to be introduced incrementally, without changing how the network is provisioned or managed at a high level.

In practice, this shows up in distributed storage systems, database clusters, and accelerator-driven workloads that are deployed on top of standard Ethernet infrastructure. In these environments, the ability to reuse the existing network is often as important as the performance characteristics themselves. In many cases, this direction reflects a practical compromise: pushing beyond application performance limits while avoiding a full redesign of the network stack from scratch.

Ethernet versus InfiniBand behavior

To understand why RoCE behaves differently in practice, it helps to compare the two worlds it bridges: InfiniBand, where RDMA was designed to run, and Ethernet, where it is being adapted.

InfiniBand enforces lossless communication as part of the fabric. Flow control and congestion management are integrated into the transport, which keeps latency stable under load.

Ethernet follows a different model, where packet loss is expected and recovery is handled by higher layers. That choice is not accidental; it comes from how Ethernet evolved. Early Ethernet was designed as a shared medium, with many hosts contending for the same wire. Simplicity and cost mattered more than strict delivery guarantees, so the network pushed complexity up the stack. If a frame collided or a buffer overflowed, it was cheaper to drop it and let higher layers retry than to coordinate every sender and receiver in real time.

That design scaled well as speeds increased and switching replaced hubs. The network stayed simple and fast, while protocols like TCP took on responsibility for reliability, ordering, and congestion control. It works well for web traffic, storage over IP, and most enterprise workloads, where a lost packet can be retransmitted without much consequence.

RDMA changes that assumption. It expects the network to behave predictably and avoid drops altogether, because retransmissions break latency guarantees and disrupt fine-grained communication patterns. RoCE therefore has to retrofit loss-avoidance mechanisms onto a transport that was never designed to be strictly lossless in the first place. RoCE bridges that gap by introducing a set of mechanisms that approximate lossless behavior for RDMA traffic.

At this point, it helps to step back and ask why these additional mechanisms are needed in the first place. Ethernet did not suddenly become problematic; the workload changed.

Why RDMA stresses Ethernet

The key challenge with RoCE is that RDMA expects a predictable, near-lossless transport, while Ethernet was originally designed around best-effort delivery. Most of the additional mechanisms around RoCE exist to bridge that gap.

RDMA traffic patterns tend to be highly synchronized and bursty. Distributed training jobs and tightly coupled HPC workloads often trigger collective operations where many nodes exchange data simultaneously. This creates what operators call "incast": multiple senders targeting the same receiver or the same set of links at once. Switch buffers fill rapidly, and in a traditional Ethernet network that would simply lead to packet drops.

TCP tolerates that behavior because retransmission is built into the transport. RDMA does not. A single dropped packet can stall a queue pair and introduce latency spikes that ripple through the entire workload.

Priority flow control (PFC) was introduced to avoid drops by pausing traffic before queues overflow. The problem is that the pause applies to the ingress port and priority class, not only to the congested flow itself. Unrelated traffic can therefore be blocked as well. This phenomenon, known as head-of-line blocking, is one of the reasons RoCE fabrics can become unstable under congestion.

Load balancing creates additional pressure. Ethernet fabrics typically rely on equal-cost multipath (ECMP) hashing to spread flows across multiple paths, but synchronized AI and HPC traffic patterns do not distribute evenly. Large flows can land on the same links while other paths remain underutilized, concentrating congestion inside a subset of the fabric.

Mechanisms such as explicit congestion notification (ECN), data center bridging (DCB), and later data center quantized congestion notification (DCQCN) were introduced to make this behavior manageable. ECN marks packets before queues overflow so endpoints can slow down gradually. DCB defines how traffic classes are isolated and prioritized across the fabric. DCQCN builds on those signals to regulate sender rates dynamically.

RoCE performance thus depends heavily on how the Ethernet network is engineered. A well-tuned fabric can achieve latency and throughput close to InfiniBand. A poorly tuned one can become unpredictable under load. Queue thresholds, ECN marking points, PFC priorities, maximum transmission unit (MTU) values, and network interface card (NIC) parameters all interact, which is why production RoCE deployments often require careful validation and iterative tuning under realistic traffic conditions.

Can RoCE share the same fabric as IP traffic?

The mechanisms described above already push Ethernet close to its limits under synchronized RDMA workloads. When the same fabric also carries general IP traffic, those effects can become harder to control and easier to trigger.

Can RoCEv2 coexistence with standard Ethernet and IP traffic be maintained without affecting performance? RDMA traffic assumes a controlled, near-lossless environment. IP traffic assumes packet loss and recovery. Bringing both together requires explicit separation within the same network, typically through traffic classes, buffer allocation, and scheduling policy.

Some environments operate a fully converged fabric, where all traffic shares the same infrastructure. This approach reduces hardware footprint but increases sensitivity to configuration errors, as congestion in one class can affect others. Other environments introduce logical separation, using VLANs or QoS classes to isolate RDMA traffic while keeping a shared physical network. The most conservative approach is a dedicated fabric, where RDMA traffic is completely isolated from other workloads.

Operational experience tends to favor some form of isolation. It reduces the number of variables involved when diagnosing performance issues and makes behavior easier to reason about under load.

Evolving congestion control

While RoCE can deliver excellent performance, large deployments also expose some of the weaker aspects of Ethernet under sustained congestion and synchronized traffic. Congestion spreads more easily, synchronized traffic patterns create hotspots, and mechanisms such as PFC can stabilize the fabric in one situation while amplifying instability in another.

Large AI training clusters pushed these issues into the spotlight once deployments started scaling into thousands of GPUs. In her OCP Global Summit 2022 keynote, Alexis Bjorlin, then VP of Infrastructure at Meta, explained that communication overhead and tail latency were directly affecting training efficiency: around 30% of AI training time was spent in networking and, for some benchmark models, more than 50%. That drove investment into topology-aware collectives, routing, and congestion management. At that scale, the network becomes part of the distributed compute system rather than simple transport infrastructure.

The industry response has focused on making Ethernet behave more predictably under large-scale RDMA traffic, while reducing dependence on mechanisms such as PFC.

A few notable examples illustrate where things are heading:

• NVIDIA Spectrum-X keeps the RoCE model, but tightly integrates Spectrum switches, BlueField DPUs, adaptive routing, telemetry, and congestion control into a single Ethernet platform optimized for AI clusters.
• The Ultra Ethernet Consortium (UEC), formed in 2023 under the Linux Foundation, takes a more open approach. Its specifications focus on stronger congestion signaling, multipathing, packet spraying, and transports that tolerate out-of-order delivery.
• Google's Falcon transport, opened through OCP in 2023, moves even further away from traditional RoCE designs. It introduces hardware-assisted retransmission, programmable congestion control, and multipath transport semantics intended to work efficiently on lossy Ethernet fabrics.
• Broadcom's Scale-Up Ethernet (SUE) framework focuses on tightly coupled accelerator domains using mechanisms such as credit-based flow control, topology-aware routing, and in-network collectives. Recent products such as Tomahawk Ultra and Thor Ultra align closely with the broader UEC direction.

RoCE exposed how difficult it is to make traditional Ethernet behave predictably under synchronized RDMA traffic at large scale. These newer approaches are all attempts to reduce that sensitivity, either by tightening integration around RoCE itself or by moving toward new Ethernet transport models designed specifically for AI and HPC communication patterns.

The Canonical perspective

RoCE depends on alignment across the entire software and hardware stack. Kernel drivers, user space libraries, NIC firmware, and the way workloads are attached to the network all contribute to the final behavior.

On Ubuntu, that alignment starts with upstream RDMA plumbing that operators already recognize. The rdma-core  stack provides libibverbs and its providers, which expose a consistent RDMA programming interface regardless of whether the underlying transport is InfiniBand or RoCE. It also includes connection management and tooling such as ibv_devinfo  and rping . In the kernel, the mlx5 driver family (for NVIDIA/Mellanox ConnectX), irdma (Intel E810/Columbiaville), bnxt_re (Broadcom NetXtreme-E), and ice/ixgbe (Intel NICs) backends expose RoCEv2 capabilities consistently. Features such as SR-IOV, VF representors, and devlink are available out of the box, which matters when you need to reason about queues, rate limiting, or firmware settings without stepping outside the distribution.

Day‑to‑day operations tend to rely on a small set of Linux primitives that are easy to overlook but critical for RoCE. ethtool  and devlink-health  expose NIC capabilities and health. tc  with mqprio  shape traffic classes. They are used to map RoCE traffic to a dedicated priority, enable PFC on that class, and tune queue bandwidth. cgroups  and CPU pinning keep data paths predictable to isolate RDMA poller threads or user-space data plane processes on specific cores and reduce scheduler jitter. All of this while standard Linux networking tools remain part of the workflow for inspecting and configuring the underlying Ethernet interfaces that carry RoCE traffic. When things misbehave, counters exposed through /sys/class/infiniband (used for both InfiniBand and RoCE devices), ethtool -S, and switch telemetry are what let you correlate queue pressure with application latency.

Driver and firmware cohesion is where many deployments struggle. Ubuntu tracks rdma-core and kernel changes together, which reduces surprises when kernels move. Where vendor features matter, NVIDIA DOCA-OFED is available through Ubuntu packaging so platform teams can use advanced capabilities on BlueField or ConnectX without forking the base system. The same applies to Intel and Broadcom stacks, which are validated against LTS kernels rather than treated as one-off add-ons.

This matters even more as Ethernet fabrics continue to evolve for AI and HPC workloads. Canonical works closely with silicon vendors, switch manufacturers, and ecosystem partners to follow developments around technologies such as Spectrum-X, Ultra Ethernet, Falcon, and next-generation RoCE congestion control. The goal is not simply hardware enablement. It is making sure Ubuntu and the surrounding cloud-native stack can expose those capabilities consistently through upstream kernels, drivers, orchestration tooling, and CNCF integrations as the ecosystem evolves.

On the orchestration side, RDMA is rarely something a single process "just uses." It has to be surfaced cleanly to containers and VMs, which is where SR-IOV VFs, device plugins, and CNI integrations come into play. Canonical keeps close to CNCF projects here, so the platform can consume what vendors and the community already provide rather than inventing a parallel stack. In practice, that means platform teams can bring in components such as NVIDIA's Network Operator, SR-IOV-focused operators, RDMA device plugins, and Multus-based secondary networking. Ubuntu provides the predictable host layer that allows those components to work together consistently. These pieces take care of discovering devices, carving out VFs, and attaching them to workloads, while Ubuntu underneath keeps the drivers, kernel interfaces, and networking behavior consistent enough that those higher layers behave as expected.

Bare-metal provisioning with MAAS and lifecycle management with Juju fit into the same picture. They let platform teams model NIC firmware, kernel parameters, and network configuration alongside the workload, rather than treating RDMA as a special case configured by hand. In practice, this reduces drift. And with RoCE, drift is often what turns a stable cluster into one with unpredictable tail latency.

Observability ties it all together. RDMA issues rarely show up as hard failures; they surface as latency spread, queue buildup, or uneven throughput. Having a consistent set of kernel drivers, user-space tools, and metrics on Ubuntu makes it possible to trace those symptoms back to specific queues, links, or policies, which is what ultimately keeps a RoCE deployment usable under load.

Designing and operating RoCE in practice

RoCE aligns with Ethernet and integrates naturally into existing environments, which is precisely why it keeps coming up in design discussions. It allows teams to push performance further without introducing a parallel networking stack. At the same time, that flexibility comes with a shift in responsibility. The network no longer guarantees behavior by construction. It has to be engineered, observed, and continuously validated.

Most teams follow a similar path, even if they describe it differently. They start by validating whether RDMA is actually the right tool for their workload. Not every distributed system benefits from it, and some behave better with simpler transport models. From there, the focus moves quickly to the network: topology consistency, traffic isolation, buffer tuning, and congestion control are not optional details. They are part of the application design.

This is also where many projects stall. RoCE works well in controlled environments, then becomes unpredictable when scaled or mixed with other traffic. That gap is rarely about hardware capability. It is about how the system is put together and how much visibility teams have into its behavior.

This is the point where it usually makes sense to step back and look at the full stack rather than individual components. The NIC, the kernel, the switch configuration, and the orchestration layer all interact. Treating them separately often leads to local optimizations and global instability. Treating them as a system tends to produce more consistent results.

From a practical standpoint, the next step is not to choose between RoCE and something else in isolation. It is to validate the workload, test the network behavior under realistic conditions, and understand where variability comes from. That work tends to surface quickly whether the existing Ethernet fabric can support the requirements or whether a more controlled approach is needed.

The right approach depends on context. Some deployments converge successfully on RoCE with careful design. Others decide that a more tightly controlled fabric is the better option. What matters is having the data and the operational understanding to make that decision with confidence.

If you are exploring RDMA over Ethernet today, this is exactly the kind of problem Canonical works on with customers and partners. From enabling RDMA stacks on Ubuntu, to validating performance across different NICs and switches, to integrating those capabilities into production platforms, the focus is on making these systems behave predictably under real workloads rather than synthetic benchmarks.

If you are evaluating RoCE, next-generation Ethernet fabrics, or AI/HPC networking architectures on Ubuntu, get in touch with Canonical to discuss your requirements and deployment goals.

Previous articles walked through RDMA (Remote Direct Memory Access) as a programming model and InfiniBand as the fabric that was built around it. Both led to the same conclusion, even if it was never stated outright: moving data, not compute, becomes the bottleneck once systems scale. So what happens when you want RDMA, but you're [...]


Categories: AI, AI Factory, Data center networking, HPC, inference, network
Source: https://ubuntu.com//blog/what-is-rdma-over-converged-ethernet-roce Jun 09, 2026, 06:05 PM

LibreOffice gives its Ribbon-style UI a pop of colour

You'll be able to customise the look of LibreOffice's Tabbed UI in the free office suite's next major release, which his due out in August 2026. LibreOffice 26.8's Tabbed UI (also known as the Notebookbar and modelled after the Ribbon in Microsoft Office) can show a colourful background when application theming is enabled under Tools > Options > Appearance. A blue shade is used by default but you can pick or set any colour you like. In the 'Customisations' section, first selected the Writer, Calc, Impress or Data Notebookbar value, then use the dropdown to chance the colour. Click apply [...]

You're reading LibreOffice gives its Ribbon-style UI a pop of colour , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, LibreOffice
Source: https://www.omgubuntu.co.uk/2026/06/libreoffice-tabbed-ui-backgrounds Jun 11, 2026, 09:48 PM