[arch-releng] Draft - Beyond AIF, long live AIF...

[Gerhard Brauer]

Hi,

First excuse, I'm not a native and good English writer and speaker, and
writing such long texts is something i normally do not day-by-day.

Could we discuss about a suggestion:

What if we drop the interactive procedure on installation process and
offers only the automatic way, controlled by a plain text file?

Huh? What he is talking about?
===============================
AIF could use a control file in plain text to do the installation; also
complex installations (ex: LVM and dmcrypt). For examples take a look at
[1] and [2].
The install process then is running automatically without need of user
invention.

Installer paradigms
====================
Today installers (either if graphically or text based) are mostly
interactive tools. They ask the user for information and the user is
giving data to the installer. Also the user must make decisions in some
steps, say Yes or No. Also in current AIF in interactive mode.

Usual a installation is a top-down and sequent work-flow. But this don't
prevent that user do "silly" things. So installers (also AIF) must do
many things "behind the view" to intercept mistakes. Or need user
invention/decision based on information from a procedure before current
step...
As a example the way grub install is handled by old arch-installer (AIF
does this a little other): We have to ask about root/boot devices to
generate a matching menu.lst file. This file is presented to the user
again to have a look or change something. From the point that the user
may have changed something some/most informations must be asked again
(or be parsed from the changed menu.lst file).

Main problem IMHO is: a today installer doesn't know at the beginning
with what information it will conclude at the end. So each needed
information for a step has to be asked/determined before this step.


K.I.S.S me...
=================
A today installer is hand-holding the user. It must be. From the user
side the installer is the first tool he normally see from a
distribution. How good he/she "feels" during this process, this often
make a pro or contra later. The user - as a !Master! - means: I could
work well with this installer, it does all what i want. First mistake!
It's always the user that makes what the installer wants. That's the
nature of this special piece oft software: It has a very restricted
environment and its only goal is: install a working system. From a
installer view the user is the obstructive part - only needed to give
some information. To get those the installer feeds the user: give him
nice varicoloured output, some play music or nice balls are wandering
from the left to the right in progress bars... Meanwhile the installer
must take care that the user make only one step left or one step right -
but not two steps...

In the "older days" installers - from users side - tend to be complex
software; these days the trend is to keep the user off from the
technical base behind the process of setup a base system. "5 clicks to
get xyz ready to run..", "Full featured linux in 15 minutes - only 3
questions"... and so on. The result - we know this - are the
full-bloated systems where in fact the distributions determine most of
the users system.

... we are frogs!
=================
During last images build and bugfixing i thought a lot about this. I
know that our "old Devs" always prefer quickinst from old arch-installer
package. Now coming familar with AIF, myself look most times and primary
on the interactive part; but doing some work with automatic install
scripts IMHO there is more potential than with quickinst.

So my question: Am i totally wrong with my thoughts and - if not - have
we the pluck to confront the user with... an text editor?

Take a breath before hit Reply key... ;-)

First: The above mentioned aif scripts are not the answer - syntax,
presentation and documentation are more the "proof-concept" to look for
answers.

Pros & Contras
==================

1. Making the settings for installation in a control file gives not that
pressure to the user what a User-Interface(UI) based installer has.
Working with this file ("editing") does not any bad things. Look for ex.
on the grub part currently in interactive AIF: The user is confronted in
this step with questions in a very isolated manner. This step is very
interdependent from the previous blockdevice setup - but these
information's were entered before 10 minutes and out-of-users-sight in
this step. In a editor all information is easy browseable and
corrections could make at any point.
IMHO a pro.

2. Install information could be saved at any time to external place by
the user - or come complete from external medium. Currently our install
procedure has to be restarted every time if the user got "stucked" in
one step, or canceled the process, or when the installer has a bug. Most
(and so in fact all) informations have to be re-entered...
Think further about the capabilities: We (and the community) could offer
templates for nearly each installation setup - without the need to bring
this in a UI...
If one has the idea to write a web-based interface to generate such
installation control file - why not?
IMHO a pro.

3. On the road to 2009.08 (and AIF) many of reported problems were UI
related problems. Such things like "Cursor not automatically placed in
Menu xyz". But also during the grub refactoring we have seen: to get
feature or procedure X to work we must have here a new dialog, and there
we have to change a other dialog... and so on.
I guess on most interactive programs the UI-based part is the biggest
part. And often the part with the most possible bugs.
Current interactive AIF hast 2 UIs: the ncurses dialog based and a pure
read/print based one. Ok, we will never ever have a graphical installer,
but we hear often: why do you use such a "antique" UI? And in fact: Most
today machines/environments could handle a graphically installer and
also modern frameworks give even better widgets to interact with the
user... But: Another UI gives potential more bugs and needs more
manpower which could be better used to make the "base" more stable.
If we use the control file based install we get rid off from such
discussions of the "neatest" installer... And IMHO the step away from
"how the others do it" could make us very modern...
IMHO a pro.

4. Yes, i have a contra... Control files/variables tend to be not very
self-explanation. For example take the current syntax for blockdevice
setup:
--------------
GRUB_DEVICE=/dev/sda
PARTITIONS='/dev/sda 100:ext2:+ 512:swap *:ext4'
BLOCKDATA='/dev/sda1 raw no_label
ext2;yes;/boot;target;no_opts;no_label;no_params
/dev/sda2 raw no_label
swap;yes;no_mountpoint;target;no_opts;no_label;no_params
/dev/sda3 raw no_label ext4;yes;/;target;no_opts;no_label;no_params'
-------------
Here we have to invest a lot of work to bring such a syntax to the user
in a better way. But on such complex steps i could imagine on "helper
applications". Maybe a similar dialog-based we currently use in
interactive AIF. But instead to "feed" a installer with this
informations this helper produces for ex. the BLOCKDATA string for above
control file.
The user then import this generated piece into the editor.
Similar helper could be one for timezone strings; all information a user
normally not know by rote and so must be "picked" from a list.
IMHO: if we make this good, the contra could went to a pro - cause at
the end the user has still a (correctly) control file to start
installation.

Read until here....?
=======================
Wow. Yes, I'm really thinking (and like to discuss) about a work-flow:
a) User boots the image, login.
b) Select/start a text editor with a base control file or select one of
the other pre-defined control files.
c) Edit his settings in this control file
d) Uses the other tty's for getting infos, start helpers. Helper output
he could load into the current control file editor.
e) After "editing the setup" he could save it extern and come back later
or
f) start the installation. No interaction is needed after this (Ok,
before fdisk'ing and formatting we should make a "break and review").
g) Base system is installed - user is happy... Cookies and taccos...

What do you think? Of course, this is nothing for the next images... 
It's a massive U-turn against the main stream, but at the end IMHO the
benefits could be great - KISS like...

These are only my personal thoughts as a releng member, no position of
"official politic".

And now: Fire at will! ;-)

Regards
	Gerhard


[1]
http://github.com/Dieterbe/aif/blob/2ef92eaa5f1106d8f1b379a8a94a477a0877bb1f/examples/generic-install-on-sda
[2]
http://github.com/Dieterbe/aif/blob/2ef92eaa5f1106d8f1b379a8a94a477a0877bb1f/examples/fancy-install-on-sda