Re: [H-source-users] generalize (or eliminate) the distros white-list

[Denis 'GNUtoo' Carikli]

On Fri, 29 Oct 2021 13:34:12 -0400
bill-auger <bill-auger@peers.community> wrote:

> my main criticism of the distros white-list, is that
> "distros-by-release" is not the most informative categorization;
> and that there is no reason for the client to discriminate,
> based on one specific server's white-list
Indeed.

> it seems to me that the kernel is the only significant factor
> which determines if some hardware "works with free software"
> (which the website shows generically for all entries) (ie: that
> really means: "works with _this_ libre kernel") - IIRC, all
> client hardware entries carry the kernel and version
> information; so distro information reduces to analytics or trivia
I'd add a minor fix here: the kernel is the most significant factor.

We also have userspace drivers for instance in bluez, mesa, modem
manager, etc. In the case of bluez, some utilities in bluez-utils can
even load firmwares inside bluetooth chips. In addition the boot
software like the BIOS/UEFI/Libreboot can also play a role.

I've in mind a similar model than what you are talking about, where a
given hardware (like a WiFi usb adapter for instance) has attached to it
several "tests", where each test would record things like the date, the
distribution version (if it has one), the distribution, the kernel, and
ideally have the ability to add comments for this test. Developers
would also have the ability to add more fields later on if needed, like
the bluez version for bluetooth dongles.

> here are some good reasons to push this concern out of the
> source code, or to remove the distros white-list entirely (an
> empty or missing white-list file, could simply default to:
> "accept-any-with-known-kernels")
The issue with the distribution + version list is also that it needs to
be maintained over time. And distributions often add new versions.
It looks less a concern for distributions as the pace of change is very
slow.

I should try to find some time to add the missing distributions (like
Replicant and probably LibreCMC and ProteanoOS as they are very
different from regular self-hosted FSDG compliant distributions.

This should also be taken into account if possible because the
compatibility level can change completely with hardware supported by
these distributions: The devices supported by Replicant 6 and all the
devices officially supported by LibreCMC don't even boot in any of the
self hosted distributions:
- For Replicant compatible devices, you need a special kernel that
  isn't packaged in any of the self-hosted distributions.
- For LibreCMC devices, 32bit MIPS isn't supported by any of the self
  hosted distributions.

> * the website already presents the question as: "does it work
>   with free software?" (not: "does it work with my distro?") -
>   WRT the EOL distros issue: even hardware entries which were
>   orphaned by a deleted EOL distro, would (forever into the
>   future) show: "does it work with free software? YES"
Right.

> * if some hardware works on any release of foo-distro, it is most
>   likely to work on all later releases - i doubt if linux-libre
>   or debian would let any useful libre drivers be dropped
That isn't always the case. The Radeon driver used to work fine in older
Trisquel releases, and at some point it stopped working, so I re-added
support for them in linux-libre but only for the GPUs I had access to.

> * if for some reason, some hardware does not work on some release
>   of foo-distro, that would be most likely because linux-libre or
>   debian has dropped the kernel module;
It could also be because the free firmware stop being supported, or
that the driver now requires a firmware (radeon), or because of some
bug in the distribution(it happened in Parabola with the b43,
b43-legacy, and the tg3 drivers), or because some userspace tools
changed, or even because a nonfree firmware was found and removed.

> and it will not work OOTB on any distro + that kernel - regardless,
> it can be made to work on that release of foo-distro (or any other),
> simply by using a previous kernel, which still has the module - again,
>   this is very unlikely to happen; but by the time it affects any
>   LTS distro, it would have already affected all other distros
>   which offer foo-kernel as the only kernel option
> 
> * the distro name is even less informative for distros with
>   multiple kernel options; because one of the kernels may
>   support some hardware, while the other kernel may not - how
>   to represent that in the DB or on the GUI? - for example,
>   guix+linux-libre vs guix+hurd - there is probably only a single
>   bool for "works with guix"? - 
Indeed, we do need more information here. In addition there are 3
Parabolas architectures (x86_64, i686, and armv7h).

> what happens when another client submits a contradictory report on
> the same release of the singular 'guix' distro - the only other way
> to capture that information, would be to treat guix as two distros:
>   'guix+linux-libre' and 'guix+hurd' - 'guix+linux-libre' would
>   probably support all of the same hardware as 'parabola'; and
>   'guix+hurd' would probably support all of the same hardware as
>   'debian+hurd' - the fixation on distros actually equates to a
>   loss of information in this way
Ting that information to the individual test would probably also work.
You could add distribution Guix, kernel: linux-libre <version> or
hurd+mach <version>.

> * hypothetically, i suppose that very little of importance would
>   be lost if the entire distros table were deleted - it could be
>   replaced with a table on the website, listing which distros use
>   foo-kernel and which use bar-kernel
We'd loose a lot of context here. And we need as much context as
possible if we want that information to also be usable for tracking
regressions for instance.

> i am not familiar with the code yet - does anyone know, if or
> how are conflicting entries handled now?
Unless that changed recently, in the web interface and in h-client, any
changes of the compatibility level overrides the previous value.

> - is there any attempt
> to collect/correlate multiple records for the same device, into
> a device-specific value/probability or a single boolean for:
> "works with free software (at least one known kernel version)"?
That would really be the way to go I think.

> - or does each client hardware record have it own independent
> (possibly conflicting) "it works with free software (for me)"
I think that's what we have now, given how the web interface and
h-client reacts.

Denis.

pgpo5mkNm1v1F.pgp
Description: OpenPGP digital signature