policy.d/README refers to non-existant 30-user file

/etc/qubes/policy.d/README refers to file “30-user” but the file does not exist in the directory.

If you want to change from the default you produce that
file yourself.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
1 Like

@1of7
30-user.policy is how you customize 90-default.policy. You can either copy 90-default.policy to a new 30-user.policy:

sudo cp /etc/qubes/policy.d/90-default.policy /etc/qubes/policy.d/30-user.policy

and edit 30-user.policy as you want:

sudo nano /etc/qubes/policy.d/30-user.policy

or create an empty 30.user.policy and only add the individual changes you want to make. i.e whatever differences you want to make to 90-default.policy are added to 30-user.policy, but don’t edit the actual 90-default.policy file.

1 Like

Part of my point was that the README is missing information that would help the reader understand the intent a bit more. The way it is worded is very inefficient in that further help is required from someone nice enough to assist. The dialog we are having will likely not be evident to someone who sees this README and that person will be stuck with trying to locate the infromation ‘somewhere over there’ (Documentation | Qubes OS). Simply adding a bit more information like that which you provide will remove the requests for clarification so that you can spend your time answering more important requests.
This seems to be a central tendancy of qubes documentation.
Another part of this question is how can someone change a README such as this to include more information to help others with lessons we learn?

The documentation is a community effort - please contribute and improve
it.

Go to github, produce a PR for the README file, to improve it.

1 Like

Thanks

For those interested in what this is all about see:

Part of the problem is the vast difference in knowledge between users. I started using Qubes with zero Linux experience. While Qubes is now my daily driver and I have a decent workflow and a relatively easy time with it, I still suffer a great deal when I need to troubleshoot, configure services, manage scripts, etc. It’s hard to tell how much of my confusion is due to previous unfamiliarity with Linux and how much is due to poor documentation. As such, it’s unclear to me how much additional explanation is appropriate in the documentation. It doesn’t always seem appropriate to add detailed explanations.

For example, if a document consists of driving directions, there shouldn’t be explanations about how to drive or even how to negotiate a detour sign. It would only clutter the documentation. It’s assumed that an experienced driver can sort that out.

After I finally got a relatively clear explanation of policy file customization, it still wasn’t clear to me if creating a “30-user.x” config file to customize a “90-default.x” config file was standard practice in the world of Linux.

So, in practice, I just tend to ask a lot of questions and give excessively detailed explanations to other users. I dare not edit documentation because I have found that Linux users - while being very nice people with a good sense of community - tend to be a bit “hands off” when it comes to explaining things in detail. Most explanations (from man files to forums) tend to be terse at best and often leave me more confused than before. That’s just the way it is I guess.

1 Like

@necker you might greatly benefit from reading one of the following books:

  • “How Linux Works” by Brian Ward
  • “The Linux Command Line” by William E. Shotts Jr.
  • “Linux in a Nutshell” by Ellen Siever, Stephen Figgins, Robert Love, and Arnold Robbins

Any one of these will give you a somewhat methodical introduction to the basic concepts that are more or less taken for granted. The terseness you experience comes from realizing that these concepts have been covered in literally hundreds of books together with the expectation that the asker of the question should do their due diligence.

These concepts are old … really old. So any edition of these books or other similar books available in libraries or in used book stores will do the trick. If you get an ebook version and have a smartphone you can consume the book in little 5 minute sessions throughout the day instead of checking social networks or news. It’ll make you more knowledgeable and less stressed out at the same time. :wink:

1 Like

@necker, you are likely one of the best choices I would consider to write documentation to help others. No doubt there are ‘experienced’ users who often skip over the ‘bit of algebra’ in their attempts to document and maybe consider the hours of research to fill in the gaps by newcomers as some crazy sort of right of passage. We can help each other by breaking things down to levels we can understand. There’s a reason for the many different ways “Hellow World” has been used as an example in computer science text books.
Many years ago I figured I could save some money by sharing one phone line with other members of my family in what eventually turned out to be a software router. I’ll never forget the help I got from someone who could really explain the nuts and bolts of how things were supposed to work, a fellow named Metcalfe. Imagine helping me…

1 Like

We must run in the same circles. :wink:

I do think that documentation would benefit from a tiered approach to explanations (i.e. advanced, intermediate and beginner) along with examples of usage when applicable.

...

Perhaps more detailed explanations could be hidden to keep the documentation from getting cluttered? Or links to alternate forms of the same documentation? That does seem like an extraordinary amount of work though.

For me, asking for help is often like asking “How does sed work?” and receiving the reply. "It’s very straightforward. sed [OPTION]... {script-only-if-no-other-script} [input-file]"

…followed by a single tear running down my cheek.

Many problems that people have in Qubes are actually not Qubes specific.
There are some Qubes specific elements, but many problems are related
to the underlying distro (or OS).

Generally, the Qubes documentation doesn’t want to duplicate material
that is (better) dealt with elsewhere, and can be found with minimal
effort.

*This is not standard practice.
But using a lower numbered config file to override a higher numbered file
is quite common

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

More people have to be prepared to step in and produce documentation.
More users have to be prepared to try and find answers for themselves.
These two things go together.

An interesting analogy - it is trivial to find extensive introductions to sed online.
Very often, users are asking questions that have already been dealt with
in the mailing lists or the Forum, and have not made even a minimal
effort to find an answer for themselves.
That makes me weep.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

Whether teaching to nuclear workers or presenting to a board of directors the theme used to be, speak as if you are educating a grade five student. This isn’t a slam against the intelligence of the audience but a tact to come up to the audience rather than to speak down. Invariably the audience is more capable than the theme but any gaps in understanding are more likely caught using this tact.
I would hope we can allow people to assist to their own measure.

1 Like

Since Qubes has a GNU/Linux base there will likely be grey areas when it comes to helping users. Because Qubes uses SALT does’t mean questions about SALT are off limits. Because sed can change the distro version in repo config files doesn’t mean sed questions are off limits. Python is the language of choice for much of the Qubes implementation, where should the line be drawn. A quick search and cogent link would likely be all that is necessary, for an informed person. Anyone should have the option of assisting someone with a question no matter how trivial it may appear to others.

More people have to be prepared to step in and produce documentation.

I am very available for such things but I question my technical chops. If someone more experienced was to organize such a project and needed help proof reading, updating documentation for more recent versions of Qubes, writing guides for simple things and other “menial” tasks, I’m totally game. Send me a private message.

More users have to be prepared to try and find answers for themselves.

If you knew how much time and effort I spent looking for answers in other blogs, guides and forums, while remaining completely baffled by certain basic problems, you would weep another tear for me.

My sed analogy was mostly addressing the fact that much of the extensive information available online (necessarily?) incorporates elements within the solution that I have to look up as well. So a single “answer” can lead me to 4 or 5 other sites just to understand the explanation. Often times, I short circuit or get overwhelmed and put it on the back burner.

But you are correct, I know it’s important to figure out as much as possible on my own. It’s not just a matter of respecting others but often times, it’s faster and I learn more.

There is already community documentation on GitHub, to which you could
contribute. To which anyone can contribute.

Any one can contribute to the official documentation with proof reading,
updating for new versions.
These are not “menial” tasks.

Also, I believe people post guides here in the Forum.

But I have heard “Guides” on Reddit and other places that either repeat
things from the official documentation, or that don’t go much further
than “Install THIS package”.
Other than karma whoring I see no point.
This isn’t Qubes specific - the internet is littered with blogs that
copy/paste from other posts, and which go old gracelessly.

There are no limits in asking for help - people are free to do whatever they like.
People are also free to choose what questions they answer, and how.

Someone who has tried to understand sed, or salt, or Qubes qrexec, but
still has problems, is likely to produce a better question, and better
answers, than someone who has not.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.