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

[Denis 'GNUtoo' Carikli]

On Mon, 01 Nov 2021 21:37:47 +1100
Yuchen Pei <hi@ypei.me> wrote:

> Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> writes:
> 
> > 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.  
> 
> What kind of role does boot software play here?  I notice that 
> some newer laptops are marked platinum because things like Intel 
> ME is not part of the criteria.  Is this what you are referring 
> to?
Through ACPI, BIOS, EFI and UEFI, pass several things to the OS:
- Information
- Bytecode that the OS runs.

For instance in Libreboot or Coreboot, certain minor hardware doesn't
work on the Thinkpad X60 (like the IRDA or the TPM), and that (still)
needs to be fixed in Coreboot / Libreboot. I had patch for theses but I
don't have the time anymore to complete the work.

In the case of nonfree BIOS / EFI/ UEFI the hardware is supposed to
work and if there is a bug in that boot software, most of the time
Linux will adapt to it and not force users to upgrade.

In the case of Coreboot and Libreboot, having things not working is
more frequent, but the good thing is that we can fix things in the
right place (In Coreboot and Libreboot) instead of adding workarounds
in Linux.

> > 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.  
> 
> For completeness, shouldn't we also add versions of drivers that 
> do not come with the kernel (e.g. nouveau), or do you mean to put 
> this piece of information in the comments?
As I understand nouveau is splited in a kernel part and a userspace
part (in mesa). Most of the work probably happens in the userspace part.

So having the mesa version looks important here, at least for rolling
releases distributions.

For out of tree kernel drivers, not many are packaged, but we might
still want to have the infrastructure to add code to detect them if
people want to work on that.

> >> 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.  
> 
> Sounds good.  BTW what do you mean by "self-hosted"?

I reused the term that is in the FSDG definition[1]:
> In particular, a free system distribution should be self-hosting.
> This means that you must be able to develop and build the system with
> tools that the system provides you. As a result, a free system
> distribution cannot include free software that can only be built by
> using nonfree software.
>
> We make an exception to this requirement for small system
> distributions, which are distros designed for devices with limited
> resources, like a wireless router for example. Free small system
> distributions do not need to be self-hosting or complete, because it
> is impractical to do development on such a system, but it must be
> developable and buildable on top of a free complete system
> distribution from our list of distributions, perhaps with the aid of
> free tools distributed alongside the small system distribution itself.

You cannot compile Replicant from Replicant, and the same applies to
LibreCMC and ProteanoOS where people need another distribution (like
Trisquel) to work on them.

References:
-----------
[1]https://www.gnu.org/distros/free-system-distribution-guidelines.html

Denis

pgpI7EiGv4awY.pgp
Description: OpenPGP digital signature