Re: [H-source-users] [PATCH 6/6] Add Guix system with GNU/Hurd to the distro list

[bill-auger]

On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> The only drawback with not adding Guix + GNU/Hurd as distribution is
> that the kernel names are not normalized,

that is what i am suggesting - lets find some deterministic way
to identify/distinguish and present the different known libre
kernels


On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> Many computers with Radeon GPUs are better
> supported with Jxself's linux-libre but not with Trisquel 10 because
> Trisquel 10 has patches on top of Linux-libre
> 
> For some other computers it could also be the opposite (they'd work
> better with an unmodified Trisquel) due to these exact same patches
> 
> So in this precise example, the exact kernel version is not that
> important as the patches were there in linux-libre

yes that is getting at the heart if the matter - i dont think
that is precisely the case though - AFAIK, trisquel takes the
ubuntu kernel source package and de-blobs the sources with a
"package-helper" script (like makeicecat) - so it is not the
FSFLA's linux-libre - it is also distinct from the debian kernel

"trisquel the distro" is not the essential factor - the
essential factor is that kernel which _incidentally_ comes
pre-installed on a default trisquel system - regardless of the
distro used, a pureos user for example could install that
trisquel kernel if necessary; or a trisquel user could install
linux-libre or the debian kernel

so my idea is to make those kernels distinguishable somehow like
tested with:
* debian linux 5.11
* trisquel linux 5.11
* linux-libre 5.11
* hurd 1.2.3

if it could be presented like that, then the distro name is
actually irrelevant - that is my thinking


On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> Indeed, that would be better than this patch, but I'm not sure if
> it's really necessary. My fear here is that it too much field could
> would confuse users (the same applies to having Guix HURD too).

again, i am not concerned with the website, where the correctness
of the contribution depends on the user's knowledge and honesty
- i am considering making the client determine which kernel and
modules are loaded - if the user notices that the client made an
incorrect guess, it would suggest opening a bug report


On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> So maybe there is another way: somehow deducing the exact kernel package
> used from uname -a or uname -r? I'm not sure how to do that though.
> 
> If somehow we have a database of kernel version strings that could
> give, with the string as input, the distribution version, and the
> exact package used, that would be great.

yea im not sure either; but that is the idea - `uname` plus the
package metadata could help with that
eg: Maintainer: The Debian Kernel Team
    Maintainer: Jason Self
    Maintainer: Trisquel GNU/Linux

for the website, i am thinking about a "drop-down"
select/options widget for the website - it could be pre-loaded
with exactly 4 kernel options (let the user type the version)
* debian linux
* trisquel linux
* linux-libre
* hurd


On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> Maybe we need to encode the architecture in the kernel extra version?

probably yes; because no one is asked which computer was used
for the test - the arch is probably very significant - i did not
think of that; but you can see there is much room for
improvement, to capture and present more useful and reliable
information


On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> The issue here is that there are sometimes a many to one relationship
> between the module name and the module.

maybe not; but it is probably safe to assume that lsusb/lspci is
going to report _something_ - whatever lsusb/lspci reoirts, that
is what the user would type by hand anyways; so the information
would be at least as reliable as it is now  - its just a matter
of white-listing the possible names, rather than letting it be
an arbitrary text field - then there would be no doubt that the
field contained the name of a known libre module, rather than
someone using a non-free wifi device on debian for example, and
reporting it as "working" with a non-free module

and perhaps not knowing or forgetting that the non-free formwars
package is installed - h-client could even check for that, in
case the device is working; but lsusb reports an empty "module
in use" name


On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> In addition some drivers are pretty modular. For instance there is
> ath9k_hw, ath9k_common and ath9k, and you need these 3 modules.

but hopefully lspci/lsusb will report only one module that is
how the h-client detects all hardware now


On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> But you're right on the fact that the website should not become too
> complicated to use. Some users might indeed not know what HURD is for
> instance.

i think this idea would simply the user-experience - instead of
asking "which kernel are you using? please run 'uname` bla bla
.. to find out" - it could be a simple option selector with only
4 options - people using a default trisquel would simply pick
"trisquel linux"


On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> I've already written code (in python) that can recreate the output of
> lspci just with the PCI ids[2], so we could potentially only store what
> is not in /usr/share/hwdata/pci.ids, though I've no idea how to find the
> driver from that progmatically.

the h-client already determines the VID:DIDs and which module the
device is using, by shelling out to lspci and lsusb and parsing
the outputs