Plans to Add Search/Filter Functionality to the HCL?

Ah, that’s my problem. I hadn’t realised that Qubes was targeted at
spoon fed Americans.
I’m sure you didn’t mean it, but that’s what came across.

I know people who work on their bikes a good deal of the time. They
tinker, swap out and customise parts. They aren’t hobbyist DIY people – they’re poor.
I know people who keep their computers running in the same way.

In my experience, people with limited resources don’t expect
to be spoon fed.
They do far more research, because the outcome really
matters to them. Of course, they will ask for help and advice, but it
tends to be informed asking.
I have to say that the Forum has undoubtedly brought in users who ask
questions that show they haven’t even looked at the basics of Qubes. So
it goes.

Sven’s proposal for a list is good.

Here we go:

1 Like

Look, a while ago I posted a long thing in GitHub, about why many folks—especially women—are uncomfortable asking for help in community support forums.

I learned how to work on motorcycles many years ago, because I really wanted to race but could not afford a mechanic (or even my own bike, or even a “whole” bike in one piece from the same sponsor). So, per the above mental model you cite, I knew there was a lot I would need to learn. I prepared for that; and expected that my ability to succeed would be a never-ending journey dependent on my ability to listen and learn, more than anything else. Because I was poor and lacked resources.

Mental models are everything. Especially with Qubes.

Not all of the people using Qubes are desiring to use it because they cannot afford “something better” (BIG air-quotes there). They come to Qubes, because it is known to be the best for safety and security. So, they come into using Qubes, expecting the resources and systems to be in place that would exist from a Mac or a Windows machine, out of simple naivete. Not arrogance.

You don’t “buy” MacOS. It just comes with your $4k laptop. Same, with Windows. Same, with Google and Facebook; they sell your data. We know none of them are “free.” So, naivete, not arrogance. At the same time, they also wouldn’t be coming to use Qubes were there not safety or security risks at hand that they need to mitigate. Yes, in the US, “Safety” and “Security” are absolutely sold as guaranteed products with price tags and smiling White middle-class families with 2.5 children shown in pictures as proof that those products work… and security dorks and infosec professionals know that’s just opportunistic Capitalists selling false promises.

For many non-technical users just getting hip to security concepts and Qubes, they are likely just at the point of accepting that the smiling White family “security system” is bogus, and that Windows and Facebook etc have backdoor access as a hidden cost—but not much more.

No, I am not asking that we “pander” to disrespectful users, but I am asking that we treat those new to Qubes as one might treat followers of a cult looking to integrate with society at-large after being isolated in their cult for too long. To not presume these folks understand how FOSS ecosystems work, or that folks understand most of everything is made possible by volunteers.

Open Source IS a learning curve, and these days I trust things that come from community forums and stack exchange, far more than I trust shit from a corporate website. I’m also an anarchist, and it took my experiences working in the tech industry for me to develop that skepticism and comfort with something so different.

Qubes OS is a community project. I am not its decider of which users are targeted. I am only advocating for folks new to FOSS, and looking to use Qubes OS for reasons outside of limited financial resources; reasons that then have them missing that mental-model reset to be resourceful, and also needing to establish for themselves what that might look like—before diving in. Even for folks with limited financial resources, I’d still like the shift into a FOSS product experience to be smooth and filled with more opportunities than roadblocks. I want more people wanting to use FOSS products, and wanting to learn.

I have also gotten a not-insignificant number of emails, asking “Why can’t you guys just prioritize UX more” or “Why can’t you do this” or “Why can’t you do that.” I honestly do not believe those people would even be wasting their time to write to anybody with those, if they really believed there were a single-digit number of paid resources, with a smaller number of paid full-time resources, and a small army of volunteers, tasked with making this multi-device operating system possible at all. Tech has gotten SO MUCH sleazy venture capital piped into it, that it is surprising for a lot of people to see a product with such a need as Qubes obviously has, not exploding with dollars at the seams. I would wonder that, too, if I weren’t familiar enough with VC to know how quickly VCs destroy projects.

So, am I advocating we spoon feed people? No. Am I advocating we provide clear paths to people who’ve been trained to expect a very different product experience, because their privilege and life context until coming into Qubes have trained them to expect something different? Yes.

People don’t know they need to “do a little work,” until we’ve told them that. I also don’t think it’s unreasonable to help them get going with Qubes a bit, to see a plausible path forward—vs a giant cultural wall that may feel in-surmountable to climb, at first. That’s what the HCL table w/o a few little “Here’s some off-the-shelf options” is likely to be, to many.

We’ve come a long way from the original “search/filter” theme.

No doubt that there’s widespread discrimination in tech, on various
grounds. It’s getting better, and I have not met any great issues in Qubes.

I think we are probably pretty close. Given your experience, I’m
surprised that you use the dork/hobbyist/tinkerer v “ordinary user”
opposition. I wish you wouldn’t, but it’s shorthand that comes naturally
to you.

As it’s always useful to compare experiences, I can say that I too get a
large number of emails about Qubes - I have never had one asking for
a UX solution - at least, not one specific to Qubes.
One reason for this is that I’m not a UX person.
Another is that most of the people I work with have been set up with
Qubes, and had some initial training in GTD with Qubes.
Oh, and they also use KDE.

I think the list Sven has started will be really valuable, and a great
addition to Qubes.

This was my second thread on the forum (the first was my hcl report) and I really struggle to decide what to take away from this.

At times I felt personally attacked, other times completely ignored and in the end the thread went into a different direction, so I am unsure if any PRs are welcome. Please understand if I do not want to get involved in the near future.

FWIW, I have no objection to these. As far as issues go, the first one is already covered by the issue @ninavizz opened. With respect to “age,” I don’t think it’s realistic to expect most users to figure out the age of their machines, and in the case of custom builds, there may not even be one. The submission date of the HCL report itself would be much easier but is not what you’re looking for.

Please do not let the discussion in this thread deter you from future participation or contribution. Know that you were not ignored; I and probably others share your initial thoughts that for new users who simply want to know “will this work or not”, the answer cannot be had easily. That’s why I applaud @Sven’s thread for helping to address that (Short list of laptops/desktops that work well with Qubes OS).

Qubes has the wonderful issue of debating the “right” way to do security, who to do it for, and most importantly…who’s gonna do it. I’ve come to learn that there is no single answer for all three of those factors and they tend to come up often in various topics, just like any other open source project.

As far as I can tell, the “who’s gonna do it” part is probably the biggest hurdle with respect to this thread (and many other Qubes issues).

So what can we do about it if we’re not web developers? I’m encouraged by the increase of HCLs I have seen. Collecting the data is the first step. The more [fresh] data points there are, the more the HCL serves its purpose. Presenting it is the next step, but prior to debating how to do that, we need to think about the goals, which is where the extra discussion arose.

Someone brand new to Qubes will not have context to think about previous releases, Xen, BIOS and motherboard versions, etcetera. A new user wants to know does a certain device work with the software I want to install. Most helpful would be HCLs for the current release. That does not mean an HCL reported during Release 3.2 won’t work - but how does a new user evaluate that? It is ambiguous to them and confusion-inducing.

That is, unless the new user cares enough about wanting to use Qubes that they are open to experimenting, troubleshooting, and reviewing documentation and community resources. To put it frankly - are they willing to lose their productivity potential to time lost doing research and debugging?

The issue is finding the balance and this is where the lively debate was focused. If the user has a hard time with the HCL, they may not enjoy Qubes later. But on the other hand, how hard of a time should they be having in the first place?

To make a long story short, while your input sounds like simple suggestions that may have appeared to be ignored, the issues run a little deeper; but don’t let that discourage you from letting your voice be heard. Qubes can really benefit from hearing more voices.

1 Like

Any contributions, discussion or PRs, are welcome.
The documentation (including the hcl) is a community effort - you can
edit in GitHub to produce PR, or use the more familiar clone/generate PR
path.
If you can help make the hcl easier to use, bearing in mind some of the
issues raised in this discussion, please do.

1 Like

I agree. Like many things life in life, there’s a gap between what the producer can produce and what the consumer wants to consume. Ideally, we could just specialize in software, make the best OS we can and not have to worry about other stuff, like hardware. In the real world, hardware is a major hurdle. We’d love to make Qubes “just work” on the hardware everyone already has. But we can’t. Well, at least we’d like to tell you (the user) which hardware will work. Except, for various reasons, we can’t really do that either. So… we can at least tell you which hardware other users have tried and what their results were. And there’s basically where we are right now. It’s not ideal for us. It’s not ideal for you. Hence, the unfortunate gap. I do welcome HCL improvements, but I also suspect that the intention behind many of them is to try to use the HCL to bridge this gap, which is probably not going to work out in the end, because it will never be exactly what the consumer wants. We probably need something else (besides the HCL) to actually bridge the gap, like @Sven’s list. (But I still welcome improvements to the HCL, because we should always be open to improving what we maintain. I’ll try to help implement what I can, but I’m also not a professional web developer.)

1 Like

For example?