Remove extra newlines at the beginning/end of files

Those are redundant, and yaml parser strips them in fact. By removing
them, loading and saving yaml file without any change indeed produce the
same output. This is useful for prepare_for_translation.py script (which
adds lang and ref tags) - to produce only change that indeed was made.

developer/system/audio.md

@@ -6,7 +6,6 @@ ref: 60
 title: Audio Virtualization
 ---
 
-
 VMs on Qubes OS have access to virtualized audio through the PulseAudio module.
 It consists of two parts:
 

developer/system/networking.md

@@ -11,7 +11,6 @@ ref: 59
 title: Networking
 ---
 
-
 ## Overall description
 
 In Qubes, the standard Xen networking is used, based on backend driver in the driver domain and frontend drivers in VMs. In order to eliminate layer 2 attacks originating from a compromised VM, routed networking is used instead of the default bridging of `vif` devices and NAT is applied at each network hop. The default *vif-route* script had some deficiencies (requires `eth0` device to be up, and sets some redundant iptables rules), therefore the custom *vif-route-qubes* script is used.

developer/system/security-critical-code.md

@@ -11,7 +11,6 @@ ref: 55
 title: Security-critical Code
 ---
 
-
 Below is a list of security-critical (i.e., trusted) code components in Qubes OS.
 A successful attack against any of these components could compromise the system's security.
 This code can be thought of as the Trusted Computing Base (TCB) of Qubes OS.
@@ -69,4 +68,3 @@ This means that we must trust at least some of the vendors that supply the code
 (We don't have to trust *all* of them, but we at least have to trust the few that provide the apps we use in the most critical domains.)
 In practice, we trust the software provided by the [Fedora Project](https://getfedora.org/).
 This software is signed by Fedora distribution keys, so it is also critical that the tools used in domains for software updates (`dnf` and `rpm`) are trustworthy.
-

developer/system/security-design-goals.md

@@ -12,7 +12,6 @@ ref: 210
 title: Security Design Goals
 ---
 
-
 Qubes OS implements a security-by-isolation (or security-by-compartmentalization) approach by providing the ability to easily create many security domains. These domains are implemented as lightweight Virtual Machines (VMs) running under the Xen hypervisor. Qubes' main objective is to provide strong isolation between these domains, so that even if an attacker compromises one of the domains, the others are still safe. Qubes, however, does not attempt to provide any security isolation for applications running within the same domain. For example, a buggy web browser running in a Qubes domain could still be compromised just as easily as on a regular Linux distribution. The difference that Qubes makes is that now the attacker doesn't have access to all the software running in the other domains.
 
 Qubes also provides features that make it easy and convenient to run these multiple domains, such as seamless GUI integration into one common desktop, secure clipboard copy and paste between domains, secure file transfer between domains, disposable VMs, and much more. Qubes also provides an advanced networking infrastructure that allows for the creation of multiple network VMs which isolate all the world-facing networking stacks and proxy VMs which can be used for advanced VPN configurations and tunneling over untrusted connections.

developer/system/storage-pools.md

@@ -6,7 +6,6 @@ ref: 57
 title: Storage Pools
 ---
 
-
 Qubes OS R3.2 introduced the concept of storage drivers and pools.  This feature
 was a first step towards a saner storage API, which is heavily rewritten in R4.
 See [here](https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-storage.html)

developer/system/template-implementation.md

@@ -10,7 +10,6 @@ ref: 58
 title: Template Implementation
 ---
 
-
 Every VM has 4 block devices connected:
 
 - **xvda** – base root device (/) – details described below