Hello Arch, my old friend :)

I use i3wm, my preferred options is to use autorandr:

autorandr --save screen1

autorandr --save screen2

Which save both configurations. You can then add the following to your config to load automatically

autorandr --change

If you are on logged in your session and want to swap lets say from screen 1 to 2 configuration you could open terminal and autorandr screen2

Edit: I switch frequently different monitor config between home and work. One thing I learned is to logout of the session then disconnect, and reconnect to my other setup. With autorandr it normally recognizes my saved profiles :+1:

Yes! Like to watch it too, nice wm videos. Because of him I tried xmonad, but didnt like it that much. But discovered qtile instead!

1 Like

Also on my “Forever Growing List of Things To Try”.

You may find this helpful:


Edit: and this: https://man.archlinux.org/man/pacman.8


OMG this is brilliant!!!

I’m gonna have a hard time remembering that - lol.

THANK YOU SO MUCH for linking that script!!

ANNND there’s an official Arch package, this is too awesome!
Already in less than a few hours past initial OS install, I’m totally loving this OS :heart:

1 Like

Arch Wiki is your friend and a fantastic resource.

Learn pacman inside out, best package manager in penguin land.


Understanding how to define (PKGBUILD) and build (makgepkg) packages definitely helps.



Arch User Repository.


Fantastic tool, so many packages in one location, easy to use.

Just be careful though as all these packages are user maintained. Each AUR package has its own web page. Read it first. AUR package comments, PKGBUILDs and source help determine a level of trust in an AUR package.

As Arch is a rolling system you’ll need to maintain it to keep it healthy in the long term. Install once, maintain indefinitely.


If you are looking for apps to do certain tasks, this may help.


If you need / want access to older lts kernels and lts nvidia drivers use this.

Unofficial repo for older LTS kernels

And finally you’ll need a tested backup / restore process; and be familiar with chrooting into a system through a live environment to fix issues that require it.

You won’t need these often, but Arch is bleeding edge so you’ll probably need them eventually.

Have fun!


welcome to the forum @oh_jaimito :partying_face: :tada: :balloon: :enos_flag:


For now, I’m spending my evening familiarizing myself with bspwm and it’s key-bindings.

So far I have only installed neovim, nodejs, npm, and neofetch. All the other goodies can wait.

I’ll probably wait a while before relying on the AUR, make, and build. I’ll stick with the standard repos untill I can’t find what I need. but so far - it has surpassed my expectations!

Thank you @kjw :smiley: :stuck_out_tongue: :slight_smile: :heart:

AUR is the one aspect of Arch I cannot live without. Once you learn how to use an AUR helper like yay / paru / trizen / etc you’ll never look back.

A new major kernel version (5.15) is dropping soon, test your backup / restore process, and don’t forget testing chrooting into your system. These major kernel updates tend to cause the most issues historically.


I shall proceed with the most caution!

I will be posting quite often. As I have used Debian based Distros for over 10 years, there are a LOT of differences here.

Thanks for the help @otherbarry :+1:


It is a matter of personal preference but I would say “no”.

-Rs remove packages recursively. I tend to prefer to handle orphans myself rather than let -Rs do it. Especially since -Rs can remove optional dependencies of other packages.(To be fair, I haven’t tested this in a couple of years so it is possible this was fixed at some point).

I never use -Rn. This is one of the most misunderstood options of pacman. -Rn stops package removal from creating .pacsave files. Normally, .pacsave files are created whenever a file in a package’s backup array has been modified by the user. Some things to consider:

  • Most packages don’t have anything in the backup array to being with
  • The files in the backup array are generally very small configuration files
  • .pacsave files are only created if you have modified the file
  • .pacsave files can be easily removed at a later date
  • If you accidentally delete a package that had an important config, the .pacsave file can be used to restore your config

This means that a very small number of .pacsave files would even be created in the first place.

1 Like

Since i use -Rns constantly i haven’t seen anything like that in about 2 years, i believe you mixed it with other option…-c or -u?

To remove a package and its dependencies which are not required by any other installed package:

pacman -Rs package_name

Pacman saves important configuration files when removing certain applications and names them with the extension: .pacsave. To prevent the creation of these backup files use the -n option:

pacman -Rn package_name

(c) https://wiki.archlinux.org/title/Pacman#Removing_packages

So i assume -Rn means that it removes .pacsave for a given package you want to remove only?
Actually, i’ll test it later :man_scientist:

There are/were certain circumstances where -Rs would remove optional dependencies of other packages. If you haven’t seen it, there are three possibilities:

  • You coincidentally have never triggered one of those scenarios
  • You have, but didn’t notice the optional dependency was missing
  • The issue was fixed at some point and pacman no longer does that

It doesn’t remove anything. It just never creates them in the first place.


I sure hope it’s that:

coz otherwise that would be a bug in my mind :upside_down_face:

Oh sorry, i’ve mixed it with .pacnew, now i get what you mean :sweat_smile:
Well, for the most part i’m fine with it coz usually when i want to remove something, i don’t want to hear about it at all even in form of .pacsave, because i’ve manually :upside_down_face:

Seemingly optional dependencies for some package won’t fall under the not required by any other packages installed.

Using -Rns I have had sometimes “warning” messages that some packages to be removed was flagged as optional dependencies of another package. So I needed to check if I really needed to keep them or not.


Well, then maybe i was really lucky so far, thx for headsup @dalto :wink:


I just use -R to remove packages and then go manually through the list orphans and remove those I don’t want to keep (and those I do want, I mark as explicitly installed). It’s easy, because I keep my list of orphans clean, so I always know what depended on what.

If I have any doubts, I investigate using pactree or pacman -Qi or -Si.

I trust my manual process more than I trust any recursive option. It’s usually just a handful of packages that need to be cleaned up. Recursive options only make sense when you have dozens of packages to remove, but in that case, it may be easier to just snip off the branch of the dependency tree fairly low, with -Rc (of course, paying attention to what is being removed).

Ha, I’m the opposite. I nuke everything I want to remove with pacman -Rnsc (I have an alias for it) and just have a glance at what is being removed. If I see no obvious issues I let the operation go ahead.

Some quick lazy hints:

  • Simple command yay will update your system (equivalent to yay -Syu)
  • Command yay searchterm is equivalent to yay -s searchterm and will search and provide a list of found packages that you can immediately install by choosing the list entry number

yay has the same syntax as pacman, but also works with AUR. Nice thing about it is you don’t need to call it with sudo (it will ask for password if it needs privileges at some point).

I used to have aliases for complex pacman commands, yay is so short I don’t need any (well except for the thorough remove command as I said earlier).

I use -Rc in a loop to remove orphans in order to catch the dependencies of dependencies. It still won’t remove optional dependencies that way. I have never understood why -Rs is built in such a way that it removes optional dependencies.