AHXproject

LibreOffice 26.8 set a new first-week download record

LibreOffice 26.8 was download more than 1 million times in its first week of release, which The Document Foundation say is the highest first-week figure of any release of the free office suite. Released on 26 August, LibreOffice 26.8 saw 1,031,162 downloads from the official website, which provides installers for Windows, macOS and Linux, during the first seven days. As many Linux users update via other sources, like the Snap Store, Flathub and PPAs, the real figure will be even higher than that. "This is the highest number of downloads in the first week of any LibreOffice release", The Document [...]

You're reading LibreOffice 26.8 set a new first-week download record , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, LibreOffice
Source: https://www.omgubuntu.co.uk/2026/09/libreoffice-download-record Sep 02, 2026, 06:15 PM

Linux App Release Roundup (August 2026)

August saw a number of slew of notable Linux app updates, and in this post I roundup a few that might have passed you by. But unless you've been sleeping under a rock you'll have already heard about Firefox 153, the big OpenShot 4.0 release with colour grading and the latest update to the ebook manager Calibre letting you generate new book covers using online generative AI. August also saw open-source Mastodon client Tuba pick up a stack of new features, LibreOffice 26.8 debuted a new paragraph composer engine (makes sense, promise). We also saw NVIDIA GeForce NOW app leave [...]

You're reading Linux App Release Roundup (August 2026) , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, App Updates, Cine, kdenlive, LRR, Newelle, VirtualBox
Source: https://www.omgubuntu.co.uk/2026/09/linux-app-release-roundup-august-2026 Sep 02, 2026, 01:18 AM

Surviving the uncharted: when dedicated OpenStack expertise is your best ally in disaster recovery 

Some support cases are routine. Others take you off the documented path entirely, into territory where the only way forward is deep, hands on open source expertise. This series looks at how Canonical Support navigates the unexpected: cases where standard playbooks aren't enough, and a support engineer helps a customer find a solution in real time.

This is one of those cases. A customer's production OpenStack environment went, overnight, from fully operational to unable to provision, scale, or manage a single resource.

What happened

OpenStack is not a single piece of software. It is a coordinated architecture of services that manage core infrastructure components like compute, networking, identity, storage, all of which depend on a shared database that keeps a record of the current state of the cloud: what is running, where, and how it is configured.

During routine operations, an action targeted the database cluster underpinning that control plane. Within seconds, the layer that lets operators manage the cloud, provision, migrate, scale, was gone.

The support case opened the same day.

The first problem: the backup

The team's first question was straightforward: when was the last backup taken, and had it ever been tested as a restore? The available backup was old enough that it no longer reflected the cloud's current state. Virtual machines had moved, resources had been reallocated, credentials had rotated since it was captured.

Restoring it directly risked producing a control plane that described a cloud that no longer existed. That ruled out the simplest path, and left something harder: rebuild the control plane around live, running workloads, without breaking them.

This is worth pausing on, because it is a common gap even in mature operations. A backup schedule tells you data is being captured. It does not tell you the restore will work, or that the restored state will still match reality by the time you need it. The two need to be validated together, on a cadence tied to how quickly the environment actually changes.

The thing that didn't break

Before touching anything, the assigned support engineer checked what was still running, and found that nothing had actually gone down. No workloads were lost. The business kept running. What had been lost was the ability to manage the cloud: no new provisioning, no migration, no scaling.

This is a property of OpenStack's architecture worth understanding on its own terms. The control plane manages the state of the cloud; the data plane does the actual work, compute, networking, storage. These layers are decoupled by design, specifically so that a failure in management infrastructure does not take down the workloads depending on it. It is one of the architectural advantages that makes OpenStack viable for large scale production environments in the first place, and it is exactly what held up here.

That guarantee only helps you if you know it exists and know how to use it to shape a recovery strategy. Recognizing it early is what turned this from an open ended crisis into a scoped, solvable engineering problem within the first hour.

The recovery

With existing workloads confirmed safe, the team turned to rebuilding the control plane. Because the need to rebuild a database from scratch is such a rare edge case, standard recovery documentation covers only damaged or degraded states. So the engineer developed and validated a new procedure for that specific scenario: reconstructing the database cluster, restoring available data in a controlled sequence, then reconnecting every OpenStack service to the new database, one dependency at a time.

That last part was the bulk of the work. The relationships linking each service to the database had to be reestablished individually, and gaps between the backup's state and the cloud's actual state had to be reconciled by hand, including cases where a VM was running perfectly well but the database, working from stale information, reported it as stopped or in error.

It took several days of close, sustained collaboration between the Canonical engineer and the customer's team. By the end, the cloud was fully operational, with zero workloads lost.

What this case actually shows

Two things are worth taking from this.

Backup validation deserves the same rigor as backup scheduling. This is not a hypothetical gap. Cockroach Labs' State of Resilience 2025 survey  found that 62% of organizations do not perform regular backup restoration exercises, and 71% do no failover testing at all, despite nearly all of them running some form of resiliency testing on paper. Separately, Acronis' Q1 2026 telemetry  across its disaster recovery platform found that 85% of recovery servers had RPO monitoring turned off entirely, meaning no automatic check on whether backups are even recent enough to be useful, and only 18% of backup rules were configured for monthly testing.

The pattern is consistent: having a backup policy is common, but proving that policy actually works under real conditions is not. That gap tends to stay invisible until the day it matters, which is exactly why a tested, timed, end to end restore process belongs on a resilience checklist next to RTO and RPO targets, not treated as a given once the backup job shows green.

In a system this interconnected, architectural knowledge is what makes recovery possible at all. Knowing that OpenStack's control and data planes are decoupled was not trivial here. It was the fact that determined the entire recovery strategy, because it told the engineer, within the first hour, that the business had not already lost. That is the kind of knowledge that matters exactly once, at the highest stakes moment, and it is precisely what deep, specialized support exists to provide on demand.

Large, distributed infrastructure accumulates operational complexity and interdependency by nature, at every vendor and every layer of the stack. What determines the outcome when something goes wrong is not whether an environment is complex. It is whether the team responding has the depth to move fast, diagnose correctly, and build a solution under pressure when the documented path runs out.

The procedure developed during this incident has since been documented for future cases. But the case itself is a useful reminder of what a support subscription is actually buying: not just answers to known problems, but access to the expertise to navigate the ones nobody has written down yet.

If your organization runs OpenStack in production, talk to us about Ubuntu Pro with Support .

A customer's OpenStack control plane went down overnight after their only backup proved stale. Canonical support rebuilt the database cluster live, service by service, without losing a single workload.


Categories: Database, OpenStack, Support
Source: https://ubuntu.com//blog/support-restores-openstack Sep 01, 2026, 02:10 PM

Firefox 155 brings AI-powered Smart Window to more countries

Mozilla Firefox 155 is released, making Smart Window available in USA, Canada & France. Plus, blocked tracker counts, container reordering and Linux fixes.

You're reading Firefox 155 brings AI-powered Smart Window to more countries , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, AI/ML, App Updates, Firefox
Source: https://www.omgubuntu.co.uk/2026/09/firefox-155-released Sep 01, 2026, 05:34 AM

Ubuntu's IRC support channels to be 'sunset', some aren't happy

Getting is planning to 'sunset' IRC as an official support method, and some long-time users aren't happy. The recently Ubuntu 26.04.1 LTS release announcement didn't include a link to the Ubuntu Support IRC channel under its "if you have a question" section – though, from looking, the last announcement to list IRC was the one for Ubuntu 24.10). That led to questions on if the Ubuntu support IRC channel is still an official community support option (the Help app in Ubuntu 26.04 still has links to pages which mention IRC). Aaron Rainbolt, an Ubuntu Community Council member, said the omission [...]

You're reading Ubuntu's IRC support channels to be 'sunset', some aren't happy , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, Canonical, IRC
Source: https://www.omgubuntu.co.uk/2026/08/ubuntu-irc-channels-official-sunset Sep 01, 2026, 01:25 AM

Why Ubuntu 26.04 upgrades from 24.04 are currently delayed

If you're wondering why you can't do a directly upgrade to Ubuntu 26.04 from 24.04 yet, despite the Resolute Raccoon's first point release being live, there is a reason. Canonical's Oliver Reiche said in the mailing list announcement for Ubuntu 26.04.1 LTS that upgrades will be delayed by a few weeks to allow couple of backports to land. These will "address regressions in a recent version of rust-coreutils". Users on Ubuntu 25.10 are not affected by this; upgrades from 25.10 went live in April. Unlike the ISOs, which target a fixed release date, upgrades don't. Enabling upgrades from one release to the [...]

You're reading Why Ubuntu 26.04 upgrades from 24.04 are currently delayed , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News
Source: https://www.omgubuntu.co.uk/2026/08/ubuntu-2404-to-2604-upgrade-delay Aug 31, 2026, 05:33 PM

OpenShot 4.0 adds colour grading, recording dock and Qt 6 support

OpenShot 4.0 sees the open-source video editor add colour grading tools, a recording dock for audio and screen capture and new AI effects.

You're reading OpenShot 4.0 adds colour grading, recording dock and Qt 6 support , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, AI/ML, App Updates, openshot, Video Editors
Source: https://www.omgubuntu.co.uk/2026/08/openshot-4-0-release Aug 31, 2026, 01:39 AM

AI harnesses for telco autonomous networks

Across the global landscape, telecommunications operators have already deployed machine learning for predictive maintenance, customer care chatbots, and anomaly detection. However, as the industry transitions toward Autonomous Networks Level 4 (AN L4), where networks can make intent-driven, predictive decisions and perform closed-loop management with minimal human intervention, a fundamental architectural challenge has emerged:

How do you build a secure, reliable, and interoperable AI harness that bridges probabilistic AI reasoning with deterministic, carrier-grade network execution?

Connecting large language models (LLMs) or autonomous agents directly to critical network functions poses severe operational risks. An AI-generated decision may be incorrect, out of policy, based on a stale state, or unsafe under unobserved conditions. An erroneous or poorly scoped change in a production core or radio access network (RAN) could violate service-level objectives, destabilize a control loop, or propagate across dependent network functions if existing protection and isolation mechanisms fail.

To move AI from isolated proofs-of-concept into resilient production, telcos will likely require an end-to-end operational AI harness: a platform architecture that combines open cloud substrates, interoperable agent protocols, trusted operational context, declarative GitOps workflows, confidential inference, intent-driven orchestration, policy enforcement, and closed-loop assurance.

A key architectural principle is to separate the agentic read path (for observation and cognition) from the network's write path (for governance and execution). AI can interpret context, diagnose problems, and propose actions, while deterministic policy, validation, orchestration, and assurance mechanisms govern what changes are actually allowed to reach the network. This principle is increasingly reflected in the industry's work on L4 autonomy.

Why autonomous networks need an AI harness

Modern AI production environments demand dense accelerator nodes, high-throughput east-west fabrics, low tail-latency networking, and specialized memory management for key-value (KV) caching. Dropping these memory-dense, probabilistic workloads onto legacy telco architectures engineered for rigid change windows creates friction across different levels:

• Fragmented execution & data islands: Telemetry, alarm streams, and topology maps often live in vendor-siloed systems with different schemas and levels of data quality.
• Missing operational fabric for agents: Autonomous AI agents require unified identity management, fine-grained role-based access control (RBAC) audited tool access, and policy enforcement to prevent unauthorized or conflicting network changes.
• Infrastructure bottlenecks: AI inference introduces very different resource and scheduling characteristics from conventional containerized network functions (CNFs). High-throughput accelerator access, NUMA placement, PCIe topology, SR-IOV/RDMA networking, CPU/GPU scheduling, memory bandwidth and KV-cache management need to coexist with the deterministic latency, isolation, and availability requirements of telco workloads.

To resolve these bottlenecks, standards bodies and open-source initiatives, including ETSI, TM Forum, O-RAN Alliance, and the Linux Foundation, are developing complementary pieces of the architecture required for autonomous networks. Translating these evolving, domain-specific frameworks into an operational reality requires an open, end-to-end platform harness that bridges low-level cloud substrates with high-level agentic reasoning. Such architecture is better understood as four interacting planes:

• Context plane: telemetry, topology, inventory, alarms, service state, knowledge graphs, and other operational data.
• Reasoning plane: AI/ML models and agents that diagnose, predict, plan, and interpret intent.
• Control plane: identity, policy, validation, arbitration, orchestration, and closed-loop decision mechanisms.
• Execution plane: the CNFs, RAN, core, transport, cloud infrastructure, and other network resources that ultimately implement approved changes.

The AI harness sits across these planes, connecting the agentic read path to the network's write path. This links probabilistic reasoning to deterministic control without allowing the model itself to become the network's final authority. In other words, AI can interpret context and propose actions, while deterministic policy, validation, orchestration, and assurance mechanisms govern what changes are actually allowed to reach the network.

The cloud-native foundation layer

At the foundation of any AI-native network sits the cloud substrate. Telcos have strong incentives to avoid maintaining completely parallel, siloed infrastructure stacks (e.g., one for CNFs and another for AI inference pipelines). Some network and AI workloads may benefit from shared infrastructure, while others may require dedicated accelerators, separate security domains, or physically isolated resources. The cloud foundation should therefore provide a common operational model without imposing a single hardware topology.

Canonical delivers the open-source infrastructure portfolio needed to build a unified runtime environment where AI models and network functions can coexist on shared physical infrastructure, while still allowing operators to dedicate or isolate resources where required:

• Metal-as-a-Service (MAAS ): Automates bare-metal server discovery, firmware management, and provisioning for GPU-enabled servers and edge platforms.
• Ubuntu & real-time kernels : Deliver a secure operating system foundation with native kernel support for hardware acceleration, low-latency networking (SR-IOV, DPDK), and confidential computing trusted execution environments.
• Canonical Kubernetes  & MicroCloud : Provide low-touch Kubernetes orchestration and edge cloud infrastructure tailored for distributed edge deployments.
• Juju & charmed operators : Encapsulate complex day-2 operational logic, automated upgrades, and integration across infrastructure, data services, and AI/ML tooling.

The same foundation can host the inference layer, allowing operators to deploy and manage model-serving workloads alongside cloud-native network functions. Canonical's inference snaps  provide a way to package and deploy inference runtimes such as vLLM and llama.cpp as repeatable, versioned workloads for serving LLMs. Juju and charmed operators can then provide model-driven deployment, configuration, integration, scaling, and lifecycle management for the applications and infrastructure supporting those workloads.

Standardizing agentic AI with the model context protocol (MCP)

To advance from rule-based automation to agentic AI, reasoning models need a standardized way to discover and query network context and tools. Bespoke API integration isn't the answer, as it can recreate the vendor lock-in and fragmentation that cloud-native architectures were designed to avoid.

The industry is increasingly addressing this through the model context protocol (MCP), governed within the Linux Foundation's Agentic AI Foundation (AAIF). However, MCP is an interoperability layer, not a telco policy engine or network controller. The underlying network APIs and protocols remain responsible for actual network operations, while MCP can serve as an agent-facing protocol layer for the network context read path, providing:

• Interoperability and context retrieval: MCP standardizes how AI agents discover and invoke tools, allowing an agent to query telemetry, inspect cluster health, and gather topology or diagnostic information across heterogeneous systems while leaving the underlying data and observability systems in place. This can significantly reduce bespoke integration at the agent layer.
• Composability: Operators can expose new network capabilities, metrics, or diagnostic models through MCP server wrappers, enabling rapid, modular expansion of the operational toolkit available for the agentic layer
• Security integration and tool exposure: MCP standardizes tool invocation and provides an authorization framework for protected endpoints, including mechanisms that support human control over tool invocation. But, because MCP handles protocol-level interactions rather than enterprise policy, operators need to maintain control by pairing MCP servers with existing identity, RBAC, and audit workflows. This allows operators to expose narrowly scoped diagnostic tools rather than raw network APIs.

Exposing read-oriented cluster lifecycle observability tools enables AI agents to safely query cluster health, inspect deployment resource states, and evaluate workloads without risking unapproved configuration changes.

Safe execution: policy, orchestration, and declarative control as the guardrails

While MCP provides an agent-facing interface for context discovery and tool invocation, state-changing network operations should follow a separate, strictly controlled write path. In a carrier-grade network, an AI agent should not have unrestricted, direct, state-changing access to live network elements.

Instead, operators can establish operational guardrails by routing agent decisions through policy enforcement, validation, orchestration, and assurance mechanisms. Declarative GitOps workflows is one useful mechanism for selected classes of declarative infrastructure change. A representative workflow could include:

• Context & planning (read path): The AI agent gathers context through MCP, analyzes telemetry (e.g. via Prometheus/OpenTelemetry) and formulates a remediation plan (e.g. scaling a UPF instance or reallocating an O-RAN slice).
• Policy and risk evaluation: Before any state-changing action is accepted, a policy engine evaluates whether the proposed operation is permitted. Policies can consider agent identity, network domain, service criticality, time, maintenance state, data freshness, expected blast radius, concurrent changes, and service-level constraints.
• Declarative commit (write path): For changes suited to declarative infrastructure management, the agent can express its proposal as a configuration change committed to a version-controlled Git repository or, where appropriate, represented through a Juju model or bundle.
• Validation & digital twins: A CI/CD pipeline intercepts the commit and validates the proposed change against a network digital twin or pre-production test environment, where available, to simulate impact and identify violations of policy and service constraints..
• Human-in-the-loop oversight: If the action's blast radius exceeds pre-defined risk thresholds, the commit automatically triggers a review request for a human operator.
• Reconciliation & rollback: Once approved, declarative controllers (such as FluxCD or charmed operators) reconcile the desired state into the live network. Other network domains may instead use domain-specific orchestrators, controllers, RIC components, or existing network-management interfaces. 
• Closed-loop assurance: Post-deployment monitoring evaluates whether the resulting network state remains within the intended service and policy boundaries. Where safe reversal is supported, assurance mechanisms can trigger automated remediation or rollback.

Different control-loop timescales should also be accounted for. A large language model should not necessarily sit inside a millisecond-scale RAN control loop. Fast, deterministic control loops can remain within network-native controllers, with AI agents operating at slower timescales for diagnosis, prediction, planning, policy interpretation, and higher-level optimization.

This separation reflects an emerging pattern in Level 4 autonomous network architectures: agentic AI can interpret context and propose actions, while digital twins, intent-based controls, orchestration, and assurance mechanisms constrain and validate execution.

Security & confidential AI: protecting data, models, and prompts in use

As AI agents handle real-time subscriber traffic, service tickets, and proprietary network topologies, data privacy and supply-chain security become paramount. Traditional encryption at rest and in transit is insufficient when data must be decrypted in memory during model inference.

Confidential AI applies hardware-backed trusted execution environments (such as AMD SEV-SNP, Intel TDX, and NVIDIA Confidential GPUs) to protect data and, where supported, model weights while in use. A remote-attestation service can verify cryptographic measurements spanning the host firmware, guest OS, and inference runtime against an operator-defined trust policy before a key broker releases sensitive keys or model assets. Confidential computing therefore establishes a verifiable hardware-backed trust boundary around protected workloads.

Canonical supports confidential AI  across private and public cloud environments:

• Ubuntu 26.04 LTS: Provides integrated host and guest OS support for AMD SEV-SNP and Intel TDX, giving operators full control over confidential VM deployments on their bare-metal infrastructure.
• Ubuntu Core: Offers an immutable, transactional guest OS image packaged with snaps, which reduces configuration drift. Where confidential VMs are used, remote attestation provides an independent mechanism for verifying the measured boot and runtime environment, supporting appliance-like inference endpoints at the edge.

Accelerating developer workflows with Canonical Workshop

Building production-grade AI harnesses requires rapid developer iteration. Yet, granting experimental agentic tooling unconstrained access to host machines creates severe security risks. As telco teams build next-generation network intelligence like agentic troubleshooting assistants or local inference engines, they face an operational paradox: developers require fast access to modern AI runtimes (such as Ollama, OpenCode, vLLM, llama.cpp) and hardware SDKs (e.g., NVIDIA CUDA, AMD ROCm), while platform and security teams must enforce strict isolation to prevent driver conflicts or unvetted, destructive agent commands.

Canonical's Workshop  addresses this friction by enabling engineers to launch composable, sandboxed development environments on Ubuntu via a single command (snap install workshop –classic).

Defined through simple, version-controlled YAML specification files, Workshops run inside unprivileged system containers powered by LXD. This creates an additional isolation boundary around experimental or hallucination-prone tools or AI agents, reducing their access to the host by default without sacrificing developer speed.

To solve the brittleness of bespoke container mappings, Workshop uses a uniform resource interface inspired by snapd. Modular SDKs request controlled access to host capabilities, such as discrete GPUs, host mounts, or SSH agents, providing controlled access to host resources while keeping resource access explicit, version-controlled, and administratively controlled. Because the environment is defined declaratively, the same Workshop specification can be reused across developer machines, CI/CD pipelines, and digital twin testbeds, improving reproducibility, reducing configuration drift, and accelerating the path from lab prototype to production harness.

Conclusion

Achieving Autonomous Networks Level 4 is not a matter of dropping a large language model onto an existing network stack. It requires a coordinated, open-source platform architecture that aligns silicon capabilities, cloud-native orchestration, confidential execution, standardized agent interfaces, operational knowledge, intent-driven control, and deterministic network safeguards.

By combining Canonical's end-to-end software stack, from bare-metal MAAS provisioning and Ubuntu Confidential VMs to Charmed MLOps, Workshop developer sandboxes, and inference snaps, operators can build a trusted, repeatable AI harness.

This open foundation gives telcos greater control over their data, infrastructure choices, and deployment architecture, while providing a more repeatable path to operationalizing AI and, ultimately, toward the requirements of the 6G era.

Next steps

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

• Learn about Canonical's solutions for telco
• Discover Canonical's guide to open source AI infrastructure
• Try Canonical Workshop
• Get in touch with Canonical's telco team

As the telco industry transitions toward Autonomous Networks Level 4, a fundamental architectural challenge has emerged: how do you build a secure, reliable and interoperable AI harness that bridges probabilistic AI reasoning with deterministic, carrier-grade network execution?


Categories: AI/ML, AI/ML Infrastructure, Telco
Source: https://ubuntu.com//blog/ai-harnesses-for-telco-autonomous-networks Aug 28, 2026, 11:11 AM

Arduino® VENTUNO™ Q is available for pre-order with Ubuntu pre-installed

London, UK – August 25, 2026 – Following our initial collaboration announcement in March 2026 , Canonical and Arduino (a subsidiary of Qualcomm Technologies, Inc.) are excited to announce that VENTUNO Q is now generally available for pre-order , pre-loaded with Ubuntu.

VENTUNO Q is a dual-brain developer board designed for edge AI and robotics applications. With pre-orders opening today, developers, researchers, and industrial innovators can go straight from unboxing to executing AI inference and real-time physical actuation on a production-ready Linux environment.

With Ubuntu pre-loaded, users don't need to worry about manual board support package (BSP) flashing, complex kernel configuration, or driver downloads. VENTUNO Q comes pre-installed with Ubuntu natively running on its primary Qualcomm Dragonwing™ processor.

How VENTUNO Q accelerates edge AI performance

At the core of VENTUNO Q is its dual-brain system architecture designed for physical AI applications where perception must trigger instant action:

• Primary AI processor: Powered by the Qualcomm Dragonwing™ IQ-8275 processor, delivering up to 40 dense TOPS of NPU AI compute alongside integrated CPU and GPU capabilities. It handles heavy AI workloads offline, including Large Language Models (LLMs), Visual Language Models (VLMs), multi-camera computer vision, and speech processing.
• Real-time microcontroller: An integrated STMicroelectronics STM32H5 MCU (STM32H5F5) running Zephyr RTOS. Linked to the main processor via RPC, it provides sub-millisecond, deterministic control for motors, actuators, and sensors without jitter.

The board comes equipped with 16 GB RAM and 64 GB expandable eMMC storage, providing ample memory to run concurrent multi-model inference pipelines locally at the edge.

Unified development tools

Running on top of pre-loaded Ubuntu, the Arduino® App Lab is designed to deliver a  seamless development experience. Developers can execute private, local AI models out of the box without requiring a cloud connection:

• Pre-integrated AI models: Run local LLMs (e.g., Qwen 3, Gemma 4), VLMs, Whisper ASR, MeloTTS, MediaPipe gesture recognition, YoloX object tracking, and FOMO-AD visual anomaly detection directly on the device.
• Flexible toolchain (BYOM / TYOM): Bring Your Own Model (BYOM) from Hugging Face or Qualcomm AI Hub, or train custom models via Edge Impulse. Developers can write code in VS Code, Python IDEs, Docker, or traditional Arduino sketches.
• ROS 2 ready: Ubuntu on VENTUNO Q natively supports ROS 2, enabling NPU-accelerated perception, SLAM, and Nav2 navigation algorithms out of the box.

"VENTUNO Q redefines what's possible at the edge by combining high-performance AI with deterministic, real-time control. We're moving beyond just 'smart' devices to true physical intelligence. With Ubuntu and Arduino App Lab handling the complexity of the underlying stack – from containers to AI models – developers have the freedom to focus entirely on bringing their most ambitious ideas to life."

Fabio Violante, Vice President and General Manager of Arduino at Qualcomm
Enterprise ready and production grade

"We've worked closely with Arduino and Qualcomm Technologies to deliver an 'industrial-grade' software stack as a starting point. By pre-loading a production-ready Ubuntu environment on VENTUNO Q developer boards, we're removing the barriers between prototyping and commercial scale."

Cindy Goldberg, Vice President of Cloud and Silicon Partnerships at Canonical

For teams moving from prototype to commercial deployment, the VENTUNO Q is designed to provide a direct scaling path:

• Hardware compatibility:  Expansion options with support for standard Arduino® UNO™ shields and carriers, Modulino™ nodes, and Raspberry Pi® HATs.
• Rich connectivity: Features 3× MIPI-CSI camera connectors, 3× CAN-FD interfaces, Wi-Fi 6, Bluetooth 5.3, 2.5 Gb Ethernet, HDMI, and multi-pin GPIO/PWM options.
• Prototype-to-production pipeline: Code developed on VENTUNO Q developer board can be easily ported onto commercial products such as the production-certified Dragonwing IQ8 System-on-Modules (SoMs) through the Works with Arduino ™ program.

Getting started

Download the official Ubuntu image for VENTUNO Q directly from Canonical at ubuntu.com/download/qualcomm-iot#ventunoq .

To order your VENTUNO Q board or explore technical specifications and documentation, visit arduino.cc/product-ventuno-q

About Arduino

Arduino (a subsidiary of Qualcomm Technologies, Inc.) is a leading open-source hardware and software provider and an accessible platform for creating interactive projects. With an estimated 33 million active users, the Arduino ecosystem has expanded over 20 years to address new demands and challenges, offering products for IoT, wearables, 3D printing, and embedded environments.

About 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 https://canonical.com/  

Qualcomm branded products are products of Qualcomm Technologies, Inc. and/or its subsidiaries. Arduino, VENTUNO, UNO, and Modulino are trademarks or registered trademarks of Arduino S.r.l.

London, UK – August 25, 2026 – Following our initial collaboration announcement in March 2026, Canonical and Arduino (a subsidiary of Qualcomm Technologies, Inc.) are excited to announce that VENTUNO Q is now generally available for pre-order, pre-loaded with Ubuntu. VENTUNO Q is a dual-brain developer board designed for edge AI and robotics applications. With [...]


Categories: AI, IoT, Ubuntu, Ubuntu Desktop, Ubuntu Pro
Source: https://ubuntu.com//blog/arduino-ventuno-q-is-available-for-pre-order-with-ubuntu-pre-installed Aug 25, 2026, 10:13 PM

Ubuntu 26.04.1 LTS is now available to download

Ubuntu 26.04.1 LTS is now available to download, the first of 5 point releases scheduled for the 'Resolute Raccoon' in the 3 years. The release doesn't add new features, but brings a refreshed installation image (.iso) that includes all of the bug fixes, security patches and package updates released since the Ubuntu 26.04 LTS release back in April. No new hardware enablement stack is included since there's not been a newer Ubuntu release to backport a kernel and graphics driver set from. Next year's Ubuntu 26.04.2 LTS release will bring the Linux kernel and GPU drivers that ship in Ubuntu [...]

You're reading Ubuntu 26.04.1 LTS is now available to download , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, Point Releases, Ubuntu 26.04 LTS
Source: https://www.omgubuntu.co.uk/2026/08/ubuntu-26041-lts-point-release-download Aug 28, 2026, 02:06 AM