I Finally Have a System That Feels Like Mine

It took 40 days, but I’m here. A working Arch setup with Hyprland that doesn’t just function - it feels right.

The animations are smooth. The keybindings make sense to my fingers. The colors don’t hurt my eyes. Everything is where I expect it to be.

And the best part? I built every piece of this myself.

No pre-made theme packs. No “download my dotfiles” repos I copied blindly. This is mine. Every configuration line, every color code, every keybinding - I chose it, tested it, tweaked it until it felt perfect.

For the first time since leaving Windows, I’m not thinking about my OS. I’m just… working in it.

The Dotfiles Journey

A month ago, I didn’t even know what dotfiles were.

Now I have a whole Git repository dedicated to them.

Dotfiles are the config files that control everything in your Linux setup. They’re called “dotfiles” because they start with a dot (.config, .bashrc, .xinitrc) and are usually hidden by default.

Every program you configure - your shell, your window manager, your terminal, your editor - stores its settings in dotfiles. And if you back them up properly, you can recreate your entire setup on a new machine in minutes.

The idea clicked when I broke my Hyprland config for the third time and had to reconfigure everything from scratch. Again.

I thought: “There has to be a better way.”

There was. Git.

I created a GitHub repo. Started tracking my configs. Now when I experiment with settings and break something, I can just git checkout back to what worked.

But more than that: having a dotfiles repo forced me to actually understand what I was configuring. Because if I was going to commit something to version control, I needed to know what it did and why I chose it.

The Reinstall That Taught Me Something Hilarious

Once I had my dotfiles organized, I wanted to test them properly. Could I actually recreate my setup from scratch using my configs?

Only one way to find out: reinstall everything.

So I backed everything up, wiped my drive, and started the Arch installation process again. From scratch. Manual partitioning. Base system install. The whole thing.

Except this time, I knew what I was doing. What took me four hours the first time took maybe 90 minutes. I was efficient. Confident. Following my own documentation.

Got the base system up. Booted in. Started pulling my dotfiles from GitHub to configure everything.

And that’s when someone in a forum mentioned something casually: “Why didn’t you just use archinstall?”

Wait. What?

Turns out, Arch has had a guided installer since 2021. A CLI-based installation script that walks you through the process. Still terminal-based, still teaches you what you’re installing, but with helpful prompts and error checking.

All this time. All those hours manually partitioning, configuring, installing. And there was a built-in guided installer the whole time.

I felt so stupid.

For about five minutes.

Then I realized: I’m glad I didn’t know about archinstall.

If I’d found it first, I would’ve used it. And I would’ve learned so much less. I wouldn’t understand partitioning as well. Wouldn’t know what each base package does. Wouldn’t have that deep knowledge of how the system fits together.

archinstall is great. It’s helpful. It’s smart to use it.

But going through the manual installation a couple of times taught me more about Linux than any guided process could have.

Sometimes the hard way is the better way. Even if you feel dumb when you discover the shortcut existed all along.

Building the Hyprland Config

My Hyprland config started as a mess. Just whatever I could cobble together from examples online.

Now it’s… well, it’s still messy. But it’s organized mess. And every line serves a purpose.

Keybindings that make sense:
Super + Return opens a terminal. Because of course it does.
Super + D launches my app launcher.
Super + Q closes windows.
Super + [1-9] switches workspaces.

Nothing fancy. Just logical. Muscle memory built over weeks of repetition.

Window rules that work:
Firefox always opens on workspace 2. Music player on workspace 5. Chat apps on workspace 4. When I open these apps, they go where they belong. Automatically.

Animations that don’t suck:
Smooth but not slow. Fast but not jarring. Curves configured just right so windows slide into place naturally.

I spent an embarrassing amount of time tweaking animation curves. Worth it.

Colors that work together:
Dark theme. Accent colors that pop but don’t scream. Transparency where it helps, solid where it doesn’t.

Took me three color scheme iterations to find something I could stare at for 8 hours without eye strain.

The Terminal Setup

Switched from whatever default terminal I had to kitty.

Why kitty? Fast. GPU-accelerated. Configured with a single text file. Supports ligatures. Has tabs and splits built in.

The config was intimidating at first - so many options. Font size, line spacing, cursor shape, bell sound (disabled immediately), keybindings for tabs and splits.

But once configured? Perfect. My terminal feels responsive. Looks clean. Has everything I need and nothing I don’t.

Then there’s the shell. Started with bash because that’s what everyone starts with. Moved to zsh with oh-my-zsh after someone mentioned it in a forum.

The difference was immediate. Better autocomplete. Syntax highlighting. Git integration in the prompt. Plugins for everything.

My prompt now shows:

  • Current directory
  • Git branch and status
  • Whether my last command succeeded or failed

Simple information. But it makes working in the terminal so much smoother.

Development Environment Coming Together

The point of all this wasn’t to have a pretty desktop. It was to build things.

So I needed a development environment that actually worked.

Editor situation:
Started with VS Code because familiar. Bloated like windows though.

Tried Zed - this new editor everyone’s talking about. Fast. Native. Beautiful. Worked great on Wayland.

Used it for two weeks. Liked it. But there was this voice in the back of my head saying: “You’re using a GUI editor. In a terminal-focused system. While learning CLI tools. What are you doing?”

I wasn’t ready for Neovim yet. But I knew eventually I’d have to try it.

Version control workflow:
Git from the terminal became natural. No more GUI clients. Just git add, git commit, git push.

Aliases helped: gst for status, gco for checkout, gc for commit. Small shortcuts that added up.

Tiling Windows Changed How I Work

A month with tiling windows and I can’t imagine going back.

No more dragging windows around. No more resizing. No more “where did I put that terminal?”

Everything automatically tiles. Two windows? They split the screen 50/50. Three windows? One big, two small. Four windows? A grid.

Need more space for something? Keybinding to resize. Need to focus? Keybinding to fullscreen. Need to move something to another workspace? Another keybinding.

My hands barely touch the mouse anymore. Everything is keyboard-driven. And it’s fast.

The first week, I hated it. Felt constrained. Felt like I was fighting the system.

Now? Overlapping windows feel chaotic. Wasted space feels wrong. I’m spoiled.

The Satisfaction of Self-Built

Here’s what no one tells you about building your own setup:

It’s not just about having the perfect workflow. It’s about understanding your workflow.

When something breaks, I know where to look. When I want to change something, I know which file to edit. When I need a new feature, I know how to add it.

I’m not dependent on a developer’s choices. I’m not waiting for an update to fix something. I’m not stuck with defaults I hate.

This system is mine. From the bootloader to the window animations to the terminal prompt.

And when someone asks “what’s your setup?” I don’t say “oh, I use Pop!_OS with the default theme.” I can actually explain what I’m running and why.

That feels good.

Where I Am Now

My system:

  • Base: Arch Linux
  • Compositor: Hyprland
  • Terminal: kitty + zsh + oh-my-zsh
  • Status bar: waybar (custom config)
  • Launcher: wofi (themed to match)
  • Editor: Zed (for now)
  • Browser: Firefox
  • Everything else: chosen and configured intentionally

My dotfiles are versioned. My workflow is smooth. My muscle memory is building.

I’m actually productive again. More productive than I was on Windows, honestly. Fewer distractions. Faster navigation. Everything optimized for my specific needs.

But there’s a problem brewing.

I spend a lot of time tweaking configs. “Just one more adjustment.” “Let me try this font.” “What if I change this keybinding?”

It’s fun. It’s satisfying. But it’s also… endless.

There’s always something to optimize. Always a better color scheme to try. Always a new tool someone mentions that I want to integrate.

I came here to learn to code. To build things. But lately, I’ve been spending more time configuring my system than actually using it to build anything.

The setup is perfect. Now I need to actually use it for what I built it for.

Tomorrow, I start a new project. Something real. No more tweaking. No more “just one more config change.”

Time to actually ship something.

The arch.log series: Documenting my journey from Windows to Arch, from consumer to builder, from breaking things to understanding them. Still learning. Still shipping. Still honest about the messy parts.