This content originally appeared on DEV Community and was authored by Shubham Patil
This is an article originally from Medium. I have decided to switch from Medium to dev.to and import all my posts from there.
So I’ve been wishing to switch to Linux for about a year and a half now. There was just something intriguing about Linux that made me want to use it.
I used to use a 2019 Macbook Air (I still do but not very often), but the speed of the thing kills me. Sometimes I have a couple VS Code and browser windows open and it just starts lagging a lot. Not to mention the keyboard, which (due to my fault) ended up requiring a certified Apple Repair Store to fix an arrow key. The reason is not entirely me being dumb because I noticed that the key was sticky. This article is not going to be about the performance of the Mac but it was one of the reasons I wanted to switch to Linux.
My first experience with Linux was installing Ubuntu on a Lenovo Ideapad 310 about a year ago. That laptop got very slow due to it’s drive being a hard drive, not an SSD.
When I first installed it, I encountered an error that basically left me unable to install the operating system. I decided to re-download and re-flash the .iso onto the USB drive and try installing it again. This time, it actually worked!
Ubuntu was very fascinating for me and it sparked an intrigue in me for Linux. I then tried multiple distros (all of them being Debian based), and finally just settled on Ubuntu.
However, I didn’t really use this laptop much and didn’t use Linux commonly. I kept using my Macbook for a year or so until the golden opportunity to use Linux arose: building a PC.
If you are interested, here is the part list (here is the link if you want to modify it):
All in all, the entire PC came for about $808 including tax!
So when the PC came, I assembled it (which took more than seven hours because this was the first time I did it) and went to sleep at 12 AM with the PC 98% complete (I had to change the PCIE slot of the WIFI card).
In the next day or two, I opened up my Macbook and started searching on how to install Arch Linux. I was really hesitant about which distro of Linux to install.
If you didn’t know already, a distro is kind of like a flavor of Linux. Think of it like ice cream. There are different flavors like chocolate, strawberry and vanilla, each having their own pros and cons.
I had a choice of Debian based distros or Arch based distros. The former being stuff like Ubuntu, Debian, PopOS, Linux Mint etc. etc. For the latter, I had options like Arch, Manjaro, Arco and Garuda.
The main reason I went with plain Arch is because the experience of setting everything up myself was really intriguing. I also thought about package availability. When it comes to installing applications, Linux is different than macOS or Windows. Power users of either two operating systems equally hate their “App stores” and normally install programs through the application developer’s website. On Linux however, these “app stores” are actually quite good and are basically the de-facto way for users to install programs. Linux distros have something called a package manager which is an interface into these “app stores.”
On top of having packages, Arch Linux has something called the AUR, which is a set of programs that were adapted to run on Arch Linux by the Arch Linux community. This was cool because instead of going to the application developer’s website for programs not in the official Arch package list (which in most cases you would have to install the application manually), I could just install it like a normal package!
In the Linux community there is a bit of negative stigma surrounding the Arch Linux installation process in the form of the installation difficulty. I admit that if you are not comfortable using the command line/the Bash shell, you should definitely not install Arch Linux and instead go with a GUI option other than Arch like Ubuntu or Manjaro and learn the terminal from there. The Arch Installation process relies heavily on terminal usage and if you don’t know how to use it, you could seriously mess up your computer’s existing installation or have to restart the entire installation from Step One.
Now that I chose Arch to be my distro, I actually had to install it. For this, I used the official Arch wiki page’s installation guide and this guide from It’s FOSS. I also got guidance from a couple Discord servers I was a part of to see if I was really doing things the right way.
I didn’t make a swap partition as my computer had enough resources for that and I didn’t make a home partition as well because creating a user later would account for that.
Note: for the step that used pacstrap, I installed network-manager as well because that would help me do WIFI related stuff post-installation.
After installing Arch Linux, I simply rebooted the computer, took out the USB drive I had the .iso on, and arrived at a tty screen with a user and password prompt. For this, I entered the username root and the password, which I setup when installing Arch Linux.
From here, I made my own user with the useradd command, which created it’s own /home/USERNAME directory.
Now I had to get a “GUI” up and running. I had used KDE and GNOME on my old laptop before but I wanted to try something called a tiling window manager. If you didn’t know, tiling window managers basically automatically resize windows based on available space, so instead of having a bunch of windows overlapping each other like macOS or Windows, all of them are on the screen and visible to the user. For this, I was going to use a tiling window manager called dwm .
dwm is a bit different than another tiling window manager called i3 because you edit the source code (which is a header file utilized by the C language) directly to tweak and customize it.
Along with dwm, I installed dmenu which basically is like Spotlight except that it only opens applications that are in the PATH environment variable. The applications themselves are just scripts running, so when I launch an application through dmenu, it’s really just executing a script to launch that program. I didn’t really customize dmenu except loading in a custom font.
For my terminal, I decided to use the Suckless Terminal, also known as st. I mainly chose this because I heard it was nice and I wasn’t ready to try out stuff like alacritty or terminator just yet (those are other terminal emulators by the way).
Oh yeah I forgot to mention something similar about two of the Suckless projects mentioned (dwm and st): they can’t be installed with a package manager. In essence, because of the concept of editing the source code directly, we have to manually install these tools. You can do that by running sudo make clean install after tweaking the source code (a file called config.h mostly). Notice how we couldn’t use a package manager (by default the package manager on Arch is pacman) to install this.
Note: For dmenu, you can install it with a package manager
To modify st terminal, you need to install things called patches, which essentially are .diff files that you need to patch to the source code to add new features. For example, a patch you chose could add scrolling to the st terminal, and you would have to run a command to merge those changes to the actual source code. This video is an excellent tutorial on patching the terminal.
For the prompt on my terminal, I decided to use something called Starship Prompt. It is an excellent cross-platform prompt which is really colorful and gives you a lot of data about the current directory you are in, which I find very helpful, especially for git. It is really fast (it’s written in Rust, which is a speedy programming language). You can find more about the prompt on their website.
To get those special symbols in the prompt, I used the FiraCode Nerd Font, which gives the ability to use these special symbols. You can download it here.
So remember those community package repositories I mentioned earlier? That is called the Arch User Repository, more commonly known as the AUR. To install a package from the AUR manually would consist of cloning repos from the AUR and running makepkg or whatever, which is highly inconvenient compared to a package manager.
This is why I installed an AUR helper called paru. If you don’t know what an AUR helper is, it basically eases the process of installing packages from the Arch User Repository. First, to get all the tools needed to actually install the tool, I ran sudo pacman -S --needed base-devel in my terminal so we can use the required command line utilities to install it. To actually install it though, I basically did a git clone [https://aur.archlinux.org/paru.git](https://aur.archlinux.org/paru.git). This makes a directory on our machine that contains the git repository for paru. I went into the directory of paru by running cd paru. Then I ran makepkg -si, to install paru.
In summary, I ran these commands to install paru (this guide helped me):
sudo pacman -S --needed base-devel
git clone https://aur.archlinux.org/paru.git
cd parumakepkg -si
Then, I could install AUR packages similar to installing them with pacman!
If you want to find how to use paru you can check the guide I linked above as it gives you the basic commands you need to use it.
One of the main packages I installed was VSCode. The package in the AUR was named visual-studio-code-bin and I installed it by running paru -S visual-studio-code-bin.
Installing AUR packages takes a bit more time than installing packages with pacman so don’t fret if it’s running scripts for a minute or so.
To set my desktop wallpaper with a tool called nitrogen. This package is in the base Arch repos so you don’t have to worry about using paru. I ran sudo pacman -S nitrogen in my terminal to install the package.
To set the wallpaper, I ran the command: nitrogen. However, there is one more step to get your wallpapers running. nitrogen only checks for images in the certain directories that you tell it to. By default it’s set to the Desktop directory. You can edit these directories manually.
To do this, press the “Preferences” button in the bottom right.
Then, set the directories with the “Add” and “Delete” button in the directories section in the GUI that pops up.
If you press the “Add” button, a file manager will popup so you can navigate to the directory containing your wallpapers!
That’s all well and all, but the wallpaper won’t stay after you restart the computer or simply end your dwm session by pressing Alt + Shift + Q. For this, I needed to run nitrogen --restore. It’s not great to run that every time you start your dwm session, so I had to figure out a way to do it on auto start.
To run commands on auto start, I installed a patch for dwm (like the st terminal) which ran a script called autostart.sh in the ~/.dwm/ directory which ran every time I started dwm. This enabled me to put nitrogen --restore & in that autostart.sh file (If you were wondering what the ampersand [the &] is doing there, it basically tells your shell to do the task in the background).
If you have been using dwm for sometime, you might be wondering why I don’t use the .xinitrc file. For those of you who have no clue what I’m talking about, let me explain. Since I’m using Arch Linux and I started from scratch, when I boot up my computer, it just plops me in the command line. This is extremely fast and when I want to start up dwm, I just run startx in the command line.
This startx command already has a file to execute commands when dwm starts called .xinitrc. I didn’t opt to use that just so that if I ever stop using startx and start using a login screen (more formally known as a display manager), I can still do all the things on autostart without having to patch dwm with the autostart.sh thing.
This whole autostart.sh thing allowed me to setup update my status bar in dwm really efficiently. In that dwm folder, I had another file called changebar.sh which basically was the script to change the status bar in dwm. If you didn’t know what the status bar in dwm is, it is in the top right.
By default, this is set to something like dwm VERSION_NUMBER , but I customized it with the changebar.sh file and a command that was xsetroot -name "whatever you want in the status bar". Also, if you were wondering how I customized the color of the top bar and everything else, check out this video.
This is where I use changebar.sh. In my autostart.sh file, I have this code written out:
while true; do
/home/shubhampatil/.dwm/changebar.sh
sleep 5s
done
This basically enters a while loop that goes on forever, activating that changebar.sh script and sleeps 5 seconds later.
You might be wondering what is in that changebar.sh file. Well, here it is:
VOLUME="$(amixer sget Master | grep -e 'Front Left:' | \\sed 's/\[^\\\[\]\*\\\[\\(\[0-9\]\\{1,3\\}%\\).\*\\(on\\|off\\).\*/\\2 \\1/' | sed 's/off/M/' | sed 's/on //')"
TIME="$(date '+%a %D | %I:%M %p')"
xsetroot -name "| ? $VOLUME | $TIME"
bash
This basically gets the current volume and gets the current time and displays it in the status bar.
Now, let me talk about volume control with dwm. For this, I had to edit the source code for dwm.
In the config.h file in the source code, I added this at the top of the file:
#include <X11/XF86keysym.h>
/* volume keys*/
static const char \*upvol\[\] = { "sh","-c", "amixer sset Master unmute; amixer set Master 5%+; /home/shubhampatil/.dwm/changebar.sh", NULL };
static const char \*downvol\[\] = { "sh","-c", "amixer sset Master unmute; amixer set Master 5%-; /home/shubhampatil/.dwm/changebar.sh", NULL };
static const char \*mutevol\[\] = { "sh","-c", "amixer set Master toggle; /home/shubhampatil/.dwm/changebar.sh", NULL };
Then, I added the lines
{ 0, XF86XK_AudioLowerVolume, spawn, {.v = downvol } },
{ 0, XF86XK_AudioMute, spawn, {.v = mutevol } },
{ 0, XF86XK_AudioRaiseVolume, spawn, {.v = upvol } },
To the keys[] array in the config.h file. After that, I just ran sudo make clean install again in the dwm source code directory, restarted dwm, and it worked! Now, whenever I pressed the volume up/down/mute keys on my keyboard, it would change the volume output of the sound.
One more thing about my computer: time. I found out that the clock on my computer got a minute out of sync with the rest of my devices.
To combat this, I installed a package called ntp(Network Time Protocol), which allowed me to sync my clock to servers on the internet that had the correct time.
This package I installed generated a .conf file, which allowed me to change the default servers to pool.ntp.org‘s servers.
My config file looks like this (located at /etc/ntpd.config)
# Please consider joining the pool:
#
# http://www.pool.ntp.org/join.html
#
# For additional information see:
# - https://wiki.archlinux.org/index.php/Network_Time_Protocol_daemon
# - [http://support.ntp.org/bin/view/Support/GettingStarted](http://support.ntp.org/bin/view/Support/GettingStarted)
# - the ntp.conf man page
# NTP pool server setup
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org
# By default, the server allows:
# - all queries from the local host
# - only time queries from remote hosts, protected by rate limiting and kod
restrict default kod limited nomodify nopeer noquery notrap
restrict 127.0.0.1
restrict ::1
# Location of drift file
driftfile /var/lib/ntp/ntp.drift
You can find more info about this pool.ntp.org stuff at https://www.ntppool.org/en/use.html.
I then had to setup my printer. Printer support with Linux is sort of complicated. I had to install the cups package. Then, I ran sudo systemctl enable cups and sudo systemctl start cups. The former made it so that the cups service would be enabled on startup. The latter basically started it right now.
Then, I went to localhost:631 in my browser to configure my printer. I went to add my pritner but discovered that the driver for my printer wasn’t present. To get these drivers, I had to install the hplip package, since I was using an HP printer. After that, the printing functionality worked properly. To find more about printer setup on Linux, I would recommend you to watch this video.
Using raw Arch Linux or Gentoo (another Linux distribution) is very different from something like Ubuntu or Manjaro. Not everything is pre-setup like you expect. Even if you install a GUI (called desktop environments) like Gnome or KDE Plasma, you will have to install some packages to get the printer setup correctly, for example. Overall, I’m glad that I tried Arch Linux, and if you’re comfortable with the Linux command line, I would suggest it too. Although, if you’re not comfortable using the command line just yet, I would suggest something like Ubuntu or PopOS!. If you’re an “intermediate” Linux user, and really want to try out Arch, I would suggest using Garuda Linux or Manjaro Linux. I am by no means an expert at Linux and I do have a lot to learn but I decided to jump in the deep end to challenge myself. In the end, Linux is still Linux so don’t feel bad about using something like Ubuntu versus raw Arch.
Another difference I am yet to call out is the nature of Arch Linux’s updates. Arch is something that has a rolling release cycle. This means all the packages that make up your install are updated on an on-going basis, instead of the operating system itself with all the packages being updated every 6 months (like Ubuntu). The latter method is called a stable release cycle. To find out if you are better suited for rolling release distro or a stable release distro, check out this video.
By Shubham Patil on August 15, 2021.
Exported from Medium on August 15, 2021.
This content originally appeared on DEV Community and was authored by Shubham Patil
Shubham Patil | Sciencx (2021-08-15T18:34:23+00:00) Using Arch Linux. Retrieved from https://www.scien.cx/2021/08/15/using-arch-linux/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.