• Re: General resolution: non-free firmware

    From Thorsten Glaser@21:1/5 to All on Sun Aug 28 03:10:01 2022
    Debian Project Secretary - Kurt Roeckx dixit:

    it are available at: https://www.debian.org/vote/2022/vote_003

    Hrm.

    Is there support for something like A but not enabled by default?
    That is, you have to actively select a nōn-default option in the
    boot menu so that the installer loads the non-free-firmware part
    and installs it (but updates will be enabled if they are installed
    in the first place)?

    Mraw,
    //mirabilos
    PS: Please do Cc me on replies.
    --
    I believe no one can invent an algorithm. One just happens to hit upon it
    when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Morrell@21:1/5 to Thorsten Glaser on Sun Aug 28 07:50:01 2022
    XPost: linux.debian.vote

    On Sun, Aug 28, 2022 at 12:56:43AM +0000, Thorsten Glaser wrote:
    Debian Project Secretary - Kurt Roeckx dixit:

    it are available at: https://www.debian.org/vote/2022/vote_003

    Is there support for something like A but not enabled by default?
    That is, you have to actively select a nōn-default option

    I don't believe so, because that doesn't solve the problem at hand. How
    exactly do you select a non-default option if you cannot see or hear it?

    More and more graphics adapters now also want firmware uploads to provide any non-basic functions. A simple basic (S)VGA-compatible framebuffer is not enough for most users these days; modern desktops expect 3D acceleration, and a lot of current
    hardware will not provide that without extra firmware.

    Current generations of common Intel-based laptops also need firmware uploads to make audio work (see the firmware-sof-signed package).

    https://blog.einval.com/2022/04/19#firmware-what-do-we-do https://peertube.debian.social/w/gpdBYkAuxJ5D8V9DmsTvJS

    -----BEGIN PGP SIGNATURE-----

    iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYwsBhAAKCRDbymUJHySO bBM+AQD1q9J/OQRAFNKaethROEB2lpCI+r6xH65oF7tGM2c4/wEA1vCj8GF2DksM DnypVzAnR8DZ8lyfvL3YulcTmJN8KA8=
    =NB96
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thorsten Glaser@21:1/5 to All on Sun Aug 28 20:20:02 2022
    Thorsten Glaser dixit:

    PS: Please do Cc me on replies.


    Phil Morrell dixit:

    Is there support for something like A but not enabled by default?
    That is, you have to actively select a nōn-default option

    I don't believe so, because that doesn't solve the problem at hand. How >exactly do you select a non-default option if you cannot see or hear it?

    You see it in the bootloader, or if not, can append it manually to the
    kernel command line so that the initrd and d-i see it both. (I’m willing
    to compromise on having early pre-initrd microcode updates always loaded
    which would be the one thing we could not easily toggle on/off from the
    initrd and/or d-i.)

    I really don’t want to vote NOTA above all, but I don’t want this
    generally enabled *by default* either.

    Composable install media would be interesting. For example, the MirBSD
    install floppy is an ustar image instead of a filesystem (with its first
    sector faking being an ustar symlink while actually being machine code
    to load the second-stage loader) enabling users to add a “boot.cfg” file
    by simply appending it to /dev/fd0 or so using tar(1).

    For CD images, presence of enough comments in the platform loader config
    around the kernel command line for d-i could allow some tool to patch it
    before burning (or putting on USB stick or whatever). (I admittedly have
    not implemented this for MirBSD yet either.) Maybe a generic tool that
    extracts a specific-named top-level file¹ that lists all live-patch
    locations (start sector (2048-byte for CDs) plus offset into that, or
    maybe better start byte offset in the image, plus length of the area,
    plus some kind of description of how to terminate it (newline plus a
    long string of comment chars tends to do this).

    Probably easy enough for those with experience to cobble together such
    an image patcher for other OSes. I could do for 16-bit DOS if needed.

    Most “weird” architectures can easily netboot, and that’s the easiest
    one to hot-patch the kernel command line for.

    Anything else?

    bye,
    //mirabilos
    ① use a file, don’t put it anywhere else in the image, because the
    reserved space for ISO 9660 is generally used to allow manifold/hybrid
    boot, and using a file would allow this for other filesystems as well;
    determining the offsets needs to be done after image creation, most of
    the time, of course, but these can trivially be patched into that file
    at that time… patching images after generation is how MirBSD’s boot
    loaders, for i386 and sparc both, are put on the ISO images; to obtain
    the sectors I’ve already written a small generic tool, but on GNU,
    isoinfo usually will do
    --
    <igli> exceptions: a truly awful implementation of quite a nice idea.
    <igli> just about the worst way you could do something like that, afaic.
    <igli> it's like anti-design. <mirabilos> that too… may I quote you on that? <igli> sure, tho i doubt anyone will listen ;)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve McIntyre@21:1/5 to Thorsten Glaser on Tue Aug 30 22:20:01 2022
    Thorsten Glaser wrote:
    Phil Morrell dixit:
    Is there support for something like A but not enabled by default?
    That is, you have to actively select a nōn-default option
    I don't believe so, because that doesn't solve the problem at hand. How >>exactly do you select a non-default option if you cannot see or hear it?

    You see it in the bootloader, or if not, can append it manually to the
    kernel command line so that the initrd and d-i see it both. (I’m willing
    to compromise on having early pre-initrd microcode updates always loaded >which would be the one thing we could not easily toggle on/off from the >initrd and/or d-i.)

    Please go and *read* and *respond* in debian-vote. The discussion is
    there, not here.

    You've utterly missed Phil's point about people not seeing or hearing
    boot options. Go and read my first mail in the thread for context.

    --
    Steve McIntyre, Cambridge, UK. steve@einval.com "We're the technical experts. We were hired so that management could
    ignore our recommendations and tell us how to do our jobs." -- Mike Andrews

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Thorsten Glaser on Tue Aug 30 23:00:02 2022
    On Tue, Aug 30, 2022 at 08:28:15PM +0000, Thorsten Glaser wrote:
    Steve McIntyre dixit:

    Please go and *read* and *respond* in debian-vote. The discussion is
    there, not here.

    I wrote where the Reply-To pointed to. Perhaps if that had been
    correct…

    It was clearly written that the discussion is happening in -vote, and
    you are supposed to reply there.
    How much more clarity do you need?

    Please take this thread there, not here.

    --
    Best,
    Nilesh

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEPpmlJvXcwMu/HO6mALrnSzQzafEFAmMOeEoACgkQALrnSzQz afFDWhAAvRqm2Vb6Uzmw3G9d9oAJ5zXJN5MT2npJ9Ag4PR88dXTXmAQSMCgJsPWx 0IJtJkzRwS8SyJYeGCtbQwmLxIRZLWoXk9125YvMysmNQbXbyvroyL/p/UyHWGcM UGizLKn4qP4w9jp/wyJ0kl4p20gJ43mqhpYaS+PPkJ5vuBcZglx8Z1uJezUfon0D X1/0Ny3p63E01TYeF1k44G4hMcs/gZq5GiH1KuZZ9zmpVWLOYUkzmJ/hBPmU0/ll bP9zBROU7nm37LIVSBZONrNqlnGc3el1zuoRSNnDzc8qx/ysPFAgLdeMta9rff/+ Olij9Y9l1BcHXJRXdNbFhzIZZt+ofNwZghYWV4LYDlUVDmDukimOv3a2dLP1On8T skrAH+mbEGPZravcXD/hKG80/en2+lqwHhIvuseXae408q8ovq046JsVtmoYVthS peidBIpN2VOiQSXLtqbu9wS1EKgiF+izVb4mA2jCOPiAC218rQbdC+JaUW2pVL8B T3JHx7wJ3OsXIEcyzKcql0aploNm+roEMSMh7OeUymP4wOwdrxRoQluAxCSPWLJV aTeiLE93jXNer4EIphgxBjhGvHEOYvxUL+GVrwoci8hCKRWOzGNVVmgFGQH/NYQZ tzFwLrhdnh79VHzmuWamutEhZYnt94IH5mj0W7GhfM0XbroOj9I=
    =4OPO
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thorsten Glaser@21:1/5 to All on Tue Aug 30 22:30:02 2022
    XPost: linux.debian.vote

    Steve McIntyre dixit:

    Please go and *read* and *respond* in debian-vote. The discussion is
    there, not here.

    I wrote where the Reply-To pointed to. Perhaps if that had been
    correct…

    You've utterly missed Phil's point about people not seeing or hearing
    boot options.

    I didn’t. I pointed out that people can select different bootloader
    options if their bootloader is already set up for them, or that they
    can pre-create different images with nōn-free-firmware enabled if not.

    Go and read my first mail in the thread for context.

    https://lists.debian.org/debian-vote/2022/08/msg00001.html

    That? It doesn’t at all address the bootloader.

    ----

    My motivation is as follows: I’d love to make some amount of gratis redistributable firmware available, but most definitely *not* as
    default, because that would undermine what Debian promises. On the
    other hand, officially creating two kinds of installers, images, etc.
    will get old very soon, so folding them to have only one, where those
    parts can optionally (but NOT by default) be enabled, ideally before
    d-i starts, would make sense to me.

    I’ll most certainly vote anything that enables it by default below NOTA.

    bye,
    //mirabilos
    --
    <ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^
    <mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
    <ch> should have cloned into a clean repo │ fault (core dumped)
    <ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)