|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: [RFC] Support for using multiple CDs during installation
Date: Wed Oct 31 2007 - 14:23:09 EDT
Your mail seriously put me off for a few days, so I've given myself some
extra time to think about it.
On Friday 26 October 2007, Joey Hess wrote:
> > As argued above, loading multiple CDs in no way conflicts with using a
> > mirror. IMO we have to always ask both questions.
>
> Neither does installing lilo to one disk and grub to another, but d-i
> does not prompt the user to choose if they want to use lilo, and follow
> that up with a separate prompt about whether to use grub. Instead d-i
> allows the -0.00001% of users who need to do this to use the menu in
> expert mode.
OK, but in your proposal the option to scan additional CDs is _not asked at all_ if they choose to use a mirror. A significant difference I'd say.
I also still feel that having to say "no" to a mirror is in any way logical if you want to use additional CDs, so we'd have to add some sort of ugly (conditional!) explanation in the use mirror dialog about that.
> > Also, first letting the user scan all CDs and then asking about adding
> > a mirror is a lot more logical than the other way around:
> > a) it seems not very natural to first scan the installation CD, then do
> > other stuff, and then go back to scanning CDs
>
> Scanning the first CD doesn't involve the user doing something, so most
> users will not particularly notice it's happened.
It still is visible for users who pay attention and it is also visible because of the way the mirror question is phrased.
> > b) it is much more natural to have a user consider:
> > - "OK, I've now scanned this huge pile of CDs; do I still want to use a
> > mirror in addition to that or not?"
>
> No, it's much more natural to optimise for the common case, which is
> using a mirror.
I don't think adding a single question that is only asked when it is relevant and has a default of "no" is a loss of optimization. I also think that a lot more users would like to be able to scan additional CDs than you think. Not everybody in the world has broadband.
> Users should not be encouraged to scan huge piles of CDs.
> Huge piles of CDs are obsolete in all but a very few edge cases.
I know your aversion against the full CD sets. I remember your blog about it. But I don't think scanning additional CDs if you already have them is in any way harmful.
I also don't think my changes "encourage them" as:
- the question is only asked when there is a real possibility the user
may have additional CDs available
- the default of the question is "no" which is an indication that you
don't absolutely need additional CDs; the question also includes the
qualification "if available"
I also very much doubt users who are at this stage of the installation and don't have multiple CDs will suddenly decide to break off the install and rush off to download/buy the full set and start the install over.
I agree that downloading/buying/scanning a full set of CDs is silly in
almost all cases. However, if you want to do something about that it should
be done where users decide to *buy or download* the images: on the website
and in documentation.
What your proposal here does is punishing users who already have multiple
CDs (and hopefully a lot will probably only have a limited number instead
of the full set anyway) by hiding the question behind an unrelated other
question and thus effectively not making the option available at all.
> Prompting for additional CDs will make the user feel that he should
> provide them, which is typically a waste of his time and leads to a
> system that is less functional (because apt asks you to switch CDs all
> the time). Or more likely, it will make the user worry that he doesn't
> have more than one CD.
Nonsense. I'm perfectly willing to clarify this in the dialog (or maybe better in an additional dialog after the user has chosen yes), but I completely disagree with this. See above.
> > than:
> > - "hey, they're asking me if I want to use a mirror; do I need one? I
> > probably do as apparently I cannot use this shitload of CDs they let
> > me download and burn..."
>
> When a user downloads a bunch of CDs they don't neeed, as in your
> example, we've already failed once, let's not fail twice.
Let's not punish them either if they've already done so...
> In general, you seem to be assuming that using multiple CDs is something
> other than an exceptional edge case. It is not. That's why I happily
> dropped it from the etch installer, and why only a few users have missed
> it.
On the other hand, we've listed the lack of support as a "known issue" and we've had it high on our TODO list. A fair number of installation reports has mentioned it as something that was missing.
And, as said before, I think it is wanted a lot more than you think. Not for full sets, but I think for a lot of users downloading the first 2-4 CDs can be a very sensible option. Consider for example the PowerPC case where CD1 hardly contains anything beyond the base system. And I've argued in my earlier mail that there is no reason why such users should not be allowed to use a mirror in combination with those CDs.
> If you want to fill in that edge case in the installer, that's fine
> (and impressive), but it's not good to complicate the installation
> process for the common case when doing so.
Adding a single, focussed question with a default of "no" is not "complicating the common case".
I'm still convinced that my implementation is the cleanest one possible. It
is focussed, has conservative defaults and it respects the relative
independence of the generators.
I'm willing to discuss changes, but hiding the option to use CD sets behind
the use mirror question is not an option for me.
Cheers,
FJP
-- To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.orgReceived on Wed Oct 31 14:23:32 2007
- application/pgp-signature attachment: This is a digitally signed message part.
This archive was generated by hypermail 2.1.8 : Wed Mar 19 2008 - 03:14:13 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |