DEV Community: Abdullah Musa

Running Chrome OS Flex on VM

Abdullah Musa — Wed, 01 Apr 2026 17:05:58 +0000

Chrome OS Flex is an incredibly lightweight operating system, especially designed to breathe new life into older hardware. Plus, its CloudReady feature is nothing short of impressive.

Now, I don’t have any aging hardware lying around, but I still wanted to give Chrome OS Flex a spin. The catch? Installing it would mean wiping an entire drive, something I wasn’t ready to do. So I thought, why not run it in a virtual machine?

There’s a twist, though: Google doesn’t officially support Chrome OS Flex in virtual environments. Unlike most operating systems that ship as a neat .iso file, Chrome OS Flex is distributed in a .bzip2 format. And even if you manage to extract it, you can’t just fire it up in a typical VM with a few clicks.

But I’ve been using QEMU/KVM for a while, and I know how powerful it can be. So I decided to put it to the test and see if I could get Chrome OS Flex running inside a VM with QEMU.

First Challenge: The Unusual Installation Image

After extracting Chrome OS Flex from its .bzip2 archive, I ended up with a raw .bin file, not the familiar .iso that most virtual machines expect.

I tried pointing my usual VM software to this .bin file, but it just wouldn’t boot. Most hypervisors are designed to boot from either a CD/DVD drive (ISO) or a USB device. A raw disk image like this doesn’t fit either category, at least not without some creative configuration.

So here I was: I had the right file, but no straightforward way to make the VM treat it as a bootable medium.

That’s where QEMU’s low‑level control became a game‑changer. QEMU doesn’t care whether your boot image is an ISO, a USB stick, or a raw disk dump. You can attach any file as a drive and tell QEMU to boot from it.

With the right command, I could make the VM treat chromeosflex.bin as if it were a physical USB drive, exactly what the installer expects. This was the key to loading Chrome OS Flex’s installation environment without any hacky workarounds.

In the next section, I’ll walk you through the exact QEMU command that made this possible.

Second Challenge: Crafting the Perfect QEMU Command

Once I understood that QEMU could treat the raw .bin file as a bootable drive, I needed to piece together the right command. After a lot of trial and error, this is what finally worked:

qemu-system-x86_64 -enable-kvm -smp 2 -m 8G -cpu host \
    -drive file="/mnt/sdc1/OSImages/ChromeOS/ChromeOSFlex Image/chromeos_16002.51.0_reven_recovery_stable-channel_mp-v6.bin",format=raw \
    -drive file=chromeos.qcow2,format=qcow2 \
    -display "gtk,gl=on,show-cursor=on" \
    -device virtio-vga-gl \
    -device usb-tablet -usb

Breaking this down:

-enable-kvm: This enables hardware acceleration using the Linux Kernel Virtual Machine. Without it, the VM would be painfully slow. KVM gives near‑native performance, which is essential for a responsive Chrome OS Flex experience.

-smp 2 -m 8G -cpu host: I allocated 2 CPU cores, 8 GB of RAM, and passed through the host CPU type. Chrome OS Flex expects decent resources, and this configuration avoids any artificial bottlenecks.

The two -drive options

The first attaches the extracted .bin file as a raw drive – this is the installer medium.

The second attaches the QCOW2 virtual disk where Chrome OS Flex will actually be installed.

-display "gtk,gl=on,show-cursor=on": This enables OpenGL acceleration for the display and shows the mouse cursor properly. It makes the VM window feel native.

-device virtio-vga-gl: This is the secret sauce. It provides a virtual GPU that supports OpenGL, effectively passing through graphics acceleration to the guest. Chrome OS Flex, like many modern OSes, relies on GPU capabilities. Without this, the installer might fail or the OS would be sluggish.

-device usb-tablet -usb: Enables USB support and adds a tablet device, which gives you smooth mouse movement without needing to grab/release the cursor.

Why These Flags Matter for Chrome OS Flex

Chrome OS Flex is picky about hardware. It expects a real machine with proper GPU support and acceleration. By combining KVM, the VirtIO GPU with OpenGL (virtio-vga-gl), and the GTK display with GL enabled, we’re effectively tricking the OS into thinking it’s running on bare metal. The installer proceeds without complaint, and the final system boots with full graphics acceleration.

In short, these flags aren’t just optional tweaks, they’re the core reason this setup works at all.

And I was In!

Once I ran that command, the Chrome OS Flex installer booted after a minute or two. I clicked Install Chrome OS Flex, let it wipe the virtual disk, and after a brief installation, the VM shut down. Removing the installer drive from the command and booting again from the QCOW2 image gave me a fully functional Chrome OS Flex environment.

If you’ve been struggling to virtualise Chrome OS Flex with other tools, give QEMU with these flags a try. The combination of KVM, GPU acceleration, and raw disk attachment makes all the difference.

Final Thoughts

Getting Chrome OS Flex to run in a virtual machine wasn’t straightforward – Google never intended it to be. But with QEMU/KVM and the right configuration, it’s absolutely possible. The combination of KVM acceleration, a properly configured VirtIO GPU, and treating the raw .bin as a bootable drive made all the difference.

If you’re curious about Chrome OS Flex but don’t want to commit hardware, I highly recommend giving this setup a try. For a complete, step‑by‑step walkthrough, including where to download the recovery image, detailed QEMU flags, and troubleshooting common pitfalls, check out my full guide here:
👉 Chrome OS Flex on QEMU
It covers everything you need to get up and running. Happy virtualizing!

Single GPU Passthrough on Linux: Running a VM Like It’s Bare Metal

Abdullah Musa — Wed, 25 Mar 2026 10:05:24 +0000

I used to believe that GPU passthrough required two graphics cards, one for the host, one for the VM. Turns out, that’s not the only way.

A few months ago, I stumbled into the world of single GPU passthrough, and it completely changed how I think about virtual machines.

Let me walk you through what it is, why I tried it, and what it taught me along the way.

Why Bother?

I’ve been using QEMU on Linux for a while, mostly for lightweight VMs. But even with decent specs, Windows in a VM always felt sluggish, until I started experimenting with hardware acceleration.

One day, after tweaking some settings, I noticed the VM felt unusually smooth. It got me thinking: If the VM can already feel this responsive, could I give it full, exclusive access to my only GPU?

I went down the rabbit hole. I found resources like the NlTESHADE YouTube channel and the RisingPrism GitLab repo, which gave me the conceptual push I needed.

The goal was simple:

Keep Linux as my daily driver.

Launch a Windows VM when needed, without rebooting.

Get as close to bare‑metal performance as possible.

Dual booting was out. Constantly restarting kills flow, and I wanted the flexibility of both operating systems at my fingertips.

What Exactly Is Single GPU Passthrough?

Instead of sharing your GPU between the host and the VM, you detach it from the host and hand it over completely to the VM.

The VM gets direct hardware access, bypassing software emulation. The result? Near-native performance for gaming, rendering, or any heavy Windows‑only workload.

When you shut down the VM, the GPU is handed back to your Linux host, and everything resumes as if nothing happened.

My Setup & How It Works

I built this on Arch Linux (though the principles apply to any distro). The stack includes:

QEMU / KVM: virtualization backbone
VFIO: kernel‑level GPU assignment
libvirt: management layer
OVMF: UEFI firmware for modern Windows VMs

Behind the Scenes

Here’s the flow:

Boot Linux normally.
Start the VM, a script unloads the GPU drivers from the host.
The GPU is passed through to the VM.
Windows boots and uses the GPU directly.
You work/play with native performance.
Shut down the VM, the GPU returns to Linux, and the host drivers reload.

No reboots. No dual boot. Just seamless switching.

Command Snippets

This is just a glimpse—don’t try to run these without proper configuration.

Check if virtualization is supported
lscpu | grep Virtualization

Load VFIO modules
sudo modprobe vfio vfio-pci
Find your GPU’s PCI ID
lspci -nn | grep -i nvidia # or amd
Bind the GPU to vfio-pci
echo "10de 1f82" > /sys/bus/pci/drivers/vfio-pci/new_id
`
The real setup involves hooks, kernel parameters, and careful timing—but that’s what the full guide is for.

The Hard Parts

This wasn’t a one‑hour project. I hit plenty of roadblocks:

The VM would start, but the screen stayed black.

Sometimes the GPU wouldn’t release back to Linux after shutdown.

Driver conflicts (especially with NVIDIA).

Windows failing to detect the GPU properly.

Every issue forced me to understand my hardware and software at a deeper level.

What I Gained (Besides Performance)

Single GPU passthrough taught me more than I expected:

How PCI devices are managed by the kernel

How driver binding and unbinding work

The inner workings of QEMU hooks and libvirt

It’s one thing to use Linux; it’s another to control exactly how your hardware behaves.

Benchmark video of Windows 11 with Single GPU Passthrough

Is This for You?

My hardware is modest—nothing high‑end. Even so, the performance was impressive enough to convince me that this setup can replace dual booting on capable machines.

If you’re tired of rebooting just to run a Windows‑only app or game, and you want to keep your Linux workflow intact, single GPU passthrough is worth the effort.

Final Words
This journey changed how I use my system. Instead of choosing between operating systems, I just switch environments, instantly, without sacrificing performance.

This article is a high‑level overview. If you want the full step‑by‑step guide, including the exact configuration, scripts, and troubleshooting steps I used, head over to my website:

🔗 Single GPU Passthrough Guide

Have you tried something similar? Got questions or war stories? Drop them in the comments, I’d love to hear about your experience.

I Switched from VirtualBox to QEMU/KVM… and It Feels Almost Native

Abdullah Musa — Mon, 23 Mar 2026 10:43:24 +0000

If you’re a developer, you probably use virtual machines regularly.

I do too.

But for the longest time, something always felt off.

The Problem With VirtualBox (At Least For Me)

On Windows, I used Oracle VM VirtualBox.

It worked.

But never perfectly.

Performance felt inconsistent
Some features felt limited
It never felt “smooth”

No matter how much I tweaked it, there was always something missing.

Then I Switched to Linux

When I moved to Linux, I still needed virtual machines.

That’s when I kept hearing about:

QEMU + KVM

At first, it sounded complicated.

Not as beginner-friendly as VirtualBox.

But one thing kept coming up everywhere:

KVM is extremely powerful

So I decided to try it.

First Impression: “Whoa, This Feels Native”

The first time I properly set up a virtual machine using QEMU/KVM, the difference was immediately noticeable.

The performance.
The responsiveness.
The smoothness.
It didn’t feel like a typical VM anymore.
It felt close to running a system natively.

Applications opened faster, animations were smoother, and overall interaction just felt better compared to what I was used to on Windows with VirtualBox.

That was the moment I realized this wasn’t just another virtualization tool. This was something much more powerful.

More Than Just Basic Virtualization

What surprised me the most wasn’t just the performance.

It was the flexibility.

There were things I didn’t even know were possible inside a virtual machine that suddenly became achievable with QEMU/KVM.

With a bit of effort and understanding, you can:

Get near-native performance
Customize hardware at a deeper level
Experiment with different system configurations
Push virtualization far beyond basic usage

It opens up a completely different way of thinking about virtual machines.

Why QEMU/KVM Feels Different

Unlike traditional VM tools, QEMU combined with KVM uses hardware virtualization directly through the Linux kernel.

This is one of the main reasons why it performs so well.

Instead of acting like a heavy abstraction layer, it works much closer to the system itself.

The result is:

Better performance
Lower overhead
More control

Of course, it does require a bit more setup and understanding compared to beginner tools. But once you get past that initial learning curve, the payoff is huge.

My Experience Using It Daily

After spending more time with QEMU/KVM, it slowly became my primary way of running virtual machines.

Instead of switching back to Windows tools, I found myself doing more and more inside Linux.

The control it gives you is hard to go back from.

It fits really well into a developer workflow where you want flexibility, performance, and the ability to experiment freely.

What I Explored With It

One of the best parts about using Linux with QEMU/KVM is the ability to explore things you normally wouldn’t try.

For example:

Running ChromeOS Flex inside a virtual machine
Experimenting with different Linux distributions safely
Trying advanced setups like GPU passthrough (even with a single GPU)

These are things I never seriously explored before.

But with QEMU/KVM, they become possible, and honestly, really fun to experiment with.

Still Exploring

Even now, I feel like I’ve only scratched the surface.

This setup opened the door to a lot of new ideas and experiments.

Linux combined with QEMU/KVM gave me the freedom to test things, break things, and learn without worrying about my main system.

And that’s something I didn’t fully experience before.

Full Setup Guide

If you’re interested in setting this up yourself, I’ve documented the complete step-by-step process on my site.

It covers everything from creating virtual disks to configuring QEMU properly and getting a working VM environment.

Install QEMU/KVM on Linux: Near-native VMs

Final Thoughts

If you’re still relying on traditional virtualization tools and haven’t tried QEMU/KVM yet, it’s definitely worth exploring.

There is a bit of a learning curve.

But once you get through it, the experience is on a completely different level.

Especially on Linux.

Exploring Hyprland on Arch Linux: 5 Dotfile Setups Worth Trying

Abdullah Musa — Wed, 04 Mar 2026 14:56:15 +0000

Exploring Hyprland on Arch Linux: 5 Dotfile Setups Worth Trying

If you have been using Arch Linux for a while, you eventually reach a point where traditional desktop environments start to feel limiting. KDE, GNOME, and XFCE are excellent in their own way, but they follow a fairly conventional desktop model.

Hyprland changes that experience completely.

Instead of a traditional desktop environment, Hyprland is a dynamic tiling Wayland compositor that focuses on fluid animations, modern rendering, and keyboard-driven workflows. It combines the power of tiling window managers with a visually polished environment that doesn’t feel minimal or unfinished.

Over the past year while experimenting with Arch Linux setups, I explored multiple Hyprland configurations. Rather than building everything manually from scratch, many users prefer starting with curated dotfile setups that already provide themes, scripts, layouts, and useful tools.

In this article, I’m sharing five Hyprland setups that I’ve worked with. Each one approaches the Hyprland experience differently, whether the focus is productivity, aesthetics, or customization.

This is not a step-by-step installation guide. Instead, it’s a practical overview based on experimenting with these environments on real systems.

Why Hyprland Has Become So Popular

One of the reasons Hyprland is gaining so much attention in the Linux community is that it solves a long-standing problem.

Traditional tiling window managers like i3 or bspwm are extremely powerful, but they often require a lot of manual configuration and can feel visually basic without heavy customization.

Hyprland brings a more modern approach to tiling. It runs on Wayland and provides smooth animations, rounded corners, blur effects, and dynamic layouts while still keeping the keyboard-driven workflow that tiling users prefer.

The result is a system that feels both highly efficient and visually polished.

Of course, building a Hyprland environment from scratch can take time. That’s where curated dotfiles come in.

Hyprland Setups I’ve Explored on Arch Linux

Over time, I experimented with several Hyprland configurations that provide different starting points depending on what kind of workflow you want.

ML4W (My Linux For Work)

ML4W is one of the most productivity-focused Hyprland frameworks I’ve used.

Instead of being just a theme or a visual setup, ML4W feels more like a structured environment designed for people who spend most of their time working inside Linux. It provides automation scripts, preconfigured layouts, and tools that make the transition into Hyprland much smoother.

One thing I appreciated about ML4W is that it removes much of the initial complexity that usually comes with tiling window managers. With the right setup, you can go from a minimal Arch installation to a complete Hyprland environment without spending hours tweaking configuration files.

For users who want a work-focused Hyprland setup, ML4W is a very solid starting point.

HyDE Project

The HyDE project is one of the most visually refined Hyprland setups available.

Compared to many tiling environments that prioritize minimalism, HyDE focuses on creating a modern and highly aesthetic desktop experience. The environment comes with dynamic themes, polished animations, and a cohesive design language across the entire system.

What makes HyDE interesting is that it manages to combine visual appeal with usability. It doesn’t feel like a flashy demo environment. Instead, it provides a balanced setup that can actually be used daily without constant tweaking.

For people who want Hyprland to look as impressive as it performs, HyDE is easily one of the best configurations to explore.

Caelestia Dotfiles

Caelestia is more focused on visual identity and customization.

While some Hyprland setups aim to stay minimal or productivity-centric, Caelestia leans more into aesthetic customization. The themes, layouts, and UI elements create a very distinctive look that stands out from more conventional Linux desktops.

It’s the type of setup that many people would describe as “riced,” where the environment is heavily styled and personalized.

If you enjoy experimenting with desktop aesthetics and want a setup that feels unique, Caelestia is a great example of how flexible Hyprland can be.

Jakoolit Hyprland

Jakoolit’s Hyprland configuration takes a slightly different approach.

Instead of focusing purely on productivity or purely on visuals, it tries to combine both. The environment includes a polished theme, useful scripts, and preconfigured tools that make the setup practical while still maintaining a strong visual style.

It feels like a middle ground between minimal tiling setups and heavily themed environments.

Because of that balance, Jakoolit’s configuration can work well for users who want a ready-to-use Hyprland desktop without spending days customizing everything manually.

End-4 Hyprland

End-4 is probably the most visually striking Hyprland setup I’ve experimented with.

This configuration pushes Hyprland’s graphical capabilities much further, with elaborate themes, animated elements, and carefully designed UI components. It’s the kind of setup that really showcases how modern Wayland compositors can transform the Linux desktop experience.

While it may not be the most minimal environment, it demonstrates what Hyprland is capable of when aesthetics become a central part of the design.

For users who enjoy visually rich Linux environments, End-4 is definitely worth exploring.

My Personal Take

After trying different Hyprland configurations, one thing became clear to me: there isn’t a single “best” setup.

Each configuration serves a different purpose.

ML4W is excellent if your goal is productivity and a structured workflow. HyDE offers one of the most polished visual experiences. Caelestia is great for aesthetic customization, while Jakoolit provides a balanced environment between visuals and usability. End-4 pushes the visual side of Hyprland even further.

What makes Hyprland interesting is that all of these environments share the same underlying compositor, yet they can feel completely different depending on how they are configured.

That flexibility is one of the biggest strengths of the Linux ecosystem.

Learn How to Install Each Setup

If you’re interested in trying any of these environments, I’ve documented detailed installation guides for each setup on my site.

They walk through the full process of preparing an Arch Linux system and deploying the dotfiles correctly.

You can find the full guides here:

• ML4W Hyprland

• HyDE Project

• Caelestia Dotfiles

• Jakoolit Hyprland

• End-4 Hyprland

Finding a Lightweight Desktop on Gentoo: XFCE Experience and Setup

Abdullah Musa — Sat, 28 Feb 2026 14:59:20 +0000

Introduction

Gentoo is a Linux distro that’s all about control and customization, and after installing the base system, the next big step for most users is getting a graphical desktop running. A Gentoo desktop environment doesn’t come out of the box, you pick what you want and build it yourself. For my setup, I chose XFCE, a lightweight and reliable desktop that works well even when the system compiles everything from source.

This article is not a step-by-step installation guide. Instead, it explains what you should expect when adding a desktop environment on Gentoo, and why XFCE is a solid choice for many users.

Preparing Gentoo for a Desktop Environment

Before installing XFCE, you need your Gentoo system ready for a graphical session. This means:
Choosing a desktop profile (e.g., desktop/systemd or desktop/openrc)
Synchronizing the Portage tree
Adding appropriate flags to make your system aware of graphics drivers
Updating the @world set to make sure everything is up-to-date

These preparatory steps ensure the system is ready to build the necessary graphical stack without surprises. The key here is Portage, Gentoo’s package system, which calculates dependencies and compiles code based on the flags you set, giving you fine-grained control over your desktop build.

Installing Xorg and XFCE

On Gentoo, the desktop experience relies on the Xorg display server and the packages that make up the XFCE environment itself.

The general flow is:

Install Xorg components and drivers
Add USE flags for XFCE and Xorg
Update your configuration files
Recompile the world set that now includes XFCE packages

Because everything is compiled, this is not an instant process. Gentoo will handle dependencies and build from source, and compilation time can vary based on hardware.

XFCE itself strikes a great balance between speed and functionality, giving you the performance of a lightweight desktop with the features most users expect in a modern GUI.

Starting The XFCE Session

Once XFCE and its dependencies are installed, you launch your desktop session through a simple command or a configured session manager. With Gentoo, this step depends on your setup, whether you use .xinitrc with startxfce4 or a display manager. Either way, the result is the same: a fully functional XFCE desktop running smoothly on Gentoo.

Because Gentoo builds everything specifically for your system, XFCE on Gentoo often feels snappy and efficient, even though the installation process itself is more involved than on binary distributions.

Why XFCE Works Well on Gentoo

XFCE is popular in source-based systems for a few reasons:

Lightweight and responsive, doesn’t demand heavy resources
Modular design, you install only what you need
Traditional desktop workflow, familiar UI for many users
Great on older or modest hardware, especially when compiled with optimized flags

Even though Gentoo requires more time up front, the end result is a custom XFCE environment tailored exactly to your machine and preferences.

Full Setup Guide

For the full step-by-step XFCE installation process on Gentoo, including exact commands and configuration, check the detailed guide here:
https://www.musabase.com/2025/08/how-to-install-a-desktop-environment-on-gentoo.html

Installing Gentoo Linux: What to Expect Before You Start

Abdullah Musa — Wed, 25 Feb 2026 12:16:56 +0000

If you’ve already experimented with distributions like Arch Linux, you might eventually become curious about Gentoo. I reached that point as well. After getting comfortable building systems manually, I wanted to see what a fully source-based Linux distribution actually feels like.

Gentoo is often described as one of the most complex Linux distributions to install. That reputation is not entirely wrong, but it’s also not the full story. Gentoo is not difficult for the sake of being difficult. It simply expects you to understand what you are building.

This article is not a command-by-command walkthrough. Instead, it explains what installing Gentoo really involves and what you should expect before starting.

What Makes Gentoo Different

The biggest difference between Gentoo and most Linux distributions is that Gentoo compiles packages from source.

Instead of installing prebuilt binaries, you extract a Stage 3 base system and then begin shaping everything yourself. Gentoo uses Portage as its package management system. Portage introduces concepts like USE flags, which allow you to decide exactly which features are compiled into your software.

You are not just installing a system. You are building it.

Kernel configuration is another major step. While some distributions automate kernel setup, Gentoo gives you the option to configure and compile your own kernel. This adds flexibility, but it also requires patience and attention to detail.

The Installation Reality

Gentoo installation requires time. If you are working with fewer CPU cores, compilation will take noticeably longer. When I first installed Gentoo, I did it inside a virtual machine with 2 CPU cores and 10GB of RAM. Compiling and installing around 241 packages from the world set using emerge took nearly 12 hours to complete.

Large packages and dependency chains significantly increase build time, especially when compiling from source with custom USE flags enabled.

This is not a distribution you install in a hurry.

It also assumes you are comfortable with the command line, disk partitioning, chroot environments, and manual configuration. You will work directly with Portage, manage configuration files manually, and understand how your system is being built layer by layer. The documentation is excellent, but it expects you to read carefully and understand what you are doing.

That said, the process teaches you a lot about how Linux works internally.

Who Should Try Gentoo

Gentoo is not for everyone.

If you want something that works immediately after installation with minimal configuration, there are better choices. But if you enjoy understanding how your system is assembled, tuning performance, and having complete control over compile options, Gentoo is worth exploring.

It is especially interesting for users who have already used Arch Linux and want to go one level deeper into system control.

Final Thoughts

Installing Gentoo is less about speed and more about understanding. It slows you down in a way that forces you to learn. Whether you decide to stay on Gentoo or return to a binary distribution afterward, the experience changes how you view Linux systems.

For a complete step-by-step installation guide with commands and detailed explanations, I’ve documented everything here:

👉 https://www.musabase.com/2025/07/how-to-install-gentoo-most-complex-os.html

Choosing a Desktop Environment on Arch Linux: KDE vs GNOME vs XFCE

Abdullah Musa — Tue, 03 Feb 2026 19:21:16 +0000

If you’re coming to Arch Linux from Windows or from more modern distributions like Fedora or CachyOS, one of the first things you’ll start looking for after installation is a desktop environment that feels familiar and comfortable. This choice matters more than most people initially think. A desktop environment on Arch is not just about how the system looks. It directly affects your workflow, stability, and how comfortable your system feels day to day.

I’ve been using Arch Linux for about a year now as part of my daily setup, and during that time I’ve tried multiple desktop environments. Some worked better for my workflow, some made more sense on older hardware, and some were useful only in specific situations. This article is not a technical guide or a comparison based on benchmarks. It’s a real-world overview based on daily use.

Why Desktop Choice Matters on Arch Linux

Arch Linux is minimal by design. When you install it, you start with a very bare system, and everything you add on top of that defines your experience. The desktop environment plays a major role here because it becomes the layer you interact with the most.

When I moved from Windows to Linux, Arch Linux was actually my first distribution. Because of that, I needed a desktop environment that felt familiar and comfortable, something closer to what I was used to on Windows. On Arch, a wrong desktop choice can easily lead to frustration. You may feel like you’re constantly fixing things, fighting defaults, or working around limitations. On the other hand, choosing the right desktop environment can make Arch feel smooth, predictable, and even boring in a good way. Since Arch doesn’t force any defaults on you, the desktop environment you choose ends up defining how stable and usable your system feels over time.

Desktop Environments I’ve Used on Arch Linux

Over the past year, I’ve mainly used three desktop environments on Arch. Each one serves a different purpose, and none of them are objectively “better” than the others.

KDE Plasma

KDE Plasma felt the closest to Windows for me, which mattered a lot since I moved from Windows directly to Arch Linux. While Linux Mint’s Cinnamon desktop is often considered even closer to the Windows experience, I had heard a lot about KDE Plasma and wanted to try it myself.

Plasma feels like a complete daily-driver desktop environment. It is flexible, feature-rich, and highly customizable without forcing you into a specific workflow. Once set up properly, it stays out of the way and lets you focus on work.

It offers a strong balance between productivity and customization. You can tweak almost everything if you want, but you don’t have to, and that flexibility is what makes KDE Plasma a solid long-term choice on Arch.

GNOME

GNOME is clean and opinionated. It has a very focused design philosophy, and it expects you to adapt to its workflow rather than customize everything from the start. Extensions play a big role here, allowing you to shape the experience without overwhelming configuration options.

If you prefer a distraction-free environment and don’t want to spend time tweaking every detail, GNOME can feel very refreshing. It’s less about control and more about consistency.

XFCE

XFCE is lightweight, stable, and predictable. It doesn’t try to be flashy or modern, but that’s exactly its strength. On older hardware, XFCE performs extremely well and remains responsive even with limited resources.

It’s a great option if you value stability over visual polish, or if you’re running Arch on machines where performance matters more than appearance.

My Personal Take

For my main system, I’ve settled on KDE Plasma as my primary desktop environment. Coming from Windows, it felt familiar enough to be comfortable while still giving me the flexibility Arch Linux is known for. It fits my daily workflow well and doesn’t require constant maintenance, which is why it’s the desktop I feel most productive on.

I use XFCE when working with older hardware or systems where I want things to stay simple and reliable. It’s lightweight and does exactly what it promises without surprises.

GNOME is something I turn to when I want a clean and focused environment with minimal tweaking. It’s not my primary choice, but it works well when I want a more structured workflow.

If you’re interested in detailed, step-by-step setup guides, I’ve documented each of these environments separately on my site:

KDE Plasma on Arch Linux

GNOME on Arch Linux

XFCE on Arch Linux

A Clean and Practical Arch Linux Installation Approach (UEFI)

Abdullah Musa — Fri, 23 Jan 2026 18:04:53 +0000

Installing Arch Linux can feel overwhelming at first, not because it is difficult,
but because it gives you many choices from the very beginning.

This post documents a clean and practical way I approach Arch Linux installation,
focused on understanding each step instead of blindly copy-pasting commands.

What This Post Covers

A minimal Arch Linux installation mindset
UEFI-based setup
GPT partitioning
Base system installation
Bootloader and essential configuration

This is not meant to replace the Arch Wiki. Instead, it is a practical walkthrough
for users who prefer a structured approach while still learning how things work.

What This Does NOT Cover

Desktop environments or window managers
Gaming or GPU configuration
Theming or ricing

Those topics deserve their own dedicated guides.

High-Level Installation Flow

Boot the Arch ISO
Verify network connectivity
Partition disks using GPT
Install the base system
Configure users, locale, and networking
Install and configure a bootloader
Reboot into a clean Arch system

Why I Wrote This

Arch Linux encourages learning by doing. Having a clear reference
helps reduce confusion while still respecting Arch’s philosophy.

Full Step-by-Step Guide

I documented the complete installation with explanations and notes here:

Complete Arch Linux Installation Guide (MusaBase)

A lightweight reference version is also available on GitHub:

Lightweight Reference on GitHub

Let me know in the comments if you’d like a follow-up on desktop setup or gaming tweaks!