My Experience with Linux
This article is mostly inspired by my experience with Arch Linux, playing with it over the last week or so. Most of the article focuses on it, but I’d decided to talk about my experience prior to that, to show where I’m coming from and provide context.
In school, I had a class called “Computer and Network Engineering”. It was much less glamorous than it sounds, but it covered some interesting things like network protocols and hardware, as well as virtualisation and working with Linux. I had heard about Linux before, but I never used it. That class, where we’d use Hyper-V to virtualise Ubuntu on a Windows 10 host, was my first time ever using a computer on something other than Windows. But it wasn’t a glamorous experience. For reasons unknown to me at the time (and, truth be told, still), the machine was very slow. This was not a problem with the hardware, as the computer I used had a Core i7 processor and 16 GB of RAM. Still, I was limited to a resolution of 1024x768, and the VM window seemed to never exceed 15 frames per second.
Fast forward a little over a year, and I found myself installing Linux Mint, a derivative of Ubuntu, on that same laptop – not as a VM, but as a permanent replacement for Windows. I’d heard that both Mint and Ubuntu were great for beginners, but I chose Mint because I’d heard that Ubuntu had some questionable practices regarding tracking, and because it uses the GNOME desktop environment by default, which I really dislike. My experience was nice, and it prepared me for the real deal, three months later. I was okay with trying out a new OS on the laptop, because it was my secondary machine, one I’d use to occasionally read stuff in the living room, or take with me outside. The vast majority of my time, however, was – and still is – spent on a desktop computer, on which I still had Windows 10, and the “three months later” I mentioned is when I finally broke ties with Microsoft and replaced the OS on that machine with Linux Mint, as well. The old system was getting buggy and bloated, and I felt that switching to Linux was a natural progression in my quest for better privacy. The switch was, for the most part, painless. Modern FOSS developers have done a great job in making their systems accessible, and Mint is about as plug-and-play as Windows, for the most part. There were some things that I had to iron out, for example the unusual mouse settings that made FPS games a pain, but these were not common, and very quickly I had a machine that was faster, freer and more private than what I’d had before.
People unfamiliar with Linux have a tendency to view it as something that’s “out there”, that you need to be a skilled computer user to use it. This is very much not true, as systems like Pop OS, Manjaro and Mint show. A lot of the necessary applications are provided out of the box, and the ones that aren’t are easy to get through built-in software managers. Customisation and personalisation are also easy, available through GUIs and menus that, while different, aren’t any more difficult to use than their mainstream counterparts. If most of what you do is browse the web, watch movies, listen to music and write things, you can get the system installed and filled with all the necessary applications a fair bit faster on Linux than on Windows. Although I am a bit beyond an average computer user, the conception that this is what allows me to use Linux would be false. In my opinion, what allowed me to dig into it was willingness to tinker. I am practical, learning little beyond what I need; the crucial fact is that, instead of adjusting my needs and wants to my knowledge, I do it the other way around. When I decided that I’d like to have my own website, I knew absolutely nothing about setting up a server, but instead of dropping the want, I simply went out and figured out how to do it. I am alright with Linux having occasional bothersome quirks, because if a problem occurs, I just look for solutions. I suspect, however, that this isn’t a character trait, but just a side-effect of my interest in computers; if I had a car and it broke down, I couldn’t be arsed to figure out its hows and whys, I’d just take it to a mechanic and have them fix it for me. Computers are interesting to me, so when something breaks, finding a way to fix it is not tiresome, but exciting.
So that’s how it is, and I’ve been using Linux Mint as a daily driver for 4 months now. Most things are working well, but there is one application, however, that I feel compelled to use, but that I have huge reservations about – Discord. It’s a social media application with chat and voice communication that’s very happy to gather user data; not just the stuff you put into it, like messages and images, but also things outside of it, like scanning active processes to search for running games, so that it can display them on your status bar. This is a huge drawback for me, but at the same time it is where almost all communication for multiplayer games is, so if you are at all interested in playing with other people, Discord is not really something you can avoid. In search of a solution to this dilemma, I figured I could use a virtual machine. Having a machine dedicated to nothing but Discord means that its invasiveness is entirely contained in a shell that has no personal data at all. It seemed like it could work and, truth be told, I just find virtual machines to be incredibly cool, so if I could get a practical use for one, I most definitely would go for it. The one thing that I had to decide was what operating system to get. I knew I wouldn’t go for Windows; it’s a bloated mess, and having it run would leave far too little system resources for gaming alongside it. Going with Linux was obvious, but there are so many choices! I felt like stepping outside the Debian ecosystem, I wanted to try something new, and a thought occurred to me: “I’m going to try Arch”.
I knew next to nothing about Arch at the time. I knew that it was a fairly popular Linux distribution, and that it was a difficult one to get into, hence the “I use Arch, by the way” joke. I thought, ‘How hard can it be?’, downloaded the ISO, made a new VM, and I found out that, oh yes indeed, it can be hard. Arch describes itself as a do-it-yourself type of OS, and this ideology extends to the installation procedure – there is no graphical user interface to guide you through it. Instead, the system loads, you’re placed on a black screen with white text (the terminal), and from here on it’s up to you how you proceed. Upon seeing this, I knew I wasn’t well-equipped to handle this, and that I’d need a guide. Thankfully, the Arch Wiki has an installation guide, which is what I used to get through it. Installing Arch really lets you see how much is abstracted behind easy-to-use interfaces in other systems. During the installation of Windows, for example, you will be presented with the choice of storage devices and their current partition schemes, and you can remove and format them to your liking with a few clicks. Once you’ve selected the partition you want, the installer does the extra stuff necessary to get it working, like creating an additional EFI partition, behind the scenes. In Arch, however, performing the same operation requires using a tool like fdisk to manually specify the name, size and type of each partition, then using mkfs to format them and lastly using mount to make them accessible for the rest of the installation process.
Some things are automated, of course; a truly manual installation would involve compiling the kernel from scratch, among other things. Arch makes things simpler for beginners by, for example, including in its repositories a base package, so that you don’t have to remember and specify every program that’s needed for basic system function; you just type in pacman -S base, and let it do its thing. My issue with it is that this base doesn’t include many things that I feel should be included in it, namely the tools you use while installing the system. After I got through the installation, I discovered that I had no internet. While the installation ISO took care of everything for me and I had internet without any extra configuration, no matter what I tried, I could not get it to work on the installed system. The solution I ultimately found involved installing a certain package, but I couldn’t get it downloaded and installed because I had no internet! Getting it from my host OS through a USB drive would surely be a lot of hassle in itself, so in the end I resorted to just reinstalling the whole thing, making sure to get the package while still running from the bootable ISO. It was actually the third time I had to reinstall it, because the first time I skipped one line in the guide and ended up not installing any boot loader (i.e. the machine had no way of detecting the system on the disk), and the second time I found out that I hadn’t set the VM correctly and was booting in BIOS mode rather than UEFI mode, which was causing a whole bunch of issues.
Ignoring the problems above, one thing that was probably to be expected, but that still was a bit surprising to me, coming from GUI-centred installers, was that the end result was still a black screen with white text; there was no graphical interface in place, the system instead resembling a DOS command prompt straight out of the 80s. Experimenting a bit more, I ended up with an Xorg display server and Xfce as my display environment. I didn’t bother with a display manager; I log in through the terminal and wrote a script to start Xorg and Xfce upon a successful login. I got Firefox and Discord on it, got the sound to work (which was a hassle in itself) and that’s pretty much it – a bare-bones system with a single purpose, that does what it should, with the whole process taking roughly 3,5 hours. Unless you play with it, though, you won’t realise just how bare-bones it actually is. For example, normally when you put in a USB stick, the system quickly opens a window, showing you the contents. In this virtual machine, however, no such thing happens, and I have to manually open the Disks utility to mount the drive. There is also no application to play media or show images, unless you install it yourself. The comparison to 80s DOS might not be all that far off.
Despite all these “shortcomings”, it has one overpowering advantage – it doesn’t lag. I mentioned that, when virtualising Ubuntu in Windows using Hyper-V, I got dismal performance. It wasn’t the only time I tried using virtual machines; I made a fair few of them, on Windows using Hyper-V, on Linux using KVM, and even tried out VMWare and VirtualBox. I installed Ubuntu, Debian, Manjaro, Windows XP, 7 and 10, but no matter the combination and no matter how I set it up, I always had horrible performance. This installation of Arch was the first (and, so far, the only) time I made a virtual machine that actually performed well. Needless to say, that made me quite excited. Besides, despite all the headaches that installing Arch involved, there was also something fascinating about it. More of the internal workings of the operating system got exposed to me than ever before, and having to consider and choose the things I used to take for granted made me wonder how much stuff is present in systems like Ubuntu and Windows that are, for the lack of a better term, bloat. I wanted to know more about what goes into a fully-featured system, and I wanted to make Arch into one.
My next [successful] install of Arch, however, would be on my laptop, not on a VM. Most of the personal data on it is just backups of the content on my main computer, so I didn’t mind losing it. I actually already wiped Linux Mint off it, and replaced it with Qubes OS mere days prior. It’s a very interesting system, but I chose to get off it because, with my current threat level, the extra security features do not quite justify the increased complexity of use. So I wiped that off as well, and got to work. My previous experience in the VM got repeated quickly, as the first thing I had to do after installing it was to reinstall it; the laptop uses Wi-Fi to connect to the internet, and to connect to a Wi-Fi network you need the iwd package, which is included in the installation ISO but not on the finished system. After a reinstall, I set about getting a graphical interface, and happened to do one rather stupid thing. You see, unless you want to personally start the interface with a command like startx, you can make a script that will start it when you log in; much like I do in the virtual machine. The problem is that I didn’t configure the Xorg server correctly, so I would log in, the X server would try to start, throw some sort of error (it happened too fast to be readable), and I would have to log in again. Of course, doing that would just repeat the start and crash of X, and so I was stuck in a perpetual loop, unable to access the system. In the process of looking for a solution, some weird things happened that I cannot explain, for I do not understand them myself, but eventually I just gave up and reinstalled the whole thing once again.
Third time’s the charm, right? I reinstalled everything, got all the right packages, and made sure to configure the X server correctly before launching it. I got LXDE installed as a desktop environment, and from here on I could start work on customising the experience. The first thing I wanted to get working was sound, and to do that I needed something to play. I copied a song from my PC onto a flash drive, and got another taste of just how bare-bones Arch is. In my VM, I can open the Disks utility to mount a drive, but as it turns out, that utility is a part of Xfce. This time, using LXDE, I had no such utility, and so to get access to the files I actually had to bring up a console and use the mount command. The sound worked out of the box, at least. Not too long after, I decided that I’m not happy with LXDE’s look, and would like something else. I knew that I wouldn’t go for GNOME, Cinnamon or Xfce, the idea of trying new things still strong, but beyond those I still had around 25 different combinations of desktop environments and desktop managers (the screen you see at the start, with the log-in prompt). I installed every single one, and kept switching between them until I settled on one configuration, uninstalling the rest. This process had its own fair share of problems, like the LightDM manager refusing to start no matter what I tried, but by the end of it I was left with a stable and functional Xorg server, SDDM desktop manager and Plasma desktop environment. It was time to get personal applications working.
The basic Arch repository has lots of popular applications, like GIMP and Firefox, but there are some that I use that are not included, like the Tor Browser. For those, there’s the Arch User Repository. It’s a collection of packages made in such a way that the installation process is roughly the same, regardless of which one you want. There are applications that could be considered software managers, connecting to and installing packages from the AUR, but Arch does not officially support any of them, instead encouraging you to get used to doing things yourself, in case you need to troubleshoot anything. First, you search for the package you want on aur.archlinux.org, then you click on the Git Clone URL to copy it, then you open a terminal and type in the command git clone [paste URL here], then cd [package name], then makepkg -si, and let it do its thing. Not great compared to Mint’s software manager, but also not terrible once you figure it out. But for a beginner, it’s not very easy. I tried installing the Tor Browser, and first ended up using makepkg without the -si argument, which meant that it didn’t resolve any dependencies, and instead just aborted the installation. That took a while to figure out, and once I got it, I had another problem in the form of an unrecognized public key. You see, before it proceeds with installation, it wants to make sure that the package is genuine, not tampered with. To do that, it uses public key cryptography, which requires a set of keys; one is in the package, and the other should be on the computer. If it’s not, then it cannot verify the package, and decides not to go ahead with the installation. Knowing this is all well and good, but… how do I add the key? Where do I get the key, and where do I put it? It took a lot of searching, and apparently you just have to use the command gpg --receive-keys [insert package’s key here].
By now I had figured out most of everything I needed to know, and got most of the needed software installed. All in all, I spent in excess of 12 hours getting the system to a finished state – far more than it would take with Windows, Mint, Manjaro and the like – but it’s a small price to pay for being able to honestly say “I use Arch, by the way”. Would I recommend Arch for beginners? Almost certainly not. If you’d like a taste of Linux, go with a more user-friendly distribution, and once you feel ready (and needy), go ahead and try Arch, ideally on a separate computer or in a virtual machine. But if you’re at all interested in how computers operate and aren't afraid of fixing problems, I think Arch offers a great practical look. It’s also why I didn’t give up halfway through: yes, some of it was frustrating, and some of it was tedious, but most of it was still good fun.