It was early in 2021, during the COVID period, that I came across YouTube videos by Luke Smith. He used to talk a lot about tech, minimalism, and control over your computer, and I was fascinated by his insights. He suggested Manjaro as a gateway into the Arch ecosystem. The pros was compelling: complete control, minimal waste, small footprint, and access to the latest software.
I’ve been using Manjaro Linux for 5+ years since then. For the entirety of that duration, I have used the system without ever looking back. I have actively thought about, configured, maintained, and occasionally fought with the OS.
But lately, I’ve been feeling something change. This post is an attempt to articulate why I’m planning to move away from Manjaro and toward Debian – not because Manjaro is bad or Debian is superior, but because what I want from my system has changed.
What Manjaro (and Arch) Gave Me
Coming from Windows, Manjaro forced me to learn things I would’ve otherwise ignored:
- what package managers are
- what package managers really do
- how to install packages and their dependencies
- some Linux system internals
- how dependencies interact (and sometimes explode)
- how each “tool” or “package” can be configured
- reading Arch Wiki for help
- getting rid of Terminal fear and learning to love it
- building packages vs using binaries
and so on. The list is pretty long, trust me. I don’t regret choosing Manjaro at all. In fact, I think it was the right choice. Manjaro didn’t hide things from me. If something broke, I had to understand why. That process taught me more about Linux internals than any “beginner-friendly” distro would have.
I always thought, that learning “Arch” was giving me super powers. I genuinely believe this phase made me a more confident engineer – not because I knew more tools, but because I learned how systems work internally.
At first (few years), I was in the honeymoon phase. Everything about Manjaro was great. But as the honeymoon phase started to end, I started noticing the subtle things – things I had ignored earlier – that slowly became bothersome.
The Cost of Rolling Release (for Me)
Manjaro made me feel powerful and not afraid to tinker around with the OS. However, over the years, the trade-offs started becoming clearer.
The first and foremost was that I was fighting with the package manager a lot. Sometimes updates would break dependencies. Updates didn’t break things often — but when they did, they were stressful. I would have to uninstall unwanted packages, or find a way to use a previous version of a package. To be honest, this did teach me a lot of dependency management. It taught me far more about dependency management than npm ever did.
Another thing was that I had to CONSTANTLY keep updating everything. Every time I start my system, mostly I would see X new updates pop up. And I could not let that thing pile on. The number used to grow on a daily basis. If I don’t update for a week, I would see 900+ updates with download size of over 3GBs. I don’t even know what is updated, but I had to constantly update my system.
Many times, the complete thing would fail also. The system would download, then try to install/build and the transaction would fail. I would then have to start the build process multiple times. Then, there was locking also. So, I had to manually delete the lock on package manager to free itself.
Most of my issues weren’t catastrophic system failures. They were subtler and more frustrating:
- dependency breakage
- tools behaving differently after an update
- Emacs breaking more often than I’d like to admit
- needing to update everything just to update one package
Over time, I realized I was spending a lot of energy maintaining the system rather than simply using it.
The Illusion of “Lightweight”
Arch-based systems feel lightweight. The system rarely ever feels slow while doing backend development. You install only what you need and the system is clean and elegant. You only have what you require.
Five years later, that illusion fades.
Between AUR packages, their dependencies, language runtimes, tooling experiments, and “temporary” installs that never got removed, my system was no longer simple. There are so many unused packages and background daemons that I’m not even aware of. I don’t want, nor do I have the time to manage them.
Yes, Arch does give you the power to only have whatever you want, but it does not factor in human error and laziness. Of course this thing is going to be applicable to any OS I use. So, the lightweight factor is more of a discipline than a feature of the OS itself. On any Linux distro, one would have the option to replace almost any tool.
So, the lightweight OS is applicable on a fresh install. Eventually, one would install a lot of bloat over time and the illusion quickly fades away.
How Neovim shaped my thinking
The first thing I started with was my text editor. I realized this is where I spent most of my time. Just like every new developer, I started development in VSCode. So, I learned a lot of keyboard shortcuts, and started getting productive. But I just felt I could be more productive. Then, I started seeing videos about Neovim a lot. I started diving deeper into those videos and saw that there might actually be some potential.
Instead of switching completely to Neovim, I started by learning vim motions inside VSCode. Over months, those motions started to become muscle memory. Around the same time, I was working more on remote servers, where vim/Nano was the only option. Nano felt like I had to learn a lot of other shortcuts, whereas I was comfortable with vim a lot more.
The biggest change wasn’t speed—it was mindset. I learned to navigate projects without relying on file explorers, which was honestly my biggest blocker for completely switching to Neovim.
Eventually, I forced a full switch to Neovim. It was uncomfortable at first, but over time, I started to become more productive. My editor became predictable, portable, and a tool that I can adapt to my requirements, instead of adapting to the tool.
That experience reshaped how I think about tools. I now prefer systems that change slowly, reward understanding, and age well. Neovim was the first place I felt that shift—and it directly influenced how I think about my operating system too.
Lessons from creating Production Systems
It is great to have the latest tech with the best features. However, in production, it is far more important to have something reliable that doesn’t break easily. This is why legacy systems rarely change.
While coding, I used to get irritated when I had to switch stacks between projects. I was learning a lot of tech, yes. However, I was not learning something well enough to understand whether it was the right choice or not. I did not have mastery over anything and I could not stick to a tech stack.
On top of that, constantly switching tools and technologies is really frustrating. After a point, you want something stable that you spend time learning and that actually stays for the long run. If you spend time learning a JS framework only to later find out that it is deprecated or not supported or going out of use, it is very frustrating to have to re-learn something new.
So, I started to move away from all the hype to understand what is actually happening. What am I actually doing, and what I really need.
What I Want Now Has Changed
Today, I’m an experienced backend developer. What I value most is:
- stability
- reproducibility
- low cognitive overhead
- tools that age well
I want to build a system once, update only when I want something more, and forget it. I don’t want anything to get in my way whenever I need to get work done. The editor, shell, and workflows need to be predictable and portable. If I switch machines or environments, I want to feel “at home” immediately.
This is why I’ve naturally moved toward tools like:
- Neovim over VSCode
- tmux over plain terminals
- curl over Postman
- plain text configs
- default CLI tools over fancy new tools
Of course using the latest tech is hip and trendy and gives you lots of features. But old tools have been used by so many developers over the years that they are really mature. They don’t chase novelty. They compound value over time. My OS should do the same.
For the longest time, I have believed that Arch is the best base OS. I have never questioned this assumption. It was always recommended by the one I adore a lot and trust. I did look into what the best Linux distro is and I would always solidify my reason that Arch is still the best and I should stick with it. Maybe that was the bias I had.
Why Debian Makes Sense Now
Debian’s philosophy is almost the opposite of Arch’s – and that’s exactly why it appeals to me now.
Debian prioritizes:
- stability over novelty
- predictability over rolling release
- long-term reliability
I don’t need the latest versions of everything anymore. I need things to behave the same way tomorrow as they did today. It’s just like the saying – “don’t fix what ain’t broken”. In that aspect, I don’t really need the latest update since everything is already working.
Debian feels like an OS that wants to disappear into the background – which is exactly what I want. I don’t want to update everything regularly to just waste bandwidth. I want to be able to update only the package I want without requiring me to update the entire system.
What I’ll Miss with Manjaro (Arch)
This isn’t a breakup without nostalgia.
I’ll miss:
- the AUR – having almost anything one command away is genuinely powerful
- the flexibility of Arch-based systems
- the feeling of total control
- Arch Wiki – Seriously the best documentation ever
But I’ve also learned that total control comes with total responsibility – and I no longer want to pay that cost. I would rather have a stable system than the latest system.
This Isn’t About “Better” or “Worse”
This switch isn’t about Manjaro being bad or Debian being superior. It’s about choices. Manjaro was the right choice when I wanted to learn deeply, tinker constantly, and explore the system itself. Debian feels like the right choice now that I want:
- consistency
- long-lived workflows
- predictability
- low cognitive overload
- a system that enables work instead of demanding attention
I’m not switching immediately or recklessly. I want to do this without disrupting my workflow. But mentally, I’m already there. Sometimes growth isn’t about adding more tools – it’s about choosing fewer, quieter ones.
Leave a Reply