Plans to Add Search/Filter Functionality to the HCL?

The problem is easy enough to describe:

A user wants to find a computer they can purchase that will work well
with the current Qubes OS revision.

The solution is much more difficult and includes availability, budget
and whether used machines are an option.

I am all for making the HCL list better, but think that what we need in
addition is a short, frequently updated list of currently available
off-the-shelf notebooks and desktops that run the currently released
Qubes OS well. …but how to get there? Maybe a forum survey every 6-12
months?

One problem is that when hardware starts to be well supported it often
is no longer commercially available. When I got my ThinkPad P51 it
required several workarounds to get R4.0 running (UEFI, WiFi). R4.0.3
and later installed without the need for any workaround or tinkering but
at that point one couldn’t actually buy a new one.

Now I am using an upgraded, maxed out ThinkPad T430 … by far the very
best Qubes OS machine I’ve ever seen or heard about. Everything works
great, the performance is awesome and it uses Coreboot/Heads. But, what
use is it to list such a setup? It requires you to hunt down all the
parts and build it yourself or shell out big Euros for a NitroPad (which
is already listed as a certified option on the Qubes OS website).

2 Likes

Yes to everyone!

I think there are three very astute and opportune solutions here, that could help everyone. I also observed while editing the docs recently, that the HCL page was either somehow buried or not named as intuitively as possible. Which I don’t say to “ding” anyone or anything, it just came to me as a “huh, this could be done better!” while doing other tasks in a similar context. Pretty sure that either Andrew or myself resolved that.

  1. Yes, updating the table with sortable headers is a great idea. Generally, traditional tables are not my own preferred way to enable sorting—but my preferred methods I feel are more complex, than the value this feature would offer the page, given user needs.

  2. It strikes me (based on what I casually observe in the Forums) that the primary need Sven hit on the nose, is a list of off-the-shelf options folks can just go buy. While there is a strong DIY ethic in the Qubes community, that still seems to be a common need among those not yet sure they’re ready to make that big time investment in building out a dream-machine.

  3. Sven additionally adding the “Content Lifecycle Management” angle to such a list, I also +1 with a chefs-kiss. Yes, a Forum survey every 6-12 months, seems like a fantastic idea to maintain the relevance of such a list—and, it nicely removes burdens from the core team, from having to maintain “yet another thing” that could bite the project in the arse the second it becomes out of date for a vocally frustrated prospective user.

2 Likes

Hi @Nina, the sorting was recently implemented by @adw, but it’s not
discoverable. One has to know to click the column header. Maybe you have
an idea how to surface this better?

I also strongly agree that the other shorter list needs to be community
driven. Not only for the effort but also as you point out to not be
“bitten in the arse”. Even thought the certified hardware page clearly
states “We take no responsibility for any vendor’s manufacturing,
shipping, payment, or other practices;” … folks just make an
association and come to the forum to complain when their (sometimes
unreasonable) demands are not met.

Being born and raised in Germany I crack up every time someone comes to
the forum complaining that they sent an email on Friday to a German
company and haven’t gotten any response 48 hours later!!! lol
different cultures :wink:

2 Likes

I am wondering: How much is compatible hardware a Linux problem and not a qubes problem?
e.g. I have some sound issues that should probably be fixed upstream.
How many are really qubes related problems?

How do you like the idea of marking or moving old (< R4.0) HCL reports? Maybe sort them into directories (according to qubes version) on Github?

PS: Also can somebody please explain to me, why there are .gitlab-ci.yml files on Github? I would like to contribute, but need some orientation.

PPS: I ran the numbers, ~61% or HCL reports are for old/unsupported versions:

$ grep -h -zoP "qubes:.*\n\K.*\n" *.yml | sort -n | uniq -c | sort -nr
    270       R4.0
    189       R3.2
     65       R3.1
     41       R3.0
     37       R2
     30       R2B2
     28       R2B3
     21       R1
     17       R4.1
     17       R2rc1
     14       R2B1
      6       R2rc2
      3       R3rc1
      2       R4.0.1-rc2
      2       R4.0.1
      2
      1       R3.1
      1       R4.0.4
      1       R4.0.2rc1
1 Like

I don’t like it.

It’s a complete mistake to assume that the reports only apply to that
release.
I doubt that people updated a report when they moved from 3.2 to
4.0, but there must be many such users.
The older reports contain useful information which will inform a buying
decision. (Certainly for 3.2 reports, and negatively for earlier
release reports.)

No doubt, the HCL could do with improvement - I suggested some areas
where it could be usefully extended, but they would need much more
research and work.

I don’t understand this idea of “commercially available”, or the desire
for shiny new things. I’m trying to be polite, but your privilege is
showing.
Not every user is in a position to spend large amounts of money on new
hardware, even if it were available. We shouldn’t make those people feel
like second class citizens. They may need Qubes more than you.

@unman:
I am aware that older reports might give insight into what might work (just like similar configurations/models). That is nice to have but hardly the main point of the HCL, is it? From my understanding (and expectation) it is about reporting what hardware has been proven to work. Users should be encouraged to upgrade to newer releases and to create a new report after successfully upgrading (and the effort to submit a report should be as low as possible while maintaining opt-in and consent).

Also I never suggested deleting old reports, I merely suggested marking them or separating them from the current ones. I agreed that my initial idea of hardware age was not worthwhile. That is why it might be better to talk about release version to give the HCL a “sense of recency”. Surely you agree that there is no point on installing EOL versions?

I am happy to answer any questions if there is any misunderstanding. You know nothing about me, so please don’t go ad hominem; this gets us nowhere.
What I am trying to offer is a less niche/hobbyist/engineer and more professional/day-job/user/company oriented view. Surely these should not be treated as second-class citizens either.

I think qubes is really great and would solve a lot of problems and needs of a lot of people. That is where I would like this to go.

Looking forward to hearing more opinions.

I’m in danger of being reprimanded again, but you seem to have
deliberately misread or misinterpreted what I said.

The HCL is not about reporting what hardware “has been proven to
work” - it’s a compilation of reports about hardware compatibility with
Qubes, good and bad.
Reports from even the oldest releases provide information about some of
the security features of that hardware. It has nothing to do with
installing those versions.

My criticism was not ad hominem, nor was it aimed at you personally.
It was a reminder that there are users for whom those older cheaper
machines aren’t a choice. Talking about “off the shelf” and
“commercially available” options is a distraction. (If it needs
to be said, this has nothing to do with DIY hobbyists.)

The HCL is a tool - it can be improved, and I’ve pointed out some areas.

I’d be strongly opposed to a list with “off-the-shelf” options, if that
means anything other than “can be bought”. The list should contain
older and cheaper hardware: who could object to that?

Agreed. Going forward let’s talk about “can be bought”, which is
precisely what I meant when I wrote “off-the-shelf”.

I have pointed out several times on the forum that users will be far
better of choosing hardware that is at least 2 years old.

We need a list of laptops and desktops that:

  1. can be bought used or new
  2. allow Qubes OS to be installed without workarounds
  3. provide a usable level of performance for every day tasks

@unman would you agree with these 3 requirements?

I thought about going through the HCL list picking machines that run
R3.2 or later and have no comments – but that doesn’t really guarantee
that there are no workarounds needed. Rather I think we should have a
thread to collect candidates and then drill down a bit on a few of them
that can be backed up by more than one person. Makes sense?

@deeplow I’d like to start a thread asking for candidates that fit these
requirements and then refine it from there. Which category do you think
is the right one (I wouldn’t want to use “HCL reports” for that please)?

Maybe “General”?

1 Like

Yes, I guess General Discussion with a short and appealing title will do the job.

“Maybe you have an idea” can be a dangerous thing to say to me. :wink:

Issue created here!

Also, FWIW: My email/contact info are on the Qubes website, and I get a non-trivial volume of emails from folks asking “What can I just go to a store and buy that will be compatible with Qubes.” Privilege is certainly a factor, but America is also a consumer-behavior driven society. So, much as I also like to throw down with privelege-checks, I’ve found that in my work with both SecureDrop and Qubes, a bigger problem (in a way) is that much of society has been trained to be spoon-fed everything from instructions for how to do things, to guidance on what to buy.

While social engineering is “not our problem,” it becomes our burden when we expect people to (gestures wildly with hands) have to independently think too much. It’s a delicate dance, how to bridge across what we all loathe, to how to keep our integrity—and our sustainability, as a largely volunteer led project.

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?