Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-05-02 23:05:19 -04:00
Code Issues Projects Releases Packages Wiki Activity

Fix links

Browse source
This commit is contained in:
Andrew David Wong 2021-06-17 07:01:53 -07:00
parent d4c577e31b
commit 76150ac9d3
No known key found for this signature in database
GPG key ID: 8CE137352A019A17
26 changed files with 46 additions and 46 deletions
Download patch file Download diff file Expand all files Collapse all files

2
developer/releases/2_0/release-notes.md
View file

@ -55,7 +55,7 @@ See [Installation Guide](/doc/installation-guide/).
### From Qubes R2 rc1
Upgrading from Qubes R2 rc1 should be a simple matter of installing updates for [dom0](/doc/software-update-dom0/) and [VMs](/doc/software-update-vm/).
Upgrading from Qubes R2 rc1 should be a simple matter of installing updates for [dom0](/doc/how-to-install-software-in-dom0/) and [VMs](/doc/software-update-vm/).
### From Qubes R2 beta 3 and older

2
developer/releases/3_1/release-notes.md
View file

@ -15,7 +15,7 @@ title: Qubes R3.1 release notes
* LIVE edition (still alpha, not part of R3.1-rc1)
* Updated GPU drivers in dom0
* Colorful window application icons (instead of just colorful lock icon)
* PV Grub support ([documentation](/doc/managing-vm-kernel/))
* PV Grub support ([documentation](/doc/managing-vm-kernels/))
* Out of the box USB VM setup, including [handling USB mouse](https://github.com/QubesOS/qubes-app-linux-input-proxy/blob/master/README.md)
* Xen upgraded to 4.6, for better hardware support (especially Skylake platform)
* Improve updates proxy flexibility - especially repositories served over HTTPS

2
developer/services/qrexec.md
View file

@ -201,7 +201,7 @@ This is why `qubes.StartApp` uses our standard `qrexec` argument grammar to stri
### Service policies with arguments
Sometimes a service name alone isn't enough to make reasonable qrexec policy.
One example of such a situation is [qrexec-based USB passthrough](/doc/usb-devices/).
One example of such a situation is [qrexec-based USB passthrough](/doc/how-to-use-usb-devices/).
Using just a service name would make it difficult to express the policy "allow access to devices X and Y, but deny to all others."
It isn't feasible to create a separate service for every device: we would need to change the code in multiple files any time we wanted to update the service.