Nodalix OS: building a Linux desktop as one system

For a long time, my Linux setup evolved the way many personal desktops do: one tool at a time.

A compositor here. A status bar there. A few scripts to glue things together. A theme, some shortcuts, a custom launcher, a systemd service, another script to repair the thing the previous script depended on.

That approach is incredibly flexible, and it is one of the reasons I enjoy Linux. But at some point I realized I was no longer interested in maintaining a collection of customizations.

I wanted to build a desktop system.

That is where Nodalix OS started to change direction.

From dotfiles to a product

Nodalix is based on Arch Linux and built around Hyprland, Wayland and QuickShell, but those technologies are not the point of the project by themselves.

The goal is cohesion.

The shell, settings, application management, updater, installer, system services, visual identity, phone integration and release infrastructure are developed and versioned together.

I want the desktop to feel intentional from first boot onwards.

That means a system setting should not feel like it belongs to a completely different project than the panel that exposes it. Updating Nodalix should not require knowing which Git repository a particular shell component came from. Connecting an iPhone should not feel like bolting an unrelated utility onto the side of the desktop.

The individual parts can remain modular internally while still behaving like one product externally.

That distinction has become one of the most important ideas behind Nodalix.

The shell is only one layer

The most visible part of Nodalix is the custom QuickShell interface.

It handles the panels, controls, desktop surfaces and many of the interactions that define the system visually. But the project is deliberately much larger than the shell.

Today the repository contains several major components:

• Nodalix Shell for the desktop interface.
• Nodalix Apps for application management and integration.
• Phone Link for native iPhone connectivity.
• Nodalix Updater for releases, channels and system updates.
• Nodalix Installer for fresh systems and supported Arch installations.
• Nodalix Release for the definition of the system itself.
• Nodalix Wallpapers and other visual assets.

Underneath those components are the usual Linux building blocks: systemd, PipeWire, BlueZ, Arch packages and the Linux kernel.

The challenge is not replacing all of them. It is integrating them well.

Why QuickShell and Hyprland

Hyprland gives Nodalix a modern Wayland compositor with a strong foundation for a dynamic desktop.

QuickShell gives me something equally important: the ability to build the shell in QML as an application rather than treating the desktop as a pile of small unrelated widgets.

That makes it easier to share state, create consistent components and reason about the desktop architecture as it grows.

It also creates a different kind of engineering problem.

Once the shell becomes central to the desktop, small inefficiencies matter. A slow icon lookup, an expensive tint operation or a blocking search path is no longer an isolated application problem — it can make the whole desktop feel worse.

A lot of recent Nodalix work has therefore been about profiling and removing those bottlenecks instead of simply adding more features.

That is the kind of work I enjoy most: finding the actual reason something feels slow, fixing the architecture behind it, and then making sure the regression cannot quietly return later.

iPhone integration without pretending Linux is macOS

One of the more unusual parts of Nodalix is Phone Link.

I use Apple devices, but I also spend a lot of time on Linux. I do not want Nodalix to imitate macOS visually, and I do not want the Apple ecosystem to dictate how the desktop works.

What I do want is useful interoperability.

Phone Link currently combines several Bluetooth technologies:

• ANCS over Bluetooth LE for notifications.
• MAP / OBEX for message access.
• PBAP / OBEX for contacts.
• HFP / oFono for call state and hands-free call control.

The connection manager treats Bluetooth LE and classic Bluetooth independently. That matters because the iPhone may still be connected for calls while the notification transport has disappeared.

Instead of tearing everything down, Nodalix can recover the missing bearer while preserving the rest of the connection.

It is a small example of the broader philosophy of the project: integration should be handled by the system, not pushed onto the user as a troubleshooting checklist.

Updates are part of the desktop

Another area where I wanted Nodalix to behave like a complete system is updates.

Arch Linux gives me an excellent rolling-release base, but a Nodalix release contains more than upstream packages. It also has its own components, package definitions and release metadata.

The updater therefore handles several layers:

• Nodalix releases.
• Stable and preview channels.
• Arch system updates.
• Application updates.
• Firmware.
• Restart requirements.
• Release notes and package contents.

There is a graphical interface in Settings, but the same backend is also available from the terminal.

I want both interfaces to describe the same underlying system instead of implementing two separate concepts of what an update means.

Hardware-aware, but recoverable

Nodalix can detect CPU capabilities and select an appropriate optimization path, including generic x86-64, x86-64-v3, x86-64-v4 and Zen 4 / Zen 5 profiles where supported.

Performance is useful, but recoverability matters more.

That is why the system keeps a standard Arch Linux kernel and boot entry available when using an optimized kernel.

The same principle applies elsewhere: an optimization should improve the normal path without making the recovery path fragile.

Packaging instead of copying files around

As the project became larger, manually copying files into the right directories stopped being acceptable.

Nodalix components are built and distributed as Arch packages. Releases use a versioned manifest, and package metadata and SHA-256 hashes are checked during installation.

That gives the project a much cleaner ownership model.

System files live where system files should live. User configuration remains in the user’s XDG directories. Pairing data and credentials do not end up inside release artifacts.

This sounds less exciting than a new UI animation, but it is the work that makes future development sustainable.

The real project is the architecture

The most interesting change in Nodalix has not been a new feature.

It has been the shift in how I think about the project.

Instead of asking:

How do I add this feature to my Linux setup?

I increasingly ask:

Where should this capability live in the system, which component should own it, and how should the rest of Nodalix interact with it?

That question changes everything.

It affects how services are split, how settings are exposed, how the shell talks to the system, how packages are built, how updates are tested and how failures are recovered.

It also makes the project slower to design in the short term and much easier to evolve in the long term.

That trade-off is worth it.

What comes next

Nodalix is still evolving quickly.

There is work to do in system architecture, security, update reliability, Phone Link, desktop performance, application integration and the overall consistency of the experience.

I am also deliberately trying to avoid turning it into an endless collection of features.

The goal is not to make Nodalix contain everything.

The goal is to make the things it does contain feel like they belong together.

That is the standard I want to keep pushing toward.

If you want to follow the project, the repository is public on GitHub, where releases, issues and ongoing development are available.

And if you are interested in Linux desktop architecture, interoperability or the messy engineering details behind making a system feel simple, that is exactly the kind of work I plan to keep writing about here.