On Sun, 2022-05-15 at 20:53 +0200, Bastian Blank wrote: > I see what you mean. But nothing of that actually enables the use of a > particular hardware. Enabling the use of particular hardware is a subset of the actual goal; enabling more people to use Debian at all, which the non-firmware items Sam suggested (TTS, input, STT) are about. Folks with no/low visual capacity require a TTS (text to speech) to be able to use Debian at all. Folks with no/low English capacity require input methods for their languages. Folks with no ability to manipulate physical input devices require an STT (speech to text) to be able to use Debian. Of course, these items also benefit everyone else, who can have temporary capacity problems; like an STT is useful to people who are driving a car. Another way to achieve enabling use of Debian at all for people who need some parts of non-free but who don't want to use the rest of non-free is apt pinning. Using pinning, the non-free installer could detect packages needed by the user from non-free, enable them and disable the rest. Perhaps a better alternative to pinning would be to add a feature to apt that warns about non-free packages before they are installed and explains main vs non-free in terms of licenses and Debian support. Of course subsetting non-free means that users can't see through apt other subsets of non-free and this is somewhat desirable since we prefer them to use main packages in preference to non-free packages and only use non-free packages when really necessary. This point means that it would be helpful to add additional subsets of non-free such as non-free/speech or non-free/input, for people who need them to use Debian at all. Then there are people who don't want to use most of non-free but need a few things in non-free like firmware and toolchain documentation, which would mean they would be happy to have other non-free subsets available; non-free/firmware non-free/doc etc. > > * Proprietary Nvidia graphics drivers. > > This is explicitly code built and run on the main CPU, not firmware. > It also needs firmware running on the device itself. In case folks didn't see the news, the situation with Nvidia has changed slightly since this thread started. For GPUs released since about 2018, they moved more of the driver into the existing proprietary firmware that was embedded in the driver before, released the source of the remaining Linux kernel parts under GPL/MIT licenses, while the userspace parts remain proprietary. https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ Presumably that firmware will go into linux-firmware.git and will now be able to be shared with the nouveau open source driver, which will mean nouveau will be able to do reclocking, which means there will be much less reason to use the proprietary userspace driver, since nouveau will be fast enough that most use-cases will be fine with it. The eventual situation will be one proprietary signed firmware, one upstream Linux kernel driver (probably nouveau updated based on ideas and code from the recent code dump from nvidia) and two userspace driver stacks, one proprietary and one from nouveau. https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/ According to the LWN comments, the nvidia firmware is now 40MB of signed proprietary RISC-V code that supports multiple generations of nvidia GPUs and runs on the RISC-V microcontrollers in nvidia GPUs. https://lwn.net/Articles/894861/ -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part