On 18/12/2018 03:48, Steve Litt wrote:
> [snip]
> Perhaps reframing it would make a difference. Perhaps renaming the
> second program "Install Software" (install_software), and having it
> boot into install_software, would satisfy all but the most
> windows-phobic that the sum of the two programs are "the installation."
> Adn the first time you run install_software and click OK, it deletes a
> flag file the first installer (the one that boots from DVD or Thumb)
> put there.
>
> Now that I understand what's involved. I don't at all begrudge Windows
> for booting in the middle of an install.


It is a real PITA (and can be expensive to companies) to spend an hour
building a system (watching GNOME suck in all its dependencies) only for
it to fail to boot because of an issue with a RAID controller, a graphics
card, EFI etc. These issues are usually better identified early in the
build process.

>
> [snip]
>>>
>>> You know what would really be fun? An installer that asks *all* of
>>> the necessary questions right at the front, so you can walk away
>>> and do something else while it installs itself. I find installers
>>> that keep asking me questions every 10 minutes annoying.
Windows NT did this using its 34 Floppy Disk install, first disk booted and
quizzed the installee, whom then just sat there swapping floppy disks...
been there, done that!

>>>
>>
>> You can use preseeding for that. And you are not asked any question at
>> all.
>
> Not the same thing. I want the discoverability of a menu when I define
> all aspects. Perhaps the best of both worlds could be obtained by
> having a Curses or GUI program providing questions to create the
> preseed. Now THAT would be cool!
>
It should be viable to either strip the UI & questions from the installer
retaining the log\preseed creation or simply set a flag so the installer
does not 'act' on the selected options but still logs as if it did.
I prefer the flag option.

To clarify further...
It is my view that the configuration program should be capable of being
run at any time after installation, even multiple times on separate
occasions as required.

For a simple example of the concept see the Raspberry Pi 'raspi-config' utility.
Differing configuration UI's could potentially be developed over time...
zsh, then ncurses, Xorg based (QT?)...