HCL needs link to R2B2 list

[cprise]

Suggest linking to the older HCL showing the R2B2 info so that newcomers
have a better approximation of compatibility for B3. What's there now is
basically a wipeout of info accumulated for R2bX so far.

I'm about to take the B3 plunge here myself... wish me luck :P

[Hakisho Nukama]

> --
> 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...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-users.
> For more options, visit https://groups.google.com/groups/opt_out.

cprise, have fun diving into R2B3.

Yes, the HCL information isn't optimally presented.
But really good collected, thanks Zrubi!

I tried to access it over a mobile phone and
this HCL table is bulky.

I propose to split the information into one table per release,
accumulated into a single wiki page (optionally move unsupported versions into
a separate wiki page - i.e. HCL-R2B2 and so on).

Qubes R2 Beta3
Device | Standard features | VT-x (HVM) | VT-d | 3.11 | 3.9 | 3.7 | Remarks

(11 devices)


Qubes R2 Beta2
Device | Standard features | VT-x (HVM) | VT-d | Remarks

(30 devices)


Qubes R1
Device | Standard features | VT-d | Remarks

(23 devices)


So there is no need to tamper with the old collected information.
And a script can be used to convert the collected reports into a wiki table,
which can be different for each release.
Therefore the script can be innovative, without caring for older
release information.

By the way, can you suffix the HCL reports with a time stamp, so it is easier to
have several reports for one machine in one directory?
(for reporting all three kernel versions of R2B3 for instance)

Best Regards,
Hakisho Nukama

[Joanna Rutkowska]

I agree with Nukama about separate tables per release. And also an
automatic script would be great.

joanna.

[Hakisho Nukama]

I've overhauled the HCL wiki page [1], and introduced a table for each release
and moved the topic for generating and submitting reports to the top,
because it seems lost otherwise.

I wonder, if the distinction between Developer Reported Machines and
User Reported Devices makes sense. Isn't it obvious through the
reported by field?
Laptop and Desktop/Workstation would be a better distinction.

I'd like to replace the OK,X with a Yes and No (or 1 and 0 ;-) ).
An example entry for a row for the R2B3 table is referenced at [2].

The additional plugin TracSubPages [3,4] could be useful for displaying several
release tables (although only formatted with wiki-syntax) inside one HCL page.
Then we could create a HCL/ReleaseVersion for each release and dynamically embed
pages [5] for the latest stable and development releases only.
This would require some extra software running one the Trac server,
but we could live with the current state.

Best Regards,
Hakisho Nukama

[1] https://www.qubes-os.org/trac/wiki/HCL?version=122 ff.
[2] https://www.qubes-os.org/trac/wiki/HCL?action=diff&version=132
[3] https://github.com/jetheis/TracSubPages
[4] https://trac-hacks.org/wiki/TracSubPagesMacro
[5] [[subpage(HCL/ReleaseVersion)]]

[Axon]

Hakisho Nukama:

I agree. I think it would look clean just to bold or color
developer-reported entries to signify that they're special; it would
become clear *why* they are special once the reader sees the name of the
reporter, which should be given instead of the generic and
depersonalized placeholder "Qubes core developers." (Qubes devs
don't/shouldn't rely on security through obscurity! Anyway, they already
indicated which machines belong to them on the public mailing list, so
it's not like it's a secret.)

> Laptop and Desktop/Workstation would be a better distinction.

This distinction is already in effect. But I agree that it shouldn't
apply only to user-reported machines

> I'd like to replace the OK,X with a Yes and No (or 1 and 0 ;-) ).
> An example entry for a row for the R2B3 table is referenced at [2].

Sounds fine to me. A check mark would also work in place of "OK."

>
> The additional plugin TracSubPages [3,4] could be useful for displaying several
> release tables (although only formatted with wiki-syntax) inside one HCL page.
> Then we could create a HCL/ReleaseVersion for each release and dynamically embed
> pages [5] for the latest stable and development releases only.
> This would require some extra software running one the Trac server,
> but we could live with the current state.

That would be neat, but I wonder if it's really worth the work to make
something fancy when very few people are going to use it. How many users
are going to read the HCL wanting to buy hardware for R1 or R2B2 instead
of RB3, for example? Probably none (unless they don't realize R2B3 is
available and most preferred). So, the past HCL tables will probably be
only of historical (or dev) interest.

[Joanna Rutkowska]

Yes, I agree.

> I'd like to replace the OK,X with a Yes and No (or 1 and 0 ;-) ).
> An example entry for a row for the R2B3 table is referenced at [2].
>

Yes, surely we should replace the 'X' with something that cannot be
mistaken for the opposite. So, either "OK" and "No", or "Yes" and "No".
And I think the latter is more consistent.

> The additional plugin TracSubPages [3,4] could be useful for displaying several
> release tables (although only formatted with wiki-syntax) inside one HCL page.
> Then we could create a HCL/ReleaseVersion for each release and dynamically embed
> pages [5] for the latest stable and development releases only.
> This would require some extra software running one the Trac server,
> but we could live with the current state.
>

Some day maybe :)

joanna.

[Zrubecz Laszlo]

Hi all,

Just read the whole thread, and now checked the new HCL page... trying
to respond to the questions, suggestions.

There were mentioned using more simple table structure... The new
design is more simple, but the wiki syntax still not support any
background colouring afaik.

About more automatic reports:
Really don't know what you mean (whoever was asking).
* Of course I can make an auto report script, but it would go
against our privacy for sure.
* the detailed hardware info have to resolved to user friendly names.
Actually I'm using this site http://pci-ids.ucw.cz/read/PC/

Overaly I like the new page but:

* "Usable" is really means nothing.
This is really should mean basic Linux compatibility. And because of
this we really can't do nothing about this, I would drop this. Instead
we should CLEARLY declare that the device must be Linux compatible
(actually f18 with one of the available kernel versions) before anyone
trying to install Qubes.

* different kernels
The different kernels are because some devices prefers newer some
needs older ones. So basically the LATEST should be used (because we
really can't stuck with an old one for long), except one really need
an older for any reason. (Like my devices :) So I would only have ONE
kernel column with the used kernel version as a content.


@Hakisho Nukama "can you suffix the HCL reports with a time stamp"
Sure, will do it soon.




--
Zrubi

[Hakisho Nukama]

On Tue, Dec 17, 2013 at 9:10 AM, Zrubecz Laszlo <ma...@zrubi.hu> wrote:
> Hi all,
>
> Just read the whole thread, and now checked the new HCL page... trying
> to respond to the questions, suggestions.
>
> There were mentioned using more simple table structure... The new
> design is more simple, but the wiki syntax still not support any
> background colouring afaik.

Indeed.

> About more automatic reports:
> Really don't know what you mean (whoever was asking).
> * Of course I can make an auto report script, but it would go
> against our privacy for sure.
> * the detailed hardware info have to resolved to user friendly names.
> Actually I'm using this site http://pci-ids.ucw.cz/read/PC/

The automation I mentioned is to extract meaningful information
out of collected reports and feed them directly into the HCL table format.
This could run on reports (on submitted or directly on users machines)
to create a standard report format (with human input* and readable),
which then can be converted automagically to a HCL table of our choice.

Currently used format:
<tr align='center'>
<td>
Devicename<br>
(CPU; Chipset; embedded VGA; BIOS version)
</td>
<td class='hcl-good'>Yes</td> <!-- Runs out of the box -->
<td class='hcl-good'>Yes</td> <!-- Kernel 3.11.1-2 -->
<td class='hcl-partial'>*</td> <!-- Kernel 3.9.2-2 -->
<td class='hcl-bad'>No</td> <!-- Kernel 3.7.4-5 -->
<td class='hcl-unknown'></td> <!-- VT-x -->
<td class='hcl-partial'>No</td> <!-- VT-d -->
<td class='hcl-partial'>
only works with 3.9 (patched) and newer kernel
</td> <!-- Remarks -->
<td class='hcl-reportedby'>
<a class='ext-link'
href='https://groups.google.com/d/msg/qubes-user/${ID}'><span
class='icon'></span>Name</a>
</td> <!-- Reported by -->
</tr>

Looking at https://www.flashrom.org/Supported_hardware#Supported_devices
for a project that uses output from their program to populate such a table.
They also rely on users sending in reports or dropping them into their pastebin.

[*] Submit-HCL-gui with drop-down (Yes, No, Unknown, Remarks) and
remark input fields:
Ask user to run qubes-hcl-collect (qubes-hcl-report) on different
kernel versions
in dom0 (only the collection of information is run in dom0) and send
it to AppVM.

Submit-HCL-gui will invoke qubes-hcl-generate (preferably in AppVM),
which extracts information and ask some questions to create a report.
- Installer runs out of the box?
The kernel branches could be automatically detected out of collected information
and remarks added by user.
- Kernel branch 3.11 works?
- Kernel branch 3.9 works?
- Kernel branch 3.7 works?
- Enabled VT-x and VT-d in BIOS or BIOS won't expose this option?
- Devices, maybe more?
Finally shows user the generated plaintext report, ready to be
submitted to list.

So 'qubes-hcl-convert ~/HCL-reports/* --html --version R2B3' will
output only reports
for R2B3 in the corresponding table format.

So only qubes-hcl-convert has to be modified for a new table format,
be it some change in layout
or moving from html to wiki syntax. And the table can be recreated
with all collected plaintext reports.

Any thoughts about this?

> Overaly I like the new page but:
>
> * "Usable" is really means nothing.
> This is really should mean basic Linux compatibility. And because of
> this we really can't do nothing about this, I would drop this. Instead
> we should CLEARLY declare that the device must be Linux compatible
> (actually f18 with one of the available kernel versions) before anyone
> trying to install Qubes.

We could state the used kernel versions and Fedora version and direct users
to look for compatible devices there, or directly on kernel.org. ;-)
Also information on VT-x and VT-d support can be found on the vendor
sites or on forums,
so why not ditch the HCL altogether?

This "Usable" column should represent the out of the box experience.
Does everything work as advertised or does the user needs some CLI-fu
or workaround to get the system working.
I've renamed the column to "Runs out of the box" and are open for a better
title, because my choice on "Usable" was indeed not a good catch.

So this column is for the average user, which isn't interested in details and
just wants to insert the DVD into their drive and click though the installer
to be ready to start using Qubes, when this is marked hcl-good.

If it is marked as hcl-partial, the user could read the remarks and
run a workaround
to get it working with the troubleshooting mode and boot a kernel that is marked
supported.

It it is marked as hcl-bad, there is no way to install it out of the ISO.

Maybe there is a newer kernel in the repository that would enable this device,
then there could be a hcl-partial in the out of the box column and the
remarks would state, that you have to install it on a supported system to update
to a kernel, which supports your device and put the drive back to your device.
Or you wait for a new Qubes release, which incorporate this newer
kernel (or build your own).

An report like the following could be classified first as hcl-bad, but
could change to hcl-partial
after a workaround has been found and in the following release to hcl-good,
if this issue gets fixed upstream in time before next release ISO is issued.
https://groups.google.com/d/msg/qubes-users/DTot3wX1-nQ/cpCsRfs5PfgJ

> * different kernels
> The different kernels are because some devices prefers newer some
> needs older ones. So basically the LATEST should be used (because we
> really can't stuck with an old one for long), except one really need
> an older for any reason. (Like my devices :) So I would only have ONE
> kernel column with the used kernel version as a content.

Then we should find a convention to fill in this one kernel column.
Maybe something like this:

- single version reported
3.11.1-2

- working from version onward or until a version
[3.7.4-5
3.7.4-5]

- working in a range of versions 3.7.4-5 till 3.9.2-2
[3.7.4-5 - 3.9.2-2]

- excluding a range or single version
]3.9.2-2 - 3.11.1-3[
]3.11.1-2[

Seems complicated to maintain different branches in one column.

Therefore I'd separate this into different kernel branches, where an short Yes
or No with the kernel version in comment is sufficient.
<td class='hcl-good'>Yes</td> <!-- Kernel 3.11.1-2 -->
The hcl-good entry should be reserved for devices, with a full support
on this kernel version.
So all drivers should work.

An *, if a kernel has to be modified or another workaround is needed.
<td class='hcl-partial'>*</td> <!-- Kernel 3.9.2-2 -->
A hcl-partial entry is usually combined with a modifications or some
unnecessary device
drivers which aren't functioning as expected.
As an example: Not supporting your firewire isn't a catastrophe. Maybe
even a blessing. ;)

<td class='hcl-bad'>No</td> <!-- Kernel 3.7.4-5 -->
The entry with the hcl-bad class means the kernel isn't working.

The script or editor could update the exact kernel version in the comment.
and latest available report would be used to fill a kernel branch column.

The HCL table thus describes a state, which is able to change with
ongoing development.

For instance, there is a indication, that you can run with a kernel
(version branch=green),
but the installer won't come with this version (out-of-the-box
column=yellow), and you've to
workaround with another kernel or install and update on a supported system
or hope for a future release or build your own release ISO with an
updated kernel.

The HCL is a guide, which should easily indicate, if you can run Qubes.
And if not, show what holds you back from running Qubes.
(nag upstream, change graphic card, increase RAM, or whatever)

It is often a shoot in the dark, even with a HCL, but if you hit jackpot, missed
or discover a workaround for a device, let us know.
Would be great if a normal user could tell us about their experience with ease,
and Zrubi, you've decreased the distance to this goal. Thanks.

> @Hakisho Nukama "can you suffix the HCL reports with a time stamp"
> Sure, will do it soon.

Thanks.

>
>
>
>
> --
> Zrubi

>
> --
> 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...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-users.
> For more options, visit https://groups.google.com/groups/opt_out.

Best Regards,
Hakisho Nukama

[Zrubecz Laszlo]

On 17 December 2013 18:25, Hakisho Nukama <nuk...@gmail.com> wrote:

> The automation I mentioned is to extract meaningful information
> out of collected reports and feed them directly into the HCL table format.
> This could run on reports (on submitted or directly on users machines)
> to create a standard report format (with human input* and readable),
> which then can be converted automagically to a HCL table of our choice.

...

Well yes, that would be good - but as I see this would need a lots of
effort to make it usable.
Not sure if it's worth it.

But if anyone can contribute such a GUI I'm happily change the current
hcl script to cooperate :)

> The HCL is a guide, which should easily indicate, if you can run Qubes.
> And if not, show what holds you back from running Qubes.
> (nag upstream, change graphic card, increase RAM, or whatever)

That's why I still think that "usable" and the different kernel
versions columns are just more confusing.

I still believe If a device runs fine with the LATEST kernel, then do
not care the other versions at all!
This is simple.

And usable (or whatever we call it) means the SAME: It is runs fine
with one of the available kernels.

Also the different colour ratings for different cells are misleading.
One device should be only in one category! (good/partial/bad)


Even if it's really nice to hear you appreciate my work, I'm really
just one of the contributors... so lets get some opinions from others
:)




--
Zrubi

[Alex Dubois]

Alex

> --
> 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...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-users.
> For more options, visit https://groups.google.com/groups/opt_out.

As far as I can see HCL has 2 aims

Help a potential hardware purchase to allow Qubes to run on it. Few aspects are Qubes specific. The other aspect could leverage on HCL from fedora.
HCL should only validate green core Qubes dev. For the other working one HCL should give status and recommend contact owner who tested.

Second use case is I have a machine, just learnt about Qubes and want to check if my machine is ok. Here again high level view (goodd/partial/bad) and a capability to reach existing owners seems to be of most value.

If the owner has the will, offering him to maintain a wiki page with what he has configured to get it working may be ok but the life time of such page is so short that i would prefer people to contact me for my T430

My 2cents

Alx

[Zrubecz Laszlo]

Hi,

Just back from my holiday.

After I recreated myself from the shock I got about the number of
unread emails, still not see to much opinions about the HCL.

I still think that the current (R2B3) one is not clear... or more
confusing than before :o


--
Zrubi

[cprise]

I have one idea for making it simpler: Instead of listing HCL reports
separately for each beta + release candidate, combine all the R2 reports
into one table. Also maybe put the beta for which each report was made
in parenthesis in one of the columns.