I have another problem for you I hooked up my 2nd monitor and ran arandr to generate my dualscreen.sh script. Then removed 2nd monitor and ran it again for my singlescreen.sh.
They’re in the default location ~/.screenlayout/ but dummy me, I deleted the original file that was there named monitor.sh. I’m guessing that if I were to restart/reload the bspwm config file, something unpredictable would happen because I deleted it . I’m looking at the bwspwm config file and it DOES call ~/.screenlayout/monitor.sh, but I have overridden it with my own script.
Is there any way that I can have BOTH dualscreen.sh & singlescreen referenced in the config, so that if one fails, the other runs?
I too was on PopOS for about a year (Solus before that), but after Cosmic was released I encountered a handful of bugs (bluetooth was broken, Gnome settings had issues, Cosmic wasn’t yet 100% stable imo), so I decided to try EndeavourOS. Granted, to the PopOS teams credit, all those issues have since been resolved. Now the beauty of PopOS is it works out of the box very very well. And that’s fine for most users, but over time I just wanted something more; I wanted to dive deeper and learn more about my system. I knew an Arch based system was that first step towards that endeavour (see what I did there ).
I’ve forgotten where I was going with all of that, but the point is, hello fellow former PopOS user and welcome to the purple side of life
This forum, the EndeavourOS wiki, along with the Arch wiki, are the best resources I’ve had the pleasure of using. I hope you enjoy your time
Eek! I get where you’re coming from but that is beyond my experience. I have only done dual monitors when I used Mac stuff really, I tried running those in Linux with arandr and it can be done but I will have to pass you on to others who know more!
The was my reason for using it in the first place Bought a brand new machine (first one in years) and maxed out the RAM with 32GB and disk space with a 500GB M2 and 1TB SSD. So I really need something with a solid history of “just working”, like you said, out of the box
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
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
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.
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.
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.
Oh sorry, i’ve mixed it with .pacnew, now i get what you mean
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