Continuing the discussion from [Todo] Wiki page regarding Qubes Filesystem Persistence:
Sorry to rehash what seems to have been an active and passionate discussion (issue 1201). Maybe I’m reading into it what I want to read, but it seems that the consensus opinion was to port “clear, short instructions on how to make Whonix work within Qubes!” I would agree that that’s the correct approach on both sides.
Barring a complete integration of Whonix into Qubes, both sites should maintain their respective docs, including some overlap when it comes to general concepts, setup procedures, and basic troubleshooting. The cost to maintaining basic docs is minimal, and these pages are reviewed frequently by many users.
The overlap is necessary because users may approach each of the projects from diverse backgrounds and not have the motivation to explore the other project in much depth, if at all. This is especially (maybe only ideally?) true for Whonix users. Qubes tends to have more technically-savvy users [judging by each vocal community which is obviously a biased measure since Whonix users value their privacy by default], which makes sense since you have to have some grasp of technical concepts to appreciate a secure OS. On the other hand, there is no technical prerequisite for wanting greater privacy. Information about Qubes needs to be presented in an even more approachable fashion to Whonix users. ie custom Qubes Getting Started page on Whonix.org…
Each project should host on its own, documentation regarding advanced, niche, project specific information. Advanced users are more likely to seek out documentation from other sources. More importantly, the documentation needs to reside where it will be best maintained. When necessary, pages should be mirrored or linked instead of keeping multiple versions.
One thing that stands out from the discussion is the need for specific criteria to determine where pages should be hosted. Otherwise, docs can develop a tendency to be over-ambitious and balloon with obsolete or poorly maintained information.
Some possible criteria:
- Which user-base is more likely to actively maintain topic?
- Does topic represent basic functionality? Then, keep in both places.
- Does topic represent optional, advanced, specific, or experimental usage? Then leave with specific project.
Examples to show that it’s not so clear cut and every page needs to be decided case-by-case:
Using Whonix as Disposable VM: Very clearly laid out already by the generalized DispVM instructions on qubes site. But not hard to maintain in both places. Is this basic functionality or optional? I don’t know. When Whonix users ask how to do this, will a link to the qubes site be sufficient or will they need more specific instructions? Ideal solution is to have automated Whonix DispVM setup when Whonix is installed… (In that sense, if it’s something that should be installed by default, maybe it is basic usage.)
Tor Bridges: With the notable exception of Chinese & Iranian users, this should not be considered basic functionality. There is also no doubt that this page would be better maintained by the Whonix user-base. Bridges are an integral part of Tor, which makes it indirectly a part of Whonix. There is no obvious relation to Qubes. Bridges stay here. (With respect to users needing censorship circumvention, it also seems more likely for them to come to Whonix before Qubes).
Qubes Filesystem Persistence: This is an advanced concept general to the Qubes OS as a whole. The code may receive patches and documenting changes faithfully is well within the interest of the qubes team. Main article should be on qubes-os.org. What happens when Whonix user wants to customize appVM and can’t figure out why changes keep getting reset? Whonix wiki should link to the main article and present a stub with Whonix-specific information.
my 2 cents…