On 8/15/19 10:22 AM, Lukas à Porta wrote:
Hello everyone,
I have been selected to write documentation for Qubes OS during the
Season of Docs <https://developers.google.com/season-of-docs/>. I am
glad to have opportunity to contribute to this project.
During my time as a technical writer for Qubes OS, I intend to work on
creating a guide for firstboot users
First, I would like to thank you for even taking on this monumental
challenge. Qubes is a hugely complex system, with lots of technical
knowledge required just to get started. Anything that you can do to
lower the bar of entry into Qubes is truly worthy of my admiration.
One area I feel that needs improvement, and admittedly is probably out
of scope for your current project, is to simplify what one needs for the
proper hardware selection and/or testing of a usable machine. The HCL
page itself has grown fairly large while most of the entries found there
are not even relevant to a new user. This is because that user will
likely only be trying to install the latest (R4.x) baseline release. The
historical information on that page just makes it that much harder to
see what systems are actually known to work with R4.x. Few of the R4.x
entries are even green all the way across, and of those that are, they
will likely need to be purchased second hand with exception of some
current laptops. The fully functioning R4.x desktop systems are clearly
under-reported, and as of the last time I checked all of them were
discontinued models.
All the other historical 2.x/3.x entries are just clutter to a new user
and make the overall process much more intimidating than it needs to be.
A shorter and more consolidated list of systems working with just the
*latest* baseline (R4.x) would make it much easier to grok the
possibilities. My suggestion would be to either have the HCL main page
display only the current systems on the current baseline, with a
historical link for those who wish to see that older information. Or to
have an active web page filter based on selectable system attributes
(laptop, desktop, system board, Qubes version, max memory, tpm, CPU,
chipset, video controller) so you can skip what is not important for the
current baseline or even the users own requirements. Even being able to
download a CSV file so you can manually filter out everything without
R4.x would be an improvement.
In a perfect world, one would be able to just go to the HCL page, click
a link, and download and burn to a USB/DVD, a live system test image
that will boot and non-destructively test a physical machine for
properly functioning hardware. Upon passing that first-pass hardware
test, the user could then be able to click a link to directly submit
that first-pass HCL report for that particular hardware configuration.
Even if that system fails the test, that might still be valid
information, providing that it is not due to some BIOS settings causing
the problem. Armed with that live USB/DVD image, even a novice could
literally run around and boot any and all available machines and get a
first-pass check to see if the proper hardware and BIOS is installed and
functional before ever wiping a machine. Nobody wants to buy and wipe an
expensive machine only to find out that Qubes will not even work on it.
If that newly purchased machine fails to boot Qubes, good luck at ever
returning that machine after having wiped the system disk.
That hardware issue is a major barrier to entry for Qubes. Granted that
first-pass hardware check could not *guarantee* that _all_ functionality
is present, such as the sleep/wake-up or internal peripherals will all
work properly, but you could at least be reasonably sure that the core
hardware and video will function before taking that major step of wiping
that machine. But this way, one could reasonably think to walk into a
showroom of machines, or even borrow a friends machine, and
non-destructively test it to see if that model machine is risk-worthy
enough to buy or not. Identifying what not to buy is equally important
information, and a list of non-working hardware to steer clear of, or
require significant work-arounds might be good to document.
Basically anything that helps the new user find suitable hardware and
just get started on this journey will be a big help to increase the
adoption rate of Qubes.
Thanks again for your dedication to Qubes!
Steve.
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/dfa27af4-0415-735c-dd97-5a5924d68af3%40jhuapl.edu.
