A Canonical engineer has published a prototype launcher that simulates how on-device AI could be used to enhance and aid users of the Ubuntu desktop.
But the warty-prototype1 snap by Didier Roche-Tolomelli (aka didrocks) is not a real launcher. It’s a semi-interactive, automated mockup. It simulates things a user could do, and that includes interacting with a (theoretical) on-device AI model to complete tasks.



Given how open the traditional Linux desktop APIs are, how much functionality is exposed in CLI form, a “desktop” OpenCode-like system could transform a Linux desktop into something other OSes coild achieve with a lot more difficulty. For example, reducing the size of a video file is just a cryptic ffmpeg command on Ubuntu. If ffmpeg isn’t installed, it’s an apt command to get it. A “make this big video 4GB” prompt is trivial to execute by a local model. And yes, an “AI desktop” would only work for most of us if it can do it all on-device. Not throwing our trusted data to OpenAI’s servers. A system like that would also require a strong harness to prevent hallucinations from rm -rf-ing the wrong thing.
It’s going to train new people to blindly type in their admin passwords and risk hosing the system
Quite possibly. But also possibly not. I’ve see plenty hosed systems by colleagues at work as they start using Ubuntu workstations with no experience.
Some years ago: “Why can’t do I get permission error, let me fix it good
chmod -R 777 /. Hey Amoeba, my system doesn’t boot anymore.”One could in principle create a model that knows the best practices, the no-nos, the dos and don’ts of Linux and try to stand in the way of the user holding the hose.
Any system like this is going to be limited by the fundamental inability of genAI to be hallucination-free. Being programmed with best practices will help but eventually it will suggest something that will be bad for the user.
True but a system like that wouldn’t just rely on the model training. It’d also rely on the harness around it. The program that takes the text from the clanker’s output and executes it. It can have, as existing tools do, a hefty static ruleset that allows / disallows / asks for user confirmation before executing. The ruleset would have to be significant and well designed to catch most disasters. Still wouldn’t be foolproof, but neither are my own CLI commands, or my brain at all times of the day. A not-so-reliable operator can be further mitigated by using a snapshotting filesystem.
Yes the harness is what i was talking about.
You can get footguns also from your own cli commands, misunderstanding the documentation, or by copy/pasting from a guide without knowing what you’re doing. But in both those cases it is clearer that it is your responsibility for understanding the context. And eventually that’s how you learn.
A generative, agentic system that does things for you without you needing to understand, and gets it right a lot of the time, but trains the user to enter the sudo password wihout understanding is not the UX I would encourage in an operating system.
True.