DNS issues in Kali HVM

deeplow · December 7, 2020, 4:51pm

Hi. I can’t comment about this installation method, but some other methods in that guide are broken (such as the one where you start on debian and dist-updade into kali.

These guides break from time to time and if no one bothers to update them, they will stay like that and many users may fall into a trap. This seems to be one of those cases, which is unfortunate. Qubes has been purging out the external documentation from the “official docs” for this reason.

github.com/QubesOS/qubes-issues

Split Qubes docs into "core" and "community" docs

opened 09:55AM - 07 Jan 19 UTC

closed 12:37PM - 08 Dec 20 UTC

ghost

T: enhancement C: doc P: default

This will likely be a controversial topic, but let's float the idea. tl;dr; i…mho it would make sense to split the docs into "core", well-reviewed, security-sensitive docs, and "community" reviewed docs that are more "peripheral" to Qubes. This should help: - increase the number of first-time contributors - who could then become regular contributors to the project - help contributors with doc guidelines and improve the quality of the docs overall; the "community" could be used as a staging area similar to the staging branch of the linux kernel - lower @marmarek 's workload - increase (and make easily found/searchable) the number of docs/resources related to Qubes OS's usage. [EDIT] An alternative would be to leave the docs as-is, and put links to "community" resources somewhere in the official docs. --- Issues with the current docs: - the PR submission process isn't easy for git noobs. At least it wasn't for me - I had to learn git only to be able to improve the docs, it did require time and motivation, hopefully that was at a time when I could spend more spare time on Qubes than I do now. That's likely not the case for most users, some of them who could have provided helpful improvements but are/were put off by the seemingly convoluted process. (Sure, once you know git it is easy but then not everyone knows git nor is interested in learning it). - @marmarek is more or less the only technical reviewer of doc PRs nowadays and his workload makes him a bottleneck; PRs can stay for weeks/months before being accepted. That can be a bit discouraging for users who have put some time in trying to improve the project. (to be clear I'm not complaining - just stating what I see). - some official docs have nothing to do with Qubes and clutter the doc ToC. The [Qubes Community](https://github.com/Qubes-Community) project [tries to solve](https://qubes-community.github.io/) (some of) the issues above. The project is very slowly getting some traction but judging by questions asked on the ML and issues which are already answered in details in docs in the project, most people aren't aware of this effort. There are also great third party resources (eg @tasket 's contributions, @unman 's repositories, ...) that users aren't aware of because they're not advertised anywhere in the official site - and rightfully so, because that could give a false sense of endorsement and/or security. Having links to those resources in a "community" resources page, with the usual disclaimer, would definitely increase the visibility of such efforts. Given all of the above, wouldn't it make sense to have only a small amount of "core" official docs that are carefully reviewed by the Qubes team and thus have a higher "security trust level", and have a Qubes endorsed community doc project (not necessarily the one mentioned above), administered by proficient/long-time qubes users - maybe picked by the Qubes team - where the submission rules/quality would be relaxed, and where it would be clear for users that those community docs have a lower "trust level" ? As noted above, this would: - allow people not familiar to git to contribute stuff, and maybe learn git in the process until they're confident enough to send PRs (both the the community and official docs). - allow people to contribute lower quality/incomplete/... *but helpful* docs (eg. specifics of installing [whateverOS] as a qube VM). - streamline the official docs structure (and thus making it easier to parse) by keeping only the documentation specific to Qubes OS, on which the community docs are based. Some of the existing docs could me moved - eg. configuration of OSes in (H)VMs, XFCE/KDE features that aren't specific to Qubes, DPI in VMs, setting a dark background, etcetera. Thoughts ?

I would advise you checking out the kali template that’s being worked on.