:: Re: [DNG] What should be the tasks …
Página Principal
Delete this message
Reply to this message
Autor: Adam Borowski
Data:  
Para: dng
Assunto: Re: [DNG] What should be the tasks of the Devuan Installer
On Tue, Dec 18, 2018 at 04:58:00PM +0000, g4sra via Dng wrote:
> 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.


Yeah... but this particular problem can be solved in the installer, and work
_better_ than having to do it after installing:

* the installer doesn't need to be crash-safe: dpkg fsyncs every file it
touches, and rewrites the whole status file after every stage, also
fsyncing it. Eatmydata could greatly help, but even then you don't need
status file writes at all -- just once at the end would be enough. Adding
stuff on a live system can't use this optimization (which isn't
implemented).

* CD/DVD/BD-ROMs have gone the way of the dodo a decade ago, any modern
computer installs from USB/SD (if not network). These media are
writeable, thus if you downloaded only netinst, additional packages can
get saved onto the stick/15mm floppy. This avoids wasting bandwidth if
you need multiple installs.

> >>> 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.


Hell yeah oh please. Tasksel and popcon need to happen before the human-off
phase commences.

> 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!


Did floppy 33 have a bad sector? :p

> >> You can use preseeding for that. And you are not asked any question at
> >> all.


Preseeding is very user unfriendly. What about saving the answers to the
install medium (see my remark above about caching packages downloaded from
the network)? It'd allow to repeat the install without forcing the user to
learn anything.

> > 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!


Aye. Current interface shares debconf's limitations -- either debconf
should be extended or the UI replaced with something dedicated.

Tasksel in particular really could learn from kernel's menuconfig.

> 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.


Possibly, yeah. This would require asking the questions beforehand rather
than at random times strewn around the install process, but -- as I said
four sections above...

> 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.


Especially in the ARM world, any board that d-i doesn't have a specific
support for requires a manual debootstrap. A separable configuration
program would be nice.

> 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?)...


Aye.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄⠀⠀⠀⠀ to the city of his birth to die.