diff --git a/developer/services/qfilecopy.md b/developer/services/qfilecopy.md
index 2f3fc0a6..dea4ef51 100644
--- a/developer/services/qfilecopy.md
+++ b/developer/services/qfilecopy.md
@@ -24,6 +24,6 @@ This has the following disadvantages:
 
 In modern Qubes OS releases, we have reimplemented interVM file copy using qrexec, which addresses the above mentioned disadvantages. Nowadays, even more generic solution (qubes rpc) is used. See the developer docs on qrexec and qubes rpc. In a nutshell, the file sender and the file receiver just read/write from stdin/stdout, and the qubes rpc layer passes data properly - so, no block devices are used.
 
-The rpc action for regular file copy is *qubes.Filecopy*, the rpc client is named *qfile-agent*, the rpc server is named *qfile-unpacker*. For DispVM copy, the rpc action is *qubes.OpenInVM*, the rpc client is named *qopen-in-vm*, rpc server is named *vm-file-editor*. Note that the qubes.OpenInVM action can be done on a normal AppVM, too.
+The rpc action for regular file copy is *qubes.Filecopy*, the rpc client is named *qfile-agent*, the rpc server is named *qfile-unpacker*. For DispVM copy, the rpc action is *qubes.OpenInVM*, the rpc client is named *qopen-in-vm*, rpc server is named *vm-file-editor*. Note that the *qubes.OpenInVM* action can be done on a normal AppVM, too.
 
 Being a rpc server, *qfile-unpacker* must be coded securely, as it processes potentially untrusted data format. Particularly, we do not want to use external tar or cpio and be prone to all vulnerabilities in them; we want a simplified, small utility, that handles only directory/file/symlink file type, permissions, mtime/atime, and assume user/user ownership. In the current implementation, the code that actually parses the data from srcVM has ca 100 lines of code and executes chrooted to the destination directory. The latter is hardcoded to `~user/QubesIncoming/srcVM`; because of chroot, there is no possibility to alter files outside of this directory.
diff --git a/developer/services/qmemman.md b/developer/services/qmemman.md
index 03495c25..f1f4d0d2 100644
--- a/developer/services/qmemman.md
+++ b/developer/services/qmemman.md
@@ -15,7 +15,7 @@ Rationale
 
 Traditionally, Xen VMs are assigned a fixed amount of memory. It is not the optimal solution, as some VMs may require more memory than assigned initially, while others underutilize memory. Thus, there is a need for solution capable of shifting free memory from VM to another VM.
 
-The [tmem](https://oss.oracle.com/projects/tmem/) project provides a "pseudo-RAM" that is assigned on per-need basis. However this solution has some disadvantages:
+The [tmem](https://web.archive.org/web/20210712161104/https://oss.oracle.com/projects/tmem/) project provides a "pseudo-RAM" that is assigned on per-need basis. However this solution has some disadvantages:
 
 - It does not provide real RAM, just an interface to copy memory to/from fast, RAM-based storage. It is perfect for swap, good for file cache, but not ideal for many tasks.
 - It is deeply integrated with the Linux kernel. When Qubes will support Windows guests natively, we would have to port *tmem* to Windows, which may be challenging.
@@ -24,13 +24,19 @@ Therefore, in Qubes another solution is used. There is the *qmemman* dom0 daemon
 
 Similarly, when there is need for Xen free memory (for instance, in order to create a new VM), traditionally the memory is obtained from dom0 only. When *qmemman* is running, it offers an interface to obtain memory from all domains.
 
-To sum up, *qmemman* pros and cons. Pros:
+To sum up, *qmemman* pros and cons.
+
+<div class="focus">
+  <i class="fa fa-check"></i> <strong>Pros</strong>
+</div>
 
 - provides automatic balancing of memory across participating PV and HVM domains, based on their memory demand
 - works well in practice, with less than 1% CPU consumption in the idle case
 - simple, concise implementation
 
-Cons:
+<div class="focus">
+  <i class="fa fa-times"></i> <strong>Cons</strong>
+</div>
 
 - the algorithm to calculate the memory requirement for a domain is necessarily simple, and may not closely reflect reality
 - *qmemman* is notified by a VM about memory usage change not more often than 10 times per second (to limit CPU overhead in VM). Thus, there can be up to 0.1s delay until qmemman starts to react to the new memory requirements
diff --git a/user/advanced-topics/bind-dirs.md b/user/advanced-topics/bind-dirs.md
index 0481dfb8..945d336e 100644
--- a/user/advanced-topics/bind-dirs.md
+++ b/user/advanced-topics/bind-dirs.md
@@ -19,7 +19,7 @@ In an app qube all of the file system comes from the template except `/home`, `/
 This means that changes in the rest of the filesystem are lost when the app qube is shutdown.
 bind-dirs provides a mechanism whereby files usually taken from the template can be persisted across reboots.
 
-For example, in Whonix, Tor's data dir `/var/lib/tor` [has been made persistent](https://github.com/Whonix/qubes-whonix/blob/8438d13d75822e9ea800b9eb6024063f476636ff/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf#L5) in the TemplateBased ProxyVM sys-whonix. In this way sys-whonix can benefit from the Tor anonymity feature 'persistent Tor entry guards' but does not have to be a standalone.
+For example, in Whonix, Tor's data dir `/var/lib/tor` [has been made persistent in the TemplateBased ProxyVM sys-whonix](https://github.com/Whonix/qubes-whonix/blob/8438d13d75822e9ea800b9eb6024063f476636ff/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf#L5). In this way sys-whonix can benefit from the Tor anonymity feature 'persistent Tor entry guards' but does not have to be a standalone.
 
 ## How to use bind-dirs.sh?
 
diff --git a/user/advanced-topics/gui-configuration.md b/user/advanced-topics/gui-configuration.md
index 56a06227..533cb084 100644
--- a/user/advanced-topics/gui-configuration.md
+++ b/user/advanced-topics/gui-configuration.md
@@ -42,8 +42,8 @@ You might face issues when playing video, if the video is choppy instead of
 smooth display this could be because the X server doesn't work. You can use the
 Linux terminal (Ctrl-Alt-F2) after starting the virtual machine, login. You can
 look at the Xorg logs file. As an option you can have the below config as
-well present in `/etc/X11/xorg.conf.d/90-intel.conf`, depends on HD graphics
-though -
+well present in `/etc/X11/xorg.conf.d/90-intel.conf` (depends on HD graphics
+though).
 
 ```bash
 Section "Device"
diff --git a/user/advanced-topics/mount-from-other-os.md b/user/advanced-topics/mount-from-other-os.md
index e930cf8e..a5e16cbf 100644
--- a/user/advanced-topics/mount-from-other-os.md
+++ b/user/advanced-topics/mount-from-other-os.md
@@ -90,7 +90,7 @@ Reverting Changes
 -----------------------------------------
 
 Any changes which were made to the system in the above steps will need to be reverted before the disk will properly boot.
-However, LVM will not allow an VG to be renamed to a name already in use.
+However, LVM will not allow a VG to be renamed to a name already in use.
 Thes steps must occur either in an app qube or using recovery media.
 
 1. Unmount any disks that were accessed.
diff --git a/user/reference/glossary.md b/user/reference/glossary.md
index 98649dd4..897f77ab 100644
--- a/user/reference/glossary.md
+++ b/user/reference/glossary.md
@@ -137,7 +137,7 @@ its net qube.
 
 ## policies
 
-In Qubes OS, "policies" govern interactions between qubes, powered by [Qubes' qrexec system](https://www.qubes-os.org/doc/qrexec/).
+In Qubes OS, "policies" govern interactions between qubes, powered by [Qubes' qrexec system](/doc/qrexec/).
 A single policy is a rule applied to a qube or set of qubes, that governs how and when information or assets may be shared with other qubes.  
 An example is the rules governing how files can be copied between qubes.  
 Policy rules are grouped together in files under `/etc/qubes/policy.d`