For years I thought I had strong opinions on Linux distros. Ubuntu was too heavy or it felt. Arch was too fiddly. Kali was surprisingly practical (don't judge me).

Looking back at nearly a decade of distro hopping, I realize I had the whole thing wrong.

It was never really about the distro. It was about what desktop environment sat on top of it.

My Linux story starts with Mint

The first Linux distribution I ever installed was Linux Mint Cinnamon, around 2017. Linux Mint is what made me think Linux was actually livable. The desktop made sense. Things were where I expected them to be. It was Ubuntu underneath, sure, but that's almost beside the point; what mattered was that the experience felt considered.

I didn't move to Ubuntu until 2019. I ran it for about six months. Then I left.

The reason I told myself at the time was that Ubuntu felt slow on my hardware. I had an i3 first-gen Intel machine. Ubuntu felt sluggish in ways that bothered me. I blamed Ubuntu.

Here's what I discovered later: the culprit wasn't Ubuntu. It was GNOME.

GNOME is a beautiful desktop. I'll give it that. But on modest hardware, it feels less responsive, and even at times, it completely freezes. It shows up in the half-second delays, the slightly-too-late window redraws, and the sense that the machine is working harder than it should be.

XFCE saved my Linux life

The thing that actually kept me on Linux, the desktop environment I kept coming back to, is XFCE.

XFCE doesn't win "most beautiful desktop" polls. But I ran it on that i3 first-gen machine, and it ran smoothly out of the box. I ran it on a Core 2 Duo at some point.

Internet browsing, YouTube, writing articles, Django, and Python development, all of it, without considerable delay. XFCE in that sweet spot between functional and fast is something I haven't found matched elsewhere for low-resource machines.

I did try KDE. More than once, actually, I wanted to like it. I kept going back, hoping something had changed. What I found, every single time, was that a single click could take three to four seconds to get a response. It felt like the desktop was thinking about whether it wanted to comply with my input.

Even recently, a few weeks ago, I tried both CachyOS and EndeavourOS as live USB sessions in a VM, and both now default to KDE. I still felt it. That sluggishness hasn't gone away for me, and I've stopped trying to convince myself otherwise. XFCE remains my benchmark for a desktop that gets out of your way.

My Kali Linux Journey

After six months on Ubuntu, I switched to Kali Linux. And not for the reason you might think.

I had not suddenly become a penetration tester. I didn't have a burning interest in cybersecurity. I switched because Kali ran better on my hardware than Ubuntu did and because I was already comfortable with APT commands from my Mint and Ubuntu days, so the transition cost was essentially zero. I had access to the same package manager, familiar commands, and a lighter desktop.

I chose a distribution built for security professionals over the supposed beginner-friendly option. I chose not because of anything Kali offered that I needed, but because Ubuntu had made itself too heavy for the machine I owned.

The Arch Linux rabbit hole

By mid-2021, I'd been reading about Arch Linux mainly through all the BTW memes. The idea of an "expert's distro" appealed to me.

So I stayed up one night and tried to install plain Arch. I did not finish the installation.

What struck me was running commands to create partition tables and configure Wi-Fi. It was baffling. Not "this is hard, but I'll figure it out." More like: why has someone decided that an operating system installer should work like this?

I tried Fedora after. Then I tried Debian. In both cases, on my ageing hardware, boot times were bad enough that I found myself questioning whether the whole exercise was worth it. With Debian, I faced an internet connectivity issue as well.

The thing that drew me to Arch was Pacman and leanness. I kept asking myself: why can't the installation be as simple as Ubuntu's, but give me the system I actually want?

That's when I found EndeavourOS. It required no manual commands to connect to Wi-Fi. No writing partition tables by hand. Just select a disk, set your timezone, keyboard layout, and hostname, and you're done.

And when I booted in for the first time, I found the default looks fascinating. The default terminal: black background, blue accents, immediately distinctive. The default wallpaper was something I actually liked enough not to replace it, which almost never happens.

I used EndeavourOS for four-five years, I think.

What those "Arch" years looked like

I want to be honest about this stretch, because people who recommend Arch-based systems sometimes skip over the rough parts.

I hit the initramfs wall three or four times. That's the experience of booting your machine and being dropped into a minimal emergency shell with no desktop, no obvious path forward, just a blinking cursor.

The first time it happened, I didn't know recovery was possible. I reinstalled the entire system. Only later did I learn to boot from a live EndeavourOS USB, use arch-chroot to get inside the broken system, and rebuild the kernel from there. The culprit was usually a problematic package upgrade.

I also ran into keyring mismatches more than once, that particular class of Arch-ecosystem errors where package signatures don't line up, and installations fail with cryptic messages. The fix I settled on:

sudo pacman -Syu archlinux-keyring endeavouros-keyring

I'm sharing them because this is the actual texture of running an Arch-based system. It's manageable. I managed it. But a beginner who hits the initramfs wall on their third week of Linux use is probably not going to calmly research arch-chroot. They're going to conclude that Linux is unstable, and they were right not to trust it.

AntiX chapter and the limits of anti-systemd

Around mid-2024, I discovered AntiX Linux and ran it alongside EndeavourOS for roughly two years. It taught me a lot about IceWM as a window manager. For someone with a potato-tier hardware, old machines that most distributions have quietly given up on, AntiX is remarkable.

But I hit the systemd wall eventually. AntiX deliberately avoids systemd, which is philosophically interesting but practically limiting. A growing range of applications that assume systemd exists simply don't work cleanly. And I'll be honest: the AntiX GUI is not appealing. It's functional, and it works. But there's a visual coarseness to it.

After two years, I started thinking about moving on.

Returning to Kali for real this time

Now I'm back on Kali, but the circumstances are completely different. I really have an interest in cybersecurity, particularly bug bounty work. I'm running a Dell laptop with an i5 8th gen and 12GB of RAM now.

Two months in, I've had one issue worth documenting. Kali ships Firefox ESR, and if you want to remove it, the system objects, because Firefox ESR is part of the kali-xfce4 metapackage, and removing it wants to take other things with it.

The workaround I found: install the equivs package, use it to create a dummy Debian package with the same name as the dependency you want to satisfy, install that dummy, and the system believes the dependency is met. It's inelegant, but functional.

Where I am now: leaving XFCE for window managers

A lot is happening in the Linux desktop world around Wayland, Hyprland, and tiling window managers. The thing that excites me about this space, and I've come to believe this more firmly the longer I've used Linux, is the plain-text configuration model.

Your entire environment lives in text files you can read, version-control, back up, and restore. That's a kind of ownership over your system that no GUI settings panel can replicate.

I spent this past couple of months trying several options: Niri, Sway, and Scroll WM. I eventually settled on Mango WM as my main environment. I know, calling it a desktop environment feels technically wrong, but it's what I live in. The configuration philosophy suits how I think about my system.

That means I'm saying goodbye to XFCE after years of loyalty. Not because XFCE failed me, but because I've moved somewhere new.

Desktop environment, not distro

Looking back at all of it, I did not like Mint just because it's Mint. I felt comfortable with Cinnamon. I did not dislike Ubuntu because it's Ubuntu. It's because GNOME demanded more of my old hardware than the hardware could give.

Every distro-hop I've listed here, from Kali to Arch to AntiX to Mango WM, was really a hop between desktop environments and window managers wearing a different distro's name. The package manager changed. The installation experience changed.

What actually decided whether I stayed or left was always what sat on top: how fast it responded, how much RAM it wanted, whether I could read its configuration in a text file, how it felt to use.

The desktop environment mattered more than the distro.

If you're picking your first Linux setup, this is the question worth asking before you pick a distro: what desktop environment does it ship, and does that match your hardware and your preference?

Running local AI models has become surprisingly accessible. Install Ollama, pull a model, and you can start chatting with it in minutes. That's exactly how I began my journey with local AI.

Using an LLM directly in terminal is okayish but it limits your ability. That's why there are so many frontends available for Ollama, providing you with a graphical, chatGPT-like interface. This way, you can easily revisit an earlier answer, copy code snippets, or have an extended discussion with a model.

Of the so many GUIs, Open WebUI is like the de facto Ollama front-end. I don't know about you but I find it difficult to set up.

I also looked at options like LibreChat, AnythingLLM, and LobeChat. They all felt geared toward users who wanted an all-in-one AI platform rather than a lightweight companion for a local Ollama UI.

This is the 'problem' that I think OrionChat solves...by its simplicity.

OrionChat: Web-based chat interface for Local LLMs

OrionChat is a free, open-source, web-based chat interface. It isn't built exclusively for Ollama. Instead, it can also talk to OpenAI, Google Gemini, Claude, Groq, Cerebras, and a few other providers.

But for this piece, I only care about one thing: how well it works as a front end for models running locally through Ollama.

It doesn't attempt to become an entire AI platform, no automation, agents, scheduled tasks. Instead, it provides a clean chat interface, model selection, and a responsive interface.

Once the models are downloaded, OrionChat simply detects them. I particularly liked this design because it doesn't introduce another layer of model management.

Installing OrionChat

Getting OrionChat running took me less than five minutes. There's no need to even run a Docker daemon.

Step 1: Clone the repository

Clone and move into the project folder.

git clone https://github.com/EliasPereirah/OrionChat.git
cd OrionChat

Step 2: Serve the files

Python makes this trivial if you already have it installed, which most Linux systems do:

python -m http.server

Step 3: Open OrionChat

Head to http://localhost:8000 in your browser. OrionChat's interface should load right away.

Letting Ollama talk to OrionChat

This is the part I actually got stuck on the first time. By default, Ollama only accepts requests from its own trusted origins, and a browser-based frontend like OrionChat doesn't automatically qualify. Every request gets silently blocked until you explicitly allow it.

Step 1: Check how you're running Ollama

If you installed Ollama via the official install script, it's almost certainly running as a systemd service. If you just launch it manually with ollama serve, skip to Step 3.

Step 2: Edit the Ollama service

You need to add the origin override to ollama.service systemd unit file.

sudo systemctl edit ollama.service

In the editor that opens, add this under the [Service] section:

[Service]
Environment="OLLAMA_ORIGINS=http://localhost"

Save, then reload and restart Ollama:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Step 3: Or, if you run Ollama manually

Skip the systemd steps entirely and just set the variable inline when you launch it:

OLLAMA_ORIGINS=http://localhost ollama serve

Step 4: Confirm it worked

Refresh the OrionChat tab in your browser. It should now connect to Ollama and start listing your locally installed models. You can choose your default Ollama model and start prompting.

It provides an option to upload files and to use the microphone with Ollama models. This is a really nice feature you can't use in CLI mode.

My wxperience running Ollama models with OrionChat

Want to go from Gemma to Qwen? A couple of clicks. Want to try Mistral instead? Select it and keep going. For someone who regularly experiments with different models, this alone is worth the five-minute setup.

Starting a conversation feels exactly like using any modern AI chatbot. Code blocks render properly. Markdown formatting looks clean. Tables show up as tables instead of a mess of pipe characters. Long conversations stay easy to navigate because everything lives in an actual interface instead of a scrolling terminal buffer.

Copying responses feels natural too, no highlighting text in a terminal and fighting with line wrapping. For anyone who asks a lot of questions to local LLMs, that alone noticeably improves the day-to-day experience.

Also, unlike other Ollama UI alternatives, OrionChat is not an Electron wrapper hiding a browser inside your app menu. It lives in a web browser ;)

Final Thoughts

Ollama already made running local models easy, and for quick tests, the terminal is perfectly adequate. But if you're talking to local models for hours every week, a proper interface makes a real difference.

OrionChat hits a sweet spot for me. It doesn't require a complicated deployment, and doesn't try to become an all-in-one AI platform. It focuses on doing one thing well: giving Ollama a pleasant place to live outside the terminal.

After using it for a while, I found myself opening OrionChat first and reaching for the CLI only when managing or updating models themselves.

If you've been relying purely on the Ollama CLI and occasionally wish it felt a bit more like ChatGPT, OrionChat is worth the five minutes it takes to try.

If OrionChat isn't quite your fit, Open WebUI, Enchanted, Chatbox, LibreChat, and NextChat are all solid alternative Ollama frontends, each trading off simplicity against features differently. Worth trying a couple to see which matches your workflow.

I already shared my experience with the Niri window manager in another post. Its scrollable workspace model is clever.

Then I stumbled across MangoWM, and I couldn't leave it alone because it offers a similar scrolling mode as compared to Niri, plus more, while still being simple to build from source code.

MangoWM is a Wayland compositor built on top of wlroots and heavily inspired by dwl (which itself draws from dwm).

On paper, it sounds like yet another minimal tiling compositor. But when I actually sat with it for a few days, something clicked. This is a guide to what I tried, what I discovered, and what made me stop going back to Niri.

What is MangoWM, anyway?

Before I get into the setup, let me introduce MangoWM.

MangoWM (sometimes referred to as "mango") is a Wayland compositor, meaning it replaces not just your window manager but the entire display server layer above the kernel. It handles input, rendering, compositing, and window management all in one relatively small binary.

It was created by a developer named DreamMaoMao, and it takes the "as lightweight as dwl, built in seconds" philosophy seriously, while tacking on a surprisingly complete feature set: smooth animations, multiple layout modes, per-tag window rules, blur and shadow effects via scenefx, scratchpads, hot-reload config, and excellent XWayland compatibility for the legacy apps you can't avoid.

The tag system (borrowed from dwm) is worth understanding upfront. Instead of numbered workspaces that you switch between sequentially, tags are labels you assign to windows. A window can carry multiple tags at once, and you can view any combination of tags simultaneously. It's a different mental model, and once it clicks, going back to linear workspaces feels oddly constraining.

Installing MangoWM on your system

MangoWM comes as a pre-built package on Arch Linux, Fedora, and NixOS. If you're just trying Mango for the first time, I highly suggest running it on Arch Linux. It eases the overall installation with just a single command.

On Arch Linux (which includes Kali, Manjaro, and EndeavourOS users), the cleanest route is through the AUR. You need an AUR helper like yay or paru:

yay -Syu scenefx0.4
yay -Syu mangowm-git

This pulls the latest git build.

If you get classic Arch Linux error messaging saying, "a manual intervention is required," then it's likely you're missing -yu flag with AUR helper.

On Fedora, MangoWM lives in the Terra third-party repository:

sudo dnf install --nogpgcheck --repofrompath 'terra,https://repos.fyralabs.com/terra$releasever' terra-release
sudo dnf install mangowm

Launching Mango WM for the first time

You can start MangoWM straight from a TTY:

mango

If you're using a display manager like SDDM or GDM, MangoWM registers a desktop session entry during install, so it should appear as a session option at the login screen.

When you open Mango WM for the very first time, all you get is a blank screen. When you hit Alt+Enter(Return), foot,(the default terminal emulator) opens, and you can start configuring the window manager from there.

Getting a working config to start from

MangoWM reads the config from ~/.config/mango/config.conf. On a fresh install, the system-wide default lives at /etc/mango/config.conf. The first thing I did was copy it over:

mkdir -p ~/.config/mango
cp /etc/mango/config.conf ~/.config/mango/config.conf

If you want a more complete starting point with Waybar, Rofi, wallpaper setup, and all, the developer maintains an example config repo.

I tried the developer-provided config, but didn't find the shortcut intuitive to use. So I went ahead and wrote my own config file from scratch. Mango WM documentation really helped me to copy configuration snippets that I wanted to achieve, a keybinding similar to Sway and i3 setup.

git clone https://github.com/DreamMaoMao/mango-config.git ~/.config/mango

To make the developer-provider config work exactly as it is, you need to install additional dependencies:

yay -Syu rofi foot xdg-desktop-portal-wlr swaybg waybar wl-clip-persist cliphist wl-clipboard wlsunset xfce-polkit swaync pamixer wlr-dpms sway-audio-idle-inhibit-git swayidle dimland-git brightnessctl swayosd wlr-randr grim slurp satty swaylock-effects-git wlogout sox

I found this genuinely useful as a reference, even though I ended up rewriting most of it from scratch within a few sessions. Reading through someone else's complete config taught me what was possible much faster than the docs alone would have.

Here's my complete config in one file. The default configuration uses Alt+arrow keys instead of a Sway-like configuration of utilizing hjkl Vim-like workflow.

Learning the tag system

This is where MangoWM diverges most sharply from compositors like Sway, Hyprland, or Niri, all of which use the workspace model I'd been on for years.

In MangoWM, every window is assigned one or more tags (numbered 1–9 by default). You view tags rather than switch to workspaces. The keybindings to know:

The thing that surprised me: you can view multiple tags simultaneously by pressing Ctrl multiple numbers. Two related projects on different tags? Hold Ctrl and press both numbers. They merge into a single view.

I resisted this for about a day. Then I stopped resisting. There's something genuinely freeing about being able to pull in exactly the windows you want without reorganizing anything.

Switching between layouts

One of MangoWM's most practical features is per-tag layout switching. You're not locked into master-stack globally. For each tag, you can cycle through:

• Master-Stack: the standard big window on the left, stack on the right
• Scroller: windows scroll horizontally, similar to Niri's model (this one made me feel at home)
• Monocle: one maximised window at a time, others hidden
• Grid: even tiling across available space
• Deck: stacked cards, only the top one visible

The default keybind to cycle layouts is Super + N. I ended up assigning specific layouts to specific tags because my work context maps cleanly to them: a Monocle tag for focused writing, a Scroller tag for reference browsing, and a Master-Stack tag for terminal work.

I have bind Alt + s to get a similar scrollable model like Niri. Similarly, to switch to normal tiling, I have bind Alt + t. To cycle windows, I have bound Super + Shift +hjkl and Super + Shift + arrow keys.

This kind of per-context layout was something I kept wishing Niri had. Niri's scrollable workspace model is clever, but it's one model. MangoWM gives you a toolkit.

Setting up your bar, launcher, and wallpaper

MangoWM doesn't bundle these, so you have to bring your own. The recommended options from the official quick-start docs are:

• Status bar: Waybar, eww, AGS, Quickshell. I use Waybar all the way.
• Launcher: rofi, fuzzel, bemenu, wmenu. I prefer Fuzzel as an application launcher on Wayland.
• Wallpaper: You have these options: swww (awww) and swaybg. Btw, I use azote for setting up wallpaper. It offers the ability to set different wallpapers for different monitors and presents a nice gallery of wallpapers to choose from.
• Notifications: swaync, mako, dunst. I prefer fnott as my notification daemon on Wayland.

I was already running Waybar with a Tokyo Night theme on Niri, and I carried the whole config over with minimal changes. The IPC support in MangoWM means you can expose workspace (tag) state to Waybar properly. The example config in the developer's repo shows exactly how.

To autostart these tools, MangoWM's config has an exec-once directive (similar to Hyprland):

exec-once = waybar
exec-once = swww-daemon
exec-once = dunst

Within about an hour, I had a working bar and wallpaper. The whole setup felt familiar to anyone who's configured a wlroots-based compositor before.

Tuning the visual effects

This is where I spent more time than I expected. MangoWM ships with window effects powered by scenefx: blur, drop shadows, corner radius, and per-window opacity. These live in the [effects] section of the config:

[effects]
blur = true
blur_passes = 2
blur_strength = 4
corner_radius = 8
shadow = true
shadow_color = 0x44000000

The hot-reload support means you can adjust values and see changes without restarting anything. Just save the file. I found myself iterating on corner radius and shadow softness for an embarrassing amount of time.

Coming from Niri, which keeps visual effects minimal, this felt almost indulgent. But it also never felt slow. The scenefx rendering layer is efficient enough that I didn't notice a GPU performance difference on my i5 with integrated graphics.

Window rules and per-app behaviour

MangoWM supports window rules that let you control how specific applications open: which tag they land on, what layout they use, whether they float, and their starting dimensions.

A basic rule in the config looks like:

[[rules]]
match_app_id = "org.mozilla.firefox"
tag = 2
layout = "master-stack"

[[rules]]
match_app_id = "foot"
floating = false

[[rules]]
match_title = "Picture-in-Picture"
floating = true
size = [400, 225]
pin = true

The pin option keeps a floating window visible across all tags, useful for PiP video, a music player, or a floating terminal you want everywhere.

I set up rules for Firefox (always tag 2, master-stack), my terminal (tag 1, no floating), and a scratchpad terminal (floating, pinned). This level of control over window placement is something I missed badly whenever I used a compositor without it.

Should you try MangoWM?

If you're already on a tiling Wayland compositor and you're happy with it, the answer depends on what's missing.

MangoWM is worth trying if you want more layout flexibility than a single-model compositor gives you, if you like the dwm tag philosophy but want modern Wayland features alongside it, or if you want smooth animations and window effects without moving to a heavier compositor like Hyprland.

It's probably not the right choice if you want a point-and-click GUI configuration tool, if you're new to tiling window managers in general, or if your distro doesn't package it and you're not comfortable building from source.

For me, the combination of fast compilation, hot-reload config, per-tag layouts, and genuinely good XWayland support hit a set of itches I didn't fully know I had. I came in expecting to write a quick "I tried it" post and came out with a compositor I'm going to stay on.

No doubt, Niri is a good window manager. But I'm sticking with MangoWM for my daily use.

When I first heard about Niri, a Rust-powered, scrollable-tiling Wayland compositor with a supposedly different take on window management, I was both skeptical and intrigued.

But after a few weeks of daily driving it and pairing it with the excellent Dank Linux desktop suite, I have a lot to say.

What Exactly Is Niri?

Niri is not your typical tiling window manager. It describes itself as a "scrollable-tiling Wayland compositor," and that one word, scrollable changes everything.

Traditional tiling WMs like i3 or Sway divide your screen into a fixed grid. Every time you open a new window, all the existing ones get reshuffled and resized. If you have ever lost track of your editor because Firefox decided to squish it into a 200-pixel-wide column, you know exactly how jarring that can be.

Niri works differently. Windows are arranged in columns on an infinite horizontal strip that extends to the right. Opening a new window never causes existing windows to resize. You simply scroll sideways to bring other windows into view, much like flipping through pages on a tablet.

The project is inspired by PaperWM, a GNOME Shell extension that brings scrollable tiling to GNOME. The motivation behind writing a standalone compositor, rather than another GNOME extension, was to isolate workspaces per monitor properly. With Niri, each display has its own discrete set of workspaces that never bleed into one another.

And crucially, it is written entirely in Rust. Which could be a deciding point for some.

Installing Niri

Niri's availability varies across distributions. I found it packaged on Fedora, Arch Linux, and Ubuntu.

If you are on Ubuntu, you will need to install it from a custom PPA or build it from source.

On Ubuntu 25.10 and above, there is a PPA:

sudo add-apt-repository ppa:avengemedia/danklinux
sudo add-apt-repository ppa:avengemedia/dms
sudo apt install niri dms

On Fedora, installation is as simple as:

sudo dnf install niri

On Arch:

sudo pacman -Syu niri alacritty dms-shell-niri
systemctl --user add-wants niri.service dms

Once installed, you can get a first impression of Niri by simply running a command niri while staying in the current Gnome or XFCE session. Later, you can launch Niri from your display manager (login screen).

At first boot, you are greeted by a hotkey overlay, a quick cheat sheet of default keybindings that I found genuinely useful. If you prefer to skip it on subsequent launches, a single config line handles that.

To get a feel, you can start pressing Alt+T a couple of times. This will open multiple instances of your default terminal emulator, allowing you to navigate different windows by pressing Alt + arrow keys, the Alt+hl Vim binding, or using the mouse scroll button.

The Scrollable Tiling Experience

I discovered the real appeal of Niri only after I stopped trying to use it like a traditional tiling WM. This mental model shift is important.

Rather than dividing my screen into regions, I started thinking in terms of a horizontal timeline of work. On the left, my text editor. Scroll right a bit in the terminal. Further right, browser, documentation, another terminal. Each workspace is its own infinite strip, and each monitor has its own independent set of workspaces. It felt a lot like having a very wide desk that you can slide across.

In traditional tiling setups, every time I opened a new window, I would mentally recalculate where things had moved. In Niri, nothing moved. What was on the left stayed on the left. New things appeared to the right.

Window resizing is still possible. You can adjust column widths and toggle preset sizes with keybindings. Niri also supports floating windows, which can be toggled per window via a keybinding or set as default through window rules. I used floating windows for things like file manager dialogs and calculator apps that feel awkward in a tiled layout.

The workspaces are dynamic and arranged vertically (similar to GNOME's workspace model), while windows scroll horizontally within each workspace. It is a two-axis system, and I experienced it as surprisingly intuitive once the initial learning curve passed.

Configuration

Niri uses a KDL-based configuration file, typically located at ~/.config/niri/config.kdl. KDL is a document language similar in spirit to JSON or TOML but with a different syntax. I found it clean and readable, though it is not something every user will be familiar with right away.

The configuration is comprehensive. You can define:

• Keybindings for almost every action
• Window rules to set default sizes, floating state, or opacity per application
• Animations for window open/close, workspace switching, and scrolling
• Input settings for keyboard, touchpad, and mouse
• Output configuration for multi-monitor setups, including scale, mode, and position

There is dedicated documentation on configuration. It walks through the config format with clear examples. Hot-reloading the config works via niri msg action reload-config, which makes tweaking much less painful than the "restart and hope" workflow of some other WMs.

One area I noted needs third-party tools: bars, notification daemons, and app launchers are not included. Niri is strictly the compositor. You bring your own Waybar, your own mako or dunst, your own wofi or rofi-wayland.

For experienced users, that modularity is a feature. For newcomers, it can feel like a lot to wire up.

That is precisely where Dank Linux comes in.

Enter Dank Linux: Turning Niri Into a Complete Desktop

Setting up a full Niri desktop from scratch, including bar, launcher, notifications, and theming, can take hours of configuration. I discovered Dank Linux as a project that elegantly solves this problem.

Dank Linux is not a distribution. It is a modern desktop suite built primarily around Niri (with also support Hyprland, Sway, MangoWC, labwc, and Miracle WM). At its heart is DankMaterialShell (DMS), a complete desktop shell featuring dynamic theming, smooth animations, a spotlight-style launcher, a control center, a system monitor, and beautiful widgets.

Getting started is almost embarrassingly easy:

curl -fsSL https://install.danklinux.com | sh

That single command brings up an interactive installer that handles dependencies, sets up DMS, configures your chosen compositor (I selected Niri), and even lets you pick your preferred terminal from the list: Ghostty, Kitty, or Alacritty.

Step 1

At first glance, the Dank Linux installer will ask you to choose your favorite window manager. Currently, it provides you with two options, i.e., Niri and Hyprland. Of course, I'll go with Niri this time.

Step 2

Next, choose your default terminal emulator from the list.

Step 3

It will provide you with a dependency check if any additional necessary needs need to be installed. You can toggle your selection for installation with the Space key.

Step 4

Dank Linux installer will prompt for privilege escalation. I'll go with the sudo option.

Step 5

The installer will also prompt you to replace the existing Niri config.kdl file.

Step 6

Finally, after the setup is complete, you'll get to see the message saying "Your system is ready" and be provided with a couple of commands to view its logs.

Now, it's time to log out and log back into our new Dank Linux environment. You can even first test the whole setup while staying on the Gnome desktop environment.

I tried booting directly into Niri and got stuck on the black screen issue for a couple of days. The issue was that I had been testing it in a VM, and I first needed to enable 3D acceleration in the VM.

Make sure to set Listen type to None and tick the checkbox next to OpenGL in Display Spice options to enable 3D acceleration if you're using QEMU/KVM.

Also, you need to make changes to Video Virtio.

What DankMaterialShell Brings

After the installer finished, I experienced one of those rare moments where a Linux desktop setup just looks good out of the box. Here is what DMS provides:

Dynamic Material You Theming

Powered by matugenDMS extracts a colour palette directly from your wallpaper and applies Material Design 3 colour schemes across the entire desktop, including system applications. Switch your wallpaper, and the whole UI recolors itself. It supports automatic light/dark mode switching too, and I found the color transitions genuinely elegant.

Dank Dash

A sidebar dashboard that surfaces media controls, weather, a calendar, and system information at a glance. It is the kind of widget panel that looks like it belongs on a premium Chromebook, not a tiling WM.

Spotlight Launcher

An application launcher that supports filesystem search and is extensible through plugins. I discovered it launches apps noticeably faster than rofi on the same hardware.

Settings

Quick toggles for Wi-Fi, Bluetooth, night light, and other system settings. It mirrors the kind of control center you see in macOS or GNOME.

System Monitor (Dank GOP)

Real-time monitoring of CPU, memory, GPU, disk, and network is presented in a clean overlay that does not require opening a separate terminal window.

Dank Search (dsearch)

Though you need to install it manually, it's a blazingly fast filesystem search tool, available both from the launcher and as a standalone CLI. When using from the launcher, you can use / to begin file search.

Dank Greeter

A polished login screen (greetd greeter) that matches the rest of the DMS aesthetic, so the visual consistency starts from the moment you boot.

In case you're still getting the default gdm3 login screen or failed to install Greeted at the installation prompt, you can do so with the following command:

dms greeter install
sudo systemctl start greetd

The DMS documentation is well organized and covers compositor-specific setup, keybind configuration through IPC, theming, plugin development, and CLI usage. Running dms setup After installation, it generates starter configs for both Niri and your chosen terminal, and dms doctor runs a diagnostic if something goes wrong.

For Niri specifically, DMS integrates tightly, including IPC-based keybind hooks and compositor blur support. The Niri community maintains a Discord server, and DankMaterialShell has its own subsection there, which I found active and helpful.

In The End...

Niri's scrollable tiling approach solves real friction in the traditional tiling workflow. It gives you a compositor that is both memory-safe (It's Rust afterall) and impressively stable.

Paired with Dank Linux's DankMaterialShell, it becomes a complete, visually coherent desktop that can genuinely compete with mainstream desktop environments on aesthetics while leaving them far behind on efficiency.

Is it for everyone? Nah! If you are new to Linux desktops, the setup complexity (even with Dank Linux's one-liner) assumes some familiarity. But if you are a tiling WM user who has ever been frustrated by windows jumping around when you open something new, Niri is worth your afternoon or night, depending on whether you are a day or night person.

If you liked horizontal scrolling but don't want to go with Niri window manager and Dank Linux together, you can consider two actively maintained projects like Scroll (a fork of Sway enabling horizontal scrolling) and PaperWM, the GNOME Shell extension I mentioned in the beginning.

Enjoy the variety in the Linux desktop offering 😸

I may hate AI slop but I am not a AI hater. I have found decent use of the AI tools and I try to include these tools in my workflow wherever it makes sense.

While mainstream LLMs like ChatGPT and Perplexity have decent free offering, they leach on the user data. "If you are not paying for the product, you are the product".

That's why I am loving the idea of exploring local AI and I have spend my fair share of time experimenting with LLMs that can be run on normal systems.

Recently, I discovered Jan AI. It is a polished, genuinely usable desktop app that runs entirely on my machine. In fact, I once tried replacing Ollama and llama cpp with Jan AI, but later changed my mind.

I'll explain why I switched back to Ollama in the later sections. First, let's learn about Jan AI.

What is Jan AI?

Jan is a free and open-source desktop application that lets you run various large language models directly on your own hardware. You can think of it as a self-hosted, offline-capable ChatGPT, except the model runs on your CPU or GPU, and no data ever leaves your machine.

The project is developed by the Jan.ai company, and the source code is available on GitHub under the AGPL-3.0 license. It's built on top of llama.cpp under the hood, which means it can run quantized GGUF models efficiently even without a dedicated GPU.

What I found impressive is that Jan's desktop application is built using the Tauri framework instead of Electron JS, which gives it a good performance boost and I think eats less RAM, too.

A quick catch, you still need plenty of RAM for running your local LLM.

The app supports Linux, macOS, and Windows. I used it on my Linux machine.

System requirements

Running a local LLM with Jan AI does require decent hardware. Here's what to realistically expect:

• 8 GB RAM minimum. It's enough for 7B parameter models at 4-bit quantization (Q4_K_M). You'll notice slowdowns with other applications open. 16 GB RAM is the sweet spot. It can comfortably run 7B models and lets you experiment with 13B models.
• GPU acceleration is optional but makes a big difference. Jan supports NVIDIA (via CUDA), AMD (via ROCm), and Intel Arc. If you don't have a compatible GPU, CPU-only mode works, but it's significantly slower.
• Disk space models range from around 4 GB (7B, Q4) to 8 GB+ (13B). Download only what you need.

Installing Jan AI on Linux

Jan offers multiple installation formats, including .deb and AppImage, but the AppImage is what I'd recommend for most Linux users. It's a single self-contained file that runs on virtually any distro without touching your system packages or requiring root privileges for the app itself. It requires no dependency hell. It's just made to work.

I am not going in the details but if you need help, refer to this guide to use AppImage on Linux.

When you run Jan AI for the first time, you should see an interface like this:

Downloading models and putting Jan to work

A freshly installed Jan is essentially an empty shell capable, but waiting. The first thing you need to do is grab a model. Think of it like the app is the frame and the model is the brain.

Finding your way to the model hub

Click the Hub in the left sidebar. This is Jan's built-in model library, a curated list of open-source models you can download with a single click.

There are dozens of models with names full of numbers and letters like Q4_K_M or IQ3_XS.

Before I recommend which ones to pick, let me quickly demystify that alphabet soup because I spent an embarrassing amount of time confused by it when I first started.

What does Q4_K_M actually mean?

Every model name carries a quantization tag. Quantization is how a model's original full-precision weights get compressed to fit on consumer hardware. Here's a practical breakdown:

• Q4: 4-bit quantization. The most common choice. Roughly 4 GB for a 7B model. Fast, memory-efficient, and quality holds up well for everyday tasks.
• Q8: 8-bit quantization. Nearly full quality, but needs about twice the RAM. Worth trying if you have 32 GB or more.
• K_M: The specific compression method (K-quants, medium variant). Generally, the best balance of speed and quality within the Q4 family.
• XS (Extra Small): This is the most aggressive compression. It results in a file size that is slightly smaller than a standard Q4_K_S

The 3 LLM models I tested

I am using an AMD laptop with an integrated GPU. I settled for CPU interference for local LLM models because enabling RoCm (Radeon Open Compute) is a hectic task, based on my research. It requires 25-30 GB of disk space.

For those of you who aren't familiar with what AMD ROCm is, it's the answer to NVIDIA's CUDA. Basically, when you run a local LLM, the heavy math, such as matrix multiplications across billions of parameters, can be offloaded to a GPU instead of the CPU.

RoCm lets software like Jan AI, PyTorch, or Llama.cpp talks to AMD Radeon GPUs to do that same heavy lifting. Without it, Jan falls back to CPU-only mode, which works but is significantly slower.

For this article, I settled on three models that cover a solid range of use cases. I asked the same question to each model - "What can you do"? Here's what I found:

Gemma 4

I don't lie. The performance wasn't superb, only 5 tokens per second.

Gemma 3

The performance was bad than the Gemma 4 2B model. It was only 3 tokens per second. I think you can use the Gemma 3 2B model variant to achieve comparable performance.

Jan

Yeah! Jan offers its own AI model. I used the Jan-v3-4b model to test. It comes with 262K context length. It can follow up instructions and do some light coding tasks.

Features I liked in Jan AI

Let's see a few features that I liked in this open source AI tool.

Unified Interface for Local and Cloud LLMs

Jan can act as a unified interface for local and cloud LLMs, instead of jumping from Claude to ChatGPT and then Gemini. You get to talk to your favorite LLMs within a single interface.

Though directly interacting with Cloud LLMs takes away your privacy, you can still use Jan AI as a unified interface to interact with any models on HuggingFace, Groq, Gemini, Qwen, Mistral, and Claude with the respective platform's API.

I'm especially in love with the Groq and Cerebras API. These platforms provide fast interference.

If your model provider is not in the list, you can still add OpenAI-compatible models to it.

To add, click on the plus icon next to "MODEL PROVIDERS". It'll ask for a name. Enter the name and then set the BASE_URL and API Key provided by your LLM platform.

Keeps your chats organized

Jan offers the functionality to organize chats per project.

Tailor Jan for Custom Experience

You can edit the system instruction. It's kind of making LLM behave like a specific expert.

Local API Server

It comes with a local API server. You can start the server by going to Settings -> Local API Server.

Use it as a tool to download AI models for Llama.cpp

Models downloaded with Jan AI application are completely compatible with Llama.cpp CLI. You can use Jan as a downloader tool and then run the downloaded AI model with llama-server a command.

Jan CLI

Jan offers a CLI interface to interact with as well.

My honest opinion on using Jan AI vs Ollama

Thanks to the developer involved in building the Jan AI app. It provides a nice GUI interface to interact with LLMs. On the contrary, I see some improvement scope for the application.

The major one is with the local LLM inference time. I tested the same model, and what I found was that Jan AI provided slow inference time as compared to Ollama on the same hardware. Ollama produced a response at a rate of 6.62 tokens/sec while Jan AI produced a response at around 5 tokens/sec.

On the second test, Ollama reported 7.35 tokens per second while Jan AI responded at 3 tokens per second. Also, I tried Llama.cpp for the same Gemma 5 E2B model with 3.97 tokens/sec.

The secondary issue is Jan application often freezes your system. I agree, running LLM models takes significant RAM memory, but there are a couple of attempts I faced where giving a prompt with the Gemma 4 E2B model freezes my system. I haven't faced any similar issue with Ollama. That's why I kept Ollama and Llama.cpp for my local AI model inference.

Who is Jan AI actually for?

After spending time with it, I'd say Jan AI fits a few kinds of people particularly well. One thing I need to justify here, although in my tests, Jan struggled to give me more than 5 tokens per second in CPU mode, running it on a system with modern GPUs like Radeon GPU, Intel Arc, Nvidia 4050, you may get to see a huge boost in performance, especially with tokens per second. You could achieve around 13-15 tokens per second.

Privacy-conscious users who want AI assistance without feeding their conversations to a corporation. Lawyers, journalists, healthcare workers, and anyone handling sensitive information fall into this category.

Developers who want a local AI backend for their tools. The OpenAI-compatible API makes it drop-in compatible with a surprising number of existing integrations.

Linux enthusiasts who simply prefer FOSS software and want to own their stack. The fact that it's AGPL-licensed and actively developed is a big plus.

People on a budget. It comes with no API costs or subscription. You run it on hardware you already own.

It's not for everyone. If you need GPT-4 level capability for complex reasoning tasks, you'll still feel the quality gap compared to frontier cloud models. But for writing assistance, summarization, brainstorming, and everyday tasks? A well-tuned 7B or 13B model gets the job done.

The bigger picture

Local AI is no longer a hobbyist experiment. The AI models like Gemma 4, Gemma 3, Granite, Jan AI model, and SmolLM2 have gotten small enough that a standard laptop can run something genuinely useful. Tools like Jan have made the setup approachable enough that you don't need to be a machine learning researcher to get started.

Jan AI won't replace cloud services for everyone. But for a growing number of Linux users who care about privacy, cost, and control, it's become a daily-use tool. I'd encourage you to try it. Download it, grab a 7B model, and see how far it gets you.