On Fri, Aug 28, 2015 at 04:33:04PM +0100, Steve McIntyre wrote: > This now means that more and more users end up enabling non-free just > to be able to get at this firmware, which is a problem for many > reasons.
> 1. Split up non-free? > --------------------- > Yes - need to work out details. (a) I'd argue non-free is already split up -- that's what the Section: header in the Packages file is for. That's certainly good enough for just pulling some selection of debs out for an installer image; and it seems like it wouldn't be too much work to use apt pinning to allow it to prevent non-firmware from non-free from getting in. For example, having the installer drop: Package: * Pin: release c=non-free Pin-Priority: -1 Package: * Pin: release c=non-free,s=non-free/kernel Pin-Priority: 500 into /etc/apt/preferences.d/10allow-non-free-firmware. (Note: "Pin: release s=" doesn't actually work. I /think/ it could be made to work, though maybe it shouldn't (section doesn't appear in the Release file after all). Worst case, "Pin: package section=non-free/kernel" could be made to work, I think) (b) In, hopefully, the mid-term, doesn't this sound like a job for bikesheds [0]? Drop non-free (and contrib?) entirely, and have a non-free or non-free-firmware-blob bikeshed, and have the installer-with-firmware come as part of the bikeshed. Nothing special about non-free at all that way, as other bikesheds could also have their own installer. [0] aka Debian PPAs for those who aren't au fait with the new terminology (c) Splitting non-free into separate components (ie, so you'd say "main contrib non-free/firmware non-free/gfdl") under ftp.debian.org/debian/dists/* would be bad though, IMO -- it makes non-free require more attention (from archive admins, maintainers, users) when we should be working to give non-free less attention. > *IMPORTANT*: We need to make sure that the messaging about this split > is clear; just because we're splitting non-free firmware out of the > default non-free area, that doesn't mean that we're suddenly endorsing > it as a concept! (I think demoting non-free to one of many bikesheds would be a massive messaging improvement here) > 2. Include non-free-firmware on official media? > ----------------------------------------------- > NO. Would the following be technically feasible? - "I want to install Debian" - download official USB installation image - write it to USB stick - "Oh, I need non-free network drivers" - download non-free firmware - mount installation image - copy firmware onto installation image - umount - boot, install Having "installation on non-free firmware systems" require a token amount of additional work by the user would be a fairly clear indication that non-free is bad, and it would be very clear that the official images, and in fact, every image we produce, doesn't include non-free firmware. > 3. Advertise the "unofficial" firmware-included media better? > ------------------------------------------------------------- > Yes. If we advertise them, it feels like doublespeak to call them "unofficial" to me. (Which is bad, though still better than not doing anything to prefer fully free stuff, and also better than making it a PITA for people to run Debian on common hardware, though, if those are the only alternatives) > 5. Anything else we can do to improve the situation? > ---------------------------------------------------- I wonder if it would make sense / be interesting to do more of the preparation work prior to the install. For instance: > If a user's machine includes hardware that needs non-free firmware, > maybe we could suggest known-good alternatives that would offer > similar functionality without the problematic firmware. If you could review this before install (on a web page, eg), and then choose where you want the non-free stuff or free alternatves (after browsing wiki links etc to fully inform yourself), you could download the firmware udebs you might need and a preseeding file corresponding to that choice, then effectively boot directly to an installed, working system, with no further questions. Also, having a hardware database that you could query before purchasing a new computer would be even better, no? (If you added a popcon style feedback loop where install results were uploaded back to a Debian server, you could log the time installation took, and use that info to provide future installs onto the same hardware with similar configurations with an *accurate* progress bar...) Cheers, aj
