Every distribution has a catalyst. For AliveOS, it was a file picker dialog.

I was running Cinnamon on Arch, and every time a Flatpak app needed to open or save a file, the portal dialog was either missing, broken, or looked like it belonged in a different desktop environment. The xdg-desktop-portal-gtk backend worked, but it was generic — no custom actions, no proper sidebar integration, no native feel.

I tried configuring xdg-desktop-portal-xapp-filepicker. It worked better, but Nemo’s portal mode had quirks: it wouldn’t stay focused, multiselect was flaky, and the save dialog didn’t handle overwrites gracefully.

So I asked myself: what if I just forked Nemo and made it do exactly what I needed?

That question became Dory. And Dory became the reason AliveOS exists.

What Dory Actually Is

Dory is a standalone file chooser portal backend and file manager, forked from Nemo (the Cinnamon file manager). But it’s not Nemo with a different name. Every namespace — binaries, D-Bus services, GSettings schemas, desktop files, library paths — has been renamed from nemo to dory.

This means Dory can be installed side-by-side with Nemo without conflicts. It doesn’t steal your file manager associations. It doesn’t overwrite your schemas. It just quietly handles portal file dialogs when called by xdg-desktop-portal-xapp-filepicker.

The Technical Challenge: Portal Dialogs Are Hard

File chooser portals are deceptively complex. Here’s what the D-Bus interface (org.Dory.FileChooser) needs to handle:

// OpenFile — standard file/folder selection
void open_file(
    string parent_window,
    string title,
    string[] accept_label,
    string[] options  // filters, multiselect, directory mode, etc.
);

// SaveFile — single file save with overwrite confirmation
void save_file(
    string parent_window,
    string title,
    string accept_label,
    string options  // suggested_name, current_folder, etc.
);

// SaveFiles — multi-file save (for GIMP layers, etc.)
void save_files(
    string parent_window,
    string title,
    string accept_label,
    string[] files,  // list of suggested filenames
    string options
);

Each of these needs to:

1. Spawn a dialog window
2. Track focus and lifecycle via GApplication holds
3. Handle the case where the user cancels
4. Return URIs or throw org.freedesktop.DBus.Error.NoResponse

The GApplication lifecycle was the first major roadblock.

Roadblock #1: The Daemon That Wouldn’t Stay Alive

When a Flatpak app requests a file, the portal backend spawns, shows the dialog, waits for user input, then returns the result. Simple in theory. In practice, the D-Bus service activation would spawn the process, the dialog would appear, but the process would exit before the user could click anything.

Root cause: GApplication was releasing its hold when the D-Bus method call completed, not when the dialog closed.

The fix: restructure the D-Bus service activation to maintain GApplication holds throughout the dialog lifecycle:

// Before: hold released immediately after method dispatch
g_application_release(app);

// After: hold maintained until dialog response
g_application_hold(app);
// ... show dialog ...
// In dialog response handler:
g_application_release(app);

This kept the process alive until the user actually selected or cancelled.

Roadblock #2: Focus Stealing and Dialog Z-Order

Portal dialogs need to appear above the requesting application. But X11 window managers (and Wayland compositors) have their own ideas about focus. The dialog would appear behind the parent window, or the parent window would steal focus back.

The fix was a combination of gtk_window_present() with gdk_window_raise() and gdk_window_focus() calls, timed after the dialog realized:

static void on_dialog_realized(GtkWidget *dialog, gpointer user_data) {
    GdkWindow *gdk_window = gtk_widget_get_window(dialog);
    gdk_window_raise(gdk_window);
    gdk_window_focus(gdk_window, GDK_CURRENT_TIME);
}

Even then, some window managers fight you. We added a GSettings persistence layer to remember the last-used directory and dialog state across invocations.

Roadblock #3: Multiselect URI Reconstruction

The portal passes selected files as a list of URIs. But when multiselect is enabled, the D-Bus response needs to reconstruct the full URI list from the internal selection model.

The bug: get_selected_uris() was only returning the first selected file when multiple files were chosen.

Root cause: the selection model was being rebuilt during the response dispatch, losing the intermediate state.

Fix: rebuild the URI list from all selected paths before the dialog closes:

// Rebuild selected_uris from all selected paths
GList *selected_paths = gtk_icon_view_get_selected_items(view);
for (GList *l = selected_paths; l != NULL; l = l->next) {
    GtkTreePath *path = l->data;
    // ... convert to URI and add to list ...
}

Roadblock #4: Save Dialog Overwrite Confirmation

The standard portal save dialog doesn’t handle overwrites — it just returns the path. But users expect a “file already exists, overwrite?” confirmation.

We implemented an intelligent overwrite modal: when the user selects a path that already exists, the dialog intercepts the selection, shows a confirmation dialog, and keeps the picker open if the user declines:

if (g_file_exists(selected_file)) {
    // Show overwrite confirmation dialog
    int response = gtk_dialog_run(GTK_DIALOG(overwrite_dialog));
    if (response == GTK_RESPONSE_NO) {
        // Keep picker open, let user choose different path
        return;
    }
}
// Proceed with save

This required careful coordination between the dialog’s response handlers and the GApplication lifecycle.

Roadblock #5: The libglycin Thumbnail Minefield

Dory generates thumbnails for files in the portal dialog. This uses libglycin for image loading. Here’s the problem: libglycin is loaded into the Cinnamon process (the desktop shell). A crash in libglycin doesn’t just crash Dory — it segfaults Cinnamon and freezes the entire desktop.

The AGENTS.md in the Dory repo spells this out clearly:

1. Never let invalid/untrusted data reach libglycin unchecked.
2. Catch and handle all libglycin errors gracefully.
3. Avoid resizing images in-place on the main thread without bounds checks.
4. Test thumbnail code under stress — large images, corrupt files, zero-byte files, symlink loops.

We added validation layers before any image data reaches libglycin: dimension checks, format verification, and buffer size validation. The thumbnail generation runs in a separate thread with error boundaries that catch and log failures without propagating them.

Recent Development: Post-Fork Commits

Here’s what’s been shipping since the initial fork:

The commit history tells the story of iterative hardening:

7c76df75 nemo-desktop: Don't crash/quit in Wayland when the monitor is removed
2e7fe76d dnd: Don't allow drops into a search result view
77f49f79 chooser: robustly resolve initial/last directory and prevent saving non-directories
5fcebdde refactor: rename action layout editor from nemo to dory
9eecb1c8 fix: force focus on file chooser dialog with gdk_window_raise + gdk_window_focus
67fee9c6 fix: rebuild selected_uris from all selected paths for proper multiselect support
66302aa3 fix: raise file chooser dialog to foreground with gtk_window_present
0ccffa54 fix: save-mode folder selection + add SaveFiles D-Bus method
539b8a9e Properties: Add Stop button for folder disk usage scanning

Current Status: Stable and Shipping

Dory is now at v6.7.6 and ships as the default file chooser portal backend in AliveOS. It’s available in the AUR as dory-git and declared as providing/conflicting with nemo to satisfy Cinnamon’s dependencies.

The extensions ecosystem is also growing:

• dory-terminal — embedded terminal in file manager
• dory-share — Samba/network sharing integration
• dory-preview — enhanced file previews
• dory-python — Python scripting support
• dory-compare — file comparison tools

What Dory Taught Me

Building Dory taught me three things about file managers:

1. Portal dialogs are first-class citizens. In a world of Flatpaks and sandboxed apps, the file picker isn’t just a UI convenience — it’s a system service.

2. Namespace isolation matters. If you want your fork to coexist with the original, you need to rename everything. Every binary, every D-Bus name, every schema path.

3. Thumbnail loading is a trust boundary. When your file manager loads arbitrary images for previews, you’re one malformed JPEG away from crashing the entire desktop.

Dory is the piece that made me realize: if I wanted a file manager that did exactly what I needed, I’d have to build it myself. And if I was building a file manager, I might as well build a distribution around it.

Acknowledgments

Dory wouldn’t exist without the incredible work of the Cinnamon and Linux Mint development team. Nemo is a polished, well-engineered file manager — forking it gave us a solid foundation that would have taken years to build from scratch.

Special thanks to:

• Clement Lefebvre and the Linux Mint team for maintaining Nemo and the broader Cinnamon ecosystem
• Michael Webster and other Nemo contributors for the extension framework and D-Bus interfaces that Dory builds upon
• The XApp team for the toolkit components that make GTK-based desktop apps feel native across Cinnamon, MATE, and XFCE

We stand on the shoulders of giants. Dory is our attempt to give back — a specialized tool for a specific use case, built on the excellent foundation the Mint team created.

Dory is available at github.com/Twilight0/dory. Extensions are at github.com/Twilight0/dory-extensions. Join the discussion on the AliveOS Forum.

Let’s cut to the chase: KDE Connect is a fantastic project, but it comes with a dependency chain that makes it unsuitable for lightweight, GTK-based desktop environments. If you’re running Cinnamon, MATE, or XFCE on Arch, you shouldn’t need to pull in half of KDE’s infrastructure just to get clipboard sync and notification mirroring working.

So we built xconnect — a fork of mconnect, Maciej Borzecki’s excellent KDE Connect protocol implementation in Vala/C. We kept the solid protocol foundation and added a GTK3/XApp GUI, expanded the CLI, and implemented features that the original project never prioritized. No KDE dependencies. Just pure functionality.

Technical Architecture

Built on top of mconnect’s Vala/C foundation, xconnect extends the architecture with three components:

1. xconnect daemon — The core service handling protocol negotiation, device discovery, TLS channel management, and packet routing via D-Bus (org.xconnect).

2. xconnectctl — A CLI client that exposes every daemon capability as a command-line interface. This isn’t just a toy wrapper; it’s a fully-featured automation tool.

3. xconnect-app — A GTK3 system tray application with device management, notification history, MPRIS media controls, and inline configuration editing.

The daemon runs as a systemd user unit, listening on UDP 1716 for incoming device discovery and broadcasting identity packets to UDP 1714 every 5 seconds. Device connections are established over TCP 1714, with TLS negotiation handled via GnuTLS.

Features Implemented

Here’s what’s working as of v2.3.0:

The Nasty Bits: Roadblocks and Fixes

Dual-Bus D-Bus Nightmare

The most insidious bug we encountered was the dual-bus problem. Here’s what happened:

• The xconnect daemon registers on dbus-broker (/run/user/1000/bus) — the modern, high-performance D-Bus implementation used by systemd.
• Terminals and the GUI were connecting to the legacy dbus-daemon.
• Result: xconnectctl list-devices would show nothing, while the GUI worked fine.

The fix required probing the systemd user bus first, then falling back to the session bus:

// In xconnectctl — try systemd user bus first
string bus_address = Environment.get_variable("DBUS_SESSION_BUS_ADDRESS");
if (bus_address == null || !bus_address.contains("/run/user/")) {
    bus_address = "unix:path=/run/user/" + UserId.to_string() + "/bus";
}

We also removed the D-Bus activation file (extra/org.xconnect.service) from installation — it was causing the legacy dbus-daemon to auto-spawn a second daemon instance with no TCP listener. Classic.

Packet Queuing During TLS Handshake

Devices would occasionally fail to receive packets during the initial connection phase. Root cause: the daemon was trying to send packets before the TLS handshake completed.

The solution was a packet queue in Device.send():

public void send(Json.Object pkt) {
    if (this._channel == null || !this._is_active) {
        this._pending_packets.add(pkt);  // Queue silently
        return;
    }
    // ... send immediately
}

Packets queue silently when the channel isn’t ready, then flush automatically after secure_incoming_channel() completes. No more lost packets.

Messenger Reaction Emoji Fallback

Here’s a fun one. Android’s background activity launch restrictions prevent PendingIntent.getActivity() from working when the phone screen is off. This means Messenger’s “Like” reaction button fails silently on the phone.

Our workaround: a Smart Emoji Sniffer that intercepts blocked action buttons and routes reaction emojis (❤️, 🔥, 👍, 💞) via RemoteInput reply instead:

// notification.vala — intercept blocked actions
if (pkg == "com.facebook.orca" && key == "Like") {
    // Route via RemoteInput instead of PendingIntent
    send_emoji_fallback(device, id, emoji);
}

It’s a hack, but it works. And it’s configurable per-package.

Cinnamon Inline Reply Integration

Cinnamon’s notification applet supports inline reply via org.freedesktop.Notifications.NotificationReplied D-Bus signal. We integrated this natively:

1. Daemon emits notification_received signal with has_reply: true and reply_label metadata.
2. GUI shows an inline reply entry at the bottom of the device detail page.
3. User types reply → SendReply() D-Bus call → daemon sends kdeconnect.notification.reply packet with requestReplyId.

No zenity popups. No separate dialogs. Just native desktop integration.

The CLI: Power in Simplicity

Here’s where xconnect really shines for automation. Every D-Bus method is exposed as a CLI command with smart device targeting:

# Target by short ID
xconnectctl share-file 80eeceab /path/to/photo.jpg

# Target by name (partial match)
xconnectctl send-sms Galaxy "+1234567890" "Meeting at 5 PM"

# Target by index
xconnectctl notifications 0

# Target by full D-Bus path
xconnectctl ping /org/xconnect/device/80eeceab "Hello from terminal"

This means you can script workflows:

#!/bin/bash
# Daily morning routine
xconnectctl show-battery Galaxy
xconnectctl show-connectivity Galaxy
xconnectctl share-url Galaxy "https://calendar.example.com/today"

Or integrate with other tools:

# Share clipboard content with phone
xconnectctl share-text 0 "$(xclip -selection clipboard -o)"

# Forward notification to Telegram bot
xconnectctl notifications 0 | grep -i "urgent" | curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d chat_id=$CHAT_ID -d text="$(cat)"

The CLI isn’t an afterthought — it’s a first-class citizen designed for power users and automation engineers.

What’s Next

The roadmap (see FEATURES.md) includes:

• Priority 1: SFTP remote filesystem access — mount phone storage via sshfs/gio mount
• Priority 2: SMS conversation threads, MMS support, configurable app reaction fallback engine
• Priority 3: Contacts sync, digitizer/stylus support, share input devices

Try It Out

# Arch Linux
git clone https://github.com/Twilight0/xconnect
cd xconnect
makepkg -si

# Enable and start
systemctl --user enable --now xconnect

# List devices
xconnectctl list-devices

No KDE dependencies. Just Vala, GTK3, and a clean D-Bus interface.

xconnect is a fork of mconnect by Maciej Borzecki. We’re grateful for the solid protocol foundation that made this project possible.

Got feedback? Found a bug? Open an issue on GitHub or join the discussion on the AliveOS Forum.

Background

Recent developments in major desktop environments have signaled a shift away from X11 toward Wayland. Notably, the KDE project has announced plans to drop X11 support in favor of Wayland-only builds in upcoming releases. While Wayland offers certain advantages, many users and organizations continue to rely on X11 for reasons including hardware compatibility, legacy software support, remote display protocols, and proven stability.

For users with older hardware, specialized workflows, or strict stability requirements, an abrupt transition away from X11 can be disruptive. Moreover, the XLibre project represents a promising effort to provide a modern, maintained X11 server with improved performance and security features, making it a viable foundation for the future of X11-based desktops.

The Need for a Cinnamon Fork

Cinnamon, as a desktop environment, offers a polished, traditional user interface that balances functionality, aesthetics, and resource usage. It has been a cornerstone of the AliveOS experience due to its coherence and suitability for both general and development workloads.

However, as the broader GNOME ecosystem (which underlies many of Cinnamon’s dependencies) continues to prioritize Wayland, there is a growing risk that future versions of Cinnamon will increasingly depend on Wayland-specific features, libraries, or assumptions that complicate or prevent clean operation on pure X11/Xlibre setups.

To safeguard the ability to run a modern, well-maintained Cinnamon desktop on X11/Xlibre systems, we propose establishing a dedicated fork of Cinnamon with the following goals:

• Preserve X11/Xlibre Compatibility: Ensure that all core components, applets, applets, and applets remain functional and well-tested on X11/Xlibre without reliance on Wayland-only dependencies.
• Fast Tracking of Fixes and Features: Rapidly integrate critical bug fixes, security patches, and meaningful new features from the upstream Cinnamon repository while filtering out changes that introduce hard Wayland dependencies or degrade X11 compatibility.
• Community-Driven Maintenance: Leverage the collective expertise of developers, testers, and users who value X11 stability to review, test, and contribute to the fork.
• Compatibility with AliveOS Goals: Align with the AliveOS philosophy of providing a lightweight, coherent, and bloat-free desktop environment that works well on a wide range of hardware, including older systems.

How You Can Help

We invite developers, testers, packagers, and enthusiastic users to join this effort. Contributions can take many forms:

Development

• Review and adapt upstream Cinnamon commits for X11/Xlibre compatibility.
• Implement fixes for issues discovered during testing.
• Assist in maintaining the fork’s build system and CI/CD pipeline.
• Help port or maintain Cinnamon applets, extensions, and settings that may require X11-specific adjustments.

Testing

• Run the fork on diverse hardware configurations, including legacy systems.
• Test compositing, window management, file operations, desktop effects, and integration with AliveOS-specific tools (e.g., Dory file manager, Respite media player).
• Report regressions, conflicts, or missing functionality via the project’s issue tracker.

Documentation and Support

• Help maintain documentation regarding installation, configuration, and known issues.
• Assist in triaging user reports and guiding newcomers.
• Contribute to translation efforts if desired.

Packaging and Distribution

• Assist in building and testing packages for various distributions (including AliveOS, Arch, Debian, Ubuntu, etc.).
• Ensure that the fork integrates cleanly with AliveOS’s custom repository and package management workflow.

Getting Started

If you are interested in contributing, please:

1. Fork the repository (to be announced) on GitHub.
2. Clone your fork and review the contributing guidelines (to be provided).
3. Join the discussion in the AliveOS Forum or open an issue on the repository to introduce yourself and share your interests.
4. Look for issues tagged help-wanted or good-first-issue to begin contributing.

We especially welcome those with experience in Cinnamon development, GTK/GNOME libraries, X11/Xlibre programming, desktop compositing, or packaging for Linux distributions.

Why This Matters

A stable, modern X11-capable desktop environment is essential for:

• Users with older GPUs or drivers that lack full Wayland support.
• Environments requiring remote display solutions (e.g., VNC, RDP, X11 forwarding) that are mature and well-understood under X11.
• Workflows dependent on specific X11 extensions or proprietary software that assumes an X11 server.
• Users who value the stability, predictability, and long-term support of a well-established display stack.

By maintaining a compatible Cinnamon fork, we aim to provide a sustainable path forward for those who wish to continue using X11 without sacrificing access to a modern, polished desktop experience.

Conclusion

The future of the Linux desktop need not be a binary choice between abandoning X11 or stagnating. With community effort, we can preserve a viable, high-performance X11-based desktop that evolves alongside the broader ecosystem. If you believe in the importance of choice, stability, and user autonomy, we invite you to join us in building this future together.

Thank you for your consideration and potential support.

After me.

Scroll to the bottom of any post and you will find a comment section powered by Giscus. It uses GitHub Discussions as the backing store, which means a couple of things:

• To comment, you need a GitHub account. If you have one, great — sign in and post away. If you do not, signing up is free and takes about a minute.
• No tracking, no ads, no third-party databases. Your comment lives in the website’s Discussions section, fully visible and under your control.
• You get notified of replies through GitHub, the same as any discussion thread.

The system maps each post to a discussion thread automatically, so comments stay organised per article. First-time commenters on a given post will trigger the creation of a fresh thread — after that, it is just a conversation.

If you have spotted a typo, want to disagree with something I wrote, or just feel like saying hello — go ahead. The comment box is waiting at the bottom of this very page.

Forum is also available at /forum — it redirects to the project’s Discussions hub, where you can start broader topics.

What I was actually doing

Bug fixing and planning. The unglamorous stuff that does not make for a thrilling blog post but is absolutely necessary if you want a distribution that does not fall apart on first boot.

I have been working on AliveOS’s main applications — xconnect, Dory, and the rest of the gang. Polishing. Refactoring. Asking myself hard questions about whether each piece actually earns its place. The usual.

This is the part of open source that nobody talks about in their README: the long, boring slog between releases where you stare at a log file for an hour, change three lines of code, and call it progress. Glamour.

The summer problem

Here is the thing about balancing a project like this with real life: it is hard. Summer makes it harder. There is family, there is work, there is the endless tug-of-war between “I should fix that bug” and “I should go outside before I turn into a pale hermit with excellent git hygiene.”

I am trying to catch up with the existing work-life-family balance, and it is, shall we say, a work in progress. The project moves forward, but not at the breakneck pace one might hope for. Steady is the word. Like a glacier, if glaciers wrote code and occasionally forgot to eat lunch.

The focus shift

Now, the part that actually matters.

When I first started AliveOS, I talked a lot about a developer-optimized environment. That was the framing, and it was honest as far as it went. But the more I worked on it, the more I realized the label was too narrow, and frankly, a bit misleading.

The real goal of AliveOS was never about catering exclusively to developers. The real goal is something broader and, I think, more interesting: a fast-paced workflow that targets general (and development) desktop usage, fusing keyboard and mouse driven paradigms. Essentially, what Cinnamon can already do — but refined, tuned, and integrated so it stops being a collection of features and starts being a flow.

A desktop where you never have to lift your hands from the keyboard unless you want to. But also a desktop where the mouse is not an afterthought, and where every action has a path — keyboard, mouse, or a combination of both, and you pick whichever is faster for the task at hand.

This is not about being a “developer distribution.” This is about being a fast desktop for anyone who cares about speed, regardless of whether they write code, edit video, or just manage five hundred open browser tabs like a civilized lunatic.

Design DNA: borrowing from COSMIC and Unity

You might look at the direction and wonder where the visual and interaction ideas come from. I will be honest about that, too.

The design of AliveOS intentionally fuses concepts from two sources that, on paper, should not have much to do with each other: System76’s COSMIC and Ubuntu’s Unity.

From COSMIC, I take primarily the look — its clean, focused, no-nonsense visual language. The attention to consistent spacing and typography, the feeling that somebody actually thought about where every pixel goes — that is the kind of polish I want, without importing the whole COSMIC shell.

From Unity, I take the layout and window manager tricks — the keyboard-and-mouse fusion that was ahead of its time and still, in my opinion, unmatched for workflow density. The global menu, the way Unity let you drive the entire desktop from the keyboard without forcing you into a tiling window manager straight out of a 1990s hacker movie. Unity understood something that many modern desktops forgot: you do not need to choose between keyboard and mouse. You use both, fluidly, and the desktop should keep up.

AliveOS is not a clone of either. It is an attempt to take the best lessons from both — COSMIC’s visual language and Unity’s layout philosophy — and fuse them into something that runs on Cinnamon’s solid, resource-conscious foundation. Borrowing good ideas is not cheating. It is standing on the shoulders of giants who got it mostly right.

Why “developer-focused” was the initial frame

Good question. The answer is boring and honest: because that is the lens I was looking through at the time.

I am a developer. I was building what I knew I needed. The developer focus was a natural starting point — it reflected the person building it, not the audience it was meant for. The mistake was assuming that “what I need” and “what the distro should be about” were the same thing. They are not quite the same.

The truth is that a fast, keyboard-driven workflow with sensible defaults and no bloat is useful for everyone, not just people who run gcc for a living. The developer angle was a useful initial sketch. But the real painting is broader. It is a general-purpose desktop that happens to be excellent for development — rather than a development desktop that happens to function for other things. The order matters.

Where we are heading

So, the direction is not changing drastically. It is clarifying. Fewer “for developers” labels, more “this is fast and you will feel it” reality. The same core philosophy (zero bloat, sensible defaults, Cinnamon’s sweet spot) just with a more honest description of what we are actually trying to achieve.

More news as things land. After me.

Here is what has been happening.

Dory File Manager: Still Getting Sharper

Dory, the file manager, continues to mature. It was one of the first pieces built specifically for this project, and it remains the one I reach for most often. The core is solid, the companion extensions are filling in nicely, and the occasional bug fix lands when something behaves in a way that is technically correct but practically annoying.

The philosophy behind Dory has not changed: do the file management things well, skip the things nobody actually uses, and do not ship a 400-megabyte dependency tree to open a folder. If it sounds simple, that is because it is. Getting it right, however, is a different conversation entirely.

Valuate: Because Numbers Need a Home Too

Meet Valuate — the new calculator app for AliveOS. It started as a “wouldn’t it be nice” and ended up as a “why does this not exist yet.”

Most Linux calculator apps fall into one of two categories: the one that comes with your desktop environment and does barely enough, or the one that tries to be a full-blown computer algebra system and weighs about as much. Valuate sits squarely in the middle: a clean, fast, GTK3-native calculator that does the math you actually need without making you feel like you need a PhD to use it.

It is early days, but it works, and it does not pull in half of GNOME to do it. More on this one soon.

A Custom Cinnamon Session

The desktop is getting its own session. Not a full fork of Cinnamon — let us not be dramatic — but a custom session that wraps the pieces AliveOS cares about into a coherent, predictable experience.

This means a tailored default configuration, sensible keybindings that do not require a cheat sheet, and a panel layout that stays out of your way while remaining exactly where you expect it. Think of it as Cinnamon with the rough edges sanded off and the bits you never use quietly removed. The kind of desktop that disappears while you work, which is the highest compliment a desktop can receive.

The Website

You are reading this, so clearly the website works. aliveos.org is live, served over HTTPS, with a landing page that lays out the manifesto and a news section where these updates go. It is built with Jekyll, deployed via GitHub Pages, and costs exactly nothing to run. Which is how a website should be.

The RSS feed is there for the three people who still use RSS feeds (you have excellent taste, by the way). The contact address for sponsorship and business inquiries is in the footer. The whole thing is clean, fast, and does not phone home to seventeen analytics trackers. Because it is a website, not a surveillance apparatus.

Bug Fixes and Testing: The Glamorous Part

Let us be honest about something: most of the work that happens at this stage is not the kind that makes for exciting blog posts. It is the kind where you spend three hours tracking down why a particular font renders strangely on one specific monitor, or why the file picker opens two pixels to the left of where it should, or why a certain package conflicts with another package in a way that only manifests on Tuesdays.

This is the unglamorous grind that separates a distribution that works from a distribution that feels right. AliveOS is firmly in the “feels right” camp, and that means a lot of small, invisible fixes that nobody will ever notice because they will just work. Which is the point.

XConnect: Your Phone, Actually Connected

This is the big one. XConnect is AliveOS’s answer to Android desktop connectivity — a full-featured suite that covers almost everything KDE Connect does, but built on XApp/GTK3 to fit naturally into the AliveOS desktop.

What does it do? The usual useful things:

• Notification syncing — your phone’s notifications, on your desktop, where you can actually read them without picking up the device.
• File transfer — drag, drop, done. No cloud services, no email yourself the file like it is 2009.
• Clipboard sharing — copy on the phone, paste on the desktop. Or the other way around. The future is bidirectional.
• Media control — pause, play, skip from your desktop while your phone streams music. Because reaching for your phone to skip a track is a civilisation-level inconvenience.
• SMS messaging — read and reply to texts from the desktop. Yes, it still works, and no, it does not require sending your messages through a third-party server.
• Remote input — use your phone as a touchpad or keyboard. Handy for presentations, couch computing, or when the cat is sitting on your keyboard and you cannot be bothered to move her.

The key difference from KDE Connect is the toolkit dependency. XConnect depends on XApp and GTK3, which means it integrates cleanly with the Cinnamon desktop and the broader XApp ecosystem without dragging in Qt libraries or additional framework dependencies. It is native, it is light, and it belongs here.

This one is still under active development, but it is far enough along to talk about. Expect a dedicated post when the feature set stabilises.

The Custom Repository

None of this matters if you cannot actually install it. The aliveos-repo custom pacman repository is the plumbing that ties everything together. It compiles and hosts stable builds of AUR and local packages, and it does so automatically — a GitHub Actions pipeline pulls, normalises, compiles, assembles, and deploys on a weekly schedule.

The repository already covers Dory and its extensions, the Cinnamon repackaging, the XLibre display server stack, AliveOS core packages, themes, and a growing collection of utilities. If you are running Arch, you can point pacman at it right now. If you are running AliveOS, it is already there.

Where Things Stand

The pieces are gathering. Some are polished, some are rough, some are still being hammered into shape on a Friday evening with questionable coffee. The target for v0.1 remains Q3 2026, and the path to get there is clearer every week.

The important thing is that every piece here exists for a reason. Not because it was popular, not because someone else shipped it, but because it solves a specific problem in a way that fits the rest of the system. That is what a curated distribution looks like. Not a bigger pile of packages — a coherent one.

More updates as pieces land.

The something that was missing

So, there I was, on Cinnamon, doing my thing. Happy-ish. And then I needed to pick a file. The dialog that popped up was, to put it kindly, not on par with Dolphin’s. Dolphin gives you a rich picker: zoom in, zoom out, switch view modes, a whole bag of options at your fingertips. The XApp desktop portal that Cinnamon relied on for this duty was, by comparison, spartan. Functional, sure. Pleasant to use, absolutely not. A relic. A thing that felt like it time-traveled here from 2008 and was mildly proud of it.

And when you spend your day opening and saving files, that gap is not cosmetic. It is a real, daily, morale-eroding annoyance. The kind you ignore for a year and then one day you snap.

A PR, with help from an unlikely collaborator

I wanted the functionality badly enough to do something about it. Stubbornness is an underrated engineering virtue. So, with the help of AI — yes, the very thing everyone is either worshipping or panicking about this year — I put together a pull request against Nemo’s upstream source repository. The changes were real: zoomable, configurable, closer to the picker I actually wanted to use. Written. Shipped. Not just a rant on an issue tracker.

And then it got rejected.

“We can’t push this to other distributions”

The reasons given were, shall we say, vague. The gist: they couldn’t push Nemo changes onto other distributions that currently depend on XApp. Which is the sort of rejection that sounds reasonable until you think about it for roughly thirty seconds — because for file picking, you can comfortably use the XApp desktop portal independently from the file manager itself. The two are not coupled the way the objection implied. Not even close.

That rejection sat with me. I had the change. I had the use case. I had nowhere to put it upstream. Ipso facto, I was grumpy.

The detour through KDE

So I did what any stubborn person does: I went somewhere I could have it. I migrated to KDE and worked on it for a month, moving away from Cinnamon — a desktop I had been using for the better part of a decade. Now, KDE is genuinely good. I like KDE. I will get to that. But then came the small matter of KDE dropping X11 for Wayland.

And there was the catch. I have a really old laptop. I am not changing to Wayland anytime soon. “Modern” does not impress me when it stops working on my hardware. And for me, XLibre looks like the more promising path forward on this venerable old box.

So I came back. And this time, rather than asking permission from anyone, I decided to put together a few pieces I find useful and straightforward. A desktop that finally has the picker I want, on a base I trust.

Why not just bolt on a few apps?

Ah, the obvious question. It would be easy, in theory, to just layer a few programs from other projects on top. Grab gnome-calculator here, something else there. Job done, innit.

No. The problem is twofold. One, these bring external dependencies that add bloat. Two, they look inconsistent with the rest of the system — like you parked a Fiat in the middle of a BMW lot and pretended nobody would notice. Two small things that, together, defeat the point of running a coherent desktop in the first place.

The sweet spot

Now, here is a thing I have learned over many years. I value the balance between three things: aesthetics, functionality, and resource usage. Most desktops pick one and sacrifice the other two. For me, Cinnamon sits exactly on top of that sweet spot. That is why I have been using it for almost ten years. Which, in Linux desktop years, is roughly three geological epochs.

Before that, I was a GNOME user. I have also used KDE. And the honest truth is: I like all of them. Every desktop environment and window manager has its pros and cons, and I genuinely appreciate each one for different reasons. Heresy, I know. A grumpy dinosaur is supposed to pick a side and hate the rest. Sorry to disappoint.

AliveOS is not a rejection of anything. It is a curation — the specific pieces, tuned to work together, on a base I trust, built around a picker that finally does what I want it to. After me.

Because “you can” is not the same as “you should have to”

Sure, an experienced user can set everything up themselves. They can also build their own desk, but most people just want somewhere to put a laptop and get to work. The point is not whether the setup is survivable — it is whether it should eat your evening before you write a single line of code.

AliveOS lands you in a coherent, working environment from the first boot. Built on Arch’s rolling base, you get the bleeding edge the way nature intended: delivered fast, without the wiki-archaeology and the “why is my audio sideways now” tax.

Tools that actually know each other

Customization is not the same as integration. Any desktop can be themed; far fewer ship tools that were designed to work together out of the box.

Take Dory’s file picker dialog. It sounds small. It is not. When an application asks you to pick a file, the dialog it shows is part of the desktop — and when that dialog is fast, native, and does not feel like it time-traveled here from 2008, finding files stops being a friction point. Multiply that kind of decision across the desktop, the media player, the developer toolchain, the defaults — and you stop fighting the setup and start working inside it.

The small daily annoyances compound. We are trying to remove them.

Made by a developer who got tired of waiting

AliveOS is not assembled from generic upstream packages and shipped. It is built by a developer who works with current tools, watches where the ecosystem is heading, and got tired of “good enough” defaults that were never good enough. The goal: something that stands out — not by piling on more, but by sweating the details the rest leave to the user.

There is a legacy forming around the project that is worth naming plainly: consistency, and actual care for the user experience. Defaults that agree with each other. A coherent desktop, not a loose collection of components that met once at a packaging step. An environment that feels like one thing, not twelve — because somebody stayed up late making it so.

So, who is it for?

For the developer who could hand-tune everything, and would rather spend that energy on something that is not their operating system. For anyone who wants the currency of Arch without the configuration hangover. And for the sort of user who has noticed that most distributions optimize for breadth of options, when what you actually wanted was a polished, opinionated default that is ready the moment you sit down.

Here is why.

Built-in Ad and Tracker Blocking

Vivaldi ships with a native ad blocker and tracker blocker enabled out of the box. No extensions needed, no configuration required. This means pages load faster, less bandwidth is consumed, and your browsing habits are not sold to the highest bidder. For a developer-focused distribution that values system efficiency, this aligns perfectly with our zero-bloat philosophy.

Chrome Extension Compatible

Vivaldi is built on Chromium and supports the full Chrome Web Store extension ecosystem. Every extension you rely on for development, security, or productivity works as expected. There is no walled garden and no compatibility gap to work around.

Built-in Mail Client

Vivaldi includes a full-featured mail client that supports multiple accounts, IMAP and POP3, search across folders, and a unified inbox. For developers who manage several email identities, this eliminates the need for a separate email application and keeps everything in one place.

Built-in Calendar and Feed Reader

Alongside mail, Vivaldi provides a private calendar for managing events and an algorithm-free feed reader for building a custom news feed based on your actual interests, not your behavioral profile.

Privacy by Design, Not by Feature

Vivaldi does not track you. There is no telemetry, no profiling, no data mining. Sync data is encrypted end-to-end, meaning even Vivaldi cannot read your bookmarks, passwords, or open tabs. The company is independent, European, and answerable only to its users, not to advertisers or investors.

Unmatched Customization

Vivaldi is the most customizable browser on the market. Developers can tailor every aspect of the interface to match their workflow:

• Workspaces to separate projects, research, and personal browsing
• Tab Stacking and Tab Tiling for side-by-side page views
• Web Panels to keep chat apps, documentation, or dev tools in the sidebar
• Quick Commands for keyboard-driven navigation
• Custom keyboard shortcuts and mouse gestures for efficiency

Built-in Productivity Tools

Vivaldi ships with tools that replace entire categories of extensions:

• Notes for jotting down ideas while browsing, synced across devices
• Capture for full-page screenshots without third-party tools
• Pop-out Video to watch tutorials or streams in a floating window while you code
• Translate for one-click page translation, processed locally for privacy

Cross-Platform Sync

Vivaldi Sync works across desktop and mobile with end-to-end encryption. Your browsing data moves with you securely, whether you are on your AliveOS workstation, a laptop, or a phone.

At the end of the day, Vivaldi respects the same principles AliveOS was built on: give the user control, avoid bloat, prioritize privacy, and never compromise on the tools that matter. It is not the default because it is popular. It is the default because it is the right tool for the job.

AI is coming to AliveOS — but strictly on your terms.

Opt-in, never default

AI features will be entirely opt-in. A fresh AliveOS install does not run any model, phone home, or reserve resources for AI workloads. If you want the capabilities, you turn them on; if you do not, they are simply not there. This keeps the base system clean and predictable, in line with our zero-bloat philosophy.

Local models only

Everything runs on your own hardware. AliveOS ships integrations for running models locally — no cloud backend, no managed endpoint, no third-party inference server. The model, the prompt, and the response all live and stay on your machine.

No calls leave the system

This is the part we want to be explicit about, because it is where most privacy-minded users get (rightly) nervous:

• Zero outbound AI traffic. No API keys, no telemetry, no “send prompt to provider” requests — ever.
• Your data never leaves the machine. Documents you summarize, code you ask for help with, conversations you have: none of it is transmitted anywhere.
• Verifiable by design. Because inference is local, you can confirm this yourself with standard network tooling; there is no hidden remote dependency to audit around.

If you are offline, the features keep working. If you are air-gapped, they keep working. Privacy and security are not a setting you have to trust us on — they are a consequence of the architecture.

What to expect

We are still shaping the exact surface area — which local runtime, which default models, and how it integrates with the desktop and the developer toolchain. The goal is a useful, no-compromises on-device AI experience that fits the rest of AliveOS: lightweight, developer-friendly, and out of the way unless you ask for it.

More details as the pieces come together.