For what it’s worth - I have been planning on putting together some initial walk-throughs on basic tasks like installing and configuring Qubes for the first time, migrating VMs from other platforms over, and other lessons learned. Long before this forum existed, I had this planned. Originally, I figured I would just toss this up on Medium and let whatever search indexers are out there guide users in.
BUT.
If there is a larger community driven effort, I would happily participate. Perhaps there is a sign up sheet that I do not know of. If so, please forgive me for interloping on this interesting conversation.
If there is a larger community driven effort, I would happily
participate. Perhaps there is a sign up sheet that I do not know of.
If so, please forgive me for interloping on this interesting
conversation.
Awesome! There will be an “asynchronous workshop” soon moderated by @nina. We will make a lot of noise in the respective forum threads when
that happens, you won’t be able to miss it
I am new here and ran across this thread. Obviously hoping your endeavor comes true!
I recently installed Qubes on a Librem Mini v2 and created two docs as walkthroughs.
I originally posted them on Purism’s forum. But offer them if they are useful.
The first in particular is rather long so I won’t copy here unless anyone wants it. (perhaps in a separate thread or under a specific category)
Divide Documentation into “How To.” “Why To.” “Consequences of not doing.”
If user can not make up his mind, “Do this (Nudge Notes).”
I agree with the idea of getting documentation for Journalists. Guessing they are not a highly computer technical audience, know enough that they should be afraid. And only want enough documentation to use Qubes without creating a hazard to themselves, their informants.
Look I have created a whole new level of confusion.
Quick question - I would like to get started on documentation but don’t know where to begin as I have never done anything like this before. Where and how do I get started? Thanks.
Started on improving existing Qubes documentation, or started on putting together a “Simple User Guide” discussed in this post?
I somewhat dropped the ball 9 weeks ago, offering to put together an asynchronous workshop and then just being perpetually too overworked to dedicate time to that. I still want to do that, but also don’t want to roadblock others excited to contribute to something, now.
I feel there are a few main points around which to orient this work, that should be defined up-front:
Who is this for (needs, motivations, existing skills)?
Who is this not for (needs, motivations, existing skills)?
What principles do we desire for content to align against?
After or in parallel to that, I’d suggest drafting an outline of topics to then write documentation against.
After or in parallel to that, if there’s a topic you feel excited to just dive on into, go for it!
This is one of the blocking factors that keeps me at this moment stalled. For example - what assumptions do have for who this is for? Basic Linux knowledge? Perhaps a few month’s of Ubuntu usage as a base “profile”?
For the second and third considerations - I have no concept.
For my part, I would like to contribute to the Simple User Guide primarily as I would like to contribute to the easing what was a rather rough onboarding experience that I had when I went through teaching myself how to Qubes. There were places were the documentation was out of date or did not exist. And I had to teach myself through trial and error, sometimes breaking my install and starting over.
There is power in pain so I do not want all things to be simple but where it makes sense - there should likely be a doc to light the way.
So back to practical matters - I believe your workshop would hold considerable value but if one has to wait perhaps one can start here? Getting started | Qubes OS
What I envision is a short, crisp introduction to the core concepts of
Qubes OS. We can assume the user is familiar with basic UI concepts
(windows, dialogs, applications, mouse). The stuff a “non-technical” Mac
or Windows user would understand.
A recent thread makes clear that even things like a clipboard may
already need some more explanations.
The guide should explain the why and the how from a user’s perspective.
Why would I want to use Qubes OS? What is compartmentalization and how
would I use it? What is a qube, template, dom0? How do I exchange
information between qubes? How do I find and install additional
software? Where do I go to ask for help?
What the guide should not be: a discussion of underlying technologies or
products (virtualization, storage pools, Xen, Linux, XFCE bla bla bla).
One doesn’t need to know those things to use Qubes OS.
The target is any person wishing to take measures to secure their
information. We should not assume anything else. They can read and they
know how to use Mac or a Windows PC. That’s it.
The only additional thing I’d add @corbeaucrypto, is that, yes, I would absolutely include within this, people new to Linux. Why? The few folks I know who use Linux systems out of financial necessity (vs nrrdtasticness), have no idea what a “desktop” or a “desktop” environment is; don’t know what a “distribution” is, and also don’t realize the have a virtual potpourri of utilities at their fingertips should they choose. “I just use Ubuntu, and that’s Linux—right?” Folks working in non-profit, mostly, fit that category; folks largely using web-based tools, and MS Office products—who feel fancy knowing that Libre Office is a solid FOSS alternative to MS Office, as an example.
So, breaking-down the Linux ecosystem in its own article, feels like a good component to this. It’s just stopped-cold, many of my own attempts at discussing Qubes with Linux folks, when I realize they just have no idea what I’m talking about. To understand a multi-environment system, folks need to have a solid understanding of how single-environment systems work. Mac? Big walled-garden. Windows PC? Same. Linux, we have choices—but those choices require some really simple foundational knowledge, to meaningfully act upon.
Also, when I say “include ppl new to Linux in this,” I don’t mean infantalizing all Linux concepts throughout the guide. Only crafting one article to break all of this down within, and then making that article readily discoverable through click-paths from glossary items and other articles. Maybe I should volunteer to write that article, come to think, lol. Definitely no time commits from me on that, but happy to own it on my volunteer plate. Or, to let someone else excited to take a jab at things, go for it!
Perhaps we can balance the Qubes Docs philosophy of non-duplication through introducing certain concepts of Linux within the context of Qubes. I started using Slackware 20 years ago (mon dieux, time flies) and I find that very little of the Linux Way is actually needed to effectively run Qubes at the user level. Most frequent command I use? Apt-get by far. I think a minimalistic touch here would be in order. The rest can be covered better by others.
But that doesn’t even apply here, because this is a community guide. The intention behind this question was not to try to impose any policies on anyone. Rather, I’m trying to help you all avoid duplication of labor and reinventing the wheel. Just trying to help.
It’s a disjointed experience to be linked-out to external articles. As a mater of practicality and sustainability, for the “official” Qubes documentation, it would be akin to building a bomb, to not link out to external articles as often as possible. For a user-friendly community guide, I’m fine writing something short and sweet. Yes, I’ll absolutely look for something already written—but for getting users adept to Qubes, the learning burden is already quite high. I’m fearful of opening The Linux Can Of Worms, when the only point of introducing Linux concepts is to ground users in an understanding of the ecosystem, as it is foundational to Qubes. Not to get folks excited to customize things and experiment, or to learn about how/why OSS is so different from proprietary OS. If that makes sense. External links should be nice to haves, not required, in the best possible experience scenario.
As a non-Linux native, really, the most critical things for me were simply understanding the “pieces” of an OS. In Mac/Windows, it’s all seamless. In Linux, it’s helpful to know what “a desktop” is, distinct from the core OS; what “bios” are, that “File Managers” and “Print Mangers” and “Audio Managers” are all helper apps that sometimes ship with a distro, and can often be replaced with alternate versions; what “a distribution” is, and how some distributions are core distributions (Debian, Fedora), while others are adaptations of the core distributions (Ubuntu, Mint). Stuff like that.
