Create Live USB page and add link

doc.md

@@ -23,13 +23,13 @@ The Basics
 Choosing Your Hardware
 ----------------------
  *  [System Requirements](/doc/system-requirements/)
- *  [Hardware Compatibility List (HCL)](/hcl)
+ *  [Hardware Compatibility List (HCL)](/hcl/)
  *  [Qubes-Certified Laptops](/doc/certified-laptops/)
 
 
 Installing Qubes
 ----------------
- *  [Use Qubes without installing: Qubes Live USB (alpha)](https://groups.google.com/d/msg/qubes-users/IQdCEpkooto/iyMh3LuzCAAJ)
+ *  [Use Qubes without installing: Qubes Live USB (alpha)](/doc/live-usb/)
  *  [How to Install Qubes](/doc/installation-guide/)
  *  [Qubes Downloads](/downloads/)
  *  [Why and How to Verify Signatures](/doc/verifying-signatures/)

installing/live-usb.md

@@ -0,0 +1,122 @@
+---
+layout: doc
+title: Live USB
+permalink: /doc/live-usb/
+---
+
+Qubes Live USB (alpha)
+======================
+
+Qubes Live USB allows you to run and try Qubes OS without having to install it
+anywhere. Qubes Live USB is currently in alpha. If you use it, please consider
+running the [HCL reporting tool](/hcl/) and sending us the results so that we
+can continue to improve it.
+
+
+Introduction
+------------
+
+We have faced several challenges when making this Live USB edition of Qubes OS,
+which traditional Linux distros don't have to bother with:
+
+1. We needed to ensure Xen is properly started when booting the stick. In fact
+we still don't support UEFI boot for the sitck for this reason, even though the
+Fedora liveusb creator we used does support it. Only legacy boot for this
+version, sorry.
+
+2. We discovered that the Fedora liveusb-create does *not* verify signatures on
+downloaded packages. We have temporarily fixed that by creating a local repo,
+verifying the signatures manually (ok, with a script ;) and then building from
+there. Sigh.
+
+3. We had to solve the problem of Qubes too easily triggering an `Out Of Memory`
+condition in Dom0 when running as Live OS.
+
+This last problem has been a result of Qubes using the copy-on-write backing for
+the VMs' root filesystems, which is used to implement our cool
+[Template-based scheme](/doc/software-update-vm/). Normally these are backed by
+regular files on disk. Even though these files are discardable upon VM reboots,
+they must be preserved during the VM's life span, and they can easily grow to a
+few tens of MBs per VM, sometimes even more. Also, each VM's private
+image, which essentially holds just the user home directory, typically starts
+with a few tens of MBs for an "empty VM". Now, while these represent rather
+insignificant numbers on a disk-basked system, in the case of a live USB all
+these files must be stored in RAM, which is a scare resource on any OS, but
+especially on Qubes.
+
+We have implemented some quick optimizations in order to minimize the above
+problem, but this is still far from a proper solution. We're planning to work
+more on this next.
+
+Now, there are three directions in how we want to work further on this Qubes
+Live USB variant:
+
+1. Introduce an easy, clickable "install to disk" option, merging this with the
+Qubes installation ISO. So, e.g. make it possible to first see if the given
+hardware is compatible with Qubes (run the HCL reporting tool) and only then
+install on the main disk. Also, ensure UEFI boot works well.
+
+2. Introduce options for persistence while still running this out of a USB
+stick. This would be achieved by allowing (select) VMs' private images to be
+stored on the r/w partition (or on another stick).
+
+2a. A nice variant of this persistence option, especially for frequent
+travellers, I think, would be to augment our backup tools so that it was
+possible to create a LiveUSB-hosted backups of select VMs. One could then pick a
+few of their VMs, necessary for a specific travel, back them to a LiveUSB stick,
+and take this stick when traveling to a hostile country (not risking taking
+other, more sensitive ones for the travel). This should make life a bit simpler
+[for some...](https://twitter.com/rootkovska/status/541980196849872896)
+
+3. Introduce more useful preconfigured VMs setup, especially including
+Whonix/Tor VMs.
+
+
+Current limitations
+-------------------
+
+0. It's considered an alpha currently, so meter your expectations
+accordingly...
+
+1. Currently just the 3 example VMs (untrusted, personal, work), plus the
+default net and firewall VMs are created automatically.
+
+2. The user has an option to manually (i.e. via command line) create an
+additional partition, e.g. for storing GPG keyring, and then mounting it to a
+select VMs. This is to add poor-man's persistence. We will be working on
+improving/automating that, of course.
+
+3. Currently there is no option of "install to disk". We will be adding this
+in the future.
+
+4. The amount of "disk" space is limited by the amount of RAM the laptop
+has. This has a side effect of e.g. not being able to restore (even few) VMs
+from a large Qubes backup blob.
+
+5. It's easy to generate Out Of Memory (OOM) in Dom0 rather easily by creating
+lots of VMs which are writing a lot into the VMs filesystem.
+
+6. There is no DispVM savefile, so if one starts one the savefile must be
+regenerated which takes about 1-2 minutes.
+
+7. UEFI boot doesn't work, and if you try booting it via UEFI Xen will not be
+started, rendering the whole experiment unusable.
+
+
+Downloading and burning
+-----------------------
+
+1. Download the ISO (and its signature for verification) from the
+   [downloads page](/downloads/#qubes-live-usb-alpha/).
+
+2. "Burn" (copy) the ISO onto a USB drive (replace `/dev/sdX` with your USB
+   drive device):
+
+    $ sudo dd if=Qubes-R3.0-rc2-x86_64-LIVE.iso of=/dev/sdX
+
+Note that you should specify the whole device, (e.g. `/dev/sdc`, not a single
+partition, e.g. `/dev/sdc1`).
+
+**Caution:** It is very easy to misuse the `dd` command. If you mix up `if` and
+`of` or specify an incorrect device, you could accidentally overwrite your
+primary system drive. Please be careful!