Update philosophy.mdx

Update with additional context that deleting configuration files from
`etc` will essentially revert an install back to factory defaults.

Also add ` around directories such as `/usr` and `/ect`

Author: NomadicCore

src/content/docs/AerynOS/philosophy.mdx

@@ -18,17 +18,17 @@ Our ground up approach has enabled us to provide atomic updates without requirin
 
 Most Linux distributions follow the [Filesystem Hierarchy Standard](https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf) which sets the structure for all files and directories on a Unix-like system. In traditional FHS based Linux distributions, package files can be installed to multiple directories, these can be directories or files that users may interact with (such as config files).
 
-In AerynOS, packages are forbidden from containing any files outside of the `/usr` directory. The /usr directory exclusively belongs to the system with the user not intended to make any changes in this directory what-so-ever. Files written under the /usr directory by a user will get removed (or reverted) the next time the system is updated.
+In AerynOS, packages are forbidden from containing any files outside of the `/usr` directory. The `/usr` directory exclusively belongs to the system with the user not intended to make any changes in this directory what-so-ever. Files written under the `/usr` directory by a user will get removed (or reverted) the next time the system is updated.
 
-In order to enable this, some packages and/or configurations are altered in AerynOS to ensure they can operate in the absence of a user provided configuration. This forces AerynOS to have sane defaults baked in at all levels, and eliminates 3-way merge conflicts on package updates. There are no conflicts, because everything in `/etc` and `/var` belongs to the user.
+In order to enable this, some packages and/or configurations are altered in AerynOS to ensure they can operate in the absence of a user provided configuration. This forces AerynOS to have sane defaults baked in at all levels, and eliminates 3-way merge conflicts on package updates. There are no conflicts, because everything in `/etc` and `/var` directories belong to the user. In this way, if a user deletes their configuration files located in the `/etc` directory, this will revert the system back to factory defaults
 
 The stateless Linux concept was originally proposed by Red Hat in 2004 and the idea has continued to evolve from there. AerynOS leans towards the approach developed by Clear Linux, and we are refining it further.
 
-However, it might still be necessary to create or update system configuration files in lockstep with package installation. In AerynOS, the only way for files to get created or updated under /etc or /var during package installation is via package "triggers". Triggers are small scripts that are run at the tail end of package installation. AerynOS supports two forms of package triggers: Transaction triggers and System triggers.
+However, it might still be necessary to create or update system configuration files in lockstep with package installation. In AerynOS, the only way for files to get created or updated under `/etc` or `/var` during package installation is via package "triggers". Triggers are small scripts that are run at the tail end of package installation. AerynOS supports two forms of package triggers: Transaction triggers and System triggers.
 
 ### Transaction Triggers
 
-Transaction triggers are run at the end of a transaction in an ephemeral container (Linux namespace) and may affect the contents of the transaction-specific /usr tree. This is useful for interdependent packages that need to dynamically produce plugin registries, for example.
+Transaction triggers are run at the end of a transaction in an ephemeral container (Linux namespace) and may affect the contents of the transaction-specific `/usr` tree. This is useful for interdependent packages that need to dynamically produce plugin registries, for example.
 
 ### System Triggers
 
@@ -106,7 +106,6 @@ We currently have four permanent builders dedicated to building official package
   <iframe src="https://exquisite.tube/videos/embed/6Srz7zLoLgAnNvFBpv9LA6" width="1280" height="720" frameborder="0"></iframe>
 </div>
 
-
 By way of example, the video above shows KDE Plasma 6.6 being built. We sent 56 packages for build and our infra was able to sort the build order, schedule them to our builders and land the full stack upgrade to our volatile repository in under an hour.
 
 The whole infra code base has been designed to be flexible, allowing additional builders to be added as required with no real upper limit. Eventually, we envisage productizing our infra tooling, such that users (or downstream distributions/companies) could create their own builder infrastructure to source build their own repositories as they see fit.