I've noticed there's a significant lack fo this. The ArchWiki doesn't have a formal guide on this, and while there's a lot of videos out there, there's not as many written articles, and very few of them are as comprehensive as I'd desire. So with that, I wanted ot fill the void here.
My goal in writing this is to focus on what the others miss in creating a comprehensive, full Linux desktop. I'm talking things like touchpad gestures, battery saving, and comprehensive themeing to name a few. I want to create something that's actually usable and competitive with proprietary desktops - outside of the fields it already grossly outclasses them in, of course.
With that being said, this is under a liberal license - Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International. So feel free to use this article as inspiration for your own guides! Just be sure that if you actually do take from this, you give me credit (MagusZ is a fine name for this purpose), you keep it under the same license and you don't use it for commercial purposes. I know the last clause makes it not "free" technically but hey, I don't just write these to be stolen by every cheap news site.
With that, let's get going!
The following is assumed throughout the article. Get it done before starting:
You installed Arch Linux in a working, bootable manner. This should be obvious.
You installed a DE of choice and set up a working display manager. If you're torn on this, go to my home page and read a few of the reviews, as well as my software list. A quick tl;dr - use MATE for older systems, Cinnamon for something more modern and KDE for max features at max resource cost. If you want a tiling WM, I'd go with i3. As for display managers, just go with LightDM or SDDM depending on your DE.
You have the basics installed - a web browser, a text editor, a file manager and a terminal emulator. This is basically enough to do anything. Read my software list if you want to see some selections for these. tl;dr I use Ungoogled Chromium (but Firefox works too!), Pluma/Xed/Featherpad, the DE's default file manager (so Caja/Nemo/Dolphin), and kitty.
You have a basic understanding of how Linux works internally. A lot of what I'm suggesting could cause potential damage to your system if you misuse it. In general the steps I suggest shouldn't if they're followed in order and in the way I suggest them, but blindly following instructions is VERY risky and you could easily end up with a hacked or bricked system. Be sure to read up on what I'm doing before actually doing it.
You have read up on basic Arch Linux essentials, most notably systemd usage, pacman and the AUR. These 3 skills are vital towards actually doing anything and I don't want to go over them because let's be real - these are teh selling points of Arch Linux, and you should know these before installing it. In particular, the AUR is a big factor here. You need to know what it is and how to use it manually.
First off, we want to set up where we actually install software from. There's two steps for this that I'll be going over.
The first step is to optimize your mirrors. The simplest way to do this is through reflector. This is a simple Python script that will find mirrors that fit your criteria, rank them, and then update your mirror list to match the results. Let's take this sample here (and feel free to use this!):
reflector --latest 10 --country us --age 24 --protocol https --sort rate --save /etc/pacman.d/mirrorlist
Let's break this down:
The latest part will get the mirrors that have been updated the latest.
The country will choose the country of the mirrors, based off of the country code you put in.
The age will choose the mirrors that were updated in the last chosen number of hours.
The protocol will determine the mirrors chosen based off of what protocols the mirrors use.
Sort and rate will rank the mirrors on their download speeds.
The mirrors are then saved into the pacman configuration file's mirror list. This is the risky part so be sure to vet mirrors to ensure they are secure and not serving malware.
Install reflector and run the script - of course adjusting to your own needs - and your mirrors should be nice and optimized!
There's quite a lot here, and they're all equally dangerous. I'm gonna repeat this - these repositories contain potential danger. None of these are vetted for malware, and you could very easily install a dangerous repository. With that being said, do your own research and add whichever repos you need.
However, there's one that isn't on this list that is, while dangerous still (albeit in a different way), better than any of those repos. That repo is the Chaotic AUR repository. Just follow the instructions it gives you and what do you get? Prebuilt versions of AUR packages. As far as I know these are build in public, in clean chroots with only base packages installed, so they're not adding anything suspicious outside of hte AUR packages themselves (if its malware, they will automatically still build it). They are sometimes behind on updates though, so be sure to vet that out. A good way is to search using sudo pacman -Ss (package name) and comparing the version to whats on pkgs.org.
Now that we have the Chaotic AUR installed, it's time to make using the actual AUR easier. The best awy to do this is to use an AUR helper.
Now, there are several out there. The ones I recommend are yay and paru. These two are the simplest to use in my opinion because they stay the closest to the original package manager, to te point where you can stop using pacman and stick to these alone. The two are actually rewrites of each other - yay in Golang, and paru in Rust. Paru receives more active development, while yay is in maintenance mode primarily. I use yay myself for the stability. This guide will assume you have these installed.
To install them, just do sudo pacman yay/paru and get them from the Chaotic AUR.
Have you used an x.org based machine and wondered why you can't pinch-to-zoom? That's because the touchpad driver libinput has very starved development and therefore does not implement these in the driver itself, instead relying on applications to provide it. And not all applications do provide this - in fact, most don't. So what do we do? This is, imo, a pretty important quality of life feature, and it's definitely something I want to have.
Fortunately, there is a solution out there called Touchegg. Unfortunately, the instructions on the page are wrong and only the competing software Fusuma had the right instructions. So let's get started on those!
sudo gpasswd -a $USER inputnewgrp input <--- DO THIS STEP.Now, you can use Touche to change inputs. For instance, I set pinch in to be Ctrl-Shift-+ so I can pinch to zoom.
This imo is still one of Linux's greatest weaknesses. This really should come out of the box. If we want this to happen, however, we need to fund libinput. Please donate to its parent group FreeDesktop.
Some desktop environments, such as GNOME and KDE Plasma, are planning on including this built in to their DE. Most of the others, however, are not. A GUI frontend for battery saving profiles is immensely beneficial towards battery life - otherwise you are basicaly running your computer on max power all the time and that takes up a lot more battery for unneeded CPU power.
There is a tool for htis called Slimbook Battery. This originates from the Slimbook company that makes Linux laptops as wel as tools for these laptops. I'd consider buying from them if I had the money but I... don't. They're kinda pricey. Fortunately, their tools are free and open source and therefore available anywhere.
Before we continue, we need to split this up into 2 groups of CPUs: - Older CPUs (Intel 7th gen and below counts for this even though id hardly call 7th gen old) - Newer CPUs (Ryzens and 8th gen Intel and up)
There are quite a few differences here: - Slimbook only supports the newer CPUs with their CPU controllers. - Slimbook Battery tool has the potential to make a lot of the older CPUs come to a crawl, speaking from experience. Even the highest setting will stlil slow it down a bit. If your CPU is older than a 4th gen Intel processor, or a pre-Ryzen AMD processor, I don't recommend using these tools.
With that, let's get started! 1. Install slimbookamdcontroller if you're using a Ryzen, or convert the deb of slimbookintelcontroller to an arch package using debtap (I HAVE NOT TESTED THIS OUT) and install that. If you know how to do this well, please put it on the AUR! Also install slimbookbattery.
The settings are pretty easy to understand so I won't go over them.
That being said, there is a final disclaimer I must give - slimbookbattery is not free software. It is merely source available - modifying it is not allowed without express permission. I use it anyways as its the best solution for what I have, but it's definitely not something I fully trust.
Let's face it here - GTK and Qt (except on KDE) out of the box are ugly. Adwaita is not a great theme, and neither is basically anything else that comes by default. Qt is in a better state assuming you're using KDE, but it could still be better. So what do we do?
While in an ideal world we'd all have good enough machines to run KDE, the fact of the matter is, not everyone prefers that. And that means we don't have KDE's theme engine. I don't know if its possible to install the theme engine outside of KDE Plasma at all, but I do know that it'd have a ton of dependencies all the same.
So what do we do? There's a themeing engine that can be installed outside of KDE that doesn't have 500000000000 depedencies. It also comes preloaded with several themes that imitate GTK themes. Welcome to Kvantum.
Just a heads up - under the hood I've heard Kvantum is quite the ugly hack. Accordingly, I would recommend avoiding this if you are doing Qt development. You definitely do not want bugs from it to interfere with your testing, and either way you should aim for the look that the end user will see anyways. I don't say this for KDE themes because let's be real, KDE is basically Qt's native environment.
Now let's install kvantum!
Install kvantum-qt5 and themes of your choice, which you can find by searching kvantum (run yay -Ss)
Run echo "export QT_STYLE_OVERRIDE=kvantum" >> ~/.profile
Log out and back in.
Out of the box, Arch Linux is what you make of it, and nothing else. That includes secure - by default, an Arch Linux install is very insecure, and it's up to you to fix that. It is also completely private in itself, but still has holes that could be used to violate that privacy.
Before I start I just want to mention - Linux inherently has a lot of security issues. It's definitely serviceable if you're just a daily user, but if you're in a really bad situation, you may wish to reconsider your usage of Arch in particular for something like QubesOS or TAILS or whatnot. Either way, don't tkae this as to say your system will be uber secure.
Also, I am NOT a security expert. I simpl yhave done a bit of research, but I do not speak authoritatively here. Do NOT take this as gospel.
Ooh boy am I about to get a lot of flame for this one.
Basically, both of htese apps use different techniques, such as kernel namespaces, to prevent applications running under them from accessing resources they are not allowed to. For instance, if you didn't want a particularly telemetry-heavy program to access the internet, you could disable this permission. It works similarly to Android.
The difference is that Firejail is the heavier and larger program. Consequently, it has significantly more vulnerabilities. This comes with Firejail having a GUI frontend, many builtin profiles, and more resources which makes it generally easier to use. It also relies on AppArmor if you're for/against that.
Bubblewrap, on the other hand, has a much more minimalistic scope. Seeing that it's the backend of Flatpak, there isn't really an official frontend to bubblewrap that's designed to work with all applications. This makes it harder to use by a good amount, but it also means that it has less of those vulnerabilities that plagued Firejail up above.
As for my opinion? This is where the flame comes in. For most ordinary users, Firejail is more than fine to run for heavy, network-facing applications. It won't stop anyone with significant experience, but form ost script kiddies it should be enough to stop them from doing too much damage. Using it on large applications - such as a web browser - is generally going to be better than letting that large application run on its own.
That being said, for high security environments, bubblewrap is going to be better. It has significantly less attack surface and that can make a world of difference. The ArchWiki page should give a good guide on how to use it anyways, and if you can't understand that, you probably shouldn't be in charge of something that security-heavy anyways.
As for instructions, it's not really that hard for Firejail:
Set up AppArmor, instructions are in the next section.
Install firejail and firetools. if you want the GUI.
That's it! That's all there is to it. I won't cover how to write profiles here because you shouldn't really need to write your own. As for bubblewrap, I'm gonna leave that to the Arch Wiki. IT's honestly a lot less scary than it looks, but it would take a lot to set up and I don't particularly wish to bloat this article up with explanations for it. The concept's easy enough if you're not stupid.
These are the second steps towards properly sandboxing your apps. These aren't enough alone, but these + Firejail/Bubblewrap will take you quite far.
As to which I recommend, I'd probably say that unless you have a lot of experience AppArmor is gonna be a lot easier while giving similarly good results. IT's also required for the vanilla installation of Firejail if you're using that. SELinux is a lot more work to set up, and as a result, I will not be covering it here. It is more secure however.
To get AppArmor up and running:
Install the apparmor package.
Enable apparmor.service.
Set the following kernel paramters in lsm=landlock,lockdown,yama,apparmor,bpf.
This should get you going.
By default, most applications run through your network encrypted only by TLS. This leaks a lot of metadata that basically will leave you naked. This is no good for privacy.
Tor will act as a multi-layered proxy that will encrypt your traffic from your network. It will hop to 3 nodes, and then decrypt (except for TLS of course) and will go to your destination. This is similar to a VPN, except more secure and run by a non profit.
Let me make this clear - just because it's run by a non profit does not mean it is 100% secure or private. Your data is fully exposed to exit nodes and many have proven to be malicious. The Tor Project as it stands is funded by the US military and therefore there is a chance that they put in ab ackdoor, though I persnally doubt this seeing that it is an open source project that is actively audtied. The FBI has been able to break through Tor before however.
In spite of all of this, its absolutely worth using Tor for network-facing applications. I do this via a tool called proxychains. I also have my Chromium browsers set up to use it through an extension called ProxySwitchy Omega.
For proxychains:
1. Install proxychains-ng and tor.
Navigate to /etc/proxychains.conf and open it up in your editor of choice.
Go to the bottom. Change socks4 to socks5.
Run sudo systemctl start tor to start the Tor service.
To open up an application through Tor, run proxychains $NAMEOFAPPLICATION. THIS WILL NOT WORK FOR CHROMIUM BASED BROWSERS.
For Chromium based browsers, however, you're going to need to configure it within the browser. There's an easy way to do this - through an extension called ProxySwitchy Omega.
So let's set that up!
Install ProxySwitchy Omega from the Chromium Web Store.
Go to the settings of PRoxySwitchy Omega. It should automatically take you there upon installation anyways.
Create a new profile.
Set the protocol to SOCKS5, the server to 127.0.0.1, and the port to 9050. Set this for all protocols.
Apply changes.
Start Tor with sudo systemctl start tor.
Set hte proxy to your new profile.
And that's it! Your Chromium browsers should now have a proxy to hide your traffic from your ISP.
A heads up - other extensions will leak your actual IP address and therefore deanonymize you. Don't use htis for that purpose. Instead, use it to bypass censorship and to hide your traffic from your ISP.
This is also gonna attract some flame.
The fact of the matter is, x.org is not secure. It is incredibly outdated and offers no sandboxing whatsoever. It's definitel your biggest running vulnerability. It also is buggy ash ell and no one has good times with it. I've probably said it before but I'll say it again - x.org is easily Linux's biggest weakness.
Unfortunately, Wayland also sucks. It's more of a usability issue in that it 1. still doesn't support screensharing and whatnot on all apps etc. 2. requires xwayland for half of the apps you'd run anyways 3. wants pipewire for a good experience which tbf is not necessarily an egative 4. it doesn't support a lot of the DEs/WMs you'd want to use 5. it uses more resources, all of this for well... only really teh security benefit. There's not a lot of real, tangible end user benefit to Wayland.
So what's my take? Use Wayland if security really matters for you. If it isn't 100% a priority though, leave it alone. If you do go for it, use pipewire, the installation of which I will not be covering.
As for installing it, it should come with your DE or WM of choice. The only 3 I know of that are worth using are GNOME (which well is questionable as hell), Sway (which is just an i3 clone) and KDE Plasma (support is not completelly seamless and bug-free yet but this is still probably your best bet).
This is a WIP becuase I have not had the chnace to test this out. I'd recommend reading the Arch Wiki on this and giving it a chance though.
I suppose I might as well include this. Firewalls manage connections inwards and outbound connections via ports.
As for which I recommend, it depends on how heavily you care about privacy and security. If you don't really focus on either, then 1. hopefully this section will change your mind and 2. honestly, just go with ufw and gufw. They do hte job well enough, are easy to use and will frankly just be out of your way.
If you're fine with a bit of invasiveness, then go with OpenSnitch. It's incredibly comprehensive in its coverage of inward/outbound connections - it will prompt you to allow/deny connections every time they happen, and allows you to create rules to handle this.
Honestly though I just use GUFW. I don't really have a strong need for OpenSnitch because I'm not in a super security-needed environment.
The combination of Firejail/Bubblewrap and AppArmor should generally carry you pretty far security-wise. You should be fine for most use cases.
Now, if you need real security, once again I implore you to not use Arch by itself and instead use TAILS or QubesOS. If you want something as a daily driver instead, I'd suggest Alpine Linux. It comes with hardened packages, installing a hardened kernel is possible, and it has significantly less attack surface due to using alternative, smaller tools for the core system. It's not perfect by any means but for a daily driver that's very security focused, it gets the job done.
If you want a moderate amount of security that's enough for most desktop users without the work you just put in this section, I'd suggest Fedora. It has SELinux, bubblewrap (in the form of flatpak), and Wayland out of the box.
If you're sitll insistent on Arch Linux for htis, at the least use Artix. It's the exact same experience, except without the monolith of unaudited code we know as systemd. It's gonna still have a lot of GNU bloat but it's the cost of practicality.
Well I didn't expect to make so much of this article about security measures but here we are. Arch Linux can be an amazing experience depending on what you make of it - it can truly be anything and be anything well (except a server imo).
With that, I hope this guide helped you in any way possible - whether you're new to Arch Linux and wanted to finally match some of the features you had wanted in Linux for a while, or you're a veteran installing it and wanting a reminder of what you usually do.
This will be a living document - I'll keep updating this as I think of things to add. Until then, I'll keep it as-is.