Since many years I'm running Arch Linux on my computers at home. Having "grown up" at work with UNIX and command line, this is just the best I can have. Everything configured is transparent, setup can be easily duplicated by copy & paste, own scripts can help to automate things, etc. And I always have the latest, greatest status of programs, libraries and kernel (and hardly ever experienced difficulties with that). In my earlier Linux days, I have been using (open)SuSE (also buying the boxes with several CDs or later DVDs) with its YAST installer and configuration GUI. Here it always was pretty tedious to make a larger upgrade to a newer version and it was not always clear where what configuration would end up. My first Linux experiences were on an old 386 computer in the 1990ies, with a Slackware distribution on 3.5" floppy disks. Command line only at that time.
The Arch Linux Wiki contains a lot of information, also valuable beyond Arch.
Correct umask Definition for GNOME Programs
Programs running under GNOME most likely create and store files with a default umask of 022.
That means “world-readable”.
Any umask command within a shell profile file only has effect for the shell but not for those
other programs running under GNOME.
Remedy is to update the PAM setup file /etc/pam.d/system-login by adding a line as following:
session optional pam_umask.so umask=0027
Then, after logging in again, GNOME programs will also obey the defined umask setting.
GNOME File Manager (Nautilus)
I have noticed that, despite the above umask correction, the default GNOME file manager Nautilus still is not obeying this. My solution is to deinstall Nautilus and instead use another file manager, like Thunar (from the XFCE environment), which does correctly obey the umask setting.
Anyway, I'm seldomly using the file manager GUI as I'm doing most on the command line (within XTerm).
Disabling Automatic Suspend on GDM Login Screen
Annoying might be that by default the GDM login screen would automatically suspend the computer after some time without interaction. The current setup for this can be checked with:
root@host$ sudo -u gdm dbus-run-session gsettings list-recursively org.gnome.settings-daemon.plugins.power
To deactivate this, following can be done:
root@host$ sudo -u gdm dbus-run-session gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
root@host$ sudo -u gdm dbus-run-session gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'nothing'
Separate GNOME Profiles
Having both a desktop/server computer and a laptop on which I work with the same user account
(synchronizing data in between them with rsync), I'd like to have different GNOME setup for both.
Screen sizes, keyboard layouts and more is different between the two computers.
By default, GNOME stores its (dconf) setup as:
~/.config/dconf/user
That would be the default on my desktop/server computer.
By adding a file /etc/dconf/profile/host on my laptop with following content (use e.g. a computer
name instead of “laptop”):
user-db:user_laptop
And adding following line to /etc/environment:
DCONF_PROFILE=host
Then GNOME will store my user settings on the laptop separately in following file:
~/.config/dconf/user_laptop
To have some initial setup available for the laptop, the user file can be copied to the
user_laptop file before logging in on the laptop (e.g. via remote login).
No Unwanted Sub-Directories in Home Directory
By default GNOME would create a set of sub-directories within one's home directory.
Not all directories, like ~/Desktop, ~/Templates, ~/Public, etc. (see
/etc/xdg/user-dirs.defaults) might be wanted.
Automatic creation of these directories can be avoided by having following line active in
/etc/xdg/user-dirs.conf (system-wide) or ~/.config/user-dirs.conf (user-based):
enabled=False
See also the manual pages of user-dirs.conf and xdg-user-dirs-update.
Controlling the User Directories
As per the above, GNOME is using a number of default directories for specific tasks.
In case the GNOME defaults are not wanted, different locations can be specified within a file
~/.config/user-dirs.dirs, e.g.:
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_DOWNLOAD_DIR="$HOME/tmp"
XDG_PICTURES_DIR="$HOME/Pictures"
XDG_VIDEO_DIR="$HOME/Video"
See also the manual page of user-dirs.dirs for a list of possible directories.
Note that the explicit XDG_PICTURES_DIR definition also seems to help to have the GNOME
screenshot feature store its results under ~/Pictures/Screenshots/ instead of ~/Screenshots/.
Meanwhile, any environment variables, like $XDG_PICTURES_DIR, don't seem to have effect anymore.
Using the New Copilot Key as Compose Key
My new laptop has the (in?)famous Copilot key instead of the usual Menu key.
On other computers I'm using the Menu key as so-called “Compose” key to enter special
characters.
On my new laptop, so far, I was using the available right Control key for that (see the article
about GNOME on Wayland Tips).
Apparently with the Linux 6.14 kernel (and newer) the Copilot key gets a correct mapping, which
allows to remap it for other purposes.
This still is a bit tricky and requires the keyd system program (part of the
Arch Linux standard packages).
The Copilot key by default generates a key combination of: Left-Meta, Left-Shift and F23.
This can be seen with
root@host$ keyd monitor
The following mapping can be provided in a file /etc/keyd/keyd.conf to have the Copilot key
function as Compose key (any file name *.conf at that location can be used):
[ids]
*
[main]
leftmeta+leftshift+f23 = overload(control,compose)
rightshift = rightshift
rightcontrol = rightcontrol
Instead of “*” as keyboard id (for any keyboard), a dedicated id can be specified, which also
can be found with keyd monitor (e.g. “0001:0001:70533846” in my case).
The main specification results in the Copilot key to act as Compose key when tapped (pressed
and released) and as Control key when hold.
Furthermore, the right Shift and Control keys need to mapped back to themselves.
Otherwise these will result in their left version.
Now the keyd system service can be enabled and started with:
root@host$ systemctl enable --now keyd.service
Then the Copilot key will be available e.g. in GNOME as the Menu key (Compose internally maps to Menu). And that key then can be used for Compose functionality.