On 2020-02-29 20:20, David Wright wrote:
On Thu 27 Feb 2020 at 17:13:26 (-0500), John Kaufmann wrote:
On 2020-02-27 09:41, Lee wrote:
[The free/non-free distinction] ... is well-explained, and in fuzzy principle I
like the explanation. In functional terms, it only became an issue for me when
the image I was installing paused to ask for a disk with needed wifi drivers.
(See the thread title.) So I have two problems with free/non-free - one
philosophical/operational, one regarding the image installation script:
1) If one can only make a working system with "non-free" drivers, what is the alternative? - a non-working
system? What is the point of being a stickler about a "free" installation if that installation itself
/requests/ "non-free" components? [Are all OEM hardware drivers by definition "non-free"?]
The premise of your question is wrong. None of my three desktop
machines needs any non-free driver. One uses a firmware blob for
sound, which it never saw until it was 12 years old when I ditched
its predecessor, a Tucson mobo'd PC. I don't think Debian has ever
carried it (Yamaha ymfpci) in the timespan over which I've used it.
But (as noted above) the "free" installation paused to /ask/ for wifi drivers for my
Thinkpad, from "non-free" media:
"If you have such media available now, insert it and continue."
I have to agree with that script: a Thinkpad without wifi could fairly be called a
non-working system... which comes back to my two-part first question, about the
philosophical/operational aspect of the "free" commitment:
- Is it a choice between a free non-working system or a non-free working
system?
- Are OEM hardware drivers by definition "non-free"?
2) When the installation pauses to ask for the insertion of a new medium
(i.e., a disk change) requiring drivers, how is that supposed to execute if the
installation does not prompt, or even allow, the CD drive to change disks (OP
of this thread)? Despite excellent replies to this thread, I'm sad that no
reply has addressed that issue.
I'm not certain the issue has been addressed at all, mainly because
there's never any real need. AIUI, and correct me if I'm wrong, you
downloaded both a free d-i and a firmware one onto two CDs, and
installed using the former. Then you needed to load the firmware from
somewhere, and wanted to use the other CD as the source.
You understand correctly. (I acknowledge a newbie misunderstanding of the
firmware image.)
Almost nobody finds themselves in this situation, nor are they intended
to. The idea is that you put any non-included drivers, whether they're
from Debian or elsewhere, onto a USB stick (or SD card, or whatever),
which you can insert at any time. (If it's already inserted, it won't
be asked for.)
Aha! - put the drivers on a /different/ media type, so the script does not need
to relinquish the CD drive. Fair enough (acknowledging another newbie glitch).
Thanks for the explanation in terms even a simpleton can grasp. That disposes
of my second question, about the installation script (but the two-part
philosophical/operational question remains).
(If the choice of images seems too complicated, that's only because it is.) For
example, just look at the pages:
...
cdimage.debian.org/images/unofficial/non-free/images-including-firmware/current/multi-arch/iso-cd/
cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.3.0+nonfree/amd64/iso-cd/
Two pages to serve the same purpose is too much churn.
except they do NOT serve the same purpose. I've got machines with
Intel 32 and 64 bit CPUs. The /multi-arch/ image works for both; the
/amd64/ will work only on an Intel 64 bit cpu.
Quite right; I was careless. That said, Debian targets many architectures. The
special case of x64 evolving out of the x86 instruction set has made x86/x64 a
common joint target (as opposed to other architectures), which my carelessness
ignored.
Maybe, though, a case can be made for more formal regularity to highlight
/intentional/ distinctions. For example,
- Should the x86/x64 distribution be under a directory tree "/images/.." while the the
x86/x64 distribution is under a directory tree "/cdimage/.."? (Surely that is a
distinction without intent or motivation?)
- Could the two pages have page *titles* to highlight their distinct purposes
[the usual reason for page titles ;-)]?
- Could they be handled on a single page, along with other architecture
targets (assuming a suitably clear and compact format - like a table?)?
I have no idea whether this is true, but there might be some intention
of evolving from cdimage to images, if only because using the term CD
to cover DVDs and USB sticks etc is confusing to some, according to
some posts here.
It /is/ true, but I like your speculation that the directory branch "cdimage" might evolve into the
branch "images". However, of course both branches are under the subdomain
_"cdimage"_[.debian.org], FWIW. Once I feel comfortable that I have a working grasp of the issues,
I will write to the Debian CD team for comment (and possibly to see if I can assist).
... I'm taking a lesson from this: some cleanup is in order.
Whereas I think the issue is that most linux documentation assumes too
much background knowledge. But I suppose that's what the mailing
lists are for - a shortcut for finding out what info you're missing :)
That's a good point, but I actually don't mind the OS learning curve ... My
questions here have been about the Debian ecosystem and installation quirks,
and I think I have learned some things that could be tidied up to make life
simpler (which, among other things, could only help my objective of offering
people a Windows escape route). With all the help received on this list, I have
learned a meta-lesson: that the place to explore those apparent 'lessons
learned' is with the Debian CD team.
I would agree that the paths through the web pages might be made a bit
more logical; not just the ISOs but also the md5sums etc. But I
imagine the d-i people have a lot on their (few) hands keeping up
with building the d-i software itself (if indeed it's the same people
responsible).
I don't doubt that, David. Still, I think I might contribute something, and the
answers here contribute to that thought.
Thanks,
John
