AHXproject

AlmaLinux to Unveil Media & Entertainment Edition at AlmaLinux Day on July 18th



The AlmaLinux OS Foundation will be hosting AlmaLinux Day on July 18th, 2026, at the E-Central DTLA Hotel in downtown Los Angeles.

The post AlmaLinux to Unveil Media & Entertainment Edition at AlmaLinux Day on July 18th  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Community, News, AlmaLinux, AlmaLinux Day, Linux distribution
Source: https://9to5linux.com/almalinux-to-unveil-media-entertainment-edition-at-almalinux-day-on-july-18th May 22, 2026, 12:27 AM

openSUSE Releases Agama 21 Installer with Better Network Management



openSUSE releases Agama 21 installer for Tumbleweed and Slowroll with systemd-boot support, better network management, as well as numerous new features and improvements. Here's what's new!

The post openSUSE Releases Agama 21 Installer with Better Network Management  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Apps, News, Agama, Agama installer, openSUSE, openSUSE installer
Source: https://9to5linux.com/opensuse-releases-agama-21-installer-with-better-network-management May 21, 2026, 08:21 PM

Nitrux 6.1 Is Now Available for Download, Powered by Linux Kernel 7.0



Nitrux 6.1 immutable, systemd-free GNU/Linux distribution is now available for download with Linux kernel 7.0, Hyprland 0.55.1, Maui Apps 4.0.3, Calamares 3.4.2 installer, and more.

The post Nitrux 6.1 Is Now Available for Download, Powered by Linux Kernel 7.0  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Distros, News, immutable, Linux distribution, Nitrux, systemd-free
Source: https://9to5linux.com/nitrux-6-1-is-now-available-for-download-powered-by-linux-kernel-7-0 May 21, 2026, 09:08 AM

Decoding design: How design and engineering thrive together in open source



Open source thrives on engineering-driven processes. Fast feedback loops, terminal tools, Git workflows: they're the lifeblood of how we build software in the open. But for software to truly excel, we need to create user experiences that empower people to use them.

I wanted to bring this conversation into the spotlight as part of Canonical's Open Design  initiatives. What better way than at FOSS Backstage 2026 Berlin ? To bring the conversation into the spotlight, I organized a panel of some of the most talented designers and engineers in the open source space: Glòria Langreo , Senior Design Director at GitHub, Eriol Fox , Core Maintainer at Open Source Design and Designer at Open Home Foundation (Home Assistant), and David Edler , Engineering Manager at Canonical. 

Here's everything I learned from " " 

1. Collaborating on the same workflow

One of the biggest misconceptions we face is the idea that designers and developers need separate, isolated workflows. Glòria immediately challenged this: at GitHub, teams work in an EPD (Engineering, Product, and Design) model, walking lockstep together. Ultimately, users don't care how your internal teams are organized, they just care about the final product.

"There is no such thing as a developer workflow and a design workflow... let's try to blend them and make them as indistinguishable as possible."
Glòria Langreo

One way to blend these workflows is to integrate design directly into the engineering cycles you already use. Eriol shared a story of introducing "Design QA" alongside standard engineering QA, which turned the QA process into a collaborative space for discussion from both parties to understand each other's perspectives and criteria points for something to be approved. David agreed, providing an engineering manager's perspective. He considers that performing Design QA is a necessary step before merging any PR: designers must review the proposed change to ensure the engineered result actually aligns with their original design intent. 

Design isn't a final layer of "polish" to be added later. If the experience is broken, it needs to be fixed in the moment, just like bad code.The takeaways:

• For designers: Don't default to a rigid design framework and lifecycle. Take the time to learn the specific environment of the engineering team you are working with.
• For engineers: Invite designers into your processes early. Eriol noted that engineers are often "just waiting for the invitation" to get involved in design, and the same goes in reverse.

2. Promote communication, empathy, and translation

Culture clashes often happen when we don't understand the constraints the other side is facing. 

For example, Glòria shared how designers can get frustrated when a seemingly simple UI filter is blocked by backend data models, leading to unfair assumptions about developers being "lazy." The fix? Designers should expand our skillset to understand how the architecture and data models actually work.

Likewise, engineers will invariably find edge cases in a design. Designers and engineers need a culture of shared critique where feedback is given at eye level, without fear. Communication is critical.

But how can teams communicate effectively in open source communities? Asynchronous work is the norm, and face-to-face meetings may be rare. Eriol provided a novel approach to solving this debate.

"I've just been kind of structuring my designs in a way that is good documentation."
Eriol Fox

What that means is treating design files as documentation. By adding version control, dates, and decision logs directly into your design files, designers can speak a language developers respect. Sharing working spaces and norms in this way helps to remove friction, making teams more effective in knowing what decisions are being made, how they are being made, and why those decisions have been made.  

The takeaways:

• For designers: As you get closer to the code and prototype with real components, the translation gap between design and engineering shrinks. Keep your early concepts low-fidelity to invite collaboration, rather than presenting a "finished" high-fidelity mockup that engineers feel they can't contribute to.
• For engineers: Learn the intention behind a design. When you understand why a designer is deliberately using specific whitespace or information hierarchy, you build a mental toolkit you can apply to future features.

3. Prove the value of design

In environments where design might be seen as secondary to shipping features, how do we prove its impact? The answer is simple: put the product in front of real users.

For engineers, joining in user testing sessions alongside the researcher or designer is highly motivating, according to David. Seeing someone struggle with a tool or product in real time makes you want to get it right, a sentiment supported by personal experiences for each of the panelists.

Glòria shared how observing a visually impaired user navigate a sign-up flow caused the engineering team to prioritize accessibility fixes the very next morning.

Eriol recounted a story where an engineer sat in on field tests in Kenya to stress-test an app under poor connectivity. The results? The engineer stayed up all night enthusiastically writing user story issues from a newfound perspective (hopefully they got their sleep as well).

Beyond user testing, Glòria pointed out that UX work, like standardizing patterns and building design systems, is fundamentally systems thinking. Getting engineering buy-in becomes much easier when developers realize that standardizing UI components means they can delete legacy code, scale faster, and maintain less technical debt.

The takeaways:

• For designers: Don't just tell engineers what to do. Show them the users' pain points and write user stories to frame your specifications.
• For engineers: Design isn't just about making things pretty; it solves complex problems like discoverability, accessibility, and consistency.

Conclusion: Be a community!

Building great open source software requires both excellent engineering and thoughtful design. The path forward is built on mutual curiosity and collaboration.

To the engineers reading this, don't be afraid to seek out design input, ask questions about user needs, and attend design-focused meetings. To the designers, don't be intimidated by the technical barriers. Lower the drawbridge to your discipline, go into engineering spaces, observe how they work, and contribute authentically.

As Eriol summarized, "Open source is as much about software as it is about being in community with each other."

When we respect each other's workflows and build together from the start, we create software that truly empowers the people using it.Check out the full panel discussion on !

Join the Canonical design team

We're looking for designers who care about craft and how systems work under the hood. At Canonical, design sits at the intersection of UX, engineering, and open source where we shape cohesive, accessible experiences across cloud, desktop, and IoT products.

If you enjoy solving complex problems and turning technical depth into clarity, explore our open roles: canonical.com/careers

Open source thrives on engineering-driven processes. Fast feedback loops, terminal tools, Git workflows: they're the lifeblood of how we build software in the open. But for software to truly excel, we need to create user experiences that empower people to use them. I wanted to bring this conversation into the spotlight as part of Canonical's [...]


Categories: Design, open design
Source: https://ubuntu.com//blog/decoding-design-how-design-and-engineering-thrive-together-in-open-source May 22, 2026, 11:12 AM

Developing web apps with local LLM inference

I've yet to meet a developer that enjoys working with metered AI APIs. The need to pay for every API call in development works in direct opposition to the ethos of rapid iteration, and it's easy for the costs to get out of hand. That's why Canonical has created a different approach to building AI-powered applications; one where the model lives inside your app, not behind a pay-per-token HTTP call. This post walks through the ideas behind Embedded AI – integrating local LLM inference directly into your app – and demonstrates those ideas in practice on the NVIDIA DGX Spark.

The problem with remote AI services

Today's default architecture for AI-powered applications is a hub-and-spoke model: multiple applications each call out to a shared AI service (OpenAI, Anthropic, Google Gemini, etc.). That service is responsible for running inference, metering usage, enforcing rate limits, and billing you by the token.

This model solves one real problem: you do not have to manage GPU infrastructure yourself. But it introduces several others:

• Cost unpredictability. Every call has a marginal cost. In development, where you iterate fast and make many exploratory requests, those costs compound quickly and often surprise teams mid-sprint.
• Network latency. A round-trip to a remote API adds tens to hundreds of milliseconds per request. For applications that chain multiple model calls (agents, RAG pipelines, multi-step reasoning), the latency accumulates and degrades user experience.
• Data privacy. Sending sensitive data to a third-party service requires trust in that service's data policies, creates compliance complexity, and may simply be prohibited in regulated industries.
• Dev-to-production friction. Development environments stub the API or use different credentials than production. Configuration drift, mock/real mismatches, and environment-specific behavior all stem from the fact that the "AI" in development is not the same thing as the "AI" in production.
• Operational complexity. Rotating API keys, managing quotas across teams, handling upstream outages, and understanding why a model behaves differently today versus last week are all problems that come bundled with remote AI services.

From AI services to local LLM inference


The idea behind Embedded AI is straightforward: treat the model and its inference runtime the way you already treat a software package as a local dependency of your application, not as a remote third-party service.

Instead of three apps all calling a shared external endpoint:

• APP 1 ──┐
• APP 2 ──┤──► AI Service (remote, metered, shared)
• APP 3 ──┘

Each app packages and runs its own inference engine:

• APP 1 + AI  (local, free at runtime, isolated)
• APP 2 + AI  (local, free at runtime, isolated)
• APP 3 + AI  (local, free at runtime, isolated)

This idea mirrors how organizations moved from server-side database instances to local SQLite, or from shared Redis clusters to in-process caches for appropriate workloads. The question is whether the hardware and the packaging tooling have caught up enough to make it practical.

In 2026, the answer is increasingly yes.

Inference snaps: installing AI like a package

The friction in running local LLM inference has historically been setup complexity: installing NVIDIA CUDA drivers, choosing the right quantization for your GPU's VRAM, configuring the inference server, managing updates. Canonical's inference snaps  solve this.

An inference snap packages together:

• The model weights in a format optimized for local hardware
• The inference runtime (llama.cpp, vLLM, or others, selected automatically)
• Hardware-specific optimizations (quantization level, batching strategy, inference engine selection)
• A standard OpenAI-compatible HTTP API exposed locally
• Dependency management and automatic updates via the Snap store

The snap's engine manager detects your hardware at install time and selects the engine that makes best use of your CPU, GPU, or NPU. You do not choose quantization manually. You do not install CUDA toolkit by hand. You run one command:

sudo snap install gemma3

With that, you have a locally running Gemma 3 inference server exposing an OpenAI-compatible endpoint, hardware-optimized, with automatic updates. The model is immediately usable from any application that knows how to make an HTTP call.

Snaps expose a content interface mechanism that lets other snaps (your application) read the endpoint URL from a shared status.json file:

sudo snap connect demo-app:inference-snap-status gemma3:status

After this connection, your application can read exactly where the inference endpoint is listening without any configuration file or environment variable management. The snap system handles the plumbing.

The reference implementations

Theembedded-ai  repository contains two concrete examples, both built as snaps themselves, so they integrate cleanly with the inference snap ecosystem.

App 1: simple chat

The first example (_01_simple_chat) is deliberately minimal. It demonstrates the core pattern: a snap-packaged Python application that reads the inference endpoint from the Gemma 3 snap's status interface and streams a chat completion to stdout.

Building and running:

# Build the snap
cd _01_simple_chat && snapcraft pack   # or: make build

# Install it
sudo snap install demo-app_*.snap --dangerous --devmode

# Connect it to the inference snap
sudo snap connect demo-app:inference-snap-status gemma3:status

# Run it
demo-app

The app streams a single chat completion using the model exposed by the inference snap. Because the inference snap exposes an OpenAI-compatible API, the Python code looks identical to code that calls api.openai.com; except the base URL points to localhost and there is no API key. The model runs on your machine. The cost of that call is electricity.

This pattern has an important architectural implication: your application code is decoupled from the specific model. Swap gemma3 for a different inference snap (say, qwen-vl or nemotron-3-nano), re-run the snap connect, and your app works against the new model with zero code changes.

App 2: PDF summarizer

The second example (_02_pdf_summarizer) shows a more realistic use case: processing a document and generating a summary using the local model.

Building and running:

# Build the snap
cd _02_pdf_summarizer && snapcraft pack   # or: make build

# Install it
sudo snap install pdf-summarizer_*.snap --dangerous --devmode

# Connect to the inference snap
sudo snap connect pdf-summarizer:inference-snap-status gemma3:status

# Summarize a PDF
pdf-summarizer /path/to/document.pdf

The app reads the PDF from disk, sends its content to the local LLM inference endpoint, and streams a concise summary to stdout. Notice what is not happening here: the PDF contents are not leaving your machine. They are not being sent to a third-party API. There is no data processing agreement to worry about, no risk of training data contamination, no latency from a WAN round-trip. The model reads your document locally and gives you an answer.

For enterprise use cases involving legal documents, medical records, financial reports, or any other sensitive material, this distinction is often the deciding factor in whether AI-powered features can be built at all.

Why package your app as a snap too?

You might wonder: why package the demo apps themselves as snaps? You could just run a Python script that calls localhost:PORT.

The answer is about distribution and dependency management. When your application is a snap:

• Dependencies are bundled. Your Python version, pip packages, and any native libraries are frozen in the snap. No virtualenv setup, no pip install -r requirements.txt on the target machine.
• The content interface works cleanly. The snap system's connection mechanism lets your app and the inference snap share a secure, well-defined channel for discovering the endpoint URL. This is cleaner than environment variables or config files and works correctly across snap updates.
• Your app updates like software. Snap updates are atomic and rollback-safe. If an update breaks something, you revert with one command.
• You ship once, run anywhere Ubuntu runs. The same snap package that runs on your DGX Spark runs on an Ubuntu server in a data centre, on edge devices with a supported GPU, or on any Ubuntu Certified hardware.

This is the realization of the dev-to-production parity promise: you develop, test, and ship the same artifact.

When does local LLM inference make sense?

Local AI is not the right answer for every situation. It makes the most sense when:

Privacy is a hard requirement. Legal, medical, financial, or government workloads where data cannot leave the premises are natural fits.

Latency matters. Applications that call the model in a tight loop (agents, real-time assistants, streaming pipelines) benefit enormously from eliminating network round-trips.

Costs would otherwise scale with usage. Internal tools used heavily by a team, e.g. code review assistants, document summarizers, knowledge base Q&A, accumulate token costs fast. A one-time hardware investment can amortize quickly against ongoing API bills.

Dev-to-production parity is important. Teams that are tired of "works against the API in dev, behaves differently in prod" issues benefit from having the exact same model and runtime in every environment.

Offline or air-gapped environments. Manufacturing floors, research labs, field deployments, and any environment without reliable internet connectivity need local inference by necessity.

It is less suitable for workloads that genuinely need frontier model scale (where a 70B local model is not competitive with a 200B+ remote one), or for sporadic, low-volume AI use where the hardware investment does not justify itself.

Getting started

Everything described in this post is open source and documented:

Inference snaps documentation and tutorials

Inference snaps source

Reference implementations

The fastest path to running your first locally-inferred completion:

# 1. Install the model snap
sudo snap install gemma3

# 2. Clone the reference repo
git clone https://github.com/abdelrahmanhosny/embedded-ai.git
cd embedded-ai/_01_simple_chat

# 3. Build and install the demo app snap
snapcraft pack        # or: make build
sudo snap install demo-app_*.snap --dangerous --devmode

# 4. Connect the app to the inference snap
sudo snap connect demo-app:inference-snap-status gemma3:status

# 5. Run it
demo-app

That is all it takes to go from zero to a locally-running, hardware-optimized, OpenAI-compatible LLM serving your application; no API key, no monthly bill, no data leaving your machine.

The code examples in this post reference the embedded-ai repository at commit main as of May 2026. The Inference Snaps project is maintained by Canonical under an open source license.

I've yet to meet a developer that enjoys working with metered AI APIs. The need to pay for every API call in development works in direct opposition to the ethos of rapid iteration, and it's easy for the costs to get out of hand. That's why Canonical has created a different approach to building AI-powered [...]


Categories: AI, Inference Snaps, Ubuntu
Source: https://ubuntu.com//blog/developing-web-apps-with-local-llm-inference May 21, 2026, 05:19 PM

PinTheft Linux kernel vulnerability mitigation

A local privilege escalation (LPE) security vulnerability in the Linux kernel, codename "PinTheft," was publicly disclosed on May 19, 2026. The vulnerability was fixed  in the mainline Linux kernel tree. A proof-of-concept exploit was published along with public disclosure. The vulnerability does not have a CVE ID assigned at the moment; other discovering teams may have given this issue other names. Ubuntu installations are only impacted if they use RDS (Reliable Datagram Sockets), a protocol generally used for high-performance computing (HPC).   The default Ubuntu configuration disables the automatic loading of the module affected by this vulnerability.

The vulnerability is a reference count bug that allows poisoning the page cache with malicious contents, similar to Copy Fail (CVE-2026-31431) or Dirty COW (CVE-2016-5195).

The vulnerability does not have a CVSS score assigned yet. Canonical assesses the vulnerability to have a CVSS 3.1 score of 7.8, corresponding to a High severity. The Ubuntu Priority assigned is Medium, the local privilege escalation to root from unprivileged users is balanced against the default configuration of Ubuntu being safe against this issue. Ubuntu uses a /etc/modprobe.d/blacklist-rare-network.conf configuration file that disables rarely used network protocols, including the affected RDS.

Impact

The vulnerability allows an attacker to replace the in-memory contents of arbitrary files. The disk contents are not affected, but programs that read a file, make changes, and write the data back may make the changes persistent.

The published proof of concept exploit rewrites a setuid executable with a very short program that grants root privileges to an unprivileged local user with very high reliability.

 The impact of the vulnerability is unclear in containerized environments. It's possible that an attacker in a container cannot use this to escape the container themselves, but could corrupt data for other containers or the main host, and if the raw storage for files is shared, could choose their targets.

Affected releases

The default configuration of all Ubuntu releases is not affected, either because the relevant kernels do not have the issue, or because the issue is mitigated in the shipped configuration.

Ubuntu kernel images for 16.04 LTS and earlier do not have the issue.

Ubuntu kernel images on Focal Fossa (20.04 LTS) and later are affected. Ubuntu Bionic Beaver (18.04 LTS) only has the vulnerable code on the HWE kernel versions (5.4).

In Ubuntu, the vulnerability fix will be distributed through the Linux kernel image packages. Until the Linux kernel security update is available, the default Ubuntu configuration is not affected because it disables the vulnerable kernel module from automatically loading. This default mitigation impacts programs that use RDS networking. Users that need this functionality would have to explicitly load the rds module, a configuration that would allow this vulnerability to be exploited.

ReleasePackage NameFixed VersionTrusty Tahr (14.04 LTS)linuxNot affectedXenial Xerus (16.04 LTS)linuxNot affectedBionic Beaver (18.04 LTS)linuxLinux 4.15 – not affectedLinux 5.4 (HWE) – mitigated in default configurationFocal Fossa (20.04 LTS)linuxMitigated in default configurationJammy Jellyfish (22.04 LTS)linuxMitigated in default configurationNoble Numbat (24.04 LTS)linuxMitigated in default configurationQuesting Quokka (25.10)linuxMitigated in default configurationResolute Raccoon (26.04 LTS)linuxMitigated in default configuration
How to check if you are impacted

Confirm that the rds module is not currently loaded:

lsmod | grep -qE '^rds ' && echo "Module is loaded (vulnerable)" || echo "Module is NOT loaded"

Ensure that the automatic loading of the module is disabled:

grep -rqE '^alias net-pf-21 off' /etc/modprobe.d/ && echo "Automatic loading disabled (NOT vulnerable)" || echo "Automatic loading possible (vulnerable)"

Ensure that the module is not loaded at boot time:

grep -rqE '^rds' /etc/modules-load.d/ /usr/lib/modules-load.d/ && echo "Module is loaded at boot time (vulnerable)" || echo "Module is not loaded at boot time (NOT vulnerable)"
Manual mitigation

No manual mitigation is necessary on default Ubuntu systems. If you previously enabled RDS on your systems, you may disable it from automatically loading again via:

rmmod rdsecho "alias net-pf-21 off" | sudo tee /etc/modprobe.d/blacklist-rds.conf
Disabling the mitigation

Once kernel updates are available and installed, the mitigation can be removed if you must run RDS applications:

sudo rm /etc/modprobe.d/blacklist-rds.conf

We recommend that you do not disable this mitigation unless you must run RDS.

A local privilege escalation (LPE) security vulnerability in the Linux kernel, codename "PinTheft," was publicly disclosed on May 19, 2026. The vulnerability was fixed in the mainline Linux kernel tree. A proof-of-concept exploit was published along with public disclosure. The vulnerability does not have a CVE ID assigned at the moment; other discovering teams may [...]


Categories: Security, Vulnerabilities
Source: https://ubuntu.com//blog/pintheft-linux-kernel-vulnerability-mitigation May 21, 2026, 03:30 PM

Canonical announces fully Managed Kubeflow AI operations platform on the Microsoft Azure Marketplace

Canonical, the publisher of Ubuntu, today announced the general availability (GA) of Managed Kubeflow on the Microsoft Azure Marketplace. This solution enables AI teams to get a fully managed, production-ready MLOps platform in their own tenant.

Upstream Kubeflow is a powerful tool for machine learning, but it remains notoriously challenging to deploy and maintain. Organizations often find that their high-value data science teams waste a considerable portion of their capacity on infrastructure maintenance. Day-2 operations, such as manual upgrades and complex security patching, frequently stall model delivery and inflate operational costs.

Canonical Managed Kubeflow solves these challenges by giving enterprise and startup AI teams a fully operational, open source MLOps platform in under an hour – managed 24/7 by Canonical's engineers – so data scientists can focus entirely on models rather than infrastructure. 

Enterprise-grade control and data governance

Managed Kubeflow on Azure removes the burden of monitoring and maintenance from platform engineering teams. Canonical's expert engineers provide 24/7 management, including seamless version upgrades.

The platform is built on the following core pillars:

• In-tenancy deployment: The service runs entirely in-tenancy within the customer's Azure Virtual Network (VNet). Proprietary models and training data never leave the customer's security perimeter.
• Single Sign On: Native integration with Microsoft Entra ID, Okta or any other OpenID Connect (OIDC) compliant identity provider provides teams with securely designed, centralized authentication and access control.
• Portability and control: Built on proven upstream Kubeflow, MLFlow and KServe, the platform ensures total portability as both the underlying application and automation code are open source. Your investment can travel with you if your strategy shifts toward hybrid or multi-cloud environments.

Accelerating Kubeflow time-to-value

The service is available directly via the Azure Marketplace  as a transactable listing. Every subscription decrements a customer's Microsoft Azure Consumption Commitment (MACC) on a 1-for-1 basis. This enables startups and large enterprises to bypass lengthy procurement cycles and deploy using existing Azure commitment.

The platform scales effortlessly to accommodate a diverse range of enterprise workload demands. Users can deploy lightweight environments for rapid prototyping and initial testing phases. For critical production workloads, built-in High Availability (HA) guarantees enhanced system reliability.

The service runs natively inside the robust Azure Kubernetes Service (AKS) environment. Administrators can configure independent worker pools featuring auto-scaling capabilities. Depending on your use case the service enables you to allocate cost-effective CPUs for development tasks and powerful GPUs for intensive model training. This optimizes Azure spend while simultaneously accelerating workflow performance.

For AI and data executives, the service solves the challenge of needing to staff specialized MLOps teams before achieving product-market fit. It combines flexibility with the reliability required for production-grade AI projects, all while ensuring data governance, significantly lowering the barrier to innovation

Get started with Managed Kubeflow on Azure 

Managed Kubeflow on Azure is available now on the Azure Marketplace. Organizations can deploy the service directly from the Azure Marketplace to begin scaling their AI operations immediately:

Deploy Managed Kubeflow on Azure

Additional resources

• Read the product documentation

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/

Canonical has announced the general availability of Managed Kubeflow on the Microsoft Azure Marketplace. This fully managed MLOps platform allows enterprise AI teams to deploy a production-ready environment in under an hour, eliminating infrastructure maintenance.


Categories: Kubeflow, Microsoft Azure
Source: https://ubuntu.com//blog/managed-kubeflow-microsoft-azure-canonical-release May 21, 2026, 09:32 AM

GNOME Sushi spacebar preview fix coming to Ubuntu 26.04

GNOME Sushi fans, rejoice: the spacebar preview feature is being fixed in Ubuntu 26.04. If you're not familiar with it, GNOME Sushi is a file preview tool similar to Quick Look on macOS. Select a file in Nautilus, press space and a floating preview window appears. It works with images, video and audio files, PDFs, plain text files and more. GNOME's Sushi isn't preinstalled in Ubuntu but many users install it themselves as it makes it easier to find specific files when rooting through folders filled with samey-seeming documents, audio files and video clip. —Well, except it doesn't (or rather, [...]

You're reading GNOME Sushi spacebar preview fix coming to Ubuntu 26.04 , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, Bug Fixes, sushi, Ubuntu 26.04 LTS
Source: https://www.omgubuntu.co.uk/2026/05/gnome-sushi-not-working-ubuntu-26-04 May 22, 2026, 07:20 PM

ONLYOFFICE 9.4 is out with a stricter FOSS licence

A new version of ONLYOFFICE, the open-source productivity suite, is out with a small set of improvements. The new release lands a couple of months after ONLYOFFICE suspended its eight-year Nextcloud partnership over Euro-Office, a fork by a European consortium that ONLYOFFICE says violates its AGPLv3 licence terms. Totally unrelated (yes, sarcasm), ONLYOFFICE 9.4 updates its licensing to tighten language around attribution, copyright notices and the labelling of modified versions. Viva le fork; it still permits modifications, but is more sniffy about any that use its trademarks. Features-wise, ONLYOFFICE 9.4.0 adds Croatian language translations across all editors and shuffles chart [...]

You're reading ONLYOFFICE 9.4 is out with a stricter FOSS licence , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, App Updates, EuroOffice, OnlyOffice
Source: https://www.omgubuntu.co.uk/2026/05/onlyoffice-9-4-released May 22, 2026, 02:41 AM

Vivaldi 8.0 released with 'biggest design overhaul, ever'

A bold new look arrives in Vivaldi 8.0, the latest update to the Chromium-based web browser. The browser's main UI elements (the bits that make a browser looks like a browser, so tabs, toolbars, panels, and content) drop their boundaries to form a continuous look. Hence the named Unified. Similar to Zen Browser, the canvas for web content is now 'framed' with rounded corners, rather than web pages flowing fully from edge-to-edge. "Unified is not a visual refresh. It is a rethinking of how the Vivaldi interface works as a system" the company says in a press release (invoking a [...]

You're reading Vivaldi 8.0 released with 'biggest design overhaul, ever' , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, App Updates, Vivaldi
Source: https://www.omgubuntu.co.uk/2026/05/vivaldi-8-0-released-redesigned May 21, 2026, 06:42 PM