⚙️ My Linux Experience

I’ve been on Windows since 1997, the time of my first PC-compatible computer. It was the default-choice OS, Windows 95. As a beginner PC user I dutifully read an MS DOS and a Windows user guides, and plunged into experiments. Being curious, I played much with the system. Fortunately, Windows 95 was highly customizable: you could change system colors, sounds, even modify startup and shutdown screens if you wanted to go a bit deeper. At that time, the alternatives were practically nonexistent, at least in my location.

In any case, I have no reason to complain: Windows 95 was a great albeit somewhat unstable operating system. You couldn’t really go for days without critical errors and reboots, and once in a while a complete reinstall was necessary. This, however, was the norm, so we treated it with "it can’t be helped" attitude. Most of later Windows versions brought much improvement. To me, Windows 98 was more like a "very extended update" of Windows 95 with many niceties but no real breakthroughs, and while Windows Me was universally hated, Windows XP was much loved for bringing not only regular UI updates, but also highly valued reliability of the NT core. For those who don’t know, there were two principal Windows lines: NT and 9x, based on different cores. User-oriented 9x line was quite unstable, but it had multimedia and DirectX, and it was compatible with pretty much any piece of hardware of the time. In contrast, server-oriented NT line was very stable, but it required more RAM and generally better PC, and you could have more issues running games or connecting peripherals. At some point, I had a PC with Windows NT, and it was perfectly fine for my coding needs. Windows XP was built on the NT core, bringing user-oriented features to a rock-solid OS, a great combination. The next Windows in line, Vista, got very little love with its reputation for being slow, unreliable, and generally not worthy as an upgrade. Following the usual pattern, Microsoft combined all bugfixes and improvements into Windows 7. Like XP, it was also universally loved.

Things went south with Windows 8. I’d have to say that despite being of a different lineage, Windows XP caused no troubles for the existing users. It looked like an evolutionary step in the the Windows 95 line. Windows before 95 (like another much-loved 3.1 version) clearly belonged to another generation, but the 95 to XP line was a perfectly smooth ride. Windows 8 coincided with the arrival of modern smartphones (2012). Microsoft wanted to have its own smartphone and apparently also wanted to have the same "look and feel" on both desktop and mobile platforms. We do see convergence between MacOS and iOS, but the attempt to cross desktop and mobile proved to be completely unsuccessful: non-overlapping tiles instead of regular windows were unusual and inconvenient. Now we do have tiled managers like Hyprland, but even now that’s not what most people prefer on their desktops, and it was definitely much less usable in the era of smaller displays.

Don’t call me conservative, but this interface was designed by someone who obviously never had to use it daily. It was not just "unusual", it was plain bad, and what is worse, it was half-baked. Old Windows had literally layers upon layers of functionality. Microsoft did not expose many of these features in the new UI even today, in 2026. What they decided to do is to create a sort of "dual interface": when you go open settings and navigate slightly off the beaten path, the system would open an old-school dialog taken straight from Windows 7 if not earlier version. They are still upgrading Windows interface bit by bit, which in practice means that:

1) Whatever you learn now, won’t work tomorrow once they rewrite some other piece of the interface. 2) You’d probably better off just running old and trusty tools, such as control command for the old Control Panel or ncpa.cpl for the Network Connections dialog.

Worst of all, the new interface is almost universally worse than its predecessor. For example, you cannot open some Settings section, then, suddenly remembering that you have to tweak something else, open another Settings instance and do something there: nope, in 2026 you are only allowed to have one window at a time. Whatever you had open in Settings will be closed, and you’ll be brought back to the starting tab. Only recently they fixed the Wi-Fi connection dialog. Imagine you receive Wi-Fi SSID and password by mail. Can you open the Wi-Fi connection window and copy&paste your data there? Nope! You can paste SSID from the clipboard, but once you switch focus back to your mail, the window would disappear (OK, as I said, it does work now). A lot of functions are now gone or hidden. For example, I could add an app to autostart simply by dragging its shortcut to the Startup folder in the Start menu. Now the only way to access this folder is to open Run command dialog and to type shell:startup. No wonder that more and more Windows user guides prefer to provide PowerShell scripts or registry hacks than to force the users to go through all these hoops and perform actions that won’t work after then next update.

There are of course other pain points, such as ads in Start menu, compulsory cloud services like OneDrive, ubiquitous Copilot and so on, and so after. I understand there are many hidden improvements coming with each new version, but what I see as a user is an endlessly growing list of annoyances: let’s place Start in the taskbar center, let’s make the taskbar immovable, let’s demand that the computer has a TPM chip, let’s save documents in the cloud by default, etc., etc. In other words, growing friction is a real thing.

What is instructive about the modern Linux is that there are no killer features or overnight successes there. What I see is a slow and steady improvement going in lockstep with Windows deterioration. In times of Windows XP or so, Linux was a strictly server-oriented operating system that had little to offer to a regular user. However, over the past 20 years, it got:

I planned to try out Linux for long time, but one obvious obstacle on the way was the expectation of high friction. Probably, this mood helped, because I was surprised how little friction I experienced. Now, let me quickly add a disclaimer that I am just a home user with pretty generic needs except software development, and many complaints I see online are not relevant for me. People are not happy with the lack of group policies, poor support of this or that Windows technology, lack of drivers for certain hardware, etc. I understand their needs are different, but in my case I already use mostly open source software, so moving between platforms turned out to be mostly seamless.

What is not there:

Thus, in a nutshell, configuring most of my daily software instruments was a piece of cake. Perhaps, the most surprising discovery (which seems sort of obvious in hindsight) is that Linux is actually much better for running old Windows software (such as games) than the current Windows. On Windows, they retire certain compatibility layers nearly with every new version. For example, Windows 10 was the last version that supported Windows 3.1 applications. Compatibility with Windows 9x line is absolutely hit and miss now: some games work, some do not, and I can never figure out why. In contrast, running Windows apps under Bottles is like working with DOSBox: there is the whole system whose job is to keep compatibility all the way down, and if something works under Bottles today, it will probably continue working in any foreseeable future. I am yet still to experiment with this system, but it seems that Bottles will be my to-go method to run old Windows games. DOSBox is fine for DOS and Windows 3.1, but it’s much tricker to use it to run Windows 9x software.

If it all sounds too good to be true, then…​ kinda yes, it is good? My previous experiences with Linux were not very enjoyable. Everything felt a bit too clunky, and there was too much of a friction, too much of arcane knowledge to possess, like what arguments tar has or how to exit from vim (ha-ha), or what combination of attributes this stupid file needs to start working, or why even the basic file operations have to be done via command line.

The present situation is a result of convergence from both sides and the general growth of complexity in the outside world. Life used to be simpler. On Linux, you had to learn vim and bash, sed and awk, and generally have the time and energy to master a lot of complex stuff to achieve very simple goals. On Windows, there was a certain well-known collection of user-friendly tools to get things done: Microsoft Office, Photoshop, WinZip, Nero Burning ROM, etc. To install software, you insert a CD, the autorun subsystem executes the installer, you get a new shortcut in the Start menu.

These days, Windows became much more complicated. You find some software, it expects you to run a PowerShell script, or have npm or git installed; some tools want you to have Python 3.9, others insist on Python 3.12, you got to generate ssh keys and make sure your firewall keeps the right ports open, and so on. Instead of the regular settings UI you sometimes have a JSON file to edit. Sometimes it is much easier to run a certain configuration script than to ensure that your firewall is fine or keys are set up correctly, which means that people started to publish snippets for command line execution. On top of that, there is still this unfunny circus with UI redesigns which makes me regret every minute spent in Settings.

All these developments take away the simplicity of Windows and bring the overall experience closer to what I disliked on Linux. On the other hand, Linux managed to smoothen many of its annoyances, and even with remaining rough sides it does not look any more complex than Windows now. There are still some annoying parts, but 1) they are on par with that I have on Windows; and 2) it is absolutely possible to use a coding agent to figure out how to mount a network share or how to autostart a background service using systemd. Say, yesterday I could not make a remote access app RustDesk work with a Linux box having a discrete GPU but no display (it proved to be a complicated combo). A coding agent did help to identify and resolve the issue (it turned out to be quite technical and not interesting). For the sake of balance, on Windows I spent many days hunting for events that used to wake up a sleeping computer to install updates. If you think it is straightforward, just check online how many different advices you will be given. It seems that heavy reliance of Linux on configuration files and logs turned out to be a great advantage in our times, since coding agents can do a lot of troubleshooting and config work in automated mode.

There are things I still miss in my old setup, and sometimes the overall experience seem right but does not entirely feel right, probably due to certain muscle memory. You do what you’ve always used to do, but it does not quite work your way. Still, I would repeat that I expected a much bumpier road.

The realm of Linux still has a lot of underlying complexity that reflects its own historical turns as well as the growing complexity of the world in general. I guess there is nothing to be done about it. There are systems that attempt to hide much of their inner workings from the user, but I am more worried about leaky abstractions and invisible structures ready to collapse than about bona-fide complexities that can be understood and dealt with properly.

I am still a beginner, and my understanding can be a bit off, but I’ll try to summarize my findings to the best of my ability.

So far, I have tried several flavors ("derivative distros") widely advertised as "beginner-friendly": MX Linux, (K)Ubuntu, Omarchy, and CachyOS. It is important to understand that essentially any Linux flavor is still the same OS under the hood, but the actual user experience may greatly vary. Each of these systems is essentially a preconfigured package of a "base distro" Linux. For example, MX Linux and (K)Ubuntu are based on Debian, while Omarchy and CachyOS are based on Arch Linux. From the user perspective, the difference between the packages is in the list of included apps and default settings, and having enough energy one may, "reconfigure", e.g., Omarchy into CachyOS.

However, it is also important to understand that the actual Linux core is much smaller than what we perceive as a core in Windows or MacOS. A lot of pretty basic functions is technically provided by the "apps" rather than the "core". For example, historically Linux had no Windows-like GUI, so it is a job of an app to provide one. Less grand cases include a clock app, a keyboard layout switcher, an application launcher (which does the job of the Windows Start button). It is easy to see that the choice of a different launcher, a taskbar, or a desktop shell greatly affects the way the system looks and how it feels to use. I first tried Omarchy, and its Hyprland-backed interface turned out to be a gap too wide to bridge. It went against all my habits, so I decided to abandon it for now. Same with Ubuntu: its GNOME desktop environment is usually described as "MacOS-like". It very well might be, but I am not a MacOS user, and it simply didn’t click with me. In contrast, CachyOS, Kubuntu and MX Linux include "Windows-like" KDE Plasma desktop. Even the same KDE Plasma can be configured slightly differently, so these three systems look similar but not identical. There are quite many desktop environments, but I think for a typical new user in 2026 the default choice should be between KDE Plasma and GNOME. Adventurous souls might try Hyprland. Sometimes the same distro can be packaged with this or that desktop environment, and this is why we have Ubuntu, Kubuntu, Lubuntu and so on.

"Base" Linux distros also differ in the choice of apps they supply. Here the differences are quite annoying because they generate complexity with no perceived benefits. In Ubuntu, you install apps with apt, in Arch Linux you do it with pacman, in Alpine Linux it is apk. If you want to configure a system service, it might be done via SysVinit or systemd. If you want to download a packaged software file, it will have a different format for different distros (the reasons behind this are mostly historical and political). Even a choice of system tools for checking basic hardware info can be different. This is why even for simple tasks like reading physical memory configuration or listing open ports there are several distinct tools, and attempting to copy&paste a command from Google results would often give you a "command not found" error. This problem is exacerbated by the blessing of open source: there are many popular utilities that do not belong to standard Linux distros, so you see them used everywhere but they do not come preinstalled. This is merely an annoyance if the tool in question is a couple of keystrokes away, but becomes a pain if you are offline or can’t install extras, so you have to figure out what actually exists on your machine fist. Again, here we see some convergence between two worlds: even on Windows nowadays people often presume you have Python, Node.js, or Git.

The need to understand the differences between the distros and even versions of the same distro gets an upward turn when you want to ship your software to the wide world. It might get unpleasant. Say, Double Commander currently ships 13 Linux packages. As a beginner user, however, you don’t need to know all that. You only have to make sure to read tutorials that are relevant to your specific base distro. Ideally you should know how choose the right package to download when faced a list like Double Commander’s, but in practice even this rarely happens, as you don’t really have to install packages from websites often.

Having decided on the desktop environment, you have to choose the base distro. From the beginner user’s perspective, the choice primarily boils down to the software update policy. It might sound strange, but here is the logic. Some users want to get the latest updates as soon as they arrive, and in this case Arch is your choice. I have Arch-based CachyOS on my desktop machine, and this is a fine OS for a workplace. Updates are never compulsory, but you do get them often. Other users need a stable system that is guaranteed not to break as a result of an update. This what Debian is for, and this is why Debian-based systems are popular for servers and all kinds of unattended machines that are supposed to be stable and just work. You might say, then Debian is the way to go in any case, because 99% of OS updates are fixes of obscure bugs and minor security issues, so what’s the benefit of upgrading it often unless you enjoy clicking the "update" button and rebooting your computer? What we care about is user software (e.g., VLC Media Player), because these are the parts that matter for our daily experience.

Here we face one important finding: user apps are much more tightly bound to the OS version on Linux than on Windows or MacOS. When you download "VLC for Debian", you get its version linked to the current Debian release, and you will get it updated with the next release, which happens once in two years. There are exceptions, e.g., for security patches. You can also circumvent this system and do get your VLC updated, but it would be essentially fighting with your OS philosophy. If you are planning to update often, just install Arch and call it a day.

The paragraph above might look like an important but still somewhat isolated point: okay, if I install Arch, I’ll get updates often, if I install Debian, it will be once in a while, end of story. Unfortunately, this "Linux way", which looks like a pure policy decision at a glance, causes yet another annoying growth of complexity that warrants discussion.

These days, when platform vendors have a choice, they distribute software via curated stores. This is how Google Play, App Store, or Nintendo Store work. Historically, Windows had no official storefront, and it was a software developer’s responsibility to setup a distribution channel. Now there is Windows Store, but few people care about it. There are essentially no rules for packaging Windows apps: it is your job to ensure it works, and it is your problem if it does not. The de-facto policy of most software developers is a) either make your package self-sufficient or b) rely on common standard libraries such as Visual C++ Redistributable or .NET Runtime but make sure the user installs them. A typical Windows machine has numerous versions of these libraries, which can now co-exist as Microsoft seem to finally have cracked the DLL hell.

The default Linux approach is (slightly) surprisingly geeky and not really developer-friendly. However, they have a bigger goal in mind: to keep the whole ecosystem stable and secure, and user apps are considered its integral part. In practice these goals translate to certain hard decisions. Every Linux distro has a concept of its official "stable" repository, which is somewhat like Google Play, but all packages there are free and open source. If you have packages installed from there, they will be updated along with any system packages in due course. If you want to get your software there, you’ll have to satisfy certain technical and licensing requirements. What matters for us now is that 1) you cannot link statically to a third-party library as it has to live in its own dedicated package, 2) there is generally no co-existence of component versions: if a library in question is already in the repo, your software has to use its current version, 3) you cannot circumvent these rules, e.g., by copying 3rd party source code into your project and thus making it "yours".

This system has clear advantages for the end user. There are no copies of the same library scattered around the system, apps are generally lean as they link dynamically, and there is no need to keep "redistributables" for Visual C++ all the way back to 2005 or so. There are also more subtle advantages: if a library gets a critical security fix, it will be immediately enjoyed by every package that uses it. These benefits, however, come at a cost. For example, if your software needs a certain library v2, but the stable repo is still on v1, all you can do is to curse and suffer. I am of course kidding, in the world of open source you can’t really prevent people from installing whatever they want, but this path is fraught with various sorts of slippery slopes.

As a user, I find the system of a single master repo attractive: if your packages come from a single source, you can update them all with a mouse click. This is a Google Play-like experience rather than what we have on Windows, where each application either annoys you with "update me" popups when you are trying get your work done or simply stays without updates until you decide to go check if there is a new version available. There are attempts to fix it: community-driven Chocolatey packages provide Linux-like experience, and I use them when I have a choice. Unfortunately, not every good software has a Chocolatey package, some of them are broken or not updated regularly, so it is hit or miss.

On Linux, you can download a package from anywhere and install it. Such packages can link whatever they want and come with any licenses: there are no technical limitations preventing you from running any binary on your own machine. However, by installing a local package, you are essentially switching to Windows-like experience, losing any connection with the upstream package provider (in other words, you’ll have to download and update it on your own from now on). As a user, you can get the best of two worlds by adding a custom repository to the master list of sources checked by the package manager on your machine.

Arch Linux sort of legalized this approach by introducing Arch User Repositories (AURs). These are community-driven repositories where beta-version or for whatever other reason "not main repo ready" packages end up. A package manager (to be precise, custom yet popular managers like yay) would install all updates, whether they come from the official repo or from AUR sources.

Unfortunately, it turns out that developing a widely compatible package for Linux is not an easy task. I don’t have enough knowledge to speak confidently, but the general gist is that on Linux everything is much more tightly integrated than on Windows. On Windows, you can use the latest compilers and yet set Windows 7 as a target platform, for example. As a developer, you basically decide: this thing should be executable on Window 7 32-bit, so you set some checkboxes and dropdowns inside your Visual Studio 2026, and voila, it works. On Linux, your OS is your development environment and is your target system, so if you compile on the latest Arch, the resulting binary might not be compatible with an older Debian.

High compatibility is still of course achievable, but many authors take an easier route by packaging their apps into AppImage or Flatpak containers. These technologies achieve compatibility by forcing older but widely compatible components (AppImage) or rolling up a sandbox environment with all required dependencies (Flatpak). From the user point of view, however, these are "yet another sources to manage", and of course you have to trust a package that does not come from an official repo. Flatpaks are normally hosted on Flathub and get updates from there, and AppImages are expected to self-update or contain embedded update URLs.

I feel the raise of AppImages and Flatpaks kind of defeats the original purist vision of a stable and secure ecosystem, but in our complex reality forcing everyone to adhere to the traditional rules is like attempting to return to the pre-Electron days. We aren’t in the best of the timelines, but the threshold of doing things "the right way" is often simply too high, especially for hobby developers.

As a user, I am somewhat annoyed that some of the apps I install come from the mainline repo, some come from AURs, some from Flatpaks, and some are AppImages. (On Arch, it seems that there is an AUR source for almost anything, so it is less of a problem.) However, there are tools designed to smoothen the experience. Shelly package manager on Arch can upgrade packages coming from all four mentioned sources.

Before we proceed to the next section I have to add for the record that if app management sounds difficult, it is because I made it sound this way. I dig deeper because I want to have centralized updates for all my apps. However, it is not really necessary to think about it too much. In practice, you can always go straight to the project homepage and install it the way its maintainers suggest.

One real pain point on Linux is fortunately on its way to obsolescence: transition to Wayland. Previously we discussed that a desktop environment is just an app, not an integral core part of Linux. If we look at the lower system lever, we’ll see that even the whole GUI subsystem that draws windows and buttons is not a part of the core either. Historically, the de-facto standard for drawing UI primitives was the X Window System, a software dinosaur that got its first release in mid-80s. The Linux world is now transitioning to a newer GUI subsystem called Wayland. This process is generally more or less done, but you can still stumble upon apps displaying visual glitches under Wayland. Somewhat surprisingly, while the root cause is Wayland, apps can behave differently under different Wayland-backed desktop environments. I had to tinker with Hyprland to make many apps usable, but KDE Plasma works perfectly fine for nearly all apps. Still, it is better to be prepared as you never know where this issue would pop up. For example, even the newest Unity Editor does not work well by default: it scales its UI in such a way that you need a magnifying glass to see anything. Fortunately, the fix is easy: just assign a couple of environment variables, and you are fine. This way, I can’t say the transition is absolutely over, but it is perfectly possible to never face any issues.

I think this is all I wanted to say about my Linux experiences. Time will show how well I’ll be able to adapt my habits. I do a lot of work on a laptop, which I have no courage to repurpose for Linux yet, but the desktop setup so far looks fine. To reiterate, I think the present state of Linux is a great example of incremental improvements: despite all snags on the way, little by little the open source community managed to resolve numerous pain points of regular users. It is a common sentiment that Linux is still not suitable for everyday needs of a non-geeky user. This is probably true, but definitely less true than a few years ago. Yes, you are expected to learn new ways, do at least some very superficial reading, and don’t be afraid to paste commands into your terminal. To me it does not sound intimidating, but I am far more geeky than the average. There is also a surprising help from agentic systems: arguably, one of the most daunting Linux experiences is to troubleshoot and fix issues. Essentially, if something does not work, you are on your own, and the process of troubleshooting would almost definitely involve reading documentation, very long logs, and editing configuration files. Agentic systems are really good at it, so now Linux comes with your personal computer guru. In this situation, there are no reasons at all to be afraid of Linux anymore. Just try it out.