On 4/26/22 09:12, Ansgar wrote:
On Mon, 2022-04-25 at 23:48 +0300, Hakan Bayındır wrote:
While what you’re saying is technically true, the default selection
means much more than a default. It’s defines the stance of Debian, as
a whole.
[...]
So, if Option 5 is adopted, the default state is as important as the
step itself IMHO. I also still believe that giving people the tools
for assembling their "firmware enabled” install media is a valid
option, but it’s not favored as far as I can see (no hard feelings,
though).
And we stay a possibility for FSF-people.
FSF people condemned Debian long ago:
https://www.gnu.org/distros/common-distros.html#Debian
While I like and support what FSF is standing for, I don’t think
their “condemnation” is a valid reason for not pursuing the ideals
DFSG puts forward. In my opinion, DFSG is one of the things underpins
the essence of Debian, and is a force for creating a more free and
open world. We’re almost there on the driver side, and while it gonna
take some time, we can be there on the firmware side. We just have to
be persistent, sometimes stubborn even.
Maybe then the "DFSG-free" installer should also exclude drivers for
devices that require non-free firmware, including preinstalled non-free
firmware? It could also show a message indicating that such devices are
not supported (if possible).
People could still assemble their "non-free firmware enabled" install
media including such drivers.
While I understand where you're coming from, I don't think such thing is
necessary, because a) Most popular devices with non-free firmware blobs
already work without such firmware, albeit with a lower performance
(e.g. Realtek NICs), and b) The drivers gracefully handle the lack of
firmware already, with a couple of harmless "ERROR:" messages.
It's worth noting that the drivers in question are already free software
and might have functionality over time to support newer devices of the
family which might have open firmware, or ideally the firmware code is
published retroactively.
Moreover, I guess excluding such drivers would require a new CI/CD
pipeline, and may require new kernel packages complicating the situation
further, for both users and maintainers alike.
My ideal to make things as frictionless and transparent possible, while
making the transition between two states as easy.
I don't believe we have to decide between DFSG and convenience. A more
gradual spectrum should be possible.
Cheers,
H.
Ansgar
