The very beginning

First stop: WSL

Fedora — the right call for the wrong hardware

Installing Arch (it was awesome)

What Arch actually feels like

Bottom line This is my journey of how I transitioned from Windows to Arch Linux, the reasons behind it, and whether it's really worth it. I'm a quite practical and no-fluff writer, so I'm sure you will find something useful or interesting. Stay tuned! Like everyone, I started on Windows. It's what everyone uses, it's what comes pre-installed, and it comes with most of what a normal person would need from a computer. Then at some point, I met Linux: open source, super fast and resource efficient, without the Windows bloat and with free licensing. Also, the server world runs on Linux, because it's faster and cheaper. So it was evident that if I wanted to take it seriously as a software dev, I had to become comfortable around Linux. The obvious first step was WSL — Windows Subsystem for Linux. You get a Linux terminal without leaving Windows, it's easy to set up, and for small scripts and simple projects it works fine. The problem showed up as soon as I tried to use it for real work. On an 8GB RAM machine running VSCode with a fullstack project open — LSPs, syntax extensions, the works — the whole thing would hang. Not a little lag, but full 30-second freezes from just opening a moderately sized codebase. WSL adds a virtualization layer on top of Windows, and Windows itself is already eating a significant chunk of your memory. On constrained hardware, it simply doesn't hold up. And even on more powerful machines, I'd rather save that compute for actual development — not for system bloat or telemetry quietly reporting back to Microsoft. So I decided to switch for real. It had a very good reputation among the dev community, since it is the most developer-friendly distro. Faster and less bloated than Ubuntu, with good stability and smooth updates with 6-month release cycles, and it handles a ton for you out of the box. The difference from day one was noticeable. Memory usage at idle dropped substantially, everything felt snappier, and I could finally run my full dev setup — VSCode, Chrome with multiple tabs open, Docker, DBeaver — without the machine gasping. But I had a small problem — my laptop's WiFi chipset. It's a MediaTek MT7902, and MediaTek simply doesn't ship Linux-compatible drivers. My fix at the time was a USB WiFi dongle, which got the job done until it broke. So I started searching for alternatives, and the most promising solution was to compile and install third-party community drivers for my chipset. The community driver didn't work on Fedora, so I tried a few other distros. None allowed for the community driver installation, except Arch Linux. Arch has a reputation. The community talks about it like a rite of passage, and for years the installation process genuinely was manual enough to intimidate most people. I went in expecting the worst. The reality in 2026: archinstall exists. It's a guided installer that walks you through partitioning, locale, desktop environment, bootloader — the whole thing. The whole installation took maybe 45 minutes. I was expecting a weekend project. Once it was up, I compiled the MediaTek driver. It worked. That alone made the whole detour worth it. I ended up automating the entire driver setup and publishing it here for anyone else stuck in the same situation. The performance difference is real, and it's immediately obvious. My system boots in about 5 seconds max — a few seconds faster than Fedora, which is a nice touch. Part of that is Arch's philosophy: you install exactly what you need, nothing else. No background updater for software you never asked for, no telemetry running quietly, no bundled apps eating RAM. The base system is minimal by design, and everything on top of it you put there deliberately. The other relevant thing about Arch is that it's a rolling release. There are no versions — no "Arch 2026" to upgrade to each year. You just run pacman -Syu and you're always on the latest everything. For a dev machine that's genuinely convenient, but still isn't something that makes it 10x better than any other distro. And the most important thing — you get to flex "I use Arch btw 💪". The greatest meme in the Linux community. The tradeoff — some things don't configure themselves. Connecting an external monitor required manual setup. Default system audio meant installing pavucontrol and configuring things from there. These aren't hard problems, but they're yours to solve — which is a different experience from what most people and devs are used to. If something doesn't work, you look it up, find the answer on the Arch Wiki or with a quick Google or AI search, install and set up what you need, and move on. Honest answer — IT DOESN'T MATTER. The real-world performance difference between Arch, Fedora, Ubuntu, and other distros is smaller than the internet would have you believe. I still recommend Arch to devs who take their craft seriously. You will gain a deeper understanding of your system. The installation teaches you things. Running, breaking, and fixing it teaches you even more. But it's not the right tool for everyone, and pretending otherwise is a kind of gatekeeping that doesn't help anyone. I also derive great satisfaction from having my OS as clean and minimal as possible, in the same way I do for my physical workspace — knowing exactly what the system has and for what purpose. Always remember — Pragmatism over dogma. The most important thing is developer experience and productivity. Having your tools work, your workflow be uninterrupted, and your system stay out of your way — that's what matters. Which distro gets you there is secondary. A 5-second extra boot time or downloading some package 200 milliseconds faster is negligible when you work for hours a day. Try the best-known distros for a while (no more than a day in total), and pick the one that resonates the most with you. Don't fall into the OS optimization hell — focus instead on the big picture (developer experience and productivity), and remember that distro hopping is itself a form of procrastination. Use that time instead to do real work or to work on something you enjoy. Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or