Starling is a new Linux desktop environment announced on Tuesday, and the claim attached to it is the interesting part: a single developer directed Claude through roughly 2,000 commits over six months to produce 335,000 lines of first party code. What comes out is a real session you can log into, with its own Wayland compositor written in C, an in tree X11 server, a shell and applications in Swift, and unmodified third party software running as native clients. It is Apache 2.0 licensed, ships as a 53 MB .deb for Ubuntu 26.04 LTS, and is honest about being version 0.2. The line counts repay a closer look.
The short answer
Starling is a new Linux desktop environment announced on Tuesday July twenty eighth. One developer directed Claude across roughly 2,000 commits over six months to produce 335,000 lines of first party code in Swift, C and C++. About 273,000 of those lines are a port of the Flutter framework to Swift, leaving roughly 62,000 for the shell, the Wayland compositor, the in tree X11 server and the bundled applications. It runs unmodified Chrome, Slack, Zoom, VS Code, IntelliJ, GIMP and Blender. Apache 2.0 licensed, version 0.2, Ubuntu 26.04 LTS on AMD Radeon and virtio-gpu.
The reflex when a project announces that an AI wrote it is to check whether anything runs. Most of the time the answer is a browser mockup with a fake dock. This one boots as a session, hosts an X11 server, and opens Blender.
What is under the name
Starling is not a shell sitting on somebody else's compositor. It brings its own, written in C, talking to DRM and KMS directly to drive the display and reading raw input devices itself. Beside it runs an X11 server hosted in the same session, with DRI3 and Present, so anything that has not made the Wayland move still gets a window.
The layer above is Swift: the shell, the window manager, the dock, workspaces, portals, and a set of first party applications covering Files, Terminal, Settings, Calculator, Text Editor, Image Viewer and an app store pointed at the Ubuntu archive. Drawing all of that is a port of the Flutter framework to Swift, which is where most of the code volume lives.
The compositor advertises xdg-shell, linux-dmabuf, viewporter and fractional-scale-v1, among others. That list is the reason unmodified Chrome and Electron applications work rather than a curated demo set.
The line counts are the honest part
335,000 lines in six months is the number that travels. The breakdown the project publishes is more useful.
Roughly 273,000 of those lines are the Flutter to Swift port. That is a translation job: a large, repetitive, well specified body of work with a reference implementation sitting right there to check against. It is close to the best case for a language model, and it is not where the hard design decisions live.
The remaining 62,000 lines are the shell, the compositor, the X11 server and the applications. That is the part that had to be invented. Sixty two thousand lines for a working Wayland compositor, an X server and a usable session is still a serious quantity of code by any measure, and it is a much more informative figure than the headline.
We would rather see the smaller number quoted, because it is the one that survives scrutiny.
What this does not tell you yet
An announcement establishes that the code exists and that it runs on the author's hardware. It does not establish how it reads.
The questions worth holding open are ordinary software questions. How does the compositor behave on Intel or NVIDIA graphics, which are not on the verified list. What happens to the protocol edge cases that toolkits only exercise under load, resize storms, damage tracking, clipboard handoff between the Wayland and X11 halves. Whether a contributor who did not direct the original work can pick up a subsystem and change it safely. Those are the questions any new compositor faces, and being written with an assistant neither exempts a project from them nor makes them worse.
The Apache 2.0 license and the public repository mean anyone motivated to answer them can. That is the useful part of this announcement.
If you want to try it
The verified configuration is narrow: Ubuntu 26.04 LTS on amd64, with AMD Radeon or virtio-gpu. You need a Wayland capable login manager, GDM3 being the obvious one, then the 53 MB .deb, then Starling appears in the session menu at the login screen.
The version number is 0.2 and the documentation says there are rough edges, missing settings and applications that still need work. Take that at face value. The sensible way to look at this today is in a virtual machine on virtio-gpu, where a compositor crash costs you nothing, or by reading the 62,000 lines that matter.
Sources and further reading
- Starling project site
- starling-build/starling on GitHub
- Phoronix: Starling, a new Linux desktop written in Swift with its own Wayland compositor
- Linux.org discussion thread on the Starling announcement
- Wayland protocol documentation
Frequently asked questions
What exactly is in Starling?
More than the word desktop usually implies. There is a Wayland compositor written in C, talking directly to DRM and KMS to drive the display and handling raw input devices itself. There is an X11 server hosted in the same session, with DRI3 and Present support, so software that has not moved to Wayland still gets a window. Above that sit a shell, a window manager, a dock, workspaces and portals, plus bundled applications: Files, Terminal, Settings, Calculator, Text Editor, Image Viewer and an app store wired to the Ubuntu archive. The shell and applications are Swift. Underneath all of it is a port of the Flutter framework to Swift, which is what the user interface is drawn with.
How much of the 335,000 lines is the interesting part?
Around 62,000 lines. The project's own breakdown puts roughly 273,000 lines in the Flutter to Swift framework port, leaving about 62,000 for the shell, the Wayland and X11 servers and the bundled applications. That distinction matters when you read the headline number. A framework port is a large, mechanical, well specified translation task with a reference implementation to check against, which is close to the ideal shape for a language model. The compositor and the shell are the part where the work has to be invented rather than translated, and 62,000 lines for a working compositor plus a session is a more sober figure than 335,000, without being an unimpressive one.
Does it actually run real applications?
That is the claim the project leans on hardest, and it is a reasonable place to put the burden of proof. The listed applications include Chrome, VS Code, Slack, Zoom, IntelliJ, GIMP and Blender, none of which were written with Starling in mind. Running unmodified clients is a meaningful bar because it means the compositor implements enough of the protocols that real toolkits depend on, rather than a demo subset. The compositor advertises xdg-shell, linux-dmabuf, viewporter and fractional-scale-v1 among others, which is the set that Chromium, Electron and the major toolkits will look for.
Can I install it, and should I?
You can, on a narrow configuration. It targets Ubuntu 26.04 LTS on amd64 with AMD Radeon or virtio-gpu graphics, which is where the developer has verified it. Installation means having a Wayland capable login manager such as GDM3, installing a 53 MB .deb, and picking Starling from the session menu at login. Whether you should depends on what you want from it. This is an early preview labelled 0.2, and the documentation says plainly that there are rough edges, missing settings and applications that still need work. As a daily driver, no. As something to read the source of, or to run in a virtual machine on virtio-gpu, yes.
What is the argument the project is actually making?
That the cost of building a desktop environment has collapsed. Historically a new desktop meant a community, years of unpaid effort and a slow climb through protocol support before anything real would run. Starling's position is that one person with an AI assistant covered that ground in six months, and therefore that the next desktop does not need decades of volunteer availability to exist. Whether the claim holds depends on questions the announcement cannot answer yet: how the code reviews, how it behaves on hardware the author does not own, and whether a codebase produced this way can be maintained by anyone other than the person who directed it. Those answers come from the repository, not the press release.