- Cleared misunderstandings of disposable templates, this word was
sometimes used interchangeably with disposables;
- Deduplicate content as much as possible;
- Reference other pages or previous sections;
- Assume the user has read the previous sections up until the
current section they are reading;
- All this deduplication enables easier reading, less clutter, but
each section doesn't stand by itself, each page does. Some things
were reinforced on multiple sections, but limited to when
extremely necessary to learn by reinforcement;
- Structure the files to their distinct use cases:
- how-to-use-disposables is just the basics to learn what are
disposables and how to use them, using GUI and CLI alternatives;
- disposable-customization has everything advanced related to
disposables, such as advanced usage, creation of disposables
templates, their customization;
- disposable-implementation assumes the user understand the previous
pages and contains a more technical description of disposables and
preloaded disposables as well as their implementation;
- Prepared usage for a GUIVM setup, avoiding mentions to dom0;
- Usage modes has been organized in GUI first and CLI second, grouped by
origin such as GUIVM and app qube;
- Usage page restricts itself to "default-dvm", it's name is not
variable like the Whonix disposable template variant and it is the
most used disposable template, thus we avoid variables replacement
that the user should think of the value to a definitive value to use
when learning. Customization page could not benefit much from this
though, as it is intended to create alternative disposable templates;
- Usage page links to Tails documentation of why using it on a VM is not
amensiac, so it can be referenced for users that ask to have Tails in
a VM for anti-forensics purposes;
- Updated the images to R4.3, nobody deserves to see the Qubes version
of the Xfce application menu anymore when the new app menu rocks. The
images also had to be updated because it was fullscreen screenshot
on a large resolution, making it very difficult to read unless
opening the image in a new tab and zooming in;
- Implementation page shows preloaded disposables alternatives that were
once used or considered as a comparative for future studies, to answer
why a different option is not being used and what requirements a
replacement must meet;
- Content from previous releases have been deleted;
- Updates to Qrexec policy v4;
- Use rST roles;
- Change non-ASCII quotes and em-dashes to ASCII;
- Standardized text writing style, many people have contributed to these
pages over the years, there is a lot of different writings styles
which make the text difficult to map. I rewrote a lot of the
paragraphs to my liking and understanding of the different stages that
a user may go through when using disposables, and even on paragraphs
that I didn't completely write, it was modified to follow the same
standard with the rest of the pages. The usage must be very simple
with just the basics, we don't want to scare the user's off of using
disposables, we want to convince them. The customization is a bit more
advanced, it assumes a lot more knowledge from the user to make
decisions by themselves such as customizing applications and qube
settings, which can affect system security. The implementation details
do not require reading the code, it just exist to explain what is
being used and why it was chosen.
Fixes: https://github.com/QubesOS/qubes-issues/issues/10282
For: https://github.com/QubesOS/qubes-issues/issues/1512
Changing `bash` lexer to `console` because it is appropriate most of
the time. Then after a manual review, some lexer have been changed.
I used `text` each time I was unsure, and for prompt outputs.
The page `/developer/building/qubes-iso-building.rst` still need to be
reviewed (look for lines starting with `$ #`).
I'm not sure about the Windows pages, should we use
[doscon](https://pygments.org/docs/lexers/#pygments.lexers.shell.MSDOSSessionLexer)
or `powershell`?
Is there an appropriate lexer for `guid.conf` content?
**Statistics - Before**
870 bash
9 python
9 c
2 yaml
**Statistics - After**
684 console
111 text
44 bash
16 yaml
9 systemd
9 c
8 python
4 ini
4 doscon
2 markdown
2 desktop
1 xorg.conf
1 xml+jinja
1 xml
1 kconfig
1 html
This suggests that the default lexer should be `console`.
This is plain rename without changing content, to help git track files
history.
Do not touch files that are going to be removed during conversion.
Thanks @parulin for the idea!
Add information about `QREXEC_REMOTE_DOMAIN` which is still on the qrexec2.md file but not on the V3. However, this still applies, so it should be documented.
