On 11/23/20 10:06 AM, Steve Coleman wrote:
On Mon, Nov 23, 2020 at 9:33 AM Andrew David Wong <a...@qubes-os.org> wrote:


If you can fix them first, that would be a great help! I think it would
make things easier for our HCL maintainer. :)

Usually, it's just the model number for that product, e.g., "FX-8320" is
short for "AMD FX(tm)-8320 Eight-Core Processor". Take a look at the
existing entries for examples:

https://github.com/QubesOS/qubes-hcl/tree/master

I am thinking of including the cpio files, but do not want to share a
serial number that they contain. WOuld those files be useful to others
if I edited them so that the serial number reads "Redacted"?


Sure, feel free to redact whatever you like. :)

If you prefer, you can send the cpio files directly to Marek
PGP-encrypted (instead of the to the mailing list). See here for more info:

https://www.qubes-os.org/doc/hcl/#generating-and-submitting-new-reports


I have a question about the HCL process and page display that I have been
wondering about.

I was for the longest time copying and pasting the HCL web page into a
spreadsheet just so I could sort and delete out all the old information, as
I was looking to replace my desktop system with something more up to date.
I can't tell you how many times in the last three years I copied the HCL to
this spreadsheet, and when my old desktop finally died I had to give up
hope and just bought a new system sight unseen that was not on the list and
I just hoped for the best. Fortunately, it worked out Ok.

As it is right now it is difficult and getting increasingly harder to find
just the latest hardware on the list as it seems that by the time something
appears on the list it is no longer even available for purchase.

Remember that these are almost all reports voluntarily submitted by users. If it's mostly old hardware, that's because few people with new hardware are submitting reports for that hardware. We can't force anyone to submit reports, and we usually can't get new hardware to generate reports on ourselves. Though, to be fair, the reports from the mailing list haven't been added in a while, so that might also be part of it.

However,
there are LOTS of machines that you could only find on eBay and many/most
lack sufficient memory, BIOS, or current chipset support for the current
Qubes R4.x system being developed. Old systems on the HCL are seemingly
never updated, so you can't tell which ones are still working and which
ones have retired years ago. There are many items on that list even in the
wrong categories (e.g. DIY System boards in the Desktop section when there
is a separate section just for those) and I see no defined process by which
to help change that.

My question is this: What would it take to get a set of simple filter
options on that HCL webpage?

This open issue is very similar to what you're asking:

https://github.com/QubesOS/qubes-issues/issues/3795

I've just opened two PRs (linked to this issue) that make the HCL tables sortable. However, some rows break on sorting. Please see the issue comments for more details and an image showing exactly how it breaks. If you can help with this, please let me know on that issue.

Or, is there a way for someone to help clean
up and better organize this list?


There are two main ways you can help:

1. Help un-break the aforementioned sorting, or provide a better way to sort or filter the tables.

2. Submit a PR that modifies or removes old or bad HCL entries:

   https://github.com/QubesOS/qubes-hcl/tree/master

Going forward it is not all that helpful to see what was historically
running, years ago, if they are no longer adequate for the current Qubes
R4.x baseline. My inclination is this lists' primary function should be to
support those who are looking for some adequate hardware that could run the
current baseline, and failing that test, it should be filtered out by
default. Or maybe just filter by date added/updated?


I can understand the motivation behind removing old entries for EOL Qubes releases. If those entries are truly of no use to anyone, then there is not much reason to keep them around. But perhaps there's some value in keeping the old entries that we're overlooking. I'm curious whether Chris and Marek have any opinions on this.

Another idea is to have separate HCL tables for each Qubes release, or even entirely separate HCL *pages* for each Qubes release. This might make sense as part of our plan for release-specific documentation:

https://github.com/QubesOS/qubes-issues/issues/5308

Another thought is we should actively request those who successfully
upgrade their systems to the latest baseline to resubmit their HCL thus
showing that the same system is still capable of running the latest
baseline number. I know matching old and new HCL reports would require some
work, but I think if you want Qubes to be more popular this is a must.


We can request it, but I'm not sure how much uptake we'll get. In practice, someone would probably have to volunteer to take on the task of making these requests. Alternatively, we could suggest in the HCL documentation something like, "If you're interested in a model, but the HCL report is out-of-date, try asking the reporter to update their report."

Theoretically, there could be an automated system that emails people to ask them to update their reports periodically (annually, for example), but again, someone would have to volunteer to help set up such a system.

At the very least the list should have a way to display only those
currently running R4.x.x by default, but then let someone tweak the filter
settings to look at older hardware if they choose to do so.


Would be good, but we need help with the code (see above).

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/000d8256-3b01-bfe2-72c1-ed68b2bcb0aa%40qubes-os.org.

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to