mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-05-02 06:46:11 -04:00
Merge branch 'translation-prepare' of https://github.com/marmarek/qubes-doc into marmarek-translation-prepare
This commit is contained in:
Andrew David Wong
commit
d328b1b1c9
219 changed files with 4770 additions and 4966 deletions
|
|
@ -1,29 +1,31 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
title: Developer Books
|
||||
permalink: /doc/devel-books/
|
||||
redirect_from:
|
||||
- /en/doc/devel-books/
|
||||
- /doc/DevelBooks/
|
||||
- /wiki/DevelBooks/
|
||||
ref: 32
|
||||
title: Developer Books
|
||||
---
|
||||
|
||||
Below is a list of various books that might be useful in learning some basics needed for Qubes development.
|
||||
|
||||
- A must-read about Xen internals:
|
||||
* _[The Definitive Guide to the Xen Hypervisor](https://www.amazon.com/Definitive-Guide-Xen-Hypervisor/dp/013234971X)_, by David Chisnall
|
||||
- _[The Definitive Guide to the Xen Hypervisor](https://www.amazon.com/Definitive-Guide-Xen-Hypervisor/dp/013234971X)_, by David Chisnall
|
||||
|
||||
- Some good books about the Linux kernel:
|
||||
* _[Linux Kernel Development](https://www.amazon.com/Linux-Kernel-Development-Robert-Love/dp/0672329468)_, by Robert Love
|
||||
* _[Linux Device Drivers](https://www.amazon.com/Linux-Device-Drivers-Jonathan-Corbet/dp/0596005903)_, by Jonathan Corbet
|
||||
- _[Linux Kernel Development](https://www.amazon.com/Linux-Kernel-Development-Robert-Love/dp/0672329468)_, by Robert Love
|
||||
- _[Linux Device Drivers](https://www.amazon.com/Linux-Device-Drivers-Jonathan-Corbet/dp/0596005903)_, by Jonathan Corbet
|
||||
|
||||
- Solid intro into Trusted Computing:
|
||||
* _[Dynamics of a Trusted Platform](https://www.amazon.com/Dynamics-Trusted-Platform-Buildin-Grawrock/dp/1934053082)_, by David Grawrock (original Intel architect for TXT)
|
||||
- _[Dynamics of a Trusted Platform](https://www.amazon.com/Dynamics-Trusted-Platform-Buildin-Grawrock/dp/1934053082)_, by David Grawrock (original Intel architect for TXT)
|
||||
|
||||
- Good book about GIT:
|
||||
* _[Pro Git](https://git-scm.com/book/en/v2)_, by Scott Chacon and Ben Straub (complete book available free online)
|
||||
- _[Pro Git](https://git-scm.com/book/en/v2)_, by Scott Chacon and Ben Straub (complete book available free online)
|
||||
|
||||
- Useful books about Python:
|
||||
* _[Programming in Python 3](http://www.qtrac.eu/py3book.html)_, by Mark Summerfield
|
||||
* _[Rapid GUI Programming with Python and Qt](http://www.qtrac.eu/pyqtbook.html)_, by Mark Summerfield
|
||||
- _[Programming in Python 3](http://www.qtrac.eu/py3book.html)_, by Mark Summerfield
|
||||
- _[Rapid GUI Programming with Python and Qt](http://www.qtrac.eu/pyqtbook.html)_, by Mark Summerfield
|
||||
(Although note that [Qt is being replaced by GTK](/doc/usability-ux/#gnome-kde-and-xfce) in Qubes code.)
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
title: Documentation Guidelines
|
||||
permalink: /doc/doc-guidelines/
|
||||
redirect_from:
|
||||
- /en/doc/doc-guidelines/
|
||||
- /wiki/DocStyle/
|
||||
- /doc/DocStyle/
|
||||
ref: 30
|
||||
title: Documentation Guidelines
|
||||
---
|
||||
|
||||
# Documentation guidelines
|
||||
|
|
@ -16,7 +18,6 @@ By cloning and regularly pulling from this repo, users can maintain their own up
|
|||
The documentation is a community effort. Volunteers work hard trying to keep everything accurate and comprehensive.
|
||||
If you notice a problem or some way it can be improved, please [edit the documentation][contribute]!
|
||||
|
||||
|
||||
## Security
|
||||
|
||||
*Also see: [Should I trust this website?](/faq/#should-i-trust-this-website)*
|
||||
|
|
@ -33,7 +34,6 @@ The documentation maintainer then verifies that the pull request is mechanically
|
|||
If so, the documentation maintainer then merges the pull request, adds a PGP-signed tag to the latest commit (usually the merge commit), then pushes to the remote.
|
||||
In cases in which another reviewer is not required, the documentation maintainer may review the pull request (in which case no signed comment is necessary, since it would be redundant with the signed tag).
|
||||
|
||||
|
||||
## Questions, problems, and improvements
|
||||
|
||||
If you have a question about something you read in the documentation, please send it to the appropriate [mailing list][support].
|
||||
|
|
@ -41,18 +41,17 @@ If you see that something in the documentation should be fixed or improved, plea
|
|||
To report an issue with the documentation, please follow our standard [issue reporting guidelines][issue].
|
||||
(If you report an issue with the documentation, you will likely be asked to address it, unless there is a clear indication in your report that you are not willing or able to do so.)
|
||||
|
||||
|
||||
## How to contribute
|
||||
|
||||
Editing the documentation is easy, so if you see that a change should be made, please contribute it!
|
||||
|
||||
A few notes before we get started:
|
||||
|
||||
* Since Qubes is a security-oriented project, every documentation change will be reviewed before it's accepted.
|
||||
* Since Qubes is a security-oriented project, every documentation change will be reviewed before it's accepted.
|
||||
This allows us to maintain quality control and protect our users.
|
||||
* We don't want you to spend time and effort on a contribution that we can't accept.
|
||||
* We don't want you to spend time and effort on a contribution that we can't accept.
|
||||
If your contribution would take a lot of time, please [file an issue][issue] for it first so that we can make sure we're on the same page before significant works begins.
|
||||
* Alternatively, you may already have written content that doesn't conform to these guidelines, but you'd be willing to modify it so that it does.
|
||||
* Alternatively, you may already have written content that doesn't conform to these guidelines, but you'd be willing to modify it so that it does.
|
||||
In this case, you can still submit it by following the instructions below.
|
||||
Just make a note in your pull request that you're aware of the changes that need to be made and that you're just asking for the content to be reviewed before you spend time making those changes.
|
||||
|
||||
|
|
@ -113,8 +112,7 @@ If, for some reason, we can't accept your pull request, we'll post a comment exp
|
|||
|
||||
[](/attachment/wiki/doc-edit/10-done.png)
|
||||
|
||||
|
||||
### How to add images
|
||||
## How to add images
|
||||
|
||||
To add an image to a page, use the following syntax in the main document.
|
||||
This will make the image a hyperlink to the image file, allowing the reader to click on the image in order to view the image by itself.
|
||||
|
|
@ -127,7 +125,6 @@ Then, submit your image(s) in a separate pull request to the [qubes-attachment]
|
|||
This is the only permitted way to include images.
|
||||
Do not link to images on other websites.
|
||||
|
||||
|
||||
## Organizational guidelines
|
||||
|
||||
### Do not duplicate documentation
|
||||
|
|
@ -231,7 +228,6 @@ To foo:
|
|||
|
||||
Once you foo, make sure to close the baz before fooing the next bar.
|
||||
|
||||
|
||||
## Qubes 4.0 ##
|
||||
|
||||
### How to Foo ###
|
||||
|
|
@ -251,7 +247,7 @@ Once you foo, make sure to close the baz before fooing the next bar.
|
|||
|
||||
Subdividing the page into clearly-labeled sections for each version has several benefits:
|
||||
|
||||
* It preserves good content for older (but still supported) versions.
|
||||
* It preserves good content for older (but still supported) versions.
|
||||
Many documentation contributors are also people who prefer to use the latest version.
|
||||
Many of them are tempted to *replace* existing content that applies to an older, supported version with content that applies only to the latest version.
|
||||
This is somewhat understandable.
|
||||
|
|
@ -261,15 +257,15 @@ Subdividing the page into clearly-labeled sections for each version has several
|
|||
With the older, supported version, there has been more time to fix bugs and make improvements in both the software and the documentation.
|
||||
Consequently, much of the documentation content for this version may have gone through several rounds of editing, review, and revision.
|
||||
It would be a tragedy for this content to vanish while the very set of users who most prize stability and reliability are depending on it.
|
||||
* It's easy for readers to quickly find the information they're looking for, since they can go directly to the section that applies to their version.
|
||||
* It's hard for readers to miss information they need, since it's all in one place.
|
||||
* It's easy for readers to quickly find the information they're looking for, since they can go directly to the section that applies to their version.
|
||||
* It's hard for readers to miss information they need, since it's all in one place.
|
||||
In the incorrect example, information that the reader needs could be in any paragraph in the entire document, and there's no way to tell without reading the entire page.
|
||||
In the correct example, the reader can simply skim the headings in order to know which parts of the page need to be read and which can be safely ignored.
|
||||
The fact that some content is repeated in the two version-specific sections is not a problem, since no reader has to read the same thing twice.
|
||||
Moreover, as one version gets updated, it's likely that the documentation for that version will also be updated.
|
||||
Therefore, content that is initially duplicated between version-specific sections will not necessarily stay that way, and this is a good thing:
|
||||
We want the documentation for a version that *doesn't* change to stay the same, and we want the documentation for a version that *does* change to change along with the software.
|
||||
* It's easy for documentation contributors and maintainers to know which file to edit and update, since there's only one page for all Qubes OS versions.
|
||||
* It's easy for documentation contributors and maintainers to know which file to edit and update, since there's only one page for all Qubes OS versions.
|
||||
Initially creating the new headings and duplicating content that applies to both is only a one-time cost for each page, and many pages don't even require this treatment, since they apply to all currently-supported Qubes OS versions.
|
||||
|
||||
By contrast, an alternative approach, such as segregating the documentation into two different branches, would mean that contributions that apply to both Qubes versions would only end up in one branch, unless someone remembered to manually submit the same thing to the other branch and actually made the effort to do so.
|
||||
|
|
@ -281,10 +277,9 @@ Good general content that was submitted only to one branch would effectively dis
|
|||
|
||||
For further discussion about version-specific documentation in Qubes, see [here][version-thread].
|
||||
|
||||
|
||||
## Style guidelines
|
||||
|
||||
* Familiarize yourself with the terms defined in the [glossary]. Use these
|
||||
* Familiarize yourself with the terms defined in the [glossary]. Use these
|
||||
terms consistently and accurately throughout your writing.
|
||||
* Syntactically distinguish variables in commands.
|
||||
For example, this is ambiguous:
|
||||
|
|
@ -300,7 +295,6 @@ For further discussion about version-specific documentation in Qubes, see [here]
|
|||
2. Using underscores (`_`) between words
|
||||
3. Using all capital letters
|
||||
|
||||
|
||||
## Markdown conventions
|
||||
|
||||
All the documentation is written in Markdown for maximum accessibility.
|
||||
|
|
@ -320,14 +314,15 @@ When making contributions, please try to observe the following style conventions
|
|||
* Insert a newline at, and only at, the end of each sentence, except when the text will be reproduced outside of the Qubes website repo (see previous item for examples).
|
||||
* Rationale: This practice results in one sentence per line, which is most appropriate for source that consists primarily of natural language text.
|
||||
It results in the most useful diffs and facilitates translation into other languages while mostly preserving source readability.
|
||||
* If appropriate, make numerals in numbered lists match between Markdown source and HTML output.
|
||||
* Rationale: In the event that a user is required to read the Markdown source directly, this will make it easier to follow, e.g., numbered steps in a set of instructions.
|
||||
* Use hanging indentations
|
||||
* If appropriate, make numerals in numbered lists match between Markdown source and HTML output.
|
||||
* Rationale: In the event that a user is required to read the Markdown source directly, this will make it easier to follow, e.g., numbered steps in a set of instructions.
|
||||
* Use hanging indentations
|
||||
where appropriate.
|
||||
* Use Atx-style headings: `# h1`, `##h 2`, `### h3`, etc.
|
||||
* When writing code blocks, use [syntax highlighting](https://github.github.com/gfm/#info-string) where [possible](https://github.com/jneen/rouge/wiki/List-of-supported-languages-and-lexers) and use `[...]` for anything omitted.
|
||||
* When providing command line examples:
|
||||
* Tell the reader where to open a terminal (dom0 or a specific domU), and show the command along with its output (if any) in a code block, e.g.:
|
||||
* Use Atx-style headings: `# h1`, `##h 2`, `### h3`, etc.
|
||||
* When writing code blocks, use [syntax highlighting](https://github.github.com/gfm/#info-string) where [possible](https://github.com/jneen/rouge/wiki/List-of-supported-languages-and-lexers) and use `[...]` for anything omitted.
|
||||
* When providing command line examples:
|
||||
* Tell the reader where to open a terminal (dom0 or a specific domU), and show the command along with its output (if any) in a code block, e.g.:
|
||||
|
||||
~~~markdown
|
||||
Open a terminal in dom0 and run:
|
||||
```shell_session
|
||||
|
|
@ -336,10 +331,12 @@ When making contributions, please try to observe the following style conventions
|
|||
Hello
|
||||
```
|
||||
~~~
|
||||
* Precede each command with the appropriate command prompt:
|
||||
|
||||
* Precede each command with the appropriate command prompt:
|
||||
At a minimum, the prompt should contain a trailing `#` (for the user `root`) or `$` (for other users) on Linux systems and `>` on Windows systems, respectively.
|
||||
* Don't try to add comments inside the code block.
|
||||
* Don't try to add comments inside the code block.
|
||||
For example, *don't* do this:
|
||||
|
||||
~~~markdown
|
||||
Open a terminal in dom0 and run:
|
||||
```shell_session
|
||||
|
|
@ -350,18 +347,17 @@ When making contributions, please try to observe the following style conventions
|
|||
Hello
|
||||
```
|
||||
~~~
|
||||
|
||||
The `#` symbol preceding each comment is ambiguous with a root command prompt.
|
||||
Instead, put your comments *outside* of the code block in normal prose.
|
||||
|
||||
([This][md] is a great source for learning about Markdown.)
|
||||
|
||||
|
||||
## Git conventions
|
||||
|
||||
Please try to write good commit messages, according to the
|
||||
[instructions in our coding style guidelines][git-commit].
|
||||
|
||||
|
||||
[qubes-doc]: https://github.com/QubesOS/qubes-doc
|
||||
[glossary]: /doc/glossary/
|
||||
[issue]: /doc/reporting-bugs/
|
||||
|
|
|
|||
|
|
@ -1,8 +1,10 @@
|
|||
---
|
||||
lang: en
|
||||
layout: sidebar
|
||||
title: Google Summer of Code
|
||||
permalink: /gsoc/
|
||||
redirect_from: /GSoC/
|
||||
ref: 33
|
||||
title: Google Summer of Code
|
||||
---
|
||||
|
||||
2021 Google Summer of Code
|
||||
|
|
@ -98,17 +100,17 @@ If applicable, links to more information or discussions
|
|||
|
||||
**Expected results**:
|
||||
|
||||
- Design how Vagrant Qubes provider should look like, including:
|
||||
- [box format](https://www.vagrantup.com/docs/plugins/providers.html#box-format)
|
||||
- method for running commands inside (ssh vs qvm-run)
|
||||
- Write a Vagrant provider able to create/start/stop/etc a VM
|
||||
- Document how to configure and use the provider, including required qrexec policy changes and possibly firewall rules
|
||||
- Write integration tests
|
||||
- Design how Vagrant Qubes provider should look like, including:
|
||||
- [box format](https://www.vagrantup.com/docs/plugins/providers.html#box-format)
|
||||
- method for running commands inside (ssh vs qvm-run)
|
||||
- Write a Vagrant provider able to create/start/stop/etc a VM
|
||||
- Document how to configure and use the provider, including required qrexec policy changes and possibly firewall rules
|
||||
- Write integration tests
|
||||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
- Ruby
|
||||
- Vagrant concepts
|
||||
- Ruby
|
||||
- Vagrant concepts
|
||||
|
||||
**Mentor**: [Wojtek Porczyk](/team/), [Marek Marczykowski-Górecki](/team/)
|
||||
|
||||
|
|
@ -124,7 +126,6 @@ If applicable, links to more information or discussions
|
|||
- Implementation of the above mechanism.
|
||||
- Documentation how to configure it securely.
|
||||
|
||||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
- shell and/or python scripting
|
||||
|
|
@ -151,10 +152,11 @@ Choose either of GUI agent, GUI daemon. Both are of similar complexity and each
|
|||
- implement tests for new GUI handling, similar to existing tests for X11 based GUI
|
||||
|
||||
Relevant links:
|
||||
- [Low level GUI documentation](/doc/gui/)
|
||||
- [qubes-gui-agent-linux](https://github.com/qubesos/qubes-gui-agent-linux)
|
||||
- [qubes-gui-daemon](https://github.com/qubesos/qubes-gui-daemon)
|
||||
- [Use Wayland instead of X11 to increase performance](https://github.com/qubesos/qubes-issues/issues/3366)
|
||||
|
||||
- [Low level GUI documentation](/doc/gui/)
|
||||
- [qubes-gui-agent-linux](https://github.com/qubesos/qubes-gui-agent-linux)
|
||||
- [qubes-gui-daemon](https://github.com/qubesos/qubes-gui-daemon)
|
||||
- [Use Wayland instead of X11 to increase performance](https://github.com/qubesos/qubes-issues/issues/3366)
|
||||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
|
|
@ -181,21 +183,21 @@ details: [#1552](https://github.com/QubesOS/qubes-issues/issues/1552),
|
|||
|
||||
**Expected results**:
|
||||
|
||||
- Adjust set of VMs and templates included in live edition.
|
||||
- Update and fix build scripts for recent Qubes OS version.
|
||||
- Update startup script to mount appropriate directories as either
|
||||
copy-on-write (device-mapper snapshot), or tmpfs.
|
||||
- Optimize memory usage: should be possible to run sys-net, sys-firewall, and
|
||||
at least two more VMs on 4GB machine. This include minimizing writes to
|
||||
copy-on-write layer and tmpfs (disable logging etc).
|
||||
- Research option to install the system from live image. If feasible add
|
||||
this option.
|
||||
- Adjust set of VMs and templates included in live edition.
|
||||
- Update and fix build scripts for recent Qubes OS version.
|
||||
- Update startup script to mount appropriate directories as either
|
||||
copy-on-write (device-mapper snapshot), or tmpfs.
|
||||
- Optimize memory usage: should be possible to run sys-net, sys-firewall, and
|
||||
at least two more VMs on 4GB machine. This include minimizing writes to
|
||||
copy-on-write layer and tmpfs (disable logging etc).
|
||||
- Research option to install the system from live image. If feasible add
|
||||
this option.
|
||||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
- System startup sequence: bootloaders (isolinux, syslinux, grub, UEFI), initramfs, systemd.
|
||||
- Python and Bash scripting
|
||||
- Filesystems and block devices: loop devices, device-mapper, tmpfs, overlayfs, sparse files.
|
||||
- System startup sequence: bootloaders (isolinux, syslinux, grub, UEFI), initramfs, systemd.
|
||||
- Python and Bash scripting
|
||||
- Filesystems and block devices: loop devices, device-mapper, tmpfs, overlayfs, sparse files.
|
||||
|
||||
**Mentor**: [Frédéric Pierret](/team/)
|
||||
|
||||
|
|
@ -219,7 +221,6 @@ REMOVED as of January 2020: work is being done on this
|
|||
**Mentor**: [Thomas Leonard](mailto:talex5@gmail.com), [Marek Marczykowski-Górecki](/team/)
|
||||
-->
|
||||
|
||||
|
||||
### LogVM(s)
|
||||
|
||||
**Project**: LogVM(s)
|
||||
|
|
@ -232,35 +233,36 @@ immune to altering past entries. See
|
|||
|
||||
**Expected results**:
|
||||
|
||||
- Design a _simple_ protocol for transferring logs. The less metadata (parsed
|
||||
in log-collecting VM) the better.
|
||||
- Implement log collecting service. Besides logs itself, should save
|
||||
information about logs origin (VM name) and timestamp. The service should
|
||||
_not_ trust sending VM in any of those.
|
||||
- Implement log forwarder compatible with systemd-journald and rsyslog. A
|
||||
mechanism (service/plugin) fetching logs in real time from those and sending
|
||||
to log-collecting VM over qrexec service.
|
||||
- Document the protocol.
|
||||
- Write unit tests and integration tests.
|
||||
- Design a _simple_ protocol for transferring logs. The less metadata (parsed
|
||||
in log-collecting VM) the better.
|
||||
- Implement log collecting service. Besides logs itself, should save
|
||||
information about logs origin (VM name) and timestamp. The service should
|
||||
_not_ trust sending VM in any of those.
|
||||
- Implement log forwarder compatible with systemd-journald and rsyslog. A
|
||||
mechanism (service/plugin) fetching logs in real time from those and sending
|
||||
to log-collecting VM over qrexec service.
|
||||
- Document the protocol.
|
||||
- Write unit tests and integration tests.
|
||||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
- syslog
|
||||
- systemd
|
||||
- Python/Bash scripting
|
||||
- syslog
|
||||
- systemd
|
||||
- Python/Bash scripting
|
||||
|
||||
**Mentor**: [Frédéric Pierret](/team/)
|
||||
|
||||
|
||||
### Whonix IPv6 and nftables support
|
||||
|
||||
**Project**: Whonix IPv6 and nftables support
|
||||
|
||||
**Brief explanation**: [T509](https://phabricator.whonix.org/T509)
|
||||
|
||||
**Expected results**:
|
||||
|
||||
- Work at upstream Tor: An older version of https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy page was the origin of Whonix. Update that page for nftables / IPv6 support without mentioning Whonix. Then discuss that on the tor-talk mailing list for wider input. - https://trac.torproject.org/projects/tor/ticket/21397
|
||||
- implement corridor feature request add IPv6 support / port to nftables - https://github.com/rustybird/corridor/issues/39
|
||||
- Work at upstream Tor: An older version of [TransparentProxy](https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy) page was the origin of Whonix. Update that page for nftables / IPv6 support without mentioning Whonix. Then discuss that on the tor-talk mailing list for wider input. [here](https://trac.torproject.org/projects/tor/ticket/21397)
|
||||
- implement corridor feature request add IPv6 support / port to nftables - [issue](https://github.com/rustybird/corridor/issues/39)
|
||||
- port [whonix-firewall](https://github.com/Whonix/whonix-firewall) to nftables
|
||||
- make connections to IPv6 Tor relays work
|
||||
- make connections to IPv6 destinations work
|
||||
|
|
@ -293,19 +295,19 @@ immune to altering past entries. See
|
|||
|
||||
**Expected results**:
|
||||
|
||||
- A template for `autounattended.xml` file for Windows installer - the template should have placeholders for settings that need to be provided by the user.
|
||||
- A tool for generating actual `autounattended.xml` file based on the template and user settings.
|
||||
- A tool for launching Windows installation, given installation image and `autounattended.xml` file (can be the same as in the above point).
|
||||
- (Optional) Unattended installation should also include Qubes Windows Tools.
|
||||
- (Optional) A tool should be able to use Windows license embedded in ACPI tables - [related discussion](https://groups.google.com/d/msgid/qubes-devel/0b7fabae-f843-e7ce-40cf-193326cecdb0%40zrubi.hu)
|
||||
- User documentation
|
||||
- Automated tests (unit tests, integration tests)
|
||||
- A template for `autounattended.xml` file for Windows installer - the template should have placeholders for settings that need to be provided by the user.
|
||||
- A tool for generating actual `autounattended.xml` file based on the template and user settings.
|
||||
- A tool for launching Windows installation, given installation image and `autounattended.xml` file (can be the same as in the above point).
|
||||
- (Optional) Unattended installation should also include Qubes Windows Tools.
|
||||
- (Optional) A tool should be able to use Windows license embedded in ACPI tables - [related discussion](https://groups.google.com/d/msgid/qubes-devel/0b7fabae-f843-e7ce-40cf-193326cecdb0%40zrubi.hu)
|
||||
- User documentation
|
||||
- Automated tests (unit tests, integration tests)
|
||||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
- Python scripting
|
||||
- Linux administration, including handling loop devices, partition tables, filesystems etc
|
||||
- For optional features, C language and x86 architecture (ACPI tables)
|
||||
- Python scripting
|
||||
- Linux administration, including handling loop devices, partition tables, filesystems etc
|
||||
- For optional features, C language and x86 architecture (ACPI tables)
|
||||
|
||||
**Mentor**: [Rafał Wojdyła](/team/), [Marek Marczykowski-Górecki](/team/)
|
||||
|
||||
|
|
@ -315,33 +317,33 @@ immune to altering past entries. See
|
|||
|
||||
**Brief explanation**: Integrating GNOME into Qubes dom0. This include:
|
||||
|
||||
- patching window manager to add colorful borders
|
||||
- removing stuff not needed in dom0 (file manager(s), indexing services etc)
|
||||
- adjusting menu for easy navigation (same applications in different VMs and such problems, dom0-related entries in one place)
|
||||
- More info: [#1806](https://github.com/QubesOS/qubes-issues/issues/1806)
|
||||
- patching window manager to add colorful borders
|
||||
- removing stuff not needed in dom0 (file manager(s), indexing services etc)
|
||||
- adjusting menu for easy navigation (same applications in different VMs and such problems, dom0-related entries in one place)
|
||||
- More info: [#1806](https://github.com/QubesOS/qubes-issues/issues/1806)
|
||||
|
||||
**Expected results**:
|
||||
|
||||
- Review existing support for other desktop environments (KDE, Xfce4, i3, awesome).
|
||||
- Patch window manager to draw colorful borders (we use only server-side
|
||||
decorations), there is already very similar patch in
|
||||
[Cappsule project](https://github.com/cappsule/cappsule-gui).
|
||||
- Configure GNOME to not make use of dom0 user home in visible way (no search
|
||||
in files there, no file manager, etc).
|
||||
- Configure GNOME to not look into external devices plugged in (no auto
|
||||
mounting, device notifications etc).
|
||||
- Package above modifications as rpms, preferably as extra configuration files
|
||||
and/or plugins than overwriting existing files. Exceptions to this rule may
|
||||
apply if no other option.
|
||||
- Adjust comps.xml (in installer-qubes-os repo) to define package group with
|
||||
all required packages.
|
||||
- Document installation procedure.
|
||||
- Review existing support for other desktop environments (KDE, Xfce4, i3, awesome).
|
||||
- Patch window manager to draw colorful borders (we use only server-side
|
||||
decorations), there is already very similar patch in
|
||||
[Cappsule project](https://github.com/cappsule/cappsule-gui).
|
||||
- Configure GNOME to not make use of dom0 user home in visible way (no search
|
||||
in files there, no file manager, etc).
|
||||
- Configure GNOME to not look into external devices plugged in (no auto
|
||||
mounting, device notifications etc).
|
||||
- Package above modifications as rpms, preferably as extra configuration files
|
||||
and/or plugins than overwriting existing files. Exceptions to this rule may
|
||||
apply if no other option.
|
||||
- Adjust comps.xml (in installer-qubes-os repo) to define package group with
|
||||
all required packages.
|
||||
- Document installation procedure.
|
||||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
- GNOME architecture
|
||||
- C language (patching metacity)
|
||||
- Probably also javascript - for modifying GNOME shell extensions
|
||||
- GNOME architecture
|
||||
- C language (patching metacity)
|
||||
- Probably also javascript - for modifying GNOME shell extensions
|
||||
|
||||
**Mentor**: [Frédéric Pierret](/team/), [Marek Marczykowski-Górecki](/team/)
|
||||
|
||||
|
|
@ -358,6 +360,7 @@ immune to altering past entries. See
|
|||
**Mentors**: Andrew Clausen and Jean-Philippe Ouellet
|
||||
|
||||
### Progress towards reproducible builds
|
||||
|
||||
**Project**: Progress towards reproducible builds
|
||||
|
||||
**Brief explanation**: A long-term goal is to be able to build the entire OS and installation media in a completely bit-wise deterministic manner, but there are many baby steps to be taken along that path. See:
|
||||
|
|
@ -384,22 +387,22 @@ Qubes currently only supports the x86_64 CPU architecture. Xen currently has add
|
|||
|
||||
Some related discussion:
|
||||
|
||||
- [#4318](https://github.com/QubesOS/qubes-issues/issues/4318) on porting to ppc64.
|
||||
- [#3894](https://github.com/QubesOS/qubes-issues/issues/3894) on porting to L4 microkernel.
|
||||
- [#4318](https://github.com/QubesOS/qubes-issues/issues/4318) on porting to ppc64.
|
||||
- [#3894](https://github.com/QubesOS/qubes-issues/issues/3894) on porting to L4 microkernel.
|
||||
|
||||
**Expected results**:
|
||||
|
||||
- Add cross-compilation support to qubes-builder and related components.
|
||||
- Make aarch64 specific adjustments to Qubes toolstacks/manager (including passthrough of devices from device tree to guest domains).
|
||||
- Aarch64 specific integration and unit tests.
|
||||
- Production of generic u-boot or uefi capable image/iso for target hardware.
|
||||
- Add cross-compilation support to qubes-builder and related components.
|
||||
- Make aarch64 specific adjustments to Qubes toolstacks/manager (including passthrough of devices from device tree to guest domains).
|
||||
- Aarch64 specific integration and unit tests.
|
||||
- Production of generic u-boot or uefi capable image/iso for target hardware.
|
||||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
- Libvirt and Qubes toolstacks (C and python languages).
|
||||
- Xen debugging.
|
||||
- General ARM architecture knowledge.
|
||||
|
||||
- Libvirt and Qubes toolstacks (C and python languages).
|
||||
- Xen debugging.
|
||||
- General ARM architecture knowledge.
|
||||
|
||||
**Mentor**: [Marek Marczykowski-Górecki](/team/)
|
||||
|
||||
|
||||
|
|
@ -426,17 +429,17 @@ More information and further links can be found in the related issue:
|
|||
|
||||
**Expected results**:
|
||||
|
||||
- Add cross-compilation support to qubes-builder and related components.
|
||||
- Make ppc64 specific adjustments to Qubes toolstacks/manager (including passthrough of devices from device tree to guest domains).
|
||||
- ppc64 specific integration and unit tests.
|
||||
- Production of generic u-boot or uefi capable image/iso for target hardware.
|
||||
- Add cross-compilation support to qubes-builder and related components.
|
||||
- Make ppc64 specific adjustments to Qubes toolstacks/manager (including passthrough of devices from device tree to guest domains).
|
||||
- ppc64 specific integration and unit tests.
|
||||
- Production of generic u-boot or uefi capable image/iso for target hardware.
|
||||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
- Libvirt and Qubes toolstacks (C and python languages).
|
||||
- KVM or XEN internals
|
||||
- General ppc64 architecture knowledge.
|
||||
|
||||
- Libvirt and Qubes toolstacks (C and python languages).
|
||||
- KVM or XEN internals
|
||||
- General ppc64 architecture knowledge.
|
||||
|
||||
**Mentor**: [Marek Marczykowski-Górecki](/team/)
|
||||
|
||||
-->
|
||||
|
|
@ -451,11 +454,12 @@ Since it's software emulation it's rather slow.
|
|||
Details, reference: [#2233](https://github.com/QubesOS/qubes-issues/issues/2233)
|
||||
|
||||
**Expected results**:
|
||||
- a simple way of setting up Android qubes with hardware emulation
|
||||
|
||||
- a simple way of setting up Android qubes with hardware emulation
|
||||
(distributed as a template or as a salt, handling various modern Android versions)
|
||||
- figuring out and implementing an easy and secure way to connect an Android
|
||||
- figuring out and implementing an easy and secure way to connect an Android
|
||||
qube to a development qube with Android studio
|
||||
- documentation and tests
|
||||
- documentation and tests
|
||||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
|
|
@ -521,7 +525,7 @@ A [Fuzzer](https://en.wikipedia.org/wiki/Fuzzing) would help to automate part of
|
|||
|
||||
## Past Projects
|
||||
|
||||
You can view the projects we had in 2017 in the [GSoC 2017 archive][2017-archive]. We also participated in GSoC 2020, and you can see the project in the [GSoC 2020 archive][2020-archive].
|
||||
You can view the projects we had in 2017 in the [GSoC 2017 archive][2017-archive]. We also participated in GSoC 2020, and you can see the project in the [GSoC 2020 archive][2020-archive].
|
||||
|
||||
Here are some successful projects which have been implemented in the past by Google Summer of Code participants.
|
||||
|
||||
|
|
@ -551,14 +555,14 @@ would override all the user changes there). More details:
|
|||
files, LVM thin volumes etc).
|
||||
- template metadata, templates repository - enable the user to browse
|
||||
available templates (probably should be done in dedicated VM, or DisposableVM)
|
||||
- manual template removal by users (without it, see problems such
|
||||
- manual template removal by users (without it, see problems such
|
||||
as [#5509](https://github.com/QubesOS/qubes-issues/issues/5509)
|
||||
- Implement the above mechanism:
|
||||
- tool to download named template - should perform download operation in
|
||||
some VM (as dom0 have no network access), then transfer the data to dom0,
|
||||
verify its integrity and then create Template VM and feed it's root
|
||||
filesystem image with downloaded data.
|
||||
- tool to browse templates repository - both CLI and GUI (preferably integrated
|
||||
- tool to browse templates repository - both CLI and GUI (preferably integrated
|
||||
with existing Template Manager tool)
|
||||
- integrate both tools - user should be able to choose some template to be
|
||||
installed from repository browsing tool - see
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
lang: en
|
||||
layout: sidebar
|
||||
title: Join
|
||||
permalink: /join/
|
||||
ref: 26
|
||||
title: Join
|
||||
---
|
||||
|
||||
Joining the Qubes OS Team
|
||||
|
|
@ -9,5 +11,4 @@ Joining the Qubes OS Team
|
|||
|
||||
The Qubes OS Project does not currently have any open positions.
|
||||
This page will be updated when open positions become available.
|
||||
In the meantime, there are many different ways you can [contribute to the Qubes OS project](/doc/contributing/).
|
||||
|
||||
In the meantime, there are many different ways you can [contribute to the Qubes OS project](/doc/contributing/).
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
title: Package Contributions
|
||||
permalink: /doc/package-contributions/
|
||||
ref: 29
|
||||
title: Package Contributions
|
||||
---
|
||||
|
||||
Package Contributions
|
||||
|
|
@ -15,38 +17,41 @@ This page explains the inclusion criteria and procedures for such packages, as w
|
|||
|
||||
Inclusion Criteria
|
||||
------------------
|
||||
|
||||
In order to be accepted, packages must:
|
||||
|
||||
* In no way weaken the security of Qubes OS.
|
||||
* Be published under an open-source license (read about the [Qubes OS License]).
|
||||
* Follow our [coding guidelines].
|
||||
* Be thoroughly tested.
|
||||
* Have a clearly-defined use case for Qubes users.
|
||||
* Not be unduly burdensome to review.
|
||||
* In no way weaken the security of Qubes OS.
|
||||
* Be published under an open-source license (read about the [Qubes OS License]).
|
||||
* Follow our [coding guidelines].
|
||||
* Be thoroughly tested.
|
||||
* Have a clearly-defined use case for Qubes users.
|
||||
* Not be unduly burdensome to review.
|
||||
|
||||
(Please note that we always reserve the right to add criteria to this list.)
|
||||
|
||||
Contribution Procedure
|
||||
----------------------
|
||||
|
||||
Before you start putting serious work into a package, we recommend that you discuss your idea with the Qubes developers and the broader community on the [qubes-devel mailing list].
|
||||
Once you have a package that's ready to become part of Qubes OS, please follow this procedure:
|
||||
|
||||
1. Ensure that your package satisfies the [Inclusion Criteria].
|
||||
2. If your code isn't already on GitHub, create a GitHub repo that contains your code. You can have a look to an example package called [qubes-skeleton].
|
||||
3. If you haven't already, [sign your code][sig].
|
||||
4. Create an issue in [qubes-issues] with the title `[Contribution] your-package-name`.
|
||||
Include a link to your repo, a brief description of your package, and a brief explanation of why you think it should be included in Qubes.
|
||||
Please note that the Qubes core developers are very busy.
|
||||
If they are under heavy load when you submit your contribution, it may be a very long time before they have time to review your package.
|
||||
If this happens, please do not be discouraged.
|
||||
If you think they may have forgotten about your pending contribution, you may "bump" your request by commenting on your issue, but please do this *very* sparingly (i.e., no more than once a month).
|
||||
We appreciate your understanding!
|
||||
5. You may be asked followup questions.
|
||||
If we decide to accept your contribution, you will be invited to join the [QubesOS-contrib] organization on GitHub as public recognition of your contribution (but without push access; see [Review Procedure]), and [QubesOS-contrib] will fork your repo.
|
||||
If we decide not to accept your contribution, we will state the reason and close the issue.
|
||||
1. Ensure that your package satisfies the [Inclusion Criteria].
|
||||
2. If your code isn't already on GitHub, create a GitHub repo that contains your code. You can have a look to an example package called [qubes-skeleton].
|
||||
3. If you haven't already, [sign your code][sig].
|
||||
4. Create an issue in [qubes-issues] with the title `[Contribution] your-package-name`.
|
||||
Include a link to your repo, a brief description of your package, and a brief explanation of why you think it should be included in Qubes.
|
||||
Please note that the Qubes core developers are very busy.
|
||||
If they are under heavy load when you submit your contribution, it may be a very long time before they have time to review your package.
|
||||
If this happens, please do not be discouraged.
|
||||
If you think they may have forgotten about your pending contribution, you may "bump" your request by commenting on your issue, but please do this *very* sparingly (i.e., no more than once a month).
|
||||
We appreciate your understanding!
|
||||
5. You may be asked followup questions.
|
||||
If we decide to accept your contribution, you will be invited to join the [QubesOS-contrib] organization on GitHub as public recognition of your contribution (but without push access; see [Review Procedure]), and [QubesOS-contrib] will fork your repo.
|
||||
If we decide not to accept your contribution, we will state the reason and close the issue.
|
||||
|
||||
Update Procedure
|
||||
----------------
|
||||
|
||||
*Anyone* can provide an update (patch) to a contributed package, not just the person who contributed that package!
|
||||
The update procedure is the same for everyone, including the original package contributor.
|
||||
|
||||
|
|
@ -57,6 +62,7 @@ Please be prepared to read and respond to these comments.
|
|||
|
||||
Review Procedure
|
||||
----------------
|
||||
|
||||
This review procedure covers both original package contributions (see [Contribution Procedure]) and all subsequent updates to those packages, including updates from the original package contributor (see [Update Procedure]).
|
||||
All changes will be reviewed by a Qubes Core Reviewer (QCR) and the [Package Maintainer] (PM).
|
||||
In all cases, the QCR will be a core Qubes developer.
|
||||
|
|
@ -65,38 +71,39 @@ For example, if someone contributes a package, then disappears, and no suitable
|
|||
|
||||
The review procedure is as follows:
|
||||
|
||||
1. Someone, S, wishes to make a change to a package, P.
|
||||
2. S submits a fast-forwardable pull request against the fork of P's repo owned by [QubesOS-contrib].
|
||||
3. The PM reviews the pull request.
|
||||
If the the pull request passes the PM's review, the PM adds a [signed][sig] *comment* on the pull request stating that it has passed review.
|
||||
(In cases in which S = PM, the PM can simply add a [signed][sig] *tag* to the HEAD commit prior to submitting the pull request.)
|
||||
If the pull request does not pass the PM's review, the PM leaves a comment on the pull request explaining why not.
|
||||
4. The QCR reviews the pull request.
|
||||
If the pull request passes the QCR's review, the QCR pushes a [signed][sig] tag to the HEAD commit stating that it has passed review and fast-forward merges the pull request.
|
||||
If the pull request does not pass the QCR's review, the QCR leaves a comment on the pull request explaining why not, and the QCR may decide to close the pull request.
|
||||
1. Someone, S, wishes to make a change to a package, P.
|
||||
2. S submits a fast-forwardable pull request against the fork of P's repo owned by [QubesOS-contrib].
|
||||
3. The PM reviews the pull request.
|
||||
If the the pull request passes the PM's review, the PM adds a [signed][sig] *comment* on the pull request stating that it has passed review.
|
||||
(In cases in which S = PM, the PM can simply add a [signed][sig] *tag* to the HEAD commit prior to submitting the pull request.)
|
||||
If the pull request does not pass the PM's review, the PM leaves a comment on the pull request explaining why not.
|
||||
4. The QCR reviews the pull request.
|
||||
If the pull request passes the QCR's review, the QCR pushes a [signed][sig] tag to the HEAD commit stating that it has passed review and fast-forward merges the pull request.
|
||||
If the pull request does not pass the QCR's review, the QCR leaves a comment on the pull request explaining why not, and the QCR may decide to close the pull request.
|
||||
|
||||
In all the cases, the first condition to be validated by the QCR's review is to ensure that the contribution **will not** hijack any core packages of [QubesOS] and of course, none of the [QubesOS-contrib] packages too. More precisely, particular attention to the whole build pipeline will be made with a specific review of:
|
||||
- Package dependencies,
|
||||
- Build scripts (including downloaded ones),
|
||||
- All downloaded components should be verified against static hash,
|
||||
- RPM/DEB installation scripts (e.g. looking at constraints who would hijack other packages),
|
||||
- Makefiles,
|
||||
- Package build [reproducible]
|
||||
|
||||
* Package dependencies,
|
||||
* Build scripts (including downloaded ones),
|
||||
* All downloaded components should be verified against static hash,
|
||||
* RPM/DEB installation scripts (e.g. looking at constraints who would hijack other packages),
|
||||
* Makefiles,
|
||||
* Package build [reproducible]
|
||||
|
||||
and any steps which would result in partial/total compromise of legitimate components. For this part, you can have a look to an example package called [qubes-skeleton].
|
||||
|
||||
Package Maintainers
|
||||
-------------------
|
||||
|
||||
If you contribute a package, we assume that you will be the maintainer of that package, unless you tell us otherwise.
|
||||
As the maintainer of the package, it is your privilege and responsibility to:
|
||||
|
||||
* [Review][Review Procedure] each pull request made against the package.
|
||||
* Decide when the package has reached a new version, and notify the Qubes core developers when this occurs.
|
||||
* [Review][Review Procedure] each pull request made against the package.
|
||||
* Decide when the package has reached a new version, and notify the Qubes core developers when this occurs.
|
||||
|
||||
If you do not wish to be the maintainer of your package, please let us know.
|
||||
If you do not act on your maintainer duties for a given package for an extended period of time and after at least one reminder, we will assume that you no longer wish to be the maintainer for that package.
|
||||
|
||||
|
||||
[installing contributed packages]: /doc/installing-contributed-packages/
|
||||
[Inclusion Criteria]: #inclusion-criteria
|
||||
[Contribution Procedure]: #contribution-procedure
|
||||
|
|
|
|||
|
|
@ -1,96 +1,7 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
title: Style-guide
|
||||
permalink: /doc/style-guide/
|
||||
ref: 27
|
||||
title: Style-guide
|
||||
---
|
||||
|
||||
Style Guide
|
||||
===========
|
||||
|
||||
## Fonts
|
||||
|
||||
Currently Qubes OS is using the following fonts for our website, branding, and other public facing (non-OS) materials. The OS itself uses what is normal for a user's desktop environment of choice.
|
||||
|
||||
<div class="styleguide">
|
||||
{% for font in site.data.styleguide.fonts %}
|
||||
<div class="row">
|
||||
<div class="col-lg-6 col-md-6 focus">
|
||||
<div class="font {{font.class}}">Custom Qubes Font</div>
|
||||
</div>
|
||||
<div class="col-lg-6 col-md-6">
|
||||
<strong>Family:</strong> {{font.family}}<br>
|
||||
</div>
|
||||
</div>
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Colors
|
||||
|
||||
The following **grayscale** colors are currently used on the Qubes website and documentation, and they will eventually match colors within the OS itself.
|
||||
|
||||
<div class="styleguide">
|
||||
{% for color in site.data.styleguide.colors %}
|
||||
{% if color.type == "grayscale" %}
|
||||
<div class="swatch more-bottom more-right">
|
||||
<div class="color add-bottom bg-{{color.class}}"></div>
|
||||
<strong class="add-bottom">{{color.name}}</strong>
|
||||
<code>#{{color.hex | downcase}}</code>
|
||||
</div>
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
The following **colors** are currently being used on the Qubes website and documentation, and they will eventually match the colors within the OS itself!
|
||||
|
||||
<div class="styleguide">
|
||||
{% for color in site.data.styleguide.colors %}
|
||||
{% if color.type == "colors" %}
|
||||
<div class="swatch more-bottom more-right">
|
||||
<div class="color add-bottom bg-{{color.class}}"></div>
|
||||
<strong class="add-bottom">{{color.name}}</strong>
|
||||
<code>#{{color.hex | downcase}}</code>
|
||||
</div>
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Icons
|
||||
|
||||
Currently, all the icons on the Qubes-OS.org website are generated using [FontAwesome](https://fontawesome.com/).
|
||||
|
||||
*As more custom work is done to generate icons for the operating system itself, they will be added here!*
|
||||
|
||||
---
|
||||
|
||||
## Logos
|
||||
|
||||
The following is a collection of various sizes and versions of the Qubes logo used both in the OS itself and on our website.
|
||||
The artwork is licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).
|
||||
The code is licensed under GNU GPLv2.
|
||||
GPLv2 and the source code can be [downloaded here](https://github.com/QubesOS/qubes-artwork).
|
||||
|
||||
<div class="styleguide">
|
||||
{% for logo in site.data.styleguide.logos %}
|
||||
{% for version in logo.versions %}
|
||||
<div class="row more-bottom">
|
||||
<div class="col-lg-4 col-md-4">
|
||||
<div class="focus">
|
||||
<img class="logo" src="{{version.path}}{{logo.image}}">
|
||||
</div>
|
||||
</div>
|
||||
<div class="col-lg-8 col-md-8">
|
||||
<p>
|
||||
<strong>Image:</strong> {{logo.image}}<br>
|
||||
<strong>Size:</strong> {{version.size}}<br>
|
||||
<strong>Format:</strong> {{version.format}}<br>
|
||||
<strong>Download:</strong> <a href="{{version.path}}{{logo.image}}" target="_blank">this image</a>
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
{% endfor %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -1,11 +1,12 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
title: Usability & UX
|
||||
permalink: /doc/usability-ux/
|
||||
ref: 31
|
||||
title: Usability & UX
|
||||
---
|
||||
|
||||
Usability & UX
|
||||
==============
|
||||
# Usability & UX
|
||||
|
||||
Software that is too complicated to use, is often unused. Because we want as many people as possible to benefit from its unique security properties, the usability and user experience of Qubes OS is an utmost priority!
|
||||
|
||||
|
|
@ -39,7 +40,6 @@ Perhaps the most common cause of mistakes is complexity. If there is a configura
|
|||
|
||||
In making software easy to use, it is crucial to be mindful of [cognitive load](https://en.wikipedia.org/wiki/Cognitive_load) which dictates that *"humans are generally able to hold only seven +/- two units of information in short-term memory."* Making sure your interfaces don't pass this short-term memory limit is perhaps the most important factor in helping a user feel comfortable instead of overwhelmed.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Easy to Understand
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue