On Thu, May 4, 2017 at 12:17 AM, Ben Hutchings wrote: > No, they should not, otherwise this certification becomes meaningless.
I see these certifications primarily as a service to Debian users and not as endorsements of vendors, but as statements of fact. The consequences to users should stated as part of the certification output. "This system can run Debian main", "This system is missing drivers for XYZ", "This system requires non-free firmware", "This system requires a custom bootloader", "This system requires a custom kernel", "This system requires a custom kernel and must use sysvinit", "This system requires an unofficial Debian port", "This system requires recompiling Debian from scratch" (CPU requirements bumps or CPU bugs). Basically, a more automated version of InstallingDebianOn. If Debian only certifies systems installed using official d-i images then we won't be certifying much, since almost everything requires preinstalled or runtime-loaded non-free firmware for some part of the system. We would basically only be able to certify RYF devices and may as well just require FSF RYF certification up-front before a system can be certified for Debian use. Since we already need two tiers of certifications for main vs non-free, is it really that much of a problem to add some more as long as our users are informed of the issues they will face? Users are going to buy or acquire those problematic systems anyway, especially in areas where there are almost zero devices that Debian could be certified for (for eg mobile devices). If they do and then decide to run Debian, information about what the consequences are would be useful. -- bye, pabs https://wiki.debian.org/PaulWise